ASPA After You Already Publish ROAs

Autonomous System Provider Authorization (ASPA) is a signed RPKI object in which an AS holder lists the upstream provider ASNs authorized to propagate its routes. While a Route Origin Authorization (ROA) verifies which ASN may originate a prefix, ASPA allows validating networks to detect route leaks and forged upstream paths along the rest of the BGP AS_PATH.

For organizations that already publish ROAs for their prefixes, ASPA is the natural second half of RPKI routing security: ROAs lock down the prefix-to-origin binding, and ASPA locks down which networks are actually upstream of that origin.

What a valid ROA cannot see

A ROA answers one question: is the rightmost ASN in the BGP announcement authorized to originate this prefix up to this length? Once that origin check passes, Route Origin Validation (RFC 6811) is finished. It does not inspect the rest of the AS path.

Two common routing failures slip past origin validation because the origin ASN remains intact:

• Accidental route leaks (RFC 7908): A multi-homed customer or lateral peer learns a route from one transit provider and mistakenly re-advertises it to another transit provider or settlement-free peer. The origin ASN at the end of the path is completely genuine, so the leaked route evaluates as RPKI-valid.
• Forged-origin path announcements: An attacker announces your prefix (or an allowed sub-prefix, as explained in When a Valid ROA Still Leaves a Hole) and prepends your legitimate origin ASN at the end of a fabricated AS path. Because the origin ASN matches your ROA, ROV alone marks the announcement Valid.

How ASPA uses Customer-to-Provider records to catch leaks

Normal Internet routing follows a "valley-free" economic model: after a route travels uphill from a customer to its transit provider (or across a single lateral peer link) and starts traveling downhill toward customers, it should never climb back uphill into another transit provider. A route that goes Provider -> Customer -> Provider has crossed a valley and is a route leak.

BGP announcements do not label whether each hop is a customer, peer, or transit provider. ASPA supplies the missing piece through a compact RPKI attestation:

When AS64496 publishes an ASPA record listing only AS64497 as its transit provider, any validating router can immediately see that an announcement claiming path ... 64498 64496 (where AS64498 is not in AS64496's ASPA provider list and is advertising the route to its own transit upstream) violates the authorized relationship.

Do you need an ASPA for cloud BYOIP?

An ASPA object is tied to an AS number, not an IP prefix. Whether your team publishes an ASPA record depends on which ASN originates your BYOIP routes:

• Cloud-originated BYOIP (provider ASN): When AWS (AS16509 / AS14618), Google Cloud (AS396982 / AS19527), or Azure (AS8075) originates your prefix from its own ASN, you publish the ROA for your prefix, and the cloud provider controls the ASPA record for its ASN.
• BYOASN or self-originated prefixes: If you bring your own ASN to a cloud, CDN, DDoS scrubbing provider, or colocation footprint, you hold the origin ASN. Publishing an ASPA for your ASN tells the world which transit and cloud networks are authorized upstream providers for your AS.
• Single-homed or non-transit ASNs (`AS 0` provider list): An AS that has no upstream transit providers at all can publish an ASPA with AS 0 to declare that no network is authorized to act as its transit provider.

Where ASPA standards and RIR support stand in October 2026

As covered in our September 2026 ASPA standards check and APNIC MyAPNIC ASPA coverage, publishing ASPA objects and enforcing ASPA dropping on routers are at different stages of maturity:

• RIR publication is live across major registries: RIPE NCC, ARIN, and APNIC let members create and manage ASPA objects in production portals and APIs, and the NRO RPKI Program has committed all five RIRs to support ASPA by the end of 2026.
• Core IETF specifications remain Internet-Drafts: The ASPA object profile, the ASPA-based AS_PATH verification algorithm, and RPKI-to-Router (RTR) protocol v2 (8210bis) are advancing through the IETF SIDROPS Working Group rather than finalized RFCs.
• Publish now, monitor before dropping: Because an ASPA record is a single atomic list per customer ASN, ASN holders can safely publish accurate provider lists today while router operators monitor validation states as the verification draft reaches RFC status.

Step-by-step process for preparing and publishing an ASPA record

An ASPA record is atomic: one customer ASN maps to one complete set of authorized provider ASNs. Omitting an active backup transit or DDoS-scrubbing upstream can make legitimate failover paths evaluate as invalid once networks enforce ASPA verification.

FAQ

Related resources