| Internet-Draft | Enhancement using ASPA and ASRA | July 2026 |
| Sriram, et al. | Expires 7 January 2027 | [Page] |
An Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS. While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 January 2027.¶
Copyright (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) record authorizes provider ASes of a customer (subject) AS [I-D.ietf-sidrops-aspa-profile]. While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers (see Appendix B and Section 7 of [I-D.ietf-sidrops-aspa-verification]). This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. The Cryptographic Message Syntax (CMS) protected content type for the RPKI ASRA object is defined in [I-D.geng-sidrops-asra-profile]. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers.¶
ASPA already has the capability of detecting forged-origin or forged-path-segment hijacks (Section 2) when a verifying AS receives a BGP Update from a customer or lateral peer. ASRA adds the capability of detecting the same when a verifying AS receives a BGP Update from a provider. A forged-origin or forged-path-segment hijack involves a fake link (i.e., forged AS peering). The ASRA algorithm operates in conjunction with ASPA in such a way that it fully preserves the route leak detection capabilities of ASPA while adding the fake link detection capability.¶
Incremental benefit is accrued by early adopters. An AS that deploys ASPA and ASRA prevents an offending AS from faking a link to it if the receiving/verifying AS also deploys ASPA and ASRA. The fake link will be detected by the receiving AS even if no other AS in the received AS path has adopted ASPA or ASRA.¶
The reader is expected to be familiar with the following related documents: [I-D.ietf-sidrops-aspa-profile], [I-D.ietf-sidrops-aspa-verification], [I-D.ietf-sidrops-8210bis].¶
The usage of terms follows Section 3 of [I-D.ietf-sidrops-aspa-verification].¶
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.¶
ASPA's properties of detection of forged-origin or forged-path-segment hijacks work only when the BGP Update is received from a customer or lateral peer (see Appendix B in [I-D.ietf-sidrops-aspa-verification]). The use of ASRA (together with ASPA) extends these properties to scenarios where the Update is received from a transit provider. This is achieved due to the added capability of detecting fake links in the AS path with the assistance of ASRAs. ASPA alone cannot detect fake links.¶
An example scenario is illustrated in Figure 1. Assume that all ASes shown in the Figure (the attacker AS(6) being a possible exception) register ASPA records and do ASPA-based AS_PATH verification. Where a link is marked C2P (Customer-to-Provider), it indicates that the AS shown below is a customer of the provider AS shown above. AS(1) originates the BGP route for prefix P which propagates to the other ASes. The AS_PATH received by AS(6) is path{5,4,3,2,1}. However, the misbehaving AS(6) shortens the path by faking a link with AS(2) and propagates the route to AS(7) with a shortened path {6,2,1} to AS(7). AS(7) fails to detect the manipulated path based on verification using only ASPAs. It chooses this path over the other valid path via AS(8). However, if ASRA is deployed by AS(2), then AS(2)'s ASPA and ASRA can indicate that AS(6) is not connected to AS(2), and the faked link from AS(6) to AS(2) will be detected. If ASRA is deployed by AS(1), AS(2), and AS(4) also, then AS(6) is prevented from conducting the forged-origin or forged-path segment type of attack on its customer AS(7) (in this scenario). The details about the registration of ASRA and the algorithms for AS path verification using ASPAs and ASRAs are provided in Section 3 and Section 4, respectively.¶
+-------+ +-------+ path{5,4,3,2,1}
| AS(4) |------| AS(5) |--------------
+-------+ +-------+ \
path{3,2,1}/ \ \ (C2P)
/(C2P) \ \
+-------+ \ +-------+
| AS(3) | path{5,4,3,2,1} \ | AS(8) |
+-------+ (C2P) \ +-------+
path{2,1} | \ |
(C2P) | \ |
+-------+ (Fake link) +-------+ |path{8,5,4,
| AS(2) |********************| AS(6) | | 3,2,1}
+-------+ +-------+ | (C2P)
path{1} | |path{6,2,1} |
(C2P) | (C2P)|(shortened) |
+-------+ +-------+ /
| AS(1) | | AS(7) |--------/
+-------+ +-------+
| (Origin) (Validating AS)
P
Figure 2 illustrates a scenario in which one customer AS(6) of the non-adopting provider AS(7) attacks the provider, which in turn propagates the attack (Update) to its other customer AS(5). In this example (Figure 2), the provider AS(7) has not adopted ASPA but all other ASes have. AS(5) is the receiver performing ASPA-based AS path verification. AS(6) conducts a fake-link (forged-origin) attack on AS(7) which accepts the route and propagates it to AS(5). AS(5) receives two routes (one each from AS(7) and AS(4)) and per-ASPA verification, the shorter route from AS(7) is Unknown while the longer route is Valid. But since both Valid and Unknown routes are eligible for path selection, AS(5) would select the shorter path from AS(7) and is thus deceived in effect by AS(6). If ASRA is deployed by AS(1) and AS(5), then AS(5) can detect and mitigate the fake-link (forged-origin) attack using ASRA and ASPA data (Section 4).¶
+-------+ +-------+
| AS(3) |---------------------------------| AS(4) |
+-------+ +-------+
path{2,1}/ |
/(C2P) path{4,3,2,1}|
+-------+ +-------+ (C2P) |
| AS(2) | | AS(7) | |
+-------+ +-------+ |
path{1} | path{6,1}/ \path{7,6,1} /
(C2P) | (C2P) / \(C2P) /
+-------+ (Fake link) +-------+ +-------+ /
| AS(1) |******************| AS(6) | | AS(5) |_/
+-------+ +-------+ +-------+
| (Origin) (Validating AS)
P
The term "Compliant AS" or "compliant BGP router" in this document refers to one that is compliant with the specifications in this document. A compliant AS that has a valid ASRA record MUST also have a valid ASPA record. A valid ASRA record for a signer (subject) AS that does not have a valid ASPA record MUST be ignored (considered unusable) for AS path verification purposes.¶
ASRA-C, ASRA-LP, and ASRA-CLP [I-D.geng-sidrops-asra-profile] are subcategories of ASRA distinguished by a subcategory field by setting its value to 1, 2, and 3, respectively. ASRA-C and ASRA-LP are used to register the lists of customers and lateral peers, respectively. Alternatively, if the subject AS does not wish to separately disclose customers and lateral peers, it MAY choose to register an ASRA-CLP to register the combined list of customers and lateral peers. An ASRA-compliant AS MUST either register ASRA-CLP alone or register both ASRA-C and ASRA-LP. To signal that there are no neighbors to report in a subcategory, AS 0 MUST be included in the corresponding ASRA subcategory in the payload field.¶
If it is found that an AS has X.509 valid ASRA-CLP and simultaneously has X.509 valid ASRA-C and/or ASRA-LP, then only the ASRA-CLP MUST be considered for AS path verification and the ASRA subcategories ASRA-C and ASRA-LP MUST be ignored.¶
It is highly RECOMMENDED that an AS (compliant signer AS) register and maintain either a single ASRA-CLP object or a single object of each subcategory ASRA-C and ASRA-LP. Such a practice helps prevent race conditions during ASRA updates. If multiple X.509 valid ASRAs of a subcategory exist for a given subject AS, the ASes listed in all such ASRAs will be combined (by the relying party) into one list of neighbors of the subcategory in consideration. This combined list will be used for AS path verification purposes.¶
All neighbors that are customers or lateral peers of the signer AS MUST be included in an ASRA(s) of an appropriate subcategory following the above-mentioned recommendations.¶
A pair of compliant ASes in a mutual transit relationship are required to include each other in their respective ASPA (Sec. 4 of [I-D.ietf-sidrops-aspa-verification]). They MUST NOT further include each other in ASRA-C, ASRA-LP, or ASRA-CLP.¶
If a compliant AS has a complex relationship with a neighbor AS, where one of the relationships is Provider, then the compliant AS must include the neighbor AS in its ASPA (Sec. 4 of [I-D.ietf-sidrops-aspa-verification]). (Note: By the term "relationship is foo" it is meant here that the neighbor's role is foo.) The AS MUST NOT further include the other AS in ASRA-C, ASRA-LP, or ASRA-CLP. A compliant AS that has a complex relationship with a neighbor AS where none of the relationships are Provider implies that its relationships with the neighbor AS are customer and lateral peer. In such a case, the AS MUST include the neighbor AS in its ASRA-CLP if doing ASRA-CLP, otherwise in its ASRA-C as well as ASRA-LP.¶
The Route Server (RS) to RS-client relationship is similar to the provider-to-customer relationship. So, a compliant non-transparent RS AS MUST either (1) list all its RS-clients as customers in ASRA-CLP, or (2) list all its RS-clients as customers in ASRA-C and register an ASRA-LP with only AS 0 listed in the set of lateral peers.¶
Transparent Internet Exchange RS AS case:¶
In the case of a transparent RS AS, the peering between any pair of clients is effectively lateral peering (note that the RS AS is absent in the AS_PATH). There are three possible methods proposed here for discovering the effective lateral peering relationships in this scenario for the purposes of AS_PATH verification:¶
Method 1: A fourth ASRA subcategory type, named ASRA-TIX (subcategory value set to 4), is used by a transparent RS AS to register itself. A transparent RS AS SHOULD register an ASRA-TIX, and an RS client at that RS AS SHOULD include the registered RS AS in the Set of Provider ASes (SPAS) of its ASPA. When two adjoining ASes in an AS_PATH are found to have included the same RS AS (from an ASRA-TIX) in their respective SPAS, they are considered lateral peers for AS_PATH verification purposes.¶
Method 2: This method uses a different semantic for ASRA-TIX. Here ASRA-TIX is used by a transparent RS AS to not only register itself but also to register a list of all its RS clients. A transparent RS AS SHOULD register an ASRA-TIX. When two adjoining ASes in an AS_PATH are found to be included in the client list of the same ASRA-TIX, they are considered lateral peers for AS_PATH verification purposes.¶
Method 3: Typically, an Internet Exchange (IX) with an RS publishes a list of all its RS clients so that each RS client can choose which other clients to peer with. The peering relationships are normally set up by using BGP Community tags or through policies configured at the RS AS. An RS client of a transparent RS AS SHOULD include in its ASRA (ASRA-LP preferably or ASRA-CLP) all the AS numbers of other RS clients that it peers with at the RS. If an RS client has selected to receive all routes from a transparent RS AS, then the RS client SHOULD include in the ASRA (ASRA-LP preferably or ASRA-CLP) the full published list of RS clients of the transparent RS.¶
Authors' notes: The SIDROPS WG's feedback and guidance will be sought about these methods. The ideas from the above methods may be combined into one comprehensive proposal for ASRA registrations for the transparent RS AS case.¶
In this section, two algorithms are described which enhance AS path verification by augmenting ASPA-based verification [I-D.ietf-sidrops-aspa-verification] with ASRA data. The basic principles behind each algorithm are explained. (The intention is that the SIDROPS WG discussions will help decide which algorithm to select.)¶
Same as in Sec. 5.1 of [I-D.ietf-sidrops-aspa-verification], let the sequence COMPRESSED_AS_PATH {AS(N), AS(N-1),..., AS(2), AS(1)} represent the AS_PATH after removing consecutive duplicate ASNs, where AS(1) is the origin AS, and AS(N) is the most recently added AS as well as a neighbor of the receiving/verifying AS. AS(N+1) represents the local (receiving/verifying) AS; it does not explicitly appear in the description of the AS_PATH verification procedures. COMPRESSED_AS_PATH is used in the verification procedures.¶
For a given AS hop, say AS(i) to AS(i+1), AS(i) is the sender and AS(i+1) is the receiver. For each such AS hop in the COMPRESSED_AS_PATH, the algorithms seek to check if the hop is a fake link, i.e., AS(i+1) forging a connection to AS(i).¶
In the descriptions that follow, a valid ASPA or ASRA is one that is X.509 valid.¶
For a given AS hop AS(i) to AS(i+1), algorithm A gives precedence to the ASPA created by the receiver AS(i+1) over the ASRA created by the sender AS(i), and hence it is less strict (compared to Algorithm B (Section 4.3)). Algorithm A can be used under the assumption that AS(i+1) is very unlikely to create a false ASPA record (i.e., falsely asserting that AS(i) as a provider) because it is a digitally signed object and hence repudiation is arguably hard. However, this algorithm does not guard against the creation of a false ASPA record, and when that is a concern, the stricter Algorithm B (Section 4.3) SHOULD be used. In Algorithm B, an ASPA assertion in the direction opposed to the Update flow (i.e., AS(i+1)'s assertion using ASPA that AS(i) is Provider) can be superceded by a contrary ASPA+ASRA assertion in the opposite direction of the Update flow (i.e., AS(i)'s assertion using ASPA+ASRA that AS(i+1) is not connected).¶
Both algorithms do not give any consideration to an ASRA assertion in the direction opposite to the Update flow, i.e., within the context of AS_PATH verification, the ASRA assertion of AS(i+1) about AS(i) is not utilized. The reason for this can be illustrated by a simple example: AS(i+1) using ASRA-C falsely asserts that AS(i) is a customer -- when in fact it is a provider -- for the purpose of evading route leak detection.¶
The following is the procedure (per Algorithm A) for determining if the AS(i) to AS(i+1) hop in the AS path is a fake link.¶
If AS(i) has valid ASPA(s) and they do not include AS(i+1) as a Provider,¶
AND if AS(i) has valid ASRA(s) and they do not include AS(i+1) as a customer or lateral peer,¶
AND {EITHER AS(i+1) has no valid ASPA OR {AS(i+1) has valid ASPA(s) and they do not include AS(i) as a Provider},¶
then set Fake-Link(AS(i), AS(i+1)) = Detected,¶
Else, set Fake-Link(AS(i), AS(i+1)) = Not Detected.¶
Remains unchanged and the same as described in Section 5.4 of [I-D.ietf-sidrops-aspa-verification].¶
The parameters min_up_ramp and min_down_ramp represent ramp lengths (in # ASes), and are computed using only ASPAs (see Section 5.3 of [I-D.ietf-sidrops-aspa-verification] and Figure 3 below).
Successive ASPAs affirm the up-ramp from AS(1) to AS(K), where K = min_up_ramp.
The up-ramp stops at AS(K) because AS(K) does not have a valid ASPA or its valid ASPA(s) do not include AS(K+1) as a provider.
The down-ramp from AS(L) to AS(N) is also affirmed by successive ASPAs, where L = N - min_down_ramp + 1.
The top of the down-ramp is at AS(L) because AS(L) does not have a valid ASPA or its valid ASPA(s) do not include AS(L-1) as a provider.¶
L = N - min_down_ramp + 1 K = min_up_ramp
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
(customer)
Each ramp has consecutive ASPA-attested
customer-to-provider hops in the bottom-to-top direction
First, run the verification algorithm for downstream paths as described in Section 5.5 of [I-D.ietf-sidrops-aspa-verification]. The obtained outcome is one of these: Valid, Invalid, Unknown. Now enhance the outcome using the following algorithm where ASRA data is applied. For the Fake-Link(AS(i), AS(i+1)) function, use the one described in Section 4.2.1.¶
If the outcome is Invalid, it remains unchanged and the procedure halts.¶
Else, if min_up_ramp = N or {min_up_ramp + min_down_ramp} > N, then the outcome remains unchanged (Valid) and the procedure halts.¶
Else, if for any i value from min_up_ramp to (N - min_down_ramp), Fake-Link(AS(i), AS(i+1)) = Detected, then change the outcome to Invalid and the procedure halts.¶
Else, if for any i value from (min_up_ramp + 1) to (N - min_down_ramp), if AS(i) has ASPA and ASRA asserting that AS(i+1) is a lateral peer (and not a Provider or Customer), then change the outcome to Invalid and the procedure halts.¶
Else, the outcome remains unchanged and the procedure halts.¶
In Step 3, the algorithm tries to determine if the AS_PATH is Invalid due to the presence of a fake link. In Step 4, the algorithm tries to utilize ASPA and ASRA information of one AS to detect a route leak while compensating for the lack of ASPA information of the next AS in the AS_PATH. This speaks to the added benefit of ASRA to detect route leaks which would have been missed otherwise due to partial deployment of ASPA.¶
As mentioned earlier in Section 4.1, Algorithm B does not give precedence to the ASPA created by the receiver AS(i+1) over the ASRA created by the sender AS(i), and hence it is strict (compared to Algorithm A). This algorithm considers the possibility that AS(i+1) could maliciously create a false ASPA record (i.e., falsely include AS(i) as a provider) to try evading fake link detection.¶
The following is the procedure (per Algorithm B) for determining if the AS(i) to AS(i+1) hop in the AS path is a fake link.¶
Remains unchanged and the same as described in Section 5.4 of [I-D.ietf-sidrops-aspa-verification].¶
Here the min_up_ramp parameter is the same as discussed in Section 4.2.2.2. First, run the verification algorithm for downstream paths as described in Section 5.5 of [I-D.ietf-sidrops-aspa-verification]. The obtained outcome is one of these: Valid, Invalid, Unknown. Now enhance the outcome using the following algorithm where ASRA data is applied. For the Fake-Link(AS(i), AS(i+1)) function, use the one described in Section 4.3.1.¶
If the outcome is Invalid, it remains unchanged and the procedure halts.¶
Else, if min_up_ramp = N, then also the outcome remains unchanged (Valid) and the procedure halts.¶
Else, if for any i value from min_up_ramp to (N - 1), Fake-Link(AS(i), AS(i+1)) = Detected, then change the outcome to Invalid and the procedure halts.¶
Else, if for any i value from (min_up_ramp + 1) to (N - 1), if AS(i) has ASPA and ASRA asserting that AS(i+1) is a lateral peer (and not a Provider or Customer), then change the outcome to Invalid and the procedure halts.¶
Else, the outcome remains unchanged and the procedure halts.¶
Every AS operator doing ASPA/ASRA SHOULD periodically check their own ASPA/ASRA objects for correctness and completeness. They SHOULD also ensure that the same are refreshed well before their expiry dates.¶
Every AS operator doing ASPA SHOULD periodically monitor all the ASPAs in the RPKI repositories to check if their AS number is incorrectly included or incorrectly not included as a provider in an ASPA (X.509 valid), and if so, they SHOULD report it to the responsible parties so that the ASPA can be rectified.¶
Every AS operator doing ASRA SHOULD periodically monitor all the ASRAs in the RPKI repositories to check if their AS number is incorrectly included or incorrectly not included in an ASRA (X.509 valid), and if so, they SHOULD report it to the responsible parties so that the ASRA can be rectified.¶
Security concerns for AS path verification using ASPA and ASRA are largely alleviated if the operational recommendations (Section 5) are followed.¶
This document does not have IANA considerations.¶
The authors wish to thank Mingqing (Michael) Huang, Alexander Azimov, Jeff Haas, Doug Montgomery, and Oliver Borchert for very helpful comments and discussions.¶