PAVA: BGP AS_PATH Validation by Querying ASes about Their Relationships
draft-flechier-sidrops-pava-02

Internet Engineering Task Force                              M. Flechier
Internet-Draft                                                 M. Heusse
Intended status: Experimental                                    A. Duda
Expires: 7 January 2027    Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
                                                             6 July 2026

PAVA: BGP AS_PATH Validation by Querying ASes about Their Relationships
                     draft-flechier-sidrops-pava-02

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

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

Copyright Notice

   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

Flechier, et al.         Expires 7 January 2027                 [Page 1]
Internet-Draft                    PAVA                         July 2026

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

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

Flechier, et al.         Expires 7 January 2027                 [Page 2]
Internet-Draft                    PAVA                         July 2026

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

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

4.1.  Principles

   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

Flechier, et al.         Expires 7 January 2027                 [Page 3]
Internet-Draft                    PAVA                         July 2026

   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.

4.2.  Validating AS Operations

4.2.1.  DNS Queries

   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.

Flechier, et al.         Expires 7 January 2027                 [Page 4]
Internet-Draft                    PAVA                         July 2026

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)

   *  ERROR: any other case

Flechier, et al.         Expires 7 January 2027                 [Page 5]
Internet-Draft                    PAVA                         July 2026

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

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

Flechier, et al.         Expires 7 January 2027                 [Page 6]
Internet-Draft                    PAVA                         July 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 just like ASPA, it does not allow
   handling complex relationships.  Similarly to ASPA, ASRA data is a
   direct input for PAVA verification.

6.  IANA Considerations

   This document has no IANA actions.

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,
              <https://www.rfc-editor.org/info/rfc2119>.

Flechier, et al.         Expires 7 January 2027                 [Page 7]
Internet-Draft                    PAVA                         July 2026

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [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,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC7132]  Kent, S. and A. Chi, "Threat Model for BGP Path Security",
              RFC 7132, DOI 10.17487/RFC7132, February 2014,
              <https://www.rfc-editor.org/info/rfc7132>.

   [RFC7353]  Bellovin, S., Bush, R., and D. Ward, "Security
              Requirements for BGP Path Validation", RFC 7353,
              DOI 10.17487/RFC7353, August 2014,
              <https://www.rfc-editor.org/info/rfc7353>.

   [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, <https://www.rfc-editor.org/info/rfc7908>.

   [RFC8205]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
              Specification", RFC 8205, DOI 10.17487/RFC8205, September
              2017, <https://www.rfc-editor.org/info/rfc8205>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc9234>.

Flechier, et al.         Expires 7 January 2027                 [Page 8]
Internet-Draft                    PAVA                         July 2026

   [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-25, 19 April 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-verification-25>.

   [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-04,
              15 May 2026, <https://datatracker.ietf.org/doc/html/draft-
              sriram-sidrops-asra-verification-04>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-grow-
              route-leak-detection-mitigation-12>.

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

Flechier, et al.         Expires 7 January 2027                 [Page 9]
Internet-Draft                    PAVA                         July 2026

   Houda Labiod
   Huawei
   Email: houda.labiod@huawei.com

Authors' Addresses

   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 7 January 2027                [Page 10]