BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects

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

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

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

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

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+"
                           \

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

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

                      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

8. Deployment Recommendations

This section describes practical deployment recommendations.¶

9. Security Considerations

11. IANA Considerations

This document includes no request to IANA.¶

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

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