]> Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG

Grenoble 38000 FR maxence.flechier@univ-grenoble-alpes.fr

Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG

martin.heusse@univ-grenoble-alpes.fr

Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG

andrzej.duda@univ-grenoble-alpes.fr

General Internet Engineering Task Force BGP, PATHSEC, DNS 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.

Introduction The Border Gateway Protocol 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 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 are incidents in which an announcement is propagated outside of its intended scope. Proposed solutions like BGPsec , OTC and the use of a Large Community offer limited solutions to these issues. ASPA 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) . PAth VAlidation (PAVA) aims to improve PATHSEC while supporting any kind of AS peering relationships as defined in 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 . The valley-free rule guarantees protection against route leaks whereas the queried ASes guarantee protection against path forgeries.

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 when, and only when, they appear in all capitals, as shown here.

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

PAVA Operations

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 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.

Validating AS Operations

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. Queries resulting in a DNS error or without any answer after a reasonable time, are attributed the UNKNOWN status.

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 . |Descending|--┐DOWN └->+---------+ +----------+<-┘ | |End | | | └------------------|-┐ | ERROR| | | |End | ERROR|SUMMIT|UP | | | | ┌-------------------┘ | | v v v v +-------+ +-----+ |Invalid| |Valid| +-------+ +-----+ ]]>

DNS Operations

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 ). 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)
• ERROR: any other case

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.

Complementarity of PAVA with Other Proposals

BGPsec BGPsec, defined in , 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.

OTC Only-To-Customer is a BGP attribute shared with BGP Open messages defined in . 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.

ASPA Current work on AS_PATH Verification based on Autonomous System Provider Authorization (ASPA) 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.

ASRA Efforts for AS_PATH Verification based on Autonomous System Relationship Authorization (ASRA) in 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.

IANA Considerations This document uses a second-level new special domain bgp.arpa

Security Considerations PAVA is subject to the following security issues and concerns. PAVA also aims to follow security requirements provided in .

• 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.

References Normative References Informative References

Acknowledgements

Contributors Thanks to all of the contributors. Grenoble INP

sebastien.viardot@grenoble-inp.fr

Huawei

junzhang1@huawei.com

Huawei

houda.labiod@huawei.com