Internet Engineering Task Force M. Flechier Internet-Draft M. Heusse Intended status: Experimental A. Duda Expires: 3 September 2026 Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG 2 March 2026 PAVA: BGP AS_PATH Validation by Querying ASes about Their Relationships draft-flechier-sidrops-pava-01 Abstract This document defines PAth VAlidation (PAVA), a scheme for validating the Border Gateway Protocol (BGP) AS_PATH field based on the AS relationships. Validation is performed by sending queries to the ASes along the path, each query containing information about the prefix and the relevant path segment. We implement querying the ASes in a path with a system relying on Domain Name System (DNS) and DNSSEC. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Flechier, et al. Expires 3 September 2026 [Page 1] Internet-Draft PAVA March 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology and List of Acronyms . . . . . . . . . . . . . . 3 4. PAVA Operations . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Validating AS Operations . . . . . . . . . . . . . . . . 4 4.2.1. DNS Queries . . . . . . . . . . . . . . . . . . . . . 4 4.2.2. Path Verification . . . . . . . . . . . . . . . . . . 5 4.3. DNS Operations . . . . . . . . . . . . . . . . . . . . . 5 4.3.1. Segment Status . . . . . . . . . . . . . . . . . . . 5 4.3.2. Zone File Creation . . . . . . . . . . . . . . . . . 6 5. Complementarity of PAVA with Other Proposals . . . . . . . . 6 5.1. BGPsec . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. OTC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. ASPA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. ASRA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The Border Gateway Protocol [RFC4271] is not secure by design. However, the evolving context of the Internet brings the need to enhance its security, reflected in several schemes advanced along the years. Path Security (PATHSEC), conceptualized in [RFC7132] brings the need to secure the AS_PATH of BGP Update announcements to protect against vulnerabilities such as path hijacks and route leaks. Path hijacks are attacks that alter an AS_PATH, and route leaks as per [RFC7908] are incidents in which an announcement is propagated outside of its intended scope. Proposed solutions like BGPsec [RFC8205], OTC [RFC9234] and the use of a Large Community Flechier, et al. Expires 3 September 2026 [Page 2] Internet-Draft PAVA March 2026 [I-D.ietf-grow-route-leak-detection-mitigation] offer limited solutions to these issues. ASPA [I-D.ietf-sidrops-aspa-verification] is the best answer but has limited coverage in cases of complex relationships and needs up-to-date information in an often external repository constituted by the Resource Public Key Infrastructure (RPKI) [RFC6480]. PAth VAlidation (PAVA) aims to improve PATHSEC while supporting any kind of AS peering relationships as defined in [RFC9234] as well as any complex relationship configuration. Moreover, PAVA allows to keep the control of relationship information directly under the AS governance and responsibility. To this aim, PAVA carries out sequential queries targeting the ASes that appear in the AS_PATH and combines the answers to assess its validity. Each individual AS discloses only partial information about its immediate neighbors. In the validation step, PAVA verifies that all pairs of ASes in the AS_PATH are effectively neighbors and that the path is valley-free [Gao]. The valley-free rule guarantees protection against route leaks whereas the queried ASes guarantee protection against path forgeries. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology and List of Acronyms The following abbreviations are used. C2P: Customer to Provider relationship P2C: Provider to Customer relationship P2P: Peer to Peer relationship 4. PAVA Operations Flechier, et al. Expires 3 September 2026 [Page 3] Internet-Draft PAVA March 2026 4.1. Principles There are two parts in PAVA: the first one is the distribution of information related to AS relationships along a path and for a given destination prefix; the second one is the validation of the AS_PATH. The more information is available along a path, the more effective is the validation process, although partial deployment and adoption still offer partial verification. Information distribution in PAVA relies on the deployment of DNS servers that share information pertaining to the local relationships of an AS with its neighbors. The information is relatively static and takes the form of a DNS zone file. The verification of an AS_PATH comprises of cutting the AS_PATH in tiled segments of 3 ASes. The DNS server associated with the central AS in each triplet is in charge of providing an answer. The validating process compiles the received answers to determine the validity of the AS_PATH. The verifying algorithm checks if the AS_PATH is valley-free [Gao] to prevent route leaks and path hijackings. The validator verifies that the list of answers is such that the relationships are first ascending with consistent C2P (up) and then descending with P2C (down), with possibly P2P between the asending and descending parts. 4.2. Validating AS Operations 4.2.1. DNS Queries The AS_PATH is split into tiled segments of 3 unique ASN such that each AS in the AS_PATH is at the center of a triplet. The end segments are made of only 2 ASes (e.g. an AS_PATH of [4 3 2 1 1 1] corresponds to 4 segments [4 3], [4 3 2], [3 2 1] and [2 1]). The validator generates a DNS query for each triplet, to which adopting ASes SHOULD answer with a status among UP, DOWN, SUMMIT, or ERROR. The validating AS compiles the answers into a list of status for the verification step. The DNS query is of the following form: [Prefix].[AS3].[AS1].[AS2].bgp.arpa, where the Prefix corresponds to the prefix of the NLRI field from the BGP Update being verified, and AS1, AS2, and AS3 correspond to the ASes in the segment [3 2 1] at stakes. All fields are encoded in plaintext. Flechier, et al. Expires 3 September 2026 [Page 4] Internet-Draft PAVA March 2026 Queries resulting in a DNS error or without any answer after a reasonable time, are attributed the UNKNOWN status. 4.2.2. Path Verification The finite state machine below processes the list of gathered status in the order of announcement propagation, that is in reverse from the AS_PATH order. The finite state machine decides on the outcome of the verification, either valid or invalid, in the sense of route eligibility as defined in [RFC4271]. Start | v +---------+ SUMMIT|DOWN +----------+ UP┌--|Ascending|------------->|Descending|--┐DOWN └->+---------+ +----------+<-┘ | |End | | | └------------------|-┐ | ERROR| | | |End | ERROR|SUMMIT|UP | | | | ┌-------------------┘ | | v v v v +-------+ +-----+ |Invalid| |Valid| +-------+ +-----+ 4.3. DNS Operations 4.3.1. Segment Status A segment of three ASes alongside a prefix forms a PAVA tuple ([3 2 1], prefix). The return status for a tuple depends on the BGP topology relationships (the relationships follow common definitions as used in [RFC9234]). This status SHOULD be adapted in cases of complex relationships. The use of a prefix provides flexibility and fine-tuning in definining a status. The status MUST be one of UP, DOWN, SUMMIT, ERROR. The status is defined as such, following the pairwise relationships in the segment (AS3-AS2, AS2-AS1): * SUMMIT: (C2P, P2P), (C2P, P2P) * UP: (C2P, C2P) * DOWN: (P2P, P2C), (P2C, P2C) Flechier, et al. Expires 3 September 2026 [Page 5] Internet-Draft PAVA March 2026 * ERROR: any other case 4.3.2. Zone File Creation PAVA uses the TXT Resource Record (RR) to store its status. An AS implementing PAVA SHOULD create a master file corresponding to its zone listing any possible segment it knows to be part of, with the answer as a status corresponding to said segment. The use of wildcards MAY be useful to limit the size of the generated master file. 5. Complementarity of PAVA with Other Proposals 5.1. BGPsec BGPsec, defined in [RFC8205], allows cryptographic verification of BGP paths by means of recursive signatures of the path. BGPSec prevents attacks that alter the AS path but does not cope with route leaks, and adds burden to the routers with cryptographic operations. Furthermore, it does not tolerate partial deployment. 5.2. OTC Only-To-Customer is a BGP attribute shared with BGP Open messages defined in [RFC9234]. OTC prevents route leaks in BGP sessions and is a great way to mitigate them. It however does not offer any additional PATHSEC mechanism, which means that ASes need to trust BGP Update messages. It does not prevent path forgeries. 5.3. ASPA Current work on AS_PATH Verification based on Autonomous System Provider Authorization (ASPA) [I-D.ietf-sidrops-aspa-verification] brings similar security guarantees as PAVA. ASPA protects against simple path forgeries and route leaks and relies on the RPKI which is already widely used for Route Origin Authorization (ROA). However, ASPA handles complex relationships through the blanket of labelling any as a Provider to Provider relationship. In contrast, PAVA addresses those relationships through per-destination prefix verifications, which allows fine-tuning and flexibility. The two approaches are also be complementary, providing different information that can be used to achieve further verification. Flechier, et al. Expires 3 September 2026 [Page 6] Internet-Draft PAVA March 2026 5.4. ASRA Efforts for AS_PATH Verification based on Autonomous System Relationship Authorization (ASRA) in [I-D.sriram-sidrops-asra-verification] aims at obviating some vulnerabilities of ASPA by publishing every relationship an AS has instead of just its providers. ASRA helps further detecting complex path forgeries like PAVA but like ASPA, it does not focus on handling complex relationships, but can provide additional information to work with PAVA. 6. IANA Considerations This document uses a second-level new special domain bgp.arpa 7. Security Considerations PAVA is subject to the following security issues and concerns. PAVA also aims to follow security requirements provided in [RFC7353]. * Relying on the DNS infrastructure means being exposed to security issues from DNS and DNSSEC, be it protocol vulnerabilities or attacks like distributed denial of service (DDoS). * The DNS system used to provide information may also disclose routing interests from some ASes. This is limited through the use of status that recover several cases, but in-depth analysis of a massive number of queries could reveal more information than intended. * Partial deployment means partial information and as such, verification can not be completely thorough unless every AS in the path has adopted PAVA. As such, partial deployment only provides partial security. * The system relies on the information provided by the ASes. Incorrect information can result in incorrect verification of the AS_PATH. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Flechier, et al. Expires 3 September 2026 [Page 7] Internet-Draft PAVA March 2026 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, . [RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security Requirements for BGP Path Validation", RFC 7353, DOI 10.17487/RFC7353, August 2014, . [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Sriram, "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages", RFC 9234, DOI 10.17487/RFC9234, May 2022, . [I-D.ietf-sidrops-aspa-verification] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa- verification-24, 19 October 2025, . Flechier, et al. Expires 3 September 2026 [Page 8] Internet-Draft PAVA March 2026 [I-D.sriram-sidrops-asra-verification] Sriram, K., Geng, N., and A. Herzberg, "Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification", Work in Progress, Internet-Draft, draft-sriram-sidrops-asra-verification-03, 3 November 2025, . [I-D.ietf-grow-route-leak-detection-mitigation] Sriram, K. and A. Azimov, "Methods for Detection and Mitigation of BGP Route Leaks", Work in Progress, Internet-Draft, draft-ietf-grow-route-leak-detection- mitigation-12, 25 February 2025, . 8.2. Informative References [Gao] Gao, L. and J. Rexford, "Stable Internet routing without global coordination", 2001. Acknowledgements Contributors Thanks to all of the contributors. Sebastien Viardot Grenoble INP Email: sebastien.viardot@grenoble-inp.fr Jun Zhang Huawei Email: junzhang1@huawei.com Houda Labiod Huawei Email: houda.labiod@huawei.com Authors' Addresses Flechier, et al. Expires 3 September 2026 [Page 9] Internet-Draft PAVA March 2026 Maxence Flechier Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG 38000 Grenoble France Email: maxence.flechier@univ-grenoble-alpes.fr Martin Heusse Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG Email: martin.heusse@univ-grenoble-alpes.fr Andrzej Duda Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG Email: andrzej.duda@univ-grenoble-alpes.fr Flechier, et al. Expires 3 September 2026 [Page 10]