ASPA: The cryptographic upgrade for BGP path security

But origin validation only tells you where a route claims to start. It says nothing about the path it took to get to you. A route can have a perfectly valid origin and still arrive via a completely illegitimate chain of ASes, through a misconfigured transit network, a malicious route leak, or a manipulated AS_PATH. This gap is exactly what ASPA (Autonomous System Provider Authorization) is designed to close.

ASPA has moved from theory into early operational deployment, even though the core ASPA profile and verification work remain in IETF draft form as of March 2026. ARIN and RIPE NCC both support ASPA object creation in production. Major networks have begun deploying ASPA validation globally. Router implementations exist in BIRD and OpenBGPD. This article is intended to explain what ASPA is, how it works technically, what it can and cannot do, and what the current state of deployment looks like.

The RPKI-ROV limitations

To understand why ASPA is necessary, let’s review what ROV does and doesn’t protect against.

RPKI-ROV validates route origins. When a prefix is received, the router checks whether there is a valid ROA for that prefix–origin combination in the RPKI. If yes, the route is considered Valid. The system catches hijacks where an unauthorized AS announces someone else’s prefix with a forged origin.

But RPKI-ROV does not validate the path. Consider this scenario: AS 64500 legitimately originates 192.0.2.0/24. There is a valid ROA. AS 64502 is a customer of AS 64501. AS 64502 receives the route from AS 64501 (its provider) and due to misconfiguration or malice, re-announces it to another provider, AS 64503. From that point, the route looks fine. The ROA is valid, but a customer is acting as transit between two providers. This is a route leak, and RPKI-ROV cannot detect it. 

What is ASPA?

ASPA is a new RPKI object type being standardised through the IETF’s SIDROPS working group. At its core, it is a cryptographically signed statement by the holder of an Autonomous System that declares: “These are my authorized upstream transit providers.”

The formal definition from the IETF draft: an ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier) can authorize one or more other Autonomous Systems as its upstream providers. Those authorized provider ASes are listed in the ASPA object, which is published in the RPKI alongside ROAs.

A router that has fetched and validated RPKI data (including ASPA objects) can then examine any incoming BGP UPDATE and ask: Does the AS_PATH in this route make sense given the declared provider relationships? If an AS in the path has an ASPA record that does not list the next AS in the path as a provider, that is a strong signal that something is wrong.

The object structure

An ASPA object contains two key fields:

Customer AS (CAS): the AS number of the issuer – the network declaring its providers.

Provider AS Set: a list of one or more AS numbers that are authorized to appear as upstream providers in BGP paths involving the CAS.

EXAMPLE ASPA OBJECT (FROM THE IETF DRAFT)
Customer AS: 65123
Provider Set:
  1: AS 64512   (Primary upstream transit provider)
  2: AS 65551   (Secondary upstream transit provider)
  3: AS 174     (Regional provider)

ASPA only lists upstream providers. Lateral peers and customers are not listed. This is intentional: the verification logic only cares about the provider-customer hierarchy. If a neighbor plays multiple roles (sometimes peer, sometimes provider), they must be included in the ASPA because their provider role makes them eligible to appear in a legitimate upstream path.

Non-transparent route servers at Internet Exchange Points (IXPs) also appear in the BGP AS_PATH and must be included. Transparent route servers, which do not insert their own ASN into the path, do not need to be listed.

How ASPA verification works:

ASPA’s verification model is built on a foundational principle: valley-free routing. In a healthy Internet topology, traffic flows in a predictable pattern that mirrors commercial relationships:

↑ Upward phase: Traffic travels from a customer up through one or more transit providers, toward the core of the Internet.

↔ Peering phase: Optionally, at some tier, traffic crosses a single lateral peer link.

↓ Downward phase: Traffic descends from a provider down to the destination customer.

A route leak creates a “valley” – an anomalous shape in the path where traffic goes down to a customer and then unexpectedly goes back up to another provider. That down-and-up shape violates the logic of the Internet: customers are not supposed to transit traffic between two providers. ASPA detects this violation by checking the AS_PATH pair by pair against the declared provider relationships in the RPKI.

The verification algorithm

The verification procedure defined in the IETF draft works by applying two checks, depending on how the route was received:

Upstream verification (routes from customers or peers): The router walks the AS_PATH from right to left (from origin toward the receiving router). At each hop, it checks: did this AS publish an ASPA that includes the adjacent AS in the path as an authorized provider? The walk continues until it finds a hop with no ASPA (Unknown), a hop with a valid ASPA that includes the neighbor (consistent), or a hop with a valid ASPA that does not include the neighbor (inconsistent).

Downstream verification (routes from providers): The router applies the same logic from the opposite direction, walking from left to right and checking the provider-to-customer descent portion of the path.

In the early stages of ASPA deployment, the vast majority of paths will result in ‘Unknown’, simply because most ASes have not yet published ASPA records. This is expected and correct behavior. ASPA is incrementally deployable: even sparse coverage can detect some route leaks, and early adopters benefit from the protection without requiring global deployment first.

How ASPA compares to ROV and BGPsec

ASPA is often discussed alongside the two other major BGP security mechanisms: RPKI-ROV and BGPsec. Each addresses a different layer of the problem, and they are complementary rather than competing.

BGPsec, defined in RFC 8205, attempted full cryptographic path validation, where every AS in the path would sign the route. While technically comprehensive, this approach imposed significant computational overhead and required simultaneous upgrades across the global routing system. After years of standardization, deployment remains near zero.

ASPA takes a deliberately pragmatic alternative: instead of signing every hop, it encodes relationships: which ASes you have chosen as your transit providers, and validates that observed paths are consistent with those declared relationships. No new cryptography is required on the router itself. Routers receive validated ASPA payloads via the existing RPKI-to-Router (RTR) protocol, exactly as they already receive ROA validation results. The path verification logic runs locally on the router, using the received payload. This architecture makes ASPA far more deployable than BGPsec.

ASPA limitations 

ASPA is not a complete solution to BGP security. Understanding its boundaries helps operators deploy it correctly and avoid overconfidence.

It cannot verify peer or customer relationships

ASPA only encodes provider relationships. It has no mechanism for verifying peer-to-peer or provider-to-customer relationships. This means certain classes of route leaks, particularly those involving complex multi-role peering arrangements, may still produce ‘Unknown’ results rather than ‘Invalid’, reducing detection accuracy in those scenarios.

Provider hijacks are largely outside its scope

A malicious or compromised provider could still hijack the prefixes of its own customers by forging path segments. The IETF draft acknowledges this: such attacks are theoretically possible but not considered a realistic threat, given that customer-provider relationships are contractual and the aggrieved party can simply remove the provider from their ASPA record and terminate the relationship.

Complex relationships can reduce coverage

Complex relationships, where an AS functions as both a peer and a provider depending on the prefix, require the AS to be listed as a provider in the ASPA. Failing to do so correctly can produce Invalid results for legitimate routes. Operators must maintain their ASPA records accurately and keep them in sync with operational changes to peering arrangements.

ASPA complements the OTC attribute

RFC 9234 defines the Only-to-Customer (OTC) attribute – a simpler, BGP-native mechanism that prevents a router from re-advertising a route it received from a non-customer to another non-customer. OTC addresses the local leak scenario (where your own router is the leaker), which ASPA cannot prevent on its own. The IETF draft recommends deploying OTC alongside ASPA: they are complementary, not competing mechanisms. 

ASPA adoption 

RIR support for ASPA publication

Network operators publish ASPA objects through their Regional Internet Registry (RIR), the same way they publish ROAs. As of March 2026:

Relying Party software (RPKI Validators)

RPKI relying party (RP) software – the tools that fetch and validate RPKI repositories and feed data to routers via the RTR protocol, must be updated to process ASPA objects. Current status:

Routinator (NLnet Labs): ASPA validation supported.

FORT Validator: ASPA support available in recent releases.

rpki-client: OpenBSD project; ASPA support implemented.

RTRlib: C library implementation of ASPA validation available.

Router Implementations

The router side is where most of the remaining work lies. Path verification must be implemented in BGP software, consuming ASPA payloads delivered by the updated RTR protocol:

Network operator deployments

Early public deployments and monitoring visibility now exist, with operators publicly discussing ASPA adoption, while ecosystem-wide deployment remains at an early stage. AWS has publicly committed to adopting ASPA as the standard matures. The NIST BGP RPKI IO (BRIO) test framework, released in August 2025, provides open-source tools for operators to test ASPA implementations against their routing infrastructure. Adoption data across all five RIRs is publicly visible through RPKI monitoring services.

Adoption stats

As of February 2026, published ASPA records represent well under one percent of the global ASN space. ROV followed the same trajectory: years of standardization, early cautious adoption, then rapid acceleration once major operators and IXPs began enforcing it. The ASPA ecosystem is at approximately the same stage ROV was in 2019 – 2020. 

The deprecation of AS_SET and ASPA

One important prerequisite for ASPA is clean, unambiguous AS_PATHs, specifically, paths that do not contain AS_SET segments. As covered in our previous blog post, the IETF formally deprecated AS_SET in May 2025. This is directly relevant to ASPA: routes with AS_SET in their AS_PATH are always considered Invalid under ASPA-based path verification. The presence of an unordered set of ASes makes it impossible to apply the ordered, directional path-verification logic that ASPA relies on.

This is why the RFC 9774 deprecation and ASPA are tightly coupled. Operators who have not yet migrated away from AS_SET aggregation need to do so not only for RFC 9774 compliance, but as a prerequisite for functional ASPA deployment.

What the operators should do now

ASPA does not require simultaneous global adoption to deliver value. Incremental deployment works because even partial ASPA coverage allows detecting leaks involving the covered ASes. Here is a practical sequence for operators:

Step 1: Ensure your RPKI foundation is solid

Before publishing ASPA objects, your ROA coverage should be complete and correct for all your announced prefixes. ASPA builds on top of the RPKI infrastructure. Ensure your RPKI validator is up to date and supports ASPA object processing.

Step 2: Audit your upstream provider relationships

Compile an accurate and complete list of your upstream transit providers: every AS that you pay for transit, and every AS that forwards your announcements toward the wider Internet. Include non-transparent IXP route servers. Include any AS that acts as a provider in any context, even if they also peer with you laterally. If in doubt, include them.

Step 3: Configure BGP roles (RFC 9234)

Before or alongside ASPA, deploy BGP roles as defined in RFC 9234. BGP roles encode the customer/provider/peer relationship in the BGP OPEN message itself, enabling the Only-to-Customer (OTC) attribute to function. This catches local route leaks, where your own router is the leaker -something that ASPA cannot prevent. 

Step 4: Publish your ASPA object

Create your ASPA object through your RIR’s RPKI portal (currently available in production at RIPE NCC and ARIN). Include all upstream transit providers identified in Step 2. Configure your router to receive ASPA validation results and log them without enforcing route rejection.

Step 5: Monitor before enforcing

Run ASPA in monitoring mode before enabling route rejection for Invalid paths. Investigate any unexpected Invalid results carefully: they may reveal ASPA records that are incomplete or incorrect on your side, or may reveal actual anomalies in paths from peers and providers.

Step 6: Enforce, Then Maintain

Once you have confidence in your ASPA records and have investigated monitoring results, configure your BGP speakers to treat ASPA-Invalid routes as ineligible for route selection. After enforcement, the most important ongoing task is maintenance: update your ASPA records whenever you add, remove, or change upstream providers. An outdated ASPA record that omits a legitimate provider will cause valid routes via that provider to be marked Invalid by ASPA-enforcing networks downstream.

If you peer at Internet Exchange Points using non-transparent route servers, those route server ASNs must appear in your ASPA provider list. Transparent route servers which forward routes without inserting their own ASN do not need to be listed. When in doubt, check with the IXP operator whether their route server operates transparently.

ASPA’s trajectory

ASPA’s trajectory in early 2026 closely mirrors the early deployment phase of RPKI-ROV around 2019–2020. The infrastructure is in place in key regions. Reference implementations exist. Major networks have begun deploying enforcement. AWS has committed to adoption. The IETF drafts are mature and stable. What remains is the same thing that drove ROV adoption: operator action, RIR completeness, and ultimately, IXPs and major transit providers setting enforcement policies that make compliance a routing necessity rather than a choice.