Skip to main content

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

Document Type Active Internet-Draft (sidrops WG)
Authors Alexander Azimov , Eugene Bogomazov , Randy Bush , Keyur Patel , Job Snijders , Kotikalapudi Sriram
Last updated 2024-02-29
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 In WG Last Call
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-17
Network Working Group                                          A. Azimov
Internet-Draft                                                    Yandex
Intended status: Standards Track                            E. Bogomazov
Expires: 1 September 2024                                    Qrator Labs
                                                                 R. Bush
                                                            IIJ & Arrcus
                                                                K. Patel
                                                                  Arrcus
                                                             J. Snijders
                                                                  Fastly
                                                               K. Sriram
                                                                USA NIST
                                                        29 February 2024

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

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
   improbable AS paths.  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 1 September 2024.

Azimov, et al.          Expires 1 September 2024                [Page 1]
Internet-Draft       ASPA-based AS_PATH Verification       February 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
     1.1.  Anomaly Propagation . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  BGP Roles . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Autonomous System Provider Authorization  . . . . . . . . . .   5
   4.  ASPA Registration Recommendations . . . . . . . . . . . . . .   5
   5.  Hop-Check Function  . . . . . . . . . . . . . . . . . . . . .   6
   6.  AS_PATH Verification  . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Algorithm for Upstream Paths  . . . . . . . . . . . . . .   8
     6.2.  Algorithm for Downstream Paths  . . . . . . . . . . . . .   9
       6.2.1.  Principles for Determination of Invalid, Valid, and
               Unknown in Downstream Path Verification (for N >= 3)    9
       6.2.2.  Formal Procedure for Verification of Downstream
               Paths . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  AS_PATH Verification and Anomaly Mitigation
           Recommendations . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Verification and Mitigation at Ingress eBGP Router  . . .  12
     7.2.  Only to Customer (OTC) Attribute  . . . . . . . . . . . .  13
   8.  Properties of ASPA-based Path Verification  . . . . . . . . .  13
   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  15
     9.1.  4-Byte AS Number Requirement  . . . . . . . . . . . . . .  15
     9.2.  Correctness of the ASPA . . . . . . . . . . . . . . . . .  15
     9.3.  Make Before Break . . . . . . . . . . . . . . . . . . . .  15
     9.4.  DoS/DDoS Mitigation Service Provider  . . . . . . . . . .  16
   10. Comparison to Other Technologies  . . . . . . . . . . . . . .  16
     10.1.  BGPsec . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.2.  Peerlock . . . . . . . . . . . . . . . . . . . . . . . .  16
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  17
   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  18
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19

Azimov, et al.          Expires 1 September 2024                [Page 2]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

     14.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     14.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  22
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

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 are able to 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 and improbable AS paths.  It
   also provides protection, to some degree, against prefix hijacks with
   forged-origin or forged-path-segment (Section 8).  These new ASPA-
   based procedures automatically detect such anomalous AS_PATHs in
   announcements that are received from customers, lateral peers
   (defined in [RFC7908]), transit providers, IXP Route Servers (RS),
   RS-clients, and mutual-transits.  The protections provided by these
   procedures (together with RPKI-ROV) are based on cryptographic
   techniques, and they are effective against many accidental and
   malicious actions.

   ASPA objects are cryptographically signed registrations of customer-
   to-provider relationships and stored in a distributed database
   [I-D.ietf-sidrops-aspa-profile].  ASPA-based path verification is an
   incrementally deployable technique and provides benefits to early
   adopters in the context of limited deployment.

   The procedures described in this document are applicable only for BGP
   routes with {AFI, SAFI} combinations {AFI 1 (IPv4), SAFI 1} and {AFI
   2 (IPv6), SAFI 1} [IANA-AF].  SAFI 1 represents NLRI used for unicast
   forwarding [IANA-SAF].

Azimov, et al.          Expires 1 September 2024                [Page 3]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

1.1.  Anomaly Propagation

   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 a
   particular ISP's customer cone, but if the anomaly propagates through
   lateral (i.e., non-transit) peers and transit providers, or reaches
   global distribution through transit-free networks, then the ill
   effects will likely be amplified and experienced across continents.

   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.

1.2.  Terminology

   The use of the term "route is ineligible" in this document 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."

   For brevity, the term "provider" is often used instead of "transit
   provider" in this document; they mean the same.

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

2.  BGP Roles

   For path verification purposes in this document, the BGP roles an AS
   can have in relation to a neighbor AS are customer, provider, lateral
   peer, Route Server (RS), RS-client, and mutual-transit.  These
   relationships, except mutual-transit, are defined in [RFC9234].
   Mutual-transit ASes MAY export everything (both customer and non-
   customer routes) to each other, i.e., consider each other as a
   customer.  For mutual-transit ASes, the customer-to-provider
   relationship applies in each direction.

Azimov, et al.          Expires 1 September 2024                [Page 4]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   All roles are configured locally and used for the registration of
   ASPA objects (Section 3, Section 4) and/or for path verification
   (Section 6).  The procedures for local BGP Role announcement in the
   BGP OPEN message and neighbor role cross-check specified in [RFC9234]
   are RECOMMENDED.  Those procedures are not applied for cross-checking
   a mutual-transit role since this role is not specified in [RFC9234].

3.  Autonomous System Provider Authorization

   An ASPA record is a digitally signed object that binds a set of
   Provider AS numbers to a Customer AS (CAS) number (in terms of BGP
   announcements) 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 definition of Provider AS is given in Section 1 of
   the ASPA profile object document [I-D.ietf-sidrops-aspa-profile].  A
   function of a Provider AS is to propagate a CAS's route announcements
   onward, i.e., to the Provider's upstream providers, lateral peers, or
   customers.  Another function is to offer outbound (customer to
   Internet) data traffic connectivity to the CAS.

   The notation (AS x, {AS y1, AS y2, ...}), is used to represent an
   ASPA object for a CAS denoted as AS x.  In this notation, the 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 4).  If a CAS has a single ASPA, then the
   SPAS for the CAS is the set of Provider ASes listed in that ASPA.  In
   case a CAS has multiple ASPAs, then the SPAS is the union of the
   Provider ASes listed in all ASPAs of the CAS.

   Verified ASPA Payload (VAP) refers to the payload in a
   cryptographically verified (i.e., X.509 valid [RFC3779] [RFC5280])
   ASPA object.  In the procedures for the AS path verification
   described in this document (Section 5, Section 6), VAP-SPAS refers to
   the set of provider ASes derived from the VAP(s) of the CAS in
   consideration.

4.  ASPA Registration Recommendations

   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 AS 0 ASPA.

Azimov, et al.          Expires 1 September 2024                [Page 5]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   Normally, the Provider ASes of a CAS would be congruent for the
   address family combinations {AFI 1 (IPv4), SAFI 1} and {AFI 2 (IPv6),
   SAFI 1}.  Exceptions to this are expected to be rare.  In any case,
   the CAS MUST list the union of all Provider ASes applicable to the
   address family combinations stated above in the SPAS and MUST also
   include any non-transparent RS AS(es) at which it is an RS-client.
   In the procedures for the AS path verification described in this
   document (Section 5, Section 6), the SPAS is always considered to be
   uniformly applicable to {AFI 1 (IPv4), SAFI 1} and {AFI 2 (IPv6),
   SAFI 1}.

   A compliant AS, including a Route Server AS (RS AS), MUST have an
   ASPA.  An AS SHOULD NOT have more than one ASPA.  An RS AS SHOULD
   register an AS 0 ASPA.

   As mentioned in Section 3, the set of provider ASes contained in the
   VAP(s) is referred to as the VAP-SPAS of the AS registering the
   ASPA(s).  Normally, a VAP-SPAS 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 5,
   Section 6).

   Each of the two ASes in a mutual-transit pair MUST register its ASPA
   including the other AS in its SPAS.  If one of the ASes in the pair
   does this registration but the other does not, it increases the risk
   of incorrect AS path verification results for routes that include the
   pair.

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

   As specified earlier, a compliant AS should maintain a single ASPA
   object that includes all its provider ASes, including any non-
   transparent RS ASes.  Such a practice helps 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.  During a transition process between
   different certificate authority (CA) registries, the ASPA records
   SHOULD be kept identical in all relevant registries.

5.  Hop-Check Function

   Let AS(i) and AS(j) represent adjacent unique ASes in an AS_PATH, and
   thus (AS(i), AS(j)) represents an AS hop.  A hop-check function,
   hop(AS(i), AS(j)), checks if the ordered pair of ASNs, (AS(i),
   AS(j)), has the property that AS(j) is an attested provider of AS(i)
   per VAP-SPAS of AS(i).  The VAP-SPAS table is assumed to be organized
   in such a way that it can be queried to check (1) if a specified CAS

Azimov, et al.          Expires 1 September 2024                [Page 6]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   = AS(i) has an entry (i.e., SPAS listed), or (2) if for a given
   (AS(i), AS(j)) tuple, AS(j) is listed in the VAP-SPAS as a provider
   associated with CAS = AS(i).  A provider AS ID included in the SPAS
   can correspond to a Provider, a non-transparent RS, or a mutual-
   transit neighbor.  A non-transparent RS is effectively a Provider to
   its RS-client.  Mutual-transit neighbors regard each other as a
   Provider (see Section 4).  The term "Provider+" in the definition of
   the hop-check function is meant to encompass all three possibilities:
   Provider, non-transparent RS, or mutual-transit neighbor.  This
   function is specified as follows:

                        /
                        | "No Attestation" if there is no entry
                        |   in VAP-SPAS table for CAS = AS(i)
                        |
   hop(AS(i), AS(j)) =  / Else, "Provider+" if the VAP-SPAS entry
                        \   for CAS = AS(i) includes AS(j)
                        |
                        | Else, "Not Provider+"
                        \

                       Figure 1: Hop-check function.

   To be clear, this function checks if AS(j) is included in the VAP-
   SPAS of AS(i), and in doing so it does not need to distinguish
   between Provider, non-transparent RS, and mutual-transit neighbor.

   The "No Attestation" result is returned only when the CAS = AS(i) has
   no entry in the VAP-SPAS table, which occurs when no ASPA is
   registered for the CAS or none of its ASPAs are cryptographically
   valid.  The hop-check function is used in the ASPA-based AS_PATH
   verification algorithms described in Section 6.1 and Section 6.2.

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

Azimov, et al.          Expires 1 September 2024                [Page 7]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   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).  The check fails also when the AS_PATH is empty (zero
   length) and such UPDATEs will also be considered to be in error.

   [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 6.1 and Section 6.2).  See Section 7 for how routes with
   Invalid AS_PATH are handled.

   In Section 6.1 and Section 6.2 below, the terms "upstream path" and
   "downstream path" generally refer to AS paths received in the
   upstream direction (from a customer or a lateral peer) and in the
   downstream direction (from a provider or a mutual-transit neighbor),
   respectively.  An RS-client receiving a route from its RS is a
   special case where the algorithm for upstream paths is applied
   (Section 6.1).

6.1.  Algorithm for Upstream Paths

   The upstream verification algorithm described here is applied when a
   route is received from a customer or lateral 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 consist of only customer-to-provider hops successively
   from the origin AS to the neighbor AS (most recently added).

   The basic principles of the upstream verification algorithm are
   stated here.  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/validating AS.  For each hop AS(i-1) to AS(i) in this
   sequence, the hop-check function, hop(AS(i-1), AS(i)), must equal
   "Provider+" (Section 5) for the AS_PATH to be Valid.  If the hop-
   check function for at least one of those hops is "Not Provider+",
   then the AS_PATH is deemed Invalid.  If the AS_PATH verification
   outcome is neither Valid nor Invalid (per the above principles), then
   it is evaluated as Unknown.

   The upstream path verification procedure is specified as follows:

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

Azimov, et al.          Expires 1 September 2024                [Page 8]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   2.  Collapse prepends in the AS_SEQUENCE(s) in the AS_PATH (i.e.,
       keep only the unique AS numbers).  Let the resulting ordered
       sequence be represented by {AS(N), AS(N-1), ..., AS(2), AS(1)},
       where AS(1) is the first-added (i.e., origin) AS and AS(N) is the
       last-added AS and neighbor to the receiving/validating AS.

   3.  If N = 1, then the procedure halts with the outcome "Valid".
       Else, continue.

   4.  At this step, N ≥ 2.  If there is an i such that 2 ≤ i ≤ N and
       hop(AS(i-1), AS(i)) = "Not Provider+", then the procedure halts
       with the outcome "Invalid".  Else, continue.

   5.  If there is an i such that 2 ≤ i ≤ N and hop(AS(i-1), AS(i)) =
       "No Attestation", then the procedure halts with the outcome
       "Unknown".  Else, the procedure halts with the outcome "Valid".

6.2.  Algorithm for Downstream Paths

   The downstream verification algorithm described here is applied when
   a route is received from a transit provider or mutual-transit
   neighbor.  As described in Section 4, a sending mutual-transit AS
   acts towards its receiving mutual-transit AS in a manner similar to
   that of a provider towards its customer.

   It is not essential, but the reader may take a look at the
   illustrations and formal proof in [sriram1] to develop a clearer
   understanding of the algorithm described here.

   Here again (as in Section 6.1), let the AS_PATH be simplified and
   represented by the ordered sequence of unique ASNs as {AS(N),
   AS(N-1),..., AS(2), AS(1)}.

   If 1 <= N <= 2, then the AS_PATH is trivially Valid.

   Section 6.2.1 below assumes that the AS_PATH contains 3 or more
   unique ASNs (N >= 3).

6.2.1.  Principles for Determination of Invalid, Valid, and Unknown in
        Downstream Path Verification (for N >= 3)

   *Determination of Invalid AS_PATH:*

   Given the above-mentioned ordered sequence, if there exist indices u
   and v such that (1) u <= v, (2) hop(AS(u-1), AS(u)) = "Not
   Provider+", and (3) hop(AS(v+1), AS(v)) = "Not Provider+", then the
   AS_PATH is Invalid.

Azimov, et al.          Expires 1 September 2024                [Page 9]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   ------------

   *Determination of Valid AS_PATH:*

   As shown in Figure 2, assume that the ASes in the AS_PATH are in the
   same physical (locational) order as in the sequence representation
   {AS(N), AS(N-1),..., AS(2), AS(1)}, i.e., AS(N) is the left-most and
   AS(1) the right-most.

                       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 & Validating AS

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

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

   Looking at Figure 2, the UPDATE is received from a provider or a
   mutual-transit neighbor (i.e., AS(N) has that role in relation to the
   receiver).  The AS_PATH may have both an up-ramp (on the right
   starting at AS(1)) and a down-ramp (on the left starting at AS(N)).
   The ramps are described as a sequence of ASes that consists of
   consecutive customer-to-provider hops.  The up-ramp starts at AS(1)
   and each AS hop, (AS(i), AS(i+1)), in it has the property that
   hop(AS(i), AS(i+1)) = "Provider+" for i = 1, 2,... , K-1.  If such a
   K does not exist, then K is set to 1.  The up-ramp ends (reaches its
   apex) at AS(K) because hop(AS(K), AS(K+1)) = "Not Provider+" or "No
   Attestation".  The down-ramp runs backward from AS(N) to AS(L).  Each
   AS hop, (AS(j), AS(j-1)), in it has the property that hop(AS(j),
   AS(j-1)) = "Provider+" for j = N, N-1,... , L+1.  If such an L does
   not exist, then L is set to N.  The down-ramp ends at AS(L) because
   hop(AS(L), AS(L-1)) = "Not Provider+" or "No Attestation".  Thus, the
   apex of the down-ramp is AS(L).

   If there is an up-ramp that runs across all ASes in the AS_PATH
   (i.e., K = N), then clearly the AS_PATH is Valid.  Similarly, if
   there is a down-ramp that runs across all ASes in the AS_PATH (i.e.,

Azimov, et al.          Expires 1 September 2024               [Page 10]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   L = 1), then also the AS_PATH is Valid.  However, if both ramps exist
   in an AS_PATH with K < N and L > 1, then the AS_PATH is Valid if and
   only if L-K <= 1.  Note that K could be greater than L (i.e., L-K has
   a negative value), which means that the up-ramp and down-ramp
   overlap, and that could happen when some adjacent ASes in the AS_PATH
   have mutual-transit relationship between them (i.e., include each
   other in their respective SPAS) (see Section 4).  If L-K = 0, it
   means that the apexes of the up-ramp and down-ramp are at the same
   AS.  If L-K = 1, it means that the apexes are at adjacent ASes.  In
   summary, the AS_PATH is Valid if L-K is 0 or 1 or has a negative
   value.

   ------------

   *Determination of Unknown AS_PATH:*

   If L-K >= 2, then the AS_PATH is either Invalid (route leak) or
   Unknown (see illustrations and proof in [sriram1]).  However, if L-K
   >= 2 and an Invalid outcome was not found by the process described
   earlier in this section, then the AS_PATH is determined to be
   Unknown.

6.2.2.  Formal Procedure for Verification of Downstream Paths

   The downstream path verification procedure is formally specified as
   follows:

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

   2.  Collapse prepends in the AS_SEQUENCE(s) in the AS_PATH (i.e.,
       keep only the unique AS numbers).  Let the resulting ordered
       sequence be represented by {AS(N), AS(N-1), ..., AS(2), AS(1)},
       where AS(1) is the first-added (i.e., origin) AS and AS(N) is the
       last-added AS and neighbor to the receiving/validating AS.

   3.  If 1 ≤ N ≤ 2, then the procedure halts with the outcome "Valid".
       Else, continue.

   4.  At this step, N ≥ 3.  Given the above-mentioned ordered sequence,
       find the lowest value of u (2 ≤ u ≤ N) for which hop(AS(u-1),
       AS(u)) = "Not Provider+".  Call it u_min.  If no such u_min
       exists, set u_min = N+1.  Find the highest value of v (N-1 ≥ v ≥
       1) for which hop(AS(v+1), AS(v)) = "Not Provider+".  Call it
       v_max.  If no such v_max exists, then set v_max = 0.  If u_min ≤
       v_max, then the procedure halts with the outcome "Invalid".
       Else, continue.

Azimov, et al.          Expires 1 September 2024               [Page 11]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   5.  Up-ramp: For 2 ≤ i ≤ N, determine the largest K such that
       hop(AS(i-1), AS(i)) = "Provider+" for each i in the range 2 ≤ i ≤
       K.  If such a largest K does not exist, then set K = 1.

   6.  Down-ramp: For N-1 ≥ j ≥ 1, determine the smallest L such that
       hop(AS(j+1), AS(j)) = "Provider+" for each j in the range N-1 ≥ j
       ≥ L.  If such smallest L does not exist, then set L = N.

   7.  If L-K ≤ 1, then the procedure halts with the outcome "Valid".
       Else, the procedure halts with the outcome "Unknown".

   In the above procedure, the computations in Steps 4, 5, and 6 can be
   done at the same time.

7.  AS_PATH Verification and Anomaly Mitigation Recommendations

   AS_PATH verification and anomaly mitigation recommendations for eBGP
   routers are specified in this section.  The recommendations apply to
   eBGP routers in general, including those on the boundary of an AS
   Confederation facing external ASes.  However, the procedures for
   ASPA-based AS_PATH verification in this document are NOT RECOMMENDED
   for use on eBGP links internal to the Confederation.

   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].  The procedures MUST
   NOT be applied to other address families by default.

7.1.  Verification and Mitigation at Ingress eBGP Router

   *Verification:* Conforming implementations of this specification are
   not required to implement the AS_PATH verification procedures (step-
   wise lists) exactly as described in Section 6.1 and Section 6.2 but
   MUST provide functionality equivalent to the external behavior
   resulting from those procedures.  In other words, the algorithms used
   in a specific implementation may differ, for example, for
   computational efficiency purposes, but the AS_PATH verification
   outcomes MUST be identical to those obtained by the procedures
   described in Section 6.1 and Section 6.2.

   *Mitigation:* Mitigation recommendations are provided here with the
   understanding that the deployed mitigation policy is set by network
   operator discretion.  If the AS_PATH is determined to be Invalid,
   then the route SHOULD be considered ineligible for route selection
   (see Section 1.2) and MUST be kept in the Adj-RIB-In for potential
   future re-evaluation (see [RFC9324]).  Also, 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

Azimov, et al.          Expires 1 September 2024               [Page 12]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   can be in the form of listing the AS hops which were evaluated by the
   hop-check function to be "Not Provider+".  For any route with an
   Unknown AS_PATH, the cause of the Unknown state SHOULD be logged for
   monitoring and diagnostic purposes.  The cause of the Unknown state
   can be in the form of listing the AS hops which were evaluated by the
   hop-check function to be "No Attestation" or "Not Provider+".

7.2.  Only to Customer (OTC) Attribute

   While the ASPA-based AS_PATH verification method (Section 7.1)
   detects and mitigates route leaks that were created by preceding ASes
   listed in the AS_PATH, it lacks the ability to prevent route leaks
   from occuring at the local AS.  The use of the Only to Customer (OTC)
   Attribute [RFC9234] fills in that gap.  The procedures utilizing the
   OTC Attribute set out in [RFC9234] complement those described in this
   document.  Implementation of those procedures in addition to ASPA-
   based AS_PATH verification is encouraged.

8.  Properties of ASPA-based Path Verification

   The ASPA-based path verification procedures are able to check routes
   received from customers, lateral peers, transit providers, RSes, RS-
   clients, and mutual-transits.  These procedures combined with BGP
   Roles and the OTC Attribute [RFC9234] and RPKI-ROV [RFC6811]
   [RFC9319] can provide a fully automated solution to detect and filter
   many of the ordinary prefix hijacks, route leaks, and prefix hijacks
   with forged-origin or forged-path-segment (see Property 3 below).

   The ASPA-based path verification at ingress eBGP routers (Section 6,
   Section 7.1) has the following properties (detection capabilities):

      Property 1: 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 originated the leak.  This assertion is true even when
      the sender AS A (or receiver AS B) is an RS AS and the neighbor AS
      that AS A sent to (or AS B received from) is an RS-client.

Azimov, et al.          Expires 1 September 2024               [Page 13]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

      Property 2: 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.  The ASPA-based path verification at AS B
      always detects such a forged-origin prefix hijack.

      Property 3: 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).  Let AS A's providers, AS P and AS Q, also be
      registering 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 hijacker attaches this path-segment at the
      beginning of their route announcement.  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.  Having to use a longer forged-path-segment to
      avoid detection by AS B diminishes the ability of the hijacked
      route to compete with the corresponding legitimate route in route
      selection.

      Property 4: Let AS A, AS B, and AS C be any three ASes in the
      Internet doing ASPA (registration and path verification).
      Consider a route propagated from AS A in any direction (i.e., to a
      neighbor AS with any of the BGP roles described in Section 2).
      Let the route be received at AS B from any direction and detected
      to be a route leak (facilitated due to a sufficient set of ASes
      doing ASPA in the AS path from AS A to AS B).  Assume that AS B's
      local policy is such that it only lowers the route's LOCAL_PREF
      [RFC4271].  Let such a route, selected and forwarded by AS B, be
      subsequently received at AS C.  No assumption is made about the
      ASPA compliance of the ASes in the intervening path from AS B to
      AS C.  The ASPA-based path verification at AS C always detects
      such received route as a leak regardless of the direction (type of
      peer) it was received from.

   In the description of the properties listed above, the term
   "customer" can be replaced with "RS-client".

Azimov, et al.          Expires 1 September 2024               [Page 14]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   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 a common customer AS (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.

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

9.  Operational Considerations

9.1.  4-Byte AS Number Requirement

   The procedures specified in this document are compatible only with
   BGP implementations that support 4-byte ASNs in the AS_PATH.  This
   limitation should not have a real effect on operations since legacy
   BGP routers are rare, and it is highly unlikely that they support
   integration with the RPKI.

9.2.  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 Set of Provider ASes (SPAS) in the ASPA, then routes
   containing the CAS (in the ASPA) and said provider AS may be
   incorrectly labeled as route leaks and considered ineligible for
   route selection (see Section 7.1).

9.3.  Make Before Break

   ASPA issuers SHOULD apply the make-before-break principle while
   updating an ASPA registration.  For example, when adding new Provider
   AS(es) in the SPAS, if the new ASPA is meant to replace a previously
   created ASPA, the latter SHOULD be decommissioned only after allowing
   sufficient time for the new ASPA to propagate to Relying Parties (RP)
   through the global RPKI system.

Azimov, et al.          Expires 1 September 2024               [Page 15]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

9.4.  DoS/DDoS Mitigation Service Provider

   An AS may have a mitigation service provider (MSP) for protection
   from Denial of Service (DoS)/Distributed DoS (DDoS) attacks targeting
   servers with IP addresses in the prefixes the AS originates.  Such an
   AS MAY include the MSP's AS in the SPAS of its ASPA.  With such an
   ASPA in place, in the event of an attack, the AS (customer of the
   MSP) can announce more specific prefixes (over a BGP session) to the
   MSP's AS for mitigation purposes, and such announcements would be
   able to pass the ASPA-based path verification.  It is assumed that
   appropriate ROAs are registered in advance so that the announcements
   can pass RPKI-ROV as well.

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 actually traveled
   the path shown in the BGPsec_PATH Attribute.  However, it does not
   detect route leaks (valley-free violations).  In comparison, the
   ASPA-based path verification described in this document detects if
   the AS path is improbable and focuses on detecting route leaks
   (including malicious cases) and forged-origin hijacks.

   BGPsec and ASPA are complementary technologies.

10.2.  Peerlock

   The Peerlock mechanism [Peerlock] [Flexsealing] has a similar
   objective as the APSA-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 1 September 2024               [Page 16]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

11.  IANA Considerations

   This document includes no request to IANA.

12.  Security Considerations

   While the ASPA-based mechanism is able to detect and mitigate the
   majority of mistakes and malicious activity affecting routes, it
   might fail to detect some malicious path modifications, especially
   for routes that are received from transit providers.

   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.
   This can be illustrated with some examples.  In Figure 3, normally
   the receiving/validating AS located at the lower left side should
   receive a route with AS_PATH {AS(5), AS(4), AS(3), AS(2), AS(1)} and
   it would be Valid (Section 6.2) given all the ASPAs that are shown in
   the figure.  However, if AS(5) which is a transit provider to the
   validating AS acts maliciously and sends the route with a shortened
   AS_PATH such as {AS(5), AS(3), AS(2), AS(1)} or {AS(5), AS(2),
   AS(1)}, such path manipulation would be undetectable (i.e., the
   AS_PATH would be considered Valid).  Also, if AS(5) were to perform a
   forged-origin hijack by inserting an AS_PATH {AS(5), AS(1)}, that
   would also be undetectable.

                      AS(4) - AS(3)
                      /         \
      (down-ramp)    /           \    (up-ramp)
                 AS(5)          AS(2)
                   /               \
                  /               AS(1)
                 /             (Origin AS)
    Receiving & Validating AS

   ASPAs: {AS(1), [AS(2)]}, {AS(2), [AS(3)]}, {AS(5), [AS(4)]},
          {AS(3), [AS 0]}, {AS(4), [AS 0]}

       Figure 3: Illustration for discussion of undetectable AS_PATH
                               manipulations.

Azimov, et al.          Expires 1 September 2024               [Page 17]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   While attacks like the examples above 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.

   The key properties or strengths of the ASPA method were described in
   Section 8.  If detection of any and all kinds of path manipulation
   attacks is the goal, then BGPsec [RFC8205] would need to be deployed
   complementary to the ASPA method.  It may be noted that BGPsec in its
   current form lacks route leak detection capabilities.

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

Azimov, et al.          Expires 1 September 2024               [Page 18]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

14.  References

14.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-17, 7 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-profile-17>.

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

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

Azimov, et al.          Expires 1 September 2024               [Page 19]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

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

   [RFC8481]  Bush, R., "Clarifications to BGP Origin Validation Based
              on Resource Public Key Infrastructure (RPKI)", RFC 8481,
              DOI 10.17487/RFC8481, September 2018,
              <https://www.rfc-editor.org/info/rfc8481>.

   [RFC8893]  Bush, R., Volk, R., and J. Heitz, "Resource Public Key
              Infrastructure (RPKI) Origin Validation for BGP Export",
              RFC 8893, DOI 10.17487/RFC8893, September 2020,
              <https://www.rfc-editor.org/info/rfc8893>.

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

14.2.  Informative References

   [BGP-SRx]  NIST, "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/>.

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

Azimov, et al.          Expires 1 September 2024               [Page 20]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

              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-12, 10 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              deprecate-as-set-confed-set-12>.

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

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

Azimov, et al.          Expires 1 September 2024               [Page 21]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

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

   [sriram1]  Sriram, K. and J. Heitz, "On the Accuracy of Algorithms
              for ASPA Based Route Leak Detection", IETF SIDROPS
              Meeting, Proceedings of the IETF 110, March 2021,
              <https://datatracker.ietf.org/meeting/110/materials/
              slides-110-sidrops-sriram-aspa-alg-accuracy-01>.

Appendix A.  Acknowledgments

   The authors wish to thank 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, Rich
   Compton, Andrei Robachevsky, and Iljitsch van Beijnum 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] as well as Kyehwan Lee and Oliver Borchert
   [BGP-SRx].

Contributors

   The following people made significant contributions to this document
   and should be considered co-authors:

           Claudio Jeker
           OpenBSD
           Email: cjeker@diehard.n-r-g.com

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

Azimov, et al.          Expires 1 September 2024               [Page 22]
Internet-Draft       ASPA-based AS_PATH Verification       February 2024

   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

   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 1 September 2024               [Page 23]