ASPA-based AS_PATH Verification for BGP Export
draft-zhang-sidrops-aspa-egress-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 | Jia Zhang , Yangyang Wang , Maria Matějka , Mingwei Xu , Kotikalapudi Sriram , Nan Geng | ||
| Last updated | 2026-07-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-zhang-sidrops-aspa-egress-05
SIDR Operations Working Group J. Zhang
Internet-Draft Zhongguancun Laboratory
Intended status: Standards Track Y. Wang
Expires: 6 January 2027 Tsinghua University
M. Matejka
CZ.NIC
M. Xu
Tsinghua University
K. Sriram
USA NIST
N. Geng
Huawei
5 July 2026
ASPA-based AS_PATH Verification for BGP Export
draft-zhang-sidrops-aspa-egress-05
Abstract
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 inadvertent propagation of
route leaks to external peers, check for local misconfigurations, and
help detect potential ASPA registration errors. This approach
complements ingress-side verification and BGP Roles/Only to Customer
(OTC); it also provides operational assurance for partial deployment
and for export-side configuration or registration problems.
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 6 January 2027.
Zhang, et al. Expires 6 January 2027 [Page 1]
Internet-Draft ASPA-based AS_PATH Verification for BGP 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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Partial ASPA ingress and BGP Roles deployment . . . . . . 4
3.2. Missing Provider in ASPA record . . . . . . . . . . . . . 5
3.3. Network merging and splitting . . . . . . . . . . . . . . 6
3.4. Advanced AS_PATH Manipulation . . . . . . . . . . . . . . 6
4. Procedure of ASPA-based AS_PATH Verification at eBGP
Egress . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Basic Egress Verification . . . . . . . . . . . . . . . . 6
4.2. Neighbor-AS-Augmented Verification . . . . . . . . . . . 7
5. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Centralized or Detached Verification . . . . . . . . . . 8
5.2. Deployment Controls . . . . . . . . . . . . . . . . . . . 8
5.3. Partial Verification . . . . . . . . . . . . . . . . . . 9
6. Using the Only to Customer (OTC) Attribute . . . . . . . . . 10
7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Zhang, et al. Expires 6 January 2027 [Page 2]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
1. Introduction
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].
Section 5 of [I-D.ietf-sidrops-aspa-verification] describes the
procedures to perform ASPA-based BGP AS_PATH verification at eBGP
ingress. This document additionally explains the reasons, use cases,
scenarios, variants and specifics of ASPA-based BGP AS_PATH
verification at eBGP egress and in detached or monitoring
configurations, in a similar way as [RFC8893] did with RPKI route
origin validation (RPKI-ROV) for BGP export.
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 is not intended to question
the adequacy of ingress ASPA verification. Egress verification is an
additional local assurance mechanism for export behavior, partial
deployment, and operational error detection.
1.1. 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. Suggested Reading
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], RPKI-ROV for BGP
export[RFC8893], and BGP Roles[RFC9234].
The definitions of Customer, Provider, Route Server, Route Server
Client and Peer, used in this document, are the same as in BGP
Roles[RFC9234].
Zhang, et al. Expires 6 January 2027 [Page 3]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
3. Problem Statement
ASPA-based AS_PATH verification at eBGP egress is motivated by
multiple operational scenarios. In partial deployment, some ingress
ASBRs may not yet support ASPA verification or BGP Roles while some
egress ASBRs or detached verification systems do. Egress
verification may then provide useful coverage for routes that would
otherwise leave the AS without ASPA-based export checks. Operational
assurance is another motivation: locally originated routes, ASPA
registration mistakes, local AS number mistakes, AS migration, and
export policy or AS_PATH manipulation may cause a route that was
valid on ingress, or was never checked on ingress, to become invalid
once exported to neighbors.
The AS_PATH verification errors may happen in a subtle way, e.g. on
routes propagated only to one neighbor, or even routes intended as
backup, ordinarily not selected as best. This is a difference
compared to Route Origin Verification where errors are often seen
nicely in public BGP analysis tools.
3.1. Partial ASPA ingress and BGP Roles deployment
ASPA and BGP Roles may be deployed incrementally inside a network.
In large networks, it is common for ASBRs to be upgraded in stages,
for older routers to remain in service for some time, or for
different border routers to support different sets of features. As a
result, an ingress ASBR may be unable to perform ASPA-based AS_PATH
verification or to attach the intended BGP Role or OTC-derived intra-
AS signal, while an egress ASBR or a detached verification system may
already have the necessary capability.
In such partial-deployment environments, egress verification can
provide additional coverage for routes that would otherwise leave the
AS without ASPA-based export checks. This is especially useful when
full-table routes received at an unupgraded ingress router are later
propagated toward customer-facing, peer-facing, or provider-facing
egress points that do support ASPA validation.
Egress verification in this scenario is a staged-deployment aid and a
local assurance mechanism. It does not replace BGP Roles, OTC, or an
equivalent intra-AS leak-prevention signal when such marking is
available. Instead, it allows an operator to gain useful
verification coverage before all ingress ASBRs have been upgraded,
and to detect export-side problems closer to the point where routes
leave the AS.
Zhang, et al. Expires 6 January 2027 [Page 4]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
3.2. Missing Provider in ASPA record
When a network (AS N) fails to publish a complete ASPA record and
omits a certain provider (AS P), all routes sent through this BGP
session become invalid when their AS_PATHs are checked later by a
peer (AS Q) or provider (AS Y) of AS P, or any other AS later on the
path.
Let's assume that AS N is otherwise configured well and announces
only its own routes and its customers' routes to its providers.
Also, all customers of N have either well configured ASPA or no ASPA
at all. Then, all routes announced to AS P by AS N have AS_PATH
which begins with AS N and possibly continues with other AS numbers.
Such an AS_PATH is evaluated as ASPA Valid or Unknown by the Upstream
algorithm as specified in [I-D.ietf-sidrops-aspa-verification],
section 5.4, based on the published customers' ASPA.
AS P then redistributes these routes to its providers (AS Y) and
peers (AS Q). On egress eBGP, AS P is prepended to AS_PATH as
specified in [RFC4271], section 5.1.2. In turn, this path is
evaluated at AS Y and AS Q by the Upstream algorithm again, but as P
is NotProvider+ of N, all the routes suddenly appear ASPA Invalid.
In the early adoption days, this scenario may happen even farther
from the mistaken network, possibly leading to mysterious misrouting.
It is also possible that the mistakenly omitted network is a backup
provider, and the invalid routes get propagated only in case of a
primary link failure, which may act as an additional deterrent for
early ASPA adoption.
+-----------------+
| AS Y |
+-----------------+
|
+---------------+ +-------------+
| AS P |------| AS Q |
| Providers: Y | | Peer of P |
+---------------+ +-------------+
|
+---------------------+
| AS N |
| Providers missing P |
+---------------------+
Figure 1: Missing Provider illustration
Zhang, et al. Expires 6 January 2027 [Page 5]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
3.3. Network merging and splitting
When a single entity controls multiple autonomous systems, they may
decide to merge them, or in reverse, they may decide to split one AS
to multiple AS's, or they simply decide to renumber their AS. This
process almost never happens atomically, and while there are multiple
approaches, almost always there are transitional periods when a
single AS uses multiple AS numbers.
These cases include situations when one BGP speaker receives a route
via eBGP, acting as AS M, but that route is then sent over e.g.
confederated eBGP to another BGP speaker which announces the route
via eBGP, acting as a different AS N. Generally, all mentioned
problems should be mitigated by first extending all ASPA records by
the new AS number, and removing the old one only after it's been
disused, but ASPA-based AS_PATH verification on BGP egress ensures
that all needed ASPA records have indeed been updated accordingly.
3.4. Advanced AS_PATH Manipulation
There are various common AS_PATH manipulation techniques. The most
common one is AS_PATH Stuffing where the local AS number is prepended
multiple times before exporting to a neighboring network, so that the
resulting route is depreferenced, and possibly used as a backup link
should the main link fail.
If the network operator happens to make a typo in their own AS number
[bgp-typo] or any other configuration mistake involving their AS_PATH
manipulation, they may accidentally introduce a path invalidity.
Running ASPA-based AS_PATH verification on BGP egress catches these
mistakes early on, possibly before actually propagating the route.
These cases generally include scenarios when a neighboring network
thinks that their neighbor is AS M, while their routes are later
announced with AS N prepended instead. In such scenarios, if the
neighboring network includes only AS M as their provider, the route
becomes invalid later on in a similar way as described in the
previous section.
4. Procedure of ASPA-based AS_PATH Verification at eBGP Egress
4.1. Basic Egress Verification
Any BGP speaker advertising routes to other autonomous systems via
eBGP (egress) SHOULD run ASPA-based AS_PATH Verification to avoid
sending routes with invalid AS_PATHs. The procedure is modified so
that it simulates what may be the outcome of the ASPA-based AS_PATH
Verification done later by other networks.
Zhang, et al. Expires 6 January 2027 [Page 6]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
The egress AS_PATH Verification SHOULD be performed on all routes
possibly eligible for being propagated at egress, not just the
current best route. This would help detecting misconfiguration in
early stages of deployment, and generally prevent the case of
unexpected backup link failure.
The egress AS_PATH Verification MUST be performed on the AS_PATH
already updated according to [RFC4271], section 5.1.2. That ensures
that the route looks like what the neighboring AS would receive from
the egress speaker.
If the neighboring AS is a Provider or a Peer, or a (transparent or
non-transparent) Route Server (RS) while the egress speaker is an RS-
client, the egress speaker runs the Upstream Verification Procedure,
as specified in [I-D.ietf-sidrops-aspa-verification], section 5.4.
If the neighboring AS is a Customer, the egress speaker runs the
Downstream Verification Procedure.
To select the appropriate verification procedure, the egress speaker
needs reliable information about the relationship between the local
AS and the egress neighbor AS. This information may be obtained from
BGP Role capabilities exchanged in the BGP OPEN message, ASPA objects
registered by the local AS and the external neighbor AS, or local BGP
peering and export-policy configuration.
If the relationship is Complex, the egress speaker SHOULD logically
segregate the single eBGP session into regular BGP Roles, and then
apply the verification procedures accordingly. If such a segregation
is not feasible, the egress speaker SHOULD determine the appropriate
verification procedure on a per-prefix basis. If this determination
is not feasible as well, then an operator MAY apply the algorithm for
downstream paths to avoid false positive outcomes.
In all cases, if the AS_PATH Verification result is Invalid, the
egress speaker SHOULD NOT propagate the affected route to that
specific neighbor, and a notification SHOULD be sent to the human
operators of the network.
4.2. Neighbor-AS-Augmented Verification
For operational assurance, especially to detect missing Provider ASes
in ASPA records, an implementation or detached verification system
(see Section 5.1) SHOULD support a verification mode that, for the
process of verification only, also prepends the neighboring AS number
when the neighboring AS is a Provider or a Customer. Otherwise, if
the provider-customer relationship is not properly reflected in the
published ASPA, the route may fail AS_PATH Verification later, as
described in Section 3.2.
Zhang, et al. Expires 6 January 2027 [Page 7]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
This neighbor-AS-augmented verification is most naturally used in
detached, offline, or monitoring configurations. Use of this mode
for inline egress enforcement is a matter of local policy and should
consider router processing cost, deployment maturity, and the
operator's intended treatment of Invalid results.
5. Optimizations
Running AS_PATH Verification for all routes at all eBGP egress may
hamper routing performance and cause unnecessary propagation delays.
In order to make the verification possible on larger scales, there
are several approaches to optimize the verification process.
Optimized egress verifications, if deployed properly, are sufficient
to detect both ASPA misconfigurations and AS Path manipulation
errors.
5.1. Centralized or Detached Verification
If the network has a BGP Route Reflector ([RFC4456]) or another
centralized control-plane node, the egress ASPA processing may be
offloaded to that node. This is feasible only when the verifying
node has sufficient per-egress context, including the egress ASBR,
the local AS number used at that egress point, the neighboring AS
number, the applicable BGP Role or local relationship, and any
export-policy context needed to simulate the egress AS_PATH. Without
this metadata, centralized verification may be incomplete or
inefficient, and is primarily useful for monitoring and operational
assurance unless it can affect the actual egress ASBR's export
decision.
It is also possible to collect routes by other means, e.g. by the BGP
Monitoring Protocol[RFC7854], and run the verification in a
completely detached configuration. While this configuration doesn't
allow for immediate route withdrawal in case of the verification
result being Invalid, it keeps the optimization advantages and allows
for easy notifications.
5.2. Deployment Controls
Operators may need controls to enable, disable, or change the
enforcement mode of egress verification as deployment evolves. Such
controls are deployment controls, not a replacement for the
verification procedure. For example, an operator may choose alert-
only or detached verification when the goal is operational assurance,
or may disable inline egress verification for a class of routes once
the relevant ingress ASPA verification and OTC or equivalent intra-AS
leak-prevention marking are deployed and the remaining motivation is
Zhang, et al. Expires 6 January 2027 [Page 8]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
already covered by local policy.
Such controls only affect how this document's egress verification is
enforced for selected routes or sessions. They do not disable ASPA,
OTC, or ingress ASPA verification, and they do not imply that ASPA-
based verification is unnecessary. They are not appropriate for
scenarios where the operator still wants egress verification to
detect AS migration mistakes, AS_PATH manipulation mistakes, ASPA
registration omissions, or other export-side operational errors.
5.3. Partial Verification
For routes received by the local AS from outside, part of the AS_PATH
should have been already validated by the ingress BGP speaker. If
the verifying node can determine which prefix of the AS PATH is not
yet verified, it MAY skip re-verifying the received part of the path,
and compose the ingress result with the local part. Otherwise, the
verifier should perform full AS_PATH verification. Partial
verification is a scoped optimization, not a relaxation of ASPA-based
AS_PATH verification.
For the simple case as described in Section 4, the egress
verification procedure would check the local AS number and, when
neighbor-AS-augmented verification is used, the neighbor's AS number
against the local ASPA database. This procedure SHOULD be automated
based on the BGP Role setting for that specific neighbor, even if the
other side doesn't support the BGP Role capability.
1. If the local AS is a Customer of the neighbor AS, which is a
Provider, then all the routes sent by local AS to the neighbor
will end up having an AS_PATH (… P, C, …) where at least the
maximum up ramp extends at least to P. Therefore, the simple
partial verification SHOULD periodically check whether P is
indeed not NotProvider+ of C.
2. If the local AS is a Provider of the neighbor AS, which is a
Customer, then all the routes sent by local AS to the neighbor
will end up having an AS_PATH (… C, P, …), where at least the
maximum down ramp extends at least to P. Therefore, the simple
partial verification SHOULD periodically check whether P is
indeed not NotProvider+ of C.
3. If the local AS is a lateral Peer of the neighbor AS, which is
therefore also a Peer, there is no need for any check, as well as
if the local AS is a Route Server Client.
Zhang, et al. Expires 6 January 2027 [Page 9]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
In case of failure of the simple periodic check, described in
previous paragraphs, the affected node SHOULD NOT propagate any route
over the affected eBGP session. The verifying node (which may be a
different node) SHOULD notify both the affected node and the human
operators of the network.
If the network does some complex AS_PATH modification (e.g., during
AS merges, splits, or renumbering transitions), the operator should
do a proper assessment of possible partial verification approaches,
which may include the aforementioned pair verifications, and maybe
other verifications as well. In such cases, it is recommended to
verify the full AS_PATH, since registration errors or omissions
frequently occur during these transitions. The full extent of
possible verifications is out of scope of this document.
6. Using the Only to Customer (OTC) Attribute
This document does not replace BGP Roles and the Only to Customer
(OTC) BGP Attribute[RFC9234]. It is expected that the ingress BGP
speaker marks the routes received on ingress accordingly, either by
OTC, or by some other means (e.g. Large Communities[RFC8092]). If
the routes are not marked, the egress verification procedure
described above may produce incorrect results.
+------------------------+
| AS X |
| |
+-------+ eBGP | +----+ iBGP +----+ | eBGP +--------+
| AS(N) |------->>| R1 |------->>| R2 |-------->>| AS Y |
+-------+ | +----+ +----+ | +--------+
| |
+------------------------+
eBGP ingress eBGP egress
Figure 2: Illustration of eBGP ingress, iBGP propagation, and
eBGP egress.
In Figure 2, R1 has direct local knowledge of the relationship
between AS X and AS(N), while R2 may only have the route as
propagated inside AS X. If the route is marked by OTC or by an
equivalent intra-AS leak-prevention signal, that marking MUST take
precedence over the outcome of egress ASPA verification. In
particular, if the marking says that the route MUST NOT be exported
to the egress neighbor, the egress speaker MUST NOT export the route
based on a Valid egress ASPA result.
Zhang, et al. Expires 6 January 2027 [Page 10]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
Specifically, while providers are easily distinguishable from the
local network's ASPA record, it is impossible to tell whether a
specific neighboring network is a customer or a peer, if they have
not signed their ASPA. With that, it's impossible and undesirable to
replace OTC by ASPA-based AS_PATH Verification on BGP egress.
7. Operational Considerations
The ASPA-based AS_PATH verification on eBGP egress is not a complete
solution on its own. There may be both false positive and false
negative results arising from e.g. outdated ASPA database, or
superfluous providers in an ASPA record. The records also do change
over time and the verification results with them.
It is expected that the operators will closely monitor all Invalid
ASPA verification results, and act accordingly. In most cases, these
results are caused by human errors, either local, or by a neighboring
network. If the operators determine that the Invalid result is
caused by a neighboring network, they SHOULD notify the operators of
that network in a timely manner.
If it is necessary to have an eBGP session with Complex relationship,
including mutual-transit arrangements, the operators should take
extra care properly documenting and designing the appropriate local
modifications of the ASPA and OTC procedures. ASPA objects can
represent mutual provider authorization at the AS level, while OTC
and BGP Roles are session oriented and may require segregating the
relationship into non-Complex sessions where feasible. This document
does not define additional BGP Roles or OTC behavior for these cases.
It is generally not recommended to switch ASPA and OTC off for these
links without having a proper alternative.
Notably, route server BGP sessions may easily become a Complex
relationship if any of the peers there becomes a provider, while
others stay as peers [RIPE92-ASPA-LAST-RESORT].
8. Security Considerations
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.
9. IANA Considerations
This document has no IANA actions
10. References
Zhang, et al. Expires 6 January 2027 [Page 11]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
10.1. Normative References
[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>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[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>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017,
<https://www.rfc-editor.org/info/rfc8092>.
[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>.
Zhang, et al. Expires 6 January 2027 [Page 12]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
[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>.
[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.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-25, 19 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-25>.
10.2. Informative References
[bgp-typo] David, L.D. and Y.S. Shavitt, "BGP Typo: A Longitudinal
Study and Remedies", DOI arXiv:2311.00335v1, November
2023, <https://doi.org/arXiv:2311.00335v1>.
[RIPE92-ASPA-LAST-RESORT]
Caletka, O., "Do not drop ASPA invalids of the last
resort", 22 May 2026, <https://ripe92.ripe.net/programme/
meeting-plan/sessions/109/ZT9NYU/>.
Acknowledgements
The authors thank Randy Bush for his valuable suggestions and
comments.
Authors' Addresses
Jia Zhang
Zhongguancun Laboratory
Beijing
China
Email: zhangj@mail.zgclab.edu.cn
Zhang, et al. Expires 6 January 2027 [Page 13]
Internet-Draft ASPA-based AS_PATH Verification for BGP July 2026
Yangyang Wang
Tsinghua University
Beijing
China
Email: wangyy@cernet.edu.cn
Maria Matejka
CZ.NIC
Czechia
Email: maria.matejka@nic.cz
Mingwei Xu
Tsinghua University
Beijing
China
Email: xmw@cernet.edu.cn
Kotikalapudi Sriram
USA National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899
United States of America
Email: ksriram@nist.gov
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Zhang, et al. Expires 6 January 2027 [Page 14]