Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification
draft-sriram-sidrops-asra-verification-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Kotikalapudi Sriram , Nan Geng , Amir Herzberg | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sriram-sidrops-asra-verification-05
sidrops K. Sriram
Internet-Draft NIST
Intended status: Standards Track N. Geng
Expires: 7 January 2027 Huawei
A. Herzberg
University of Connecticut
6 July 2026
Autonomous System Relationship Authorization (ASRA) as an Extension to
ASPA for Enhanced AS Path Verification
draft-sriram-sidrops-asra-verification-05
Abstract
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.
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 7 January 2027.
Sriram, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Enhancement using ASPA and ASRA July 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. AS Path Security Problems Addressed by ASRA . . . . . . . . . 4
2.1. Fake-Link Attack: Provider Attacking a Customer . . . . . 4
2.2. Fake-Link Attack: Customer Attacking its Non-Adopting
Provider and Other Customers . . . . . . . . . . . . . . 5
3. ASRA Registration Recommendations . . . . . . . . . . . . . . 6
4. Algorithms for Enhancement of AS Path Verification Using
ASRA . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Overview Comments About Algorithms A and B . . . . . . . 9
4.2. Algorithm A (Less Strict) . . . . . . . . . . . . . . . . 9
4.2.1. Fake Link Determination (Alg. A) . . . . . . . . . . 9
4.2.2. Enhancement to AS Path Verification Using ASRA (Alg.
A) . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Algorithm B (Strict) . . . . . . . . . . . . . . . . . . 11
4.3.1. Fake Link Determination (Alg. B) . . . . . . . . . . 11
4.3.2. Enhancement to AS Path Verification Using ASRA (Alg.
B) . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Operational Considerations . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Sriram, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Enhancement using ASPA and ASRA July 2026
1. Introduction
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].
1.1. Terminology
The usage of terms follows Section 3 of
[I-D.ietf-sidrops-aspa-verification].
Sriram, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Enhancement using ASPA and ASRA July 2026
1.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.
2. AS Path Security Problems Addressed by ASRA
2.1. Fake-Link Attack: Provider Attacking a Customer
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.
Sriram, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Enhancement using ASPA and ASRA July 2026
+-------+ +-------+ 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 1: AS_PATH shortened by a misbehaving provider.
2.2. Fake-Link Attack: Customer Attacking its Non-Adopting Provider and
Other Customers
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).
Sriram, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Enhancement using ASPA and ASRA July 2026
+-------+ +-------+
| 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
Figure 2: Customer attacking its non-adopting provider and
another customer.
3. ASRA Registration Recommendations
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
Sriram, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Enhancement using ASPA and ASRA July 2026
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
Sriram, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Enhancement using ASPA and ASRA July 2026
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.
4. Algorithms for Enhancement of AS Path Verification Using ASRA
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.
Sriram, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Enhancement using ASPA and ASRA July 2026
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.
4.1. Overview Comments About Algorithms A and B
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.
4.2. Algorithm A (Less Strict)
4.2.1. Fake Link Determination (Alg. A)
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},
Sriram, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Enhancement using ASPA and ASRA July 2026
* then set Fake-Link(AS(i), AS(i+1)) = Detected,
* Else, set Fake-Link(AS(i), AS(i+1)) = Not Detected.
4.2.2. Enhancement to AS Path Verification Using ASRA (Alg. A)
4.2.2.1. Algorithm for Upstream Paths
Remains unchanged and the same as described in Section 5.4 of
[I-D.ietf-sidrops-aspa-verification].
4.2.2.2. Algorithm for Downstream Paths (Alg. A)
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
Figure 3: Illustration of min-up-ramp and min-down-ramp
Sriram, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Enhancement using ASPA and ASRA July 2026
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.
1. If the outcome is Invalid, it remains unchanged and the procedure
halts.
2. Else, if min_up_ramp = N or {min_up_ramp + min_down_ramp} > N,
then the outcome remains unchanged (Valid) and the procedure
halts.
3. 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.
4. 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.
5. 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.
4.3. Algorithm B (Strict)
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.
4.3.1. Fake Link Determination (Alg. B)
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.
Sriram, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Enhancement using ASPA and ASRA July 2026
* 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,
* then set Fake-Link(AS(i), AS(i+1)) = Detected,
* Else, set Fake-Link(AS(i), AS(i+1)) = Not Detected.
4.3.2. Enhancement to AS Path Verification Using ASRA (Alg. B)
4.3.2.1. Algorithm for Upstream Paths
Remains unchanged and the same as described in Section 5.4 of
[I-D.ietf-sidrops-aspa-verification].
4.3.2.2. Algorithm for Downstream Paths (Alg. B)
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.
1. If the outcome is Invalid, it remains unchanged and the procedure
halts.
2. Else, if min_up_ramp = N, then also the outcome remains unchanged
(Valid) and the procedure halts.
3. 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.
4. 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.
5. Else, the outcome remains unchanged and the procedure halts.
Sriram, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Enhancement using ASPA and ASRA July 2026
5. Operational Considerations
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.
6. Security Considerations
Security concerns for AS path verification using ASPA and ASRA are
largely alleviated if the operational recommendations (Section 5) are
followed.
7. IANA Considerations
This document does not have IANA considerations.
8. Acknowledgements
The authors wish to thank Mingqing (Michael) Huang, Alexander Azimov,
Jeff Haas, Doug Montgomery, and Oliver Borchert for very helpful
comments and discussions.
9. References
9.1. Normative References
[I-D.ietf-sidrops-aspa-verification]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
J., and K. Sriram, "BGP AS_PATH Verification Based on
Autonomous System Provider Authorization (ASPA) Objects",
Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
verification-26, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-26>.
Sriram, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Enhancement using ASPA and ASRA July 2026
[I-D.ietf-sidrops-aspa-profile]
Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley,
R., and B. Maddison, "A Profile for Autonomous System
Provider Authorization", Work in Progress, Internet-Draft,
draft-ietf-sidrops-aspa-profile-27, 19 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-27>.
[I-D.geng-sidrops-asra-profile]
Geng, N., Sriram, K., and M. Huang, "A Profile for
Autonomous System Relationship Authorization (ASRA)", Work
in Progress, Internet-Draft, draft-geng-sidrops-asra-
profile-03, 20 April 2026,
<https://datatracker.ietf.org/doc/html/draft-geng-sidrops-
asra-profile-03>.
[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>.
[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>.
9.2. Informative References
[I-D.ietf-sidrops-8210bis]
Bush, R., Austein, R., and T. Harrison, "The Resource
Public Key Infrastructure (RPKI) to Router Protocol,
Version 2", Work in Progress, Internet-Draft, draft-ietf-
sidrops-8210bis-25, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
8210bis-25>.
Authors' Addresses
Kotikalapudi Sriram
NIST
Gaithersburg, MD 20899,
United States of America
Email: ksriram@nist.gov
Nan Geng
Huawei
Beijing
China
Sriram, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Enhancement using ASPA and ASRA July 2026
Email: gengnan@huawei.com
Amir Herzberg
University of Connecticut
Storrs, CT 06269,
United States of America
Email: amir.herzberg@uconn.edu
Sriram, et al. Expires 7 January 2027 [Page 15]