| Internet-Draft | PAVA | July 2026 |
| Flechier, et al. | Expires 7 January 2027 | [Page] |
This document defines PAth VAlidation (PAVA), a scheme for validating the Border Gateway Protocol (BGP) AS_PATH field based on the AS relationships. Validation involves sending queries to the ASes along the path and each query specifies information about the prefix and the relevant path segment. In this draft, for the decentralized distribution system that ASes on a path need for distributing the information, we propose to use the Domain Name System (DNS) and DNSSEC.¶
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 7 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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 [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 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.¶
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.¶
The following abbreviations are used.¶
PAVA consists of two parts. 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 a decentralized distribution service. Here, the proposal is to use the DNS, but another service could be used. With DNS, the deployment involves 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 one P2P relationship between the asending and descending parts.¶
The AS_PATH is first shrunk such that consecutive identical ASNs become a single ASN. This helps because practices such as AS_PATH prepending are irrelevent to PAVA operations. The resulting 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 segment, 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].pava.[authority]¶
Where 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. The authority corresponds to the [RFC3986] definition. All fields are encoded in plaintext.¶
Queries resulting in a DNS error or without any answer after a reasonable time, are attributed the UNKNOWN status.¶
The authority is known through storage within a dedicated object in the RPKI. Each participating AS MUST publish its authority to the RPKI. Reachability is otherwise not achievable. This object will be defined in a future related draft.¶
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|
+-------+ +-----+
¶
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):¶
PAVA uses the TXT Resource Record (RR) to store its status. An AS implementing PAVA SHOULD create a master file corresponding to its zone that lists any possible segment it knows to be part of, with the answer as a status corresponding to said segment. The use of wildcards is recommended to limit the size of the generated master file. Otherwise a dynamic DNS server handling requests could be used to keep constant control over the state of the AS connections, but would require low latency and high performance as well as a continuous bridge with the BGP control plane of the AS.¶
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.¶
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.¶
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 them as a Provider to Provider relationship. In contrast, PAVA addresses complex relationships through per-destination prefix verification, which allows fine-tuning and flexibility. The two approaches are also complementary, providing different information that can be used to achieve further verification: in fact, ASPA relationships are directly usable for PAVA verification.¶
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 just like ASPA, it does not allow handling complex relationships. Similarly to ASPA, ASRA data is a direct input for PAVA verification.¶
This document has no IANA actions.¶
PAVA is subject to the following security issues and concerns. PAVA also aims to follow security requirements provided in [RFC7353].¶
Thanks to all of the contributors.¶