Skip to main content

BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects
draft-ietf-sidrops-aspa-verification-18

Document Type Active Internet-Draft (sidrops WG)
Authors Alexander Azimov , Eugene Bogomazov , Randy Bush , Keyur Patel , Job Snijders , Kotikalapudi Sriram
Last updated 2024-07-08
Replaces draft-azimov-sidrops-aspa-verification
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Chris Morrow
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to morrowc@ops-netman.net
draft-ietf-sidrops-aspa-verification-18
Network Working Group                                          A. Azimov
Internet-Draft                                                    Yandex
Intended status: Standards Track                            E. Bogomazov
Expires: 9 January 2025                                      Qrator Labs
                                                                 R. Bush
                                                            IIJ & Arrcus
                                                                K. Patel
                                                                  Arrcus
                                                             J. Snijders
                                                                  Fastly
                                                               K. Sriram
                                                                USA NIST
                                                             8 July 2024

      BGP AS_PATH Verification Based on Autonomous System Provider
                      Authorization (ASPA) Objects
                draft-ietf-sidrops-aspa-verification-18

Abstract

   This document describes procedures that make use of Autonomous System
   Provider Authorization (ASPA) objects in the Resource Public Key
   Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP)
   AS_PATH attribute of advertised routes.  This type of AS_PATH
   verification provides detection and mitigation of route leaks and
   some forms of AS path manipulation.  It also provides protection, to
   some degree, against prefix hijacks with forged-origin or forged-
   path-segment.

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 9 January 2025.

Azimov, et al.           Expires 9 January 2025                 [Page 1]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

Copyright Notice

   Copyright (c) 2024 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology and List of Acronyms  . . . . . . . . . . . . . .   4
   4.  Autonomous System Provider Authorization  . . . . . . . . . .   4
   5.  ASPA Registration Recommendations . . . . . . . . . . . . . .   5
   6.  Provider Authorization Function . . . . . . . . . . . . . . .   6
   7.  AS_PATH Verification  . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Principles  . . . . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Algorithm for Upstream Paths  . . . . . . . . . . . . . .   8
     7.3.  Algorithm for Downstream Paths  . . . . . . . . . . . . .   9
     7.4.  Mitigation Policy . . . . . . . . . . . . . . . . . . . .   9
   8.  Deployment Recommendations  . . . . . . . . . . . . . . . . .  10
     8.1.  Application of Verification Procedures  . . . . . . . . .  10
     8.2.  BGP Roles . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.3.  Complex Peering Relationships . . . . . . . . . . . . . .  10
     8.4.  Logging . . . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     9.1.  Difference in IPv4 and IPv6 Connectivity  . . . . . . . .  11
     9.2.  Provider as Trusted Point . . . . . . . . . . . . . . . .  11
     9.3.  Manipulating AS_PATH Prepends . . . . . . . . . . . . . .  12
     9.4.  Correctness of the ASPA . . . . . . . . . . . . . . . . .  12
   10. Comparison to Other Technologies  . . . . . . . . . . . . . .  12
     10.1.  BGPsec . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.2.  Peerlock . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.3.  Only to Customer (OTC) Attribute . . . . . . . . . . . .  13
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   12. Implementation Status . . . . . . . . . . . . . . . . . . . .  13
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     13.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  17
   Appendix B.  Properties and Early Adoption Benefits . . . . . . .  18

Azimov, et al.           Expires 9 January 2025                 [Page 2]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   The Border Gateway Protocol (BGP) as originally designed is known to
   be vulnerable to prefix (or route) hijacks and BGP route leaks
   [RFC7908].  Some existing BGP extensions can partially solve these
   problems.  For example, Resource Public Key Infrastructure (RPKI)
   based route origin validation (RPKI-ROV) [RFC6480] [RFC6482]
   [RFC6811] [RFC9319] can be used to detect and filter accidental mis-
   originations.  [RFC9234] or
   [I-D.ietf-grow-route-leak-detection-mitigation] can be used to detect
   and mitigate accidental route leaks.  While RPKI-ROV can prevent
   accidental prefix hijacks, malicious forged-origin prefix hijacks can
   still occur [RFC9319].  RFC9319 includes some recommendations for
   reducing the attack surface for forged-origin prefix hijacks.

   This document describes procedures that make use of Autonomous System
   Provider Authorization (ASPA) objects [I-D.ietf-sidrops-aspa-profile]
   in the RPKI to verify properties of the BGP AS_PATH attribute of
   advertised routes.  ASPA-based AS_PATH verification provides
   detection and mitigation of route leaks.  It also provides
   protection, to some degree, against prefix hijacks with forged-origin
   or forged-path-segment (Appendix B).  These new ASPA-based procedures
   automatically detect such anomalous AS_PATHs in BGP Updates that are
   advertised between ASes.

   Both route leaks and hijacks have similar effects on ISP operations.
   They redirect traffic and can result in denial of service (DoS),
   eavesdropping, increased latency, and packet loss.  The level of
   risk, however, depends significantly on the extent of propagation of
   the anomalies.  For example, a route leak or hijack that is
   propagated only to customers may cause bottlenecking within an ISP's
   customer cone, but if the anomaly propagates through lateral (i.e.,
   non-transit) peers or transit providers, then the ill effects will
   likely be amplified and may be experienced worldwide.

   The ability to constrain the propagation of BGP anomalies to transit
   providers and lateral peers -- without requiring support from the
   source of the anomaly (which is critical if the source has malicious
   intent) -- should significantly improve the robustness of the global
   inter-domain routing system.

Azimov, et al.           Expires 9 January 2025                 [Page 3]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

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 terms are used with special meanings.

   Route is ineligible:  The term has the same meaning as in [RFC4271],
      i.e., "route is ineligible to be installed in Loc-RIB and will be
      excluded from the next phase of route selection."

   CAS:  Customer AS ([I-D.ietf-sidrops-aspa-profile], Section 1).

   PAS:  Provider AS ([I-D.ietf-sidrops-aspa-profile], Section 1).

   SPAS:  Set of Provider ASes ([I-D.ietf-sidrops-aspa-profile],
      Section 3).

   For path verification purposes in this document, the peering
   relationships an AS can have in relation to a neighbor AS are
   Customer, Provider, Peer, Route Server (RS), RS-client, and Complex.
   These peering relationships are defined in [RFC9234].  A special case
   of the Complex relation is mutual-transit when ASes MAY export
   everything (both customer and non-customer routes) to each other,
   i.e., customer-to-provider relationship applies in each direction.
   All peering relationships are defined locally.

4.  Autonomous System Provider Authorization

   An ASPA record is a digitally signed object that binds a set of PAS
   numbers to a CAS number and is signed by the CAS
   [I-D.ietf-sidrops-aspa-profile].  The ASPA attests that the CAS
   indicated a Set of Provider ASes (SPAS), which applies only to the
   IPv4 and IPv6 address families (i.e., AFI = 1 and AFI = 2) and only
   to Network Layer Reachability Information used for unicast forwarding
   (SAFI = 1).

   The notation (AS x, {AS y1, AS y2, ...}), is used to represent an
   ASPA object for a CAS denoted as AS x
   [I-D.ietf-sidrops-aspa-notation].  In this notation, the comma-
   separated set {AS y1, AS y2, ...} represents the Set of Provider ASes
   (SPAS) of the CAS (AS x).  A CAS is expected to register a single
   ASPA listing all its Provider ASes (see Section 5).  If a CAS has a

Azimov, et al.           Expires 9 January 2025                 [Page 4]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   single cryptographically valid ASPA, then the Union SPAS (U-SPAS) for
   the CAS equals to SPAS.  In case a CAS has multiple cryptographically
   valid ASPAs, then the U-SPAS for the CAS is the union of AS listed in
   all SPAS of these ASPAs.

5.  ASPA Registration Recommendations

   A compliant AS or Route Server AS (RS AS) MUST have an ASPA.  An AS
   SHOULD NOT have more than one ASPA.  An AS MUST list in its SPAS the
   union of all its Provider AS(es) and non-transparent RS AS(es) at
   which it is an RS-client.  An AS MUST include a Provider AS in its
   SPAS regardless of whether it provides connectivity for only IPv4 or
   only IPv6 or both.

   An ASPA object showing only AS 0 as a provider AS is referred to as
   an AS0 ASPA.  A non-transparent Route Server AS (RS AS) is one that
   includes its AS number in the AS_PATH.  Registering as AS0 ASPA is a
   statement by the registering AS that it has no transit providers, and
   it is also not an RS-client at a non-transparent RS AS.  If that
   statement is true, then the AS MUST register an AS0 ASPA.

   A compliant AS SHOULD register a single ASPA object.  A single ASPA
   record for an AS ought to prevent race conditions during ASPA updates
   that might affect prefix propagation.  The software that provides
   hosting for ASPA records SHOULD support enforcement of this practice.

   An AS may have providers that may be used on certain occasions, for
   an example in case of a DDoS attack.  It is RECOMMENDED to add such
   providers in ASPA in advance, so there will be no race conditions
   between ASPA distribution and route propagation.

   During a transition process between different certificate authority
   (CA) registries, the ASPA records SHOULD be kept identical in all
   relevant registries.

   Normally, a U-SPAS (see Section 4) is not expected to contain both an
   AS 0 and other Provider ASes, but an unexpected presence of AS 0 has
   no influence on the AS path verification procedures (see Section 6,
   Section 7).

   In the Complex relationship case (Section 3), an AS MUST include the
   neighbor AS in its SPAS if neighbor plays Provider role for a subset
   of received or sent prefixes.  Each of the two ASes in a mutual-
   transit pair MUST register its ASPA including the other AS in its
   SPAS.

   The ASes on the boundary of an AS Confederation MUST register ASPAs
   using the Confederation's global AS number (ASN) as the CAS.

Azimov, et al.           Expires 9 January 2025                 [Page 5]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

6.  Provider Authorization Function

   Let AS x and AS y represent two unique ASes.  A provider
   authorization function, authorized(AS x, AS y), checks if the ordered
   pair of ASNs, (AS x, AS y), has the property that AS y is an attested
   provider of AS x per U-SPAS of AS x.  By term "Provider+" the
   function should signal if AS y plays role of Provider, non-
   transparent RS, or mutual-transit neighbor.  This function is
   specified as follows:

                              /
                              | "No Attestation" if there is no entry
                              |   in U-SPAS table for CAS = AS x
                              |
   authorized(AS x, AS y) =  / Else, "Provider+" if the U-SPAS entry
                              \   for CAS = AS x includes AS y
                              |
                              | Else, "Not Provider+"
                              \

                 Figure 1: Provider authorization function.

   The "No Attestation" result is returned only when no ASPA is
   retrieved for the CAS or none of its ASPAs are cryptographically
   valid.  The provider authorization function is used in the ASPA-based
   AS_PATH verification algorithms described in Section 7.2 and
   Section 7.3.

7.  AS_PATH Verification

   The procedures described in this document are applicable only to
   four-octet AS number compatible BGP speakers [RFC6793].  If such a
   BGP speaker receives both AS_PATH and AS4_PATH attributes in an
   UPDATE, then the procedures are applied on the reconstructed AS path
   (Section 4.2.3 of [RFC6793]).  So, the term AS_PATH is used in this
   document to refer to the usual AS_PATH [RFC4271] as well as the
   reconstructed AS path.

   If an attacker creates a route leak intentionally, they may try to
   strip their AS from the AS_PATH.  To partly guard against that, a
   check is necessary to match the most recently added AS in the AS_PATH
   to the BGP neighbor's ASN.  This check MUST be performed as specified
   in Section 6.3 of [RFC4271].  If the check fails, then the AS_PATH is
   considered a Malformed AS_PATH and the UPDATE is considered to be in
   error (Section 6.3 of [RFC4271]).  The case of transparent RS MUST
   also be appropriately taken care of (e.g., by suspending the neighbor
   ASN check).  If the AS_PATH is empty (zero length), then also the
   UPDATE is considered to be an error.

Azimov, et al.           Expires 9 January 2025                 [Page 6]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   [I-D.ietf-idr-deprecate-as-set-confed-set] specifies that "treat-as-
   withdraw" error handling [RFC7606] SHOULD be applied to routes with
   AS_SET in the AS_PATH.  In the current document, routes with AS_SET
   are given Invalid evaluation in the AS_PATH verification procedures
   (Section 7.2 and Section 7.3).  See Section 7.4 for how routes with
   Invalid AS_PATH are handled.

7.1.  Principles

   Let the sequence {AS(N), AS(N-1),..., AS(2), AS(1)} represent the
   AS_PATH in terms of unique ASNs, where AS(1) is the origin AS and
   AS(N) is the most recently added AS and neighbor of the receiving/
   verifying AS.  N is the length of the received AS_PATH in unique
   ASes.  Let AS(N+1) represent the receiving/verifying AS.

                      AS(L) ............. AS(K)
                       /                     \
                   AS(L+1)                  AS(K-1)
                      .                       .
                     .                         .
      (down-ramp)   .                           .  (up-ramp)
                   .                             .
                  .                               .
                AS(N-1)                          AS(2)
                  /                                \
               AS(N)                               AS(1)
                /                                (Origin AS)
      Receiving & verifying AS (AS(N+1))
             (Customer)

          Each ramp has consecutive customer-to-provider hops in the bottom-to-top direction

           Figure 2: Illustration of up-ramp and down-ramp.

   The AS_PATH may in general have both an up-ramp (on the right
   starting at AS(1)) and a down-ramp (on the left starting at AS(N)).
   The up-ramp starts at AS(1) and each hop AS(i) to AS(i+1) represents
   Customer and Provider peering relationship.  The down-ramp runs
   backward from AS(N) to AS(L).  In the down-ramp, each pair AS(j) to
   AS(j-1) represents Customer and Provider peering relationship.  If
   there are no hops or just one hop between the apexes of the up-ramp
   and the down-ramp, then the AS_PATH is valid (valley free).

   If the sum of lengths of up-ramp and down-ramp is less than N, it is
   invalid: the prefix was leaked or AS_PATH was malformed.

Azimov, et al.           Expires 9 January 2025                 [Page 7]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   ASPA can be used to check if AS y is an attested provider of AS x,
   and thus the provider authorization function can be used to measure
   the bounds on up-ramp and down-ramp lengths.  The "Not Provider+"
   outcome of the provider authorization function can be used to
   calculate the upper boundary of ramp length and the 'No Attestation'
   outcome can be used to calculate its lower boundary.  Below are the
   formal definitions.

   Determine the maximum up-ramp length as I, where I is the minimum
   index for which authorized(A(I), A(I+1)) returns "Not Provider+".  If
   there is no such I, the maximum up-ramp length is set equal to the
   AS_PATH length N.  This parameter is defined as max_up_ramp.  The
   minimum up-ramp length can be determined as I, where I is the minimum
   index for which authorized(A(I), A(I+1)) returns "No Attestation" or
   "Not Provider+".  If there is no such I, the AS_PATH consists of only
   "Provider+" pairs; so the minimum up-ramp length is set equal to the
   AS_PATH length N.  This parameter is defined as min_up_ramp.

   Similarly, the maximum down-ramp length can be determined as N - J +
   1 where J is the maximum index for which authorized(A(J), A(J-1))
   returns "Not Provider+".  If there is no such J, the maximum down-
   ramp length is set equal to the AS_PATH length N.  This parameter is
   defined as max_down_ramp.  The minimum down-ramp length can be
   determined as N - J + 1 where J is the maximum index for which
   authorized(A(J), A(J-1)) returns "No Attestation" or "Not Provider+".
   If there is no such J, the minimum down-ramp length is set equal to
   the AS_PATH length N.  This parameter is defined as min_down_ramp.

   If the sum of max_up_ram and max_down_ramp is less than N, the AS
   path is Invalid.  Else, if the sum of min_up_ram and min_down_ramp is
   less than N, enough information is not available to perform full AS
   path verification, and the outcome is set to Unknown.  Else, the AS
   path is Valid.

   Below are formal procedures for path verification depending on the
   peering relationship between the receiving AS and its neighbour.
   These procedures use the compressed sequence representation of
   AS_PATH {AS(N), AS(N-1),..., AS(2), AS(1)} and the above-defined
   parameters max_up_ramp, min_up_ramp, max_down_ramp, and min_up_ramp

7.2.  Algorithm for Upstream Paths

   The upstream verification algorithm described here is applied when a
   route is received from a Customer or Peer, or is received by an RS
   from an RS-client, or is received by an RS-client from an RS.  In all
   these cases, the receiving/validating eBGP router expects the AS_PATH
   to have only an up-ramp (no down-ramp) for it to be Valid.
   Therefore, max_down_ramp and min_down_ramp are set to 0.

Azimov, et al.           Expires 9 January 2025                 [Page 8]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   The upstream path verification procedure is specified as follows:

   1.  If the AS_PATH is empty, then the procedure halts with the
       outcome "Invalid".

   2.  If the receiving AS is not an RS-client and the most recently
       added AS in the AS_PATH does not match the neighbor AS, then the
       procedure halts with the outcome "Invalid".

   3.  If the AS_PATH has an AS_SET, then the procedure halts with the
       outcome "Invalid".

   4.  If max_up_ramp < N, the procedure halts with the outcome
       "Invalid".

   5.  If min_up_ramp < N, the procedure halts with the outcome
       "Unknown".

   6.  Else, the procedure halts with the outcome "Valid".

7.3.  Algorithm for Downstream Paths

   The downstream verification algorithm described here is applied when
   a route is received from a Provider.

   1.  If the AS_PATH is empty, then the procedure halts with the
       outcome "Invalid".

   2.  If the most recently added AS in the AS_PATH does not match the
       neighbor AS, then the procedure halts with the outcome "Invalid".

   3.  If the AS_PATH has an AS_SET, then the procedure halts with the
       outcome "Invalid".

   4.  If max_up_ramp + max_down_ramp < N, the procedure halts with the
       outcome "Invalid".

   5.  If min_up_ramp + min_down_ramp < N, the procedure halts with the
       outcome "Unknown".

   6.  Else, the procedure halts with the outcome "Valid".

7.4.  Mitigation Policy

   The specific configuration of a mitigation policy based on AS_PATH
   verification using ASPA is at the discretion of the network operator.
   However, the following mitigation policy is highly recommended.

Azimov, et al.           Expires 9 January 2025                 [Page 9]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   *Invalid*: If the AS_PATH is determined to be Invalid, then the route
   SHOULD be considered ineligible for route selection (see Section 3)
   and MUST be kept in the Adj-RIB-In for potential future re-evaluation
   (see [RFC9324]).

   *Valid or Unknown*: When a route is evaluated as Unknown (using ASPA-
   based AS_PATH verification), it SHOULD be treated at the same
   preference level as a route evaluated as Valid.

8.  Deployment Recommendations

   This section describes practical deployment recommendations.

8.1.  Application of Verification Procedures

   The verification procedures described in this document MUST be
   applied to BGP routes with {AFI, SAFI} combinations {AFI 1 (IPv4),
   SAFI 1} and {AFI 2 (IPv6), SAFI 1} [IANA-AF] [IANA-SAF].  The
   procedures MUST NOT be applied to other address families by default.

   The procedures for ASPA-based AS_PATH verification are intended for
   implementation on edge routers on the ingress side.  This includes
   edge routers on the boundary of an AS Confederation facing external
   ASes.  However, the procedures are NOT RECOMMENDED for use on
   internal BGP (iBGP) sessions or eBGP sessions internal to an AS
   Confederation.

8.2.  BGP Roles

   The BGP Role configuration parameter and its cross-check in BGP OPEN
   message as specified in [RFC9234] are RECOMMENDED.  The configured
   BGP Roles SHOULD be used to automate the use of the above-described
   AS path verification procedures helping to distinguish whether
   upstream or downstream procedures should be applied.  The automatic
   BGP Role cross-check [RFC9234] should facilitate more accurate and
   effective deployment of ASPA.

8.3.  Complex Peering Relationships

   If multiple eBGP sessions can segregate the Complex peering
   relationship into eBGP sessions with normal peering relationships the
   receiving/verifying AS SHOULD select the algorithm (per Section 7.2
   or Section 7.3) for each of the normal sessions based on its peering
   relation type.

   If Complex peering relation can't be segregated (i.e., when a Complex
   BGP relationship occurs within one single BGP session), an operator
   may want to achieve an equivalent outcome by configuring policies on

Azimov, et al.           Expires 9 January 2025                [Page 10]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   a per-prefix basis corresponding to the peering relation for the
   prefix.  If this option is not feasible, the operator MAY apply
   Section 7.3.

8.4.  Logging

   For any route with an Invalid AS_PATH, the cause of the Invalid state
   SHOULD be logged for monitoring and diagnostic purposes.  The cause
   of the Invalid state can be recorded in the form of listing the AS
   hops which were evaluated by the provider authorization function to
   be "Not Provider+".  The logging router, however, cannot necessarily
   determine the AS that caused the route leak.

9.  Security Considerations

9.1.  Difference in IPv4 and IPv6 Connectivity

   The U-SPAS is supposed to contain the union of Providers for a CAS
   for both IPv4 and IPv6 connectivity.  This design solution may have
   side effects if a customer-to-provider relationship exists only in
   one address family, resulting in a relaxed AS_PATH verification in
   the other one.

   The authors of this document believe that this is a reasonable
   compromise, as it will simplify both the ASPA registration process
   and the verification process.  There is also an expectation that the
   difference between IPv4 and IPv6 topologies will reduce as the volume
   of IPv6 traffic grows.

9.2.  Provider as Trusted Point

   Since an upstream provider becomes a trusted point, in theory, it
   might be able to propagate some instances of hijacked prefixes with
   forged-origin or forged-path-segment or even routes with manipulated
   AS_PATHs, and such attacks might go undetected by its customers or
   upper providers.

   While such attacks may happen, it does not seem to be a realistic
   scenario.  Normally a customer and their transit provider would have
   a signed agreement, and a policy violation (of the above kind) should
   have legal consequences or the customer can just drop the
   relationship with such a provider and remove the corresponding ASPA
   record.

Azimov, et al.           Expires 9 January 2025                [Page 11]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

9.3.  Manipulating AS_PATH Prepends

   The ASPA verification procedures cannot detect the removal (or
   addition) of repeats of AS numbers in the AS path.  However, this
   attack by itself does not affect ASPA's route leak detection
   capability.

9.4.  Correctness of the ASPA

   ASPA issuers should be aware of the implications of ASPA-based AS
   path verification.  Network operators must keep their ASPA objects
   correct and up to date.  Otherwise, for example, if a provider AS is
   left out of the SPAS, then routes containing the CAS (in the ASPA)
   and said provider AS may be incorrectly labeled as Invalid and
   considered ineligible for route selection (see Section 7,
   Section 7.4).

10.  Comparison to Other Technologies

10.1.  BGPsec

   BGPsec [RFC8205] was designed to solve the problem of AS_PATH
   verification by including cryptographic signatures in BGP Update
   messages.  It offers protection against unauthorized path
   modifications and assures that the BGPsec Update traveled the path
   shown in the BGPsec_PATH Attribute.  However, it does not detect
   route leaks (valley-free violations).  Thus, BGPsec and ASPA are
   complementary technologies.

10.2.  Peerlock

   The Peerlock mechanism [Peerlock] [Flexsealing] has a similar
   objective as the ASPA-based route leak protection mechanism described
   in this document.  It is commonly deployed by large Internet carriers
   to protect each other from route leaks.  Peerlock depends on a
   laborious manual process in which operators coordinate the
   distribution of unstructured Provider Authorizations through out-of-
   band means in a many-to-many fashion.  On the other hand, ASPA's use
   of the RPKI allows for automated, scalable, and ubiquitous
   deployment, making the protection mechanism available to a wider
   range of network operators.

   The ASPA mechanism implemented in router code (in contrast to
   Peerlock's AS_PATH regular expressions) also provides a way to detect
   anomalies propagated from transit providers and IX route servers.
   ASPA is intended to be a complete solution and replacement for
   existing Peerlock deployments.

Azimov, et al.           Expires 9 January 2025                [Page 12]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

10.3.  Only to Customer (OTC) Attribute

   While the ASPA-based AS_PATH verification method (Section 7,
   Section 7.4) detects and mitigates route leaks that were created by
   preceding ASes listed in the AS_PATH, it lacks the ability to prevent
   the local AS from initiating a route leak towards its neighbor.  ASPA
   verification may also fail to detect route leaks in case of presence
   of Complex relations in the AS_PATH.  The use of the Only to Customer
   (OTC) Attribute fills in that gap (see Section 5, [RFC9234]).  The
   implementation of the procedures utilizing the OTC Attribute is
   RECOMMENDED to complement the ASPA-based AS_PATH verification.

11.  IANA Considerations

   This document includes no request to IANA.

12.  Implementation Status

   This section is to be removed before publishing as an RFC.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft.  The inclusion of this section here follows the
   process described in [RFC7942].  The description of implementations
   in this section is intended to assist the IETF in its decision
   processes in progressing drafts to RFCs.  Please note that the
   listing of any individual implementation here does not imply
   endorsement by the IETF.  Furthermore, no effort has been spent to
   verify the information presented here that was supplied by IETF
   contributors.  This is not intended as, and must not be construed to
   be, a catalog of available implementations or their features.
   Readers are advised to note that other implementations may exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   *  A BGP implementation OpenBGPD [bgpd] (version 7.8 and higher),
      written in C, was provided by Claudio Jeker, Theo Buehler, and Job
      Snijders.

   *  The implementation NIST-BGP-SRx [BGP-SRx] is a software suite that
      provides a validation engine (BGP-SRx) and a Quagga-based BGP
      router (Quagga-SRx).  It includes unit test cases for testing the
      ASPA-based path verification.  It was provided by Oliver Borchert,

Azimov, et al.           Expires 9 January 2025                [Page 13]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

      Kyehwan Lee, and their colleagues at US NIST.  It requires some
      additional work to incorporate the latest changes in the draft
      specifications related to IXP RS AS and RS-client.

   *  Implementation of ASPA-based AS path verification in the BIRD
      Internet Routing Daemon [BIRD] is provided in a side branch
      (branch mq-aspa) by Katerina Kubecova and Maria Matejka.  Its
      release is expected after RTR v2 is finalized.

13.  References

13.1.  Normative References

   [I-D.ietf-sidrops-aspa-profile]
              Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley,
              R., and B. Maddison, "A Profile for Autonomous System
              Provider Authorization", Work in Progress, Internet-Draft,
              draft-ietf-sidrops-aspa-profile-18, 25 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-profile-18>.

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

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

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,
              <https://www.rfc-editor.org/info/rfc6482>.

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793,
              DOI 10.17487/RFC6793, December 2012,
              <https://www.rfc-editor.org/info/rfc6793>.

Azimov, et al.           Expires 9 January 2025                [Page 14]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <https://www.rfc-editor.org/info/rfc7606>.

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

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

   [RFC9324]  Bush, R., Patel, K., Smith, P., and M. Tinka, "Policy
              Based on the Resource Public Key Infrastructure (RPKI)
              without Route Refresh", RFC 9324, DOI 10.17487/RFC9324,
              December 2022, <https://www.rfc-editor.org/info/rfc9324>.

13.2.  Informative References

   [BGP-SRx]  Lee, K. and O. Borchert, et al., "BGP Secure Routing
              Extension (BGP-SRx) Software Suite", NIST Open-Source
              Software , <https://www.nist.gov/services-
              resources/software/bgp-secure-routing-extension-bgp-srx-
              software-suite>.

   [bgpd]     Jeker, C., "OpenBGPD", <http://www.openbgpd.org/>.

   [BIRD]     Kubecova, K. and M. Matejka, "BIRD Internet Routing
              Daemon; branch mq-aspa", CZ.NIC BIRD Open-Source
              Software , <https://bird.nic.cz/en/>.

Azimov, et al.           Expires 9 January 2025                [Page 15]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   [Flexsealing]
              McDaniel, T., Smith, J., and M. Schuchard, "Flexsealing
              BGP Against Route Leaks: Peerlock Active Measurement and
              Analysis", November 2020,
              <https://arxiv.org/pdf/2006.06576.pdf>.

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

   [I-D.ietf-idr-deprecate-as-set-confed-set]
              Kumari, W. A., Sriram, K., Hannachi, L., and J. Haas,
              "Deprecation of AS_SET and AS_CONFED_SET in BGP", Work in
              Progress, Internet-Draft, draft-ietf-idr-deprecate-as-set-
              confed-set-14, 5 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              deprecate-as-set-confed-set-14>.

   [I-D.ietf-sidrops-aspa-notation]
              Bruijnzeels, T., Borchert, O., Ma, D., and T. de Kock,
              "Human Readable ASPA Notation", Work in Progress,
              Internet-Draft, draft-ietf-sidrops-aspa-notation-00, 9
              January 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-sidrops-aspa-notation-00>.

   [IANA-AF]  IANA, "Address Family Numbers",
              <https://www.iana.org/assignments/address-family-numbers/
              address-family-numbers.xhtml>.

   [IANA-SAF] IANA, "Subsequent Address Family Identifiers (SAFI)
              Parameters", <https://www.iana.org/assignments/safi-
              namespace/safi-namespace.xhtml>.

   [nanog-aspa]
              Sriram, K., "ASPA-based BGP AS_PATH Verification and Route
              Leaks Solution", NANOG-89, North American Network Operator
              Group Meeting, Slides/video archives from NANOG, October
              2023, <https://storage.googleapis.com/site-media-
              prod/meetings/NANOG89/4809/20231017_Sriram_Aspa-
              Based_Bgp_As_Path_v1.pdf (slides)
              https://www.youtube.com/watch?v=GdVnZGd7jMo (video)>.

Azimov, et al.           Expires 9 January 2025                [Page 16]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   [Peerlock] Snijders, J., "Peerlock", June 2016,
              <https://www.nanog.org/sites/default/files/
              Snijders_Everyday_Practical_Bgp.pdf>.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779,
              DOI 10.17487/RFC3779, June 2004,
              <https://www.rfc-editor.org/info/rfc3779>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

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

   [RFC9319]  Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B.
              Maddison, "The Use of maxLength in the Resource Public Key
              Infrastructure (RPKI)", BCP 185, RFC 9319,
              DOI 10.17487/RFC9319, October 2022,
              <https://www.rfc-editor.org/info/rfc9319>.

Appendix A.  Acknowledgments

   The authors wish to thank Claudio Jeker, Jakob Heitz, Amir Herzberg,
   Igor Lubashev, Ben Maddison, Russ Housley, Jeff Haas, Nan Geng, Nick
   Hilliard, Shunwan Zhuang, Yangyang Wang, Martin Hoffmann, Jay
   Borkenhagen, Amreesh Phokeer, Aftab Siddiqui, Dai Zhibin, Doug
   Montgomery, Padma Krishnaswamy, Rich Compton, Andrei Robachevsky,
   Rudiger Volk, Iljitsch van Beijnum, Tassilo Tanneberger, Matthias
   Waehlisch, Moritz Schulz, and Carl Seifert for comments, suggestions,
   and discussion on the path verification procedures or the text in the
   document.  For the implementation and testing of the procedures in
   the document, the authors wish to thank Claudio Jeker and Theo
   Buehler [bgpd], Kyehwan Lee and Oliver Borchert [BGP-SRx], and
   Katerina Kubecova and Maria Matejka [BIRD].

Azimov, et al.           Expires 9 January 2025                [Page 17]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

Appendix B.  Properties and Early Adoption Benefits

   The ASPA method has the properties (i.e., anomaly detection
   capabilities) listed below.  Partial deployment scenarios and early
   adoption benefits are considered.  In the case of Property 1, it is
   assumed that the attacks involve route leaks but not malicious
   removal of ASes with ASPA records from the AS path.

      *Property 1 (Route Leak Detection):* Let AS A and AS B be any two
      ASes in the Internet doing ASPA (registration and path
      verification) and no assumption is made about the ASPA deployment
      status of other ASes.  Consider a route propagated from AS A to a
      customer or lateral peer.  The route is subsequently leaked by an
      offending AS in the AS path before being received at AS B on a
      customer or lateral peer interface.  The ASPA-based path
      verification at AS B always detects such a route leak though it
      may not be able to identify the AS that caused the leak.

      *Corollary of Property 1:* An observation that follows from
      Property #1 above is that if any two ISP ASes register ASPAs and
      implement the detection and mitigation procedures, then any route
      received from one of them and leaked to the other by an AS in
      their overlapping customer cones (ASPA compliant or not) will be
      automatically detected and mitigated.  In effect, if most major
      ISPs are compliant, the propagation of route leaks in the Internet
      will be severely limited.

      *Property 2 (Detection of Forged-Origin Prefix Hijack):* Again,
      let AS A and AS B be any two ASes in the Internet doing ASPA
      (registration and path verification) and no assumption is made
      about the ASPA deployment status of other ASes.  Consider a route
      received at AS B on a customer or lateral peer interface that is a
      forged-origin prefix hijack involving AS A as the forged-origin.
      Assume that the offending AS X is not included in the ASPA of AS
      A.  The ASPA-based path verification at AS B always detects such a
      forged-origin prefix hijack.

      *Property 3 (Detection of Forged-Path-Segment Prefix Hijack):*
      This is an extension of Property 2 above to the case of prefix
      hijacking with a forged-path-segment.  Such hijacking refers to
      the forging of multiple contiguous ASes in an AS path beginning
      with the origin AS.  Again, let AS A and AS B be any two ASes in
      the Internet doing ASPA (registration and path verification).
      Assume that AS A's providers, AS P and AS Q, also register ASPA.
      No assumption is made about the ASPA deployment status of any
      other ASes in the Internet.  Consider a route received at AS B on
      a customer or lateral peer interface that is a prefix hijack with
      a forged-path-segment {AS P, AS A} or {AS Q, AS A}.  That is, the

Azimov, et al.           Expires 9 January 2025                [Page 18]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

      offending AS X attaches this path-segment at the beginning of its
      (AS X's) route announcement.  Assume that AS X is not included in
      the ASPA of AS P or AS Q.  The ASPA-based path verification at AS
      B always detects such a forged-path-segment prefix hijack.  For a
      chance to be successful (remain undetected by AS B), the hijacker
      may resort to a forged-path-segment with three ASes including a
      provider AS of AS P (or AS Q).  But even that can be foiled
      (detected) if the providers of AS P and AS Q also register ASPA.
      The forged-path-segment hijack in consideration is entirely
      prevented (for any forged-path-segment length) if all ASes in the
      contiguous C2P hops from AS A up to its Tier 1 have ASPA
      registrations.

   The above properties show that ASPA-based path verification offers
   significant benefits to early adopters.  Limitations of the method
   with regard to some forms of malicious AS path manipulations are
   discussed in Section 9.

Authors' Addresses

   Alexander Azimov
   Yandex
   Ulitsa Lva Tolstogo 16
   Moscow
   119021
   Russian Federation
   Email: a.e.azimov@gmail.com

   Eugene Bogomazov
   Qrator Labs
   1-y Magistralnyy tupik 5A
   Moscow
   123290
   Russian Federation
   Email: eb@qrator.net

   Randy Bush
   Internet Initiative Japan & Arrcus, Inc.
   5147 Crystal Springs
   Bainbridge Island, Washington 98110
   United States of America
   Email: randy@psg.com

Azimov, et al.           Expires 9 January 2025                [Page 19]
Internet-Draft       ASPA-based AS_PATH Verification           July 2024

   Keyur Patel
   Arrcus
   2077 Gateway Place
   Suite #400
   San Jose, CA 95119
   United States of America
   Email: keyur@arrcus.com

   Job Snijders
   Fastly
   Amsterdam
   Netherlands
   Email: job@fastly.com

   Kotikalapudi Sriram
   USA National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD 20899
   United States of America
   Email: ksriram@nist.gov

Azimov, et al.           Expires 9 January 2025                [Page 20]