| Internet-Draft | ASPA-based AS_PATH Verification for BGP | January 2026 |
| Zhang, et al. | Expires 24 July 2026 | [Page] |
This document describes AS_PATH verification based on Autonomous System Provider Authorization (ASPA) for egress eBGP speakers. ASPA is a Resource Public Key Infrastructure (RPKI) object that allows an AS to register its transit provider ASes. Performing ASPA-based AS_PATH verification at egress can prevent the propagation of route leaks to external peers, check for local misconfigurations, and help detect potential ASPA registration errors. This approach complements ingress-side verification; it ensures coverage should ASPA deployment be absent at the ingress eBGP router of the AS.¶
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 24 July 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components 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.¶
Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) can be used to verify BGP AS_PATH for detection and mitigation of route leaks and certain prefix hijacks involving forged origins or forged path-segments [I-D.ietf-sidrops-aspa-verification]. The ASPA object profile is defined in [I-D.ietf-sidrops-aspa-profile].¶
The procedures described in Section 5 of [I-D.ietf-sidrops-aspa-verification] perform ASPA-based BGP AS_PATH verification at eBGP ingress. Performing BGP AS_PATH verification at eBGP egress (this document) can be beneficial as follows: (1) Ensure coverage should ASPA deployment be absent at the ingress eBGP router of the AS, and (2) Check whether the AS_PATH (with the local AS added) as received by the eBGP neighbor at egress router would be Invalid and, if so, avoid sending the BGP Update. The egress AS_PATH verification inherently detects and alerts the local AS operator if there were any eBGP peering misconfiguration or error in the ASPA registration of the eBGP neighbor on the ingress side.¶
This document does not change the semantics or procedures of ASPA-based BGP AS_PATH verification defined in [I-D.ietf-sidrops-aspa-verification]. It explains important use cases and specifics of correct implementation of ASPA-based path verification at eBGP egress, as [RFC8893] did with RPKI route origin validation (RPKI-ROV) for BGP export. The verification procedure at eBGP egress is a little different from the procedure at the eBGP ingress.¶
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.¶
It is assumed that the reader understands BGP[RFC4271], RPKI[RFC6480], ASPA object profile[I-D.ietf-sidrops-aspa-profile], ASPA-based BGP AS_PATH verification[I-D.ietf-sidrops-aspa-verification], and RPKI-ROV for BGP export[RFC8893].¶
When a BGP speaker advertises a route to an external peer through eBGP egress, the BGP speaker prepends its own AS number to the AS_PATH of the route, and performs ASPA-based AS_PATH verification before sending the route to the external peer.¶
Suppose the BGP router is at AS X, and its external peer is at AS Y, and the AS_PATH P of the route to be advertised to external peer by the BGP speaker is represented by {AS X, AS(N), ..., AS(2), AS(1)}, where AS(1) is the origin AS, and AS X is the local AS number added by the BGP speaker of AS X at eBGP egress (see Figure 1). In this AS_PATH, the AS number (ASN) used for AS X MUST be the ASN of the router's BGP configuration (see [RFC8481] [RFC8893]).¶
+------------------------+
| AS X |
| |
+-------+ eBGP | +----+ iBGP +----+ | eBGP +--------+
| AS(N) |-------->>| R1 |------>>| R2 |-------->>| AS Y |
+-------+ | /+----+ +----+\ | +--------+
|/ \|
/------------------------\
eBGP ingress/ \eBGP egress
The method of ASPA-based AS_PATH verification at the eBGP egress of the BGP speaker is described as follows:¶
The egress verification procedure described above can produce incorrect results at R2 in some cases (see Figure 1). This is because at R1 there is direct knowledge (based on local configuration) of AS X's peering relation with the neighbor AS(N) while at R2 the procedure must rely on the ASPA data. But the ASPA data may be absent or insufficient. For example, let the AS(N) to AS X relationship be complex consisting of a C2P session and a p2p session. AS(N) has an ASPA that attests that AS X is a provider (per ASPA specification). Let the AS X to AS Y relationship be C2P or p2p. Then for a route originated by AS(N) and sent to AS X on the p2p session, the egress verification at R2 produces a Valid outcome. Only R1 knows that the route made ingress on a p2p session; R2 does not. In order that R2 does not forward the route to AS Y, it cannot rely on the outcome of the egress verification in this example. It is imperative that R1 attaches the Only to Customer (OTC) Attribute [RFC9234] to the route on ingress. Even if the ingress router R1 is not upgraded to perform ASPA verification (partial deployment of ASPA within an AS), it must be upgraded to do OTC (or minimally an intra-AS BGP Community that emulates the OTC Attribute for route leak prevention).¶
There can be a complex peering relationship on either side of AS X (with AS(N) or with AS Y).¶
If multiple eBGP sessions can segregate the Complex peering relationship into eBGP sessions with normal peering relationships the receiving/verifying AS SHOULD select the appropriate algorithm (for upstream or downstream paths per Sec. 5.4 or Sec. 5.5, respectively, in [I-D.ietf-sidrops-aspa-verification]) for each of the normal sessions based on its peering relation type.¶
If a Complex peering relation cannot 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 applying an appropriate algorithm (for upstream or downstream paths) on a per-prefix basis corresponding to the peering relation for the prefix. If this option is not feasible, then an operator MAY apply the algorithm for downstream paths to avoid false positive outcomes.¶
There would be concerns about the extra workload or redundancy of processing due to performing verification at both ingress and egress. There should be some optimizations implemented or available for use when appropriate so that redundant processing can be minimized. Examples of optimizations are:¶
Performing ASPA-based egress AS_PATH verification allows an eBGP router, in some cases, to prevent local route leaks and to help diagnose local peering misconfigurations and ASPA registration errors. The cases where these benefits may not materialize are: (1) eBGP peering relations are complex, or (2) the eBGP neighbor on the ingress side has no ASPA registration, or (3) the local AS is in an AS migration state. In the first and second cases, the egress ASPA algorithm (Section 3) could produce a false negative result but never a false positive and hence the behavior would be conservative (i.e., a valid route is not dropped). When there is AS migration, it is necessary that the local AS has conveyed to its customer ASes all the relevant AS numbers (temporary as well as the global AS ID) for correct ASPA registrations.¶
Egress AS_PATH verification will prevent misconfigurations of the egress router. If the local AS has multiple AS numbers, it is necessary to ensure that the AS number added to the AS_PATH at the egress is correct and whether it could lead to neighbors validating it as Invalid. Additionally, the local AS needs to check if any modifications to the AS_PATH in export policy are legitimate. Verification at the egress will prevent the local AS from advertising routes with invalid AS_PATHs, allowing for quick detection of issues and correction of local configuration errors.¶
Performing AS_PATH verification at the ingress can detect route leaks in the routes received from eBGP neighbors, but additional measures are needed to prevent local route leaks. As discussed in Section 3.1), the OTC Attribute helps prevent local routes leaks . Egress ASPA verification can also detect some (but not all) local route leaks.¶
If the local AS or customers have registration errors or omissions, they can be detected at the egress, allowing for quick identification of the issue. This mainly includes the following two scenarios:¶
(1) Case of local AS: If the local AS has omitted one or more providers in the Set of Provider ASes (SPAS) in its ASPA, the local AS may end up advertising routes with ASPA-invalid AS_PATH to its customers.¶
(2) Case of Customer AS: If a Customer of the local AS forgets to include the local AS in their SPAS, the local AS may end up advertising their routes with ASPA-invalid AS_PATH to its neighbors.¶
Performing AS_PATH verification at the egress could detect such registration errors immediately and point to its actual source clearly and noticeably; otherwise, routes advertised by the local AS may be filtered by other ASes, leaving the local AS unaware of the issue.¶
The peering relationships between the local AS and its external neighbor ASes, including Customer-Provider/Provider-Customer, Peer-Peer, Route Server (RS) and RS-client, mutual-transit, are used in path verification procedures to determine whether upstream or downstream procedures should be applied. There are the following possible ways to know the relations between the local AS and its external neighbor AS: (1) The first way is to use the BGP Role Capabilities exchanged in the BGP OPEN message as specified in [RFC9234]; (2) The second way is to use ASPA objects registered by the local AS and its external neighbor AS; (3) Another way is to use the local BGP peering configuration.¶
The security considerations that apply to ASPA-based AS_PATH verification (see [I-D.ietf-sidrops-aspa-verification]) also apply to the procedure described in this document.¶
This document has no IANA actions¶
The authors thank Nan Geng, Sriram Kotikalapudi and Randy Bush for their valuable suggestions and comments.¶