ASPA Explained: BGP Path Validation Beyond RPKI Origin Checks

What is ASPA? ASPA (Autonomous System Provider Authorization) is a signed RPKI object in which the holder of an AS number lists the AS numbers it authorizes to act as its upstream transit providers. Other networks use those objects to check the AS path of a BGP route rather than its origin alone, which lets them detect route leaks and certain forged-path hijacks that plain RPKI origin validation cannot catch.

If you run RPKI Route Origin Authorizations (ROAs), you already cover the origin side of routing security. ROAs prove that a given AS is allowed to originate a given prefix. They say nothing about the rest of the path that a route took to reach you. ASPA is the piece that starts to close that gap, and between December 2025 and July 2026 it moved from a working-group discussion into something you can sign at the RIPE NCC, ARIN and APNIC.

Why is RPKI origin validation not enough?

RPKI Route Origin Validation (ROV, explained in what is RPKI) answers one question: is the AS at the end of this path allowed to originate this prefix? ROV is genuinely useful. It blocks the classic accidental hijack where someone fat-fingers a more-specific prefix and originates it from the wrong AS.

But BGP carries an entire AS_PATH, and ROV never looks at it beyond the origin. Two large classes of incident slip straight through.

The first is the route leak. A network receives a route from one provider or peer and, usually by misconfiguration, re-announces it to another provider or peer when it should not. The origin AS is legitimate. The prefix is legitimate. The ROA is valid. Nothing about the origin is wrong. The problem is purely relational: an AS in the middle propagated the route in a direction that violates normal customer-provider economics, and traffic gets pulled through a network that was never meant to carry it. Large leaks pass origin validation for exactly this reason. In the June 2019 leak through a BGP optimizer and Verizon, ROV could only have rejected the leaked more-specifics that broke the maxLength of published ROAs, as Cloudflare noted at the time; leaked routes with a valid origin and length pass ROV by design.

The second is the forged-origin (or forged-path-segment) hijack. An attacker announces a victim's prefix but prepends the victim's real AS as the origin, so the route passes ROV. The rest of the path is fabricated to steer traffic. Because ROV stops at the last hop, a well-constructed forgery with the correct origin looks clean.

ASPA exists precisely because the AS_PATH is where these attacks live, and until recently there was no cryptographically verifiable way to reason about it.

What does an ASPA object actually declare?

An ASPA object is small and deliberately narrow in scope. According to the IETF profile (draft-ietf-sidrops-aspa-profile, revision 29 of 29 July 2026), the signed eContent of an ASPA contains three things:

That is the whole object. One customer ASN, and the set of upstreams it says are allowed to appear directly "above" it in a BGP path. Just as a ROA covers one origin, an ASPA covers exactly one customer AS. If your organization holds several ASNs, you sign a separate ASPA for each one.

One addition matters at internet exchanges. If you are a client of a non-transparent route server, one that puts its own AS number in the path, that route server's AS goes into your provider list too. The verification draft requires it, and the RIPE NCC's ASPA guidance says the same.

The mental model is simple. You are publicly and cryptographically stating: "These, and only these, networks are my transit providers. If you see my AS in a path where the AS above me is not one of these, something is wrong." Everyone else can read that statement and act on it.

Note what an ASPA does not describe. It does not list your customers. It does not list your peers in the lateral (settlement-free) sense. It records the provider relationships going up, because those are the relationships that let a verifier reconstruct which direction a route should flow. For peers, the verification draft asks for mutual listing only when two networks send each other both customer and non-customer routes (its "Complex" case), and it warns that listing a network that is not your provider weakens route leak detection.

How does ASPA path validation work?

The verification procedure is defined in a companion draft (draft-ietf-sidrops-aspa-verification, revision 28 of 24 August 2026). It walks the AS_PATH and asks, at each hop, whether a customer-to-provider step is authorized by a published ASPA. The result of that walk is one of three states, mirroring the ROV vocabulary:

• Valid: the path is consistent with the provider relationships everyone has declared.
• Invalid: a hop contradicts a published ASPA, meaning some AS appears as a provider for a customer that never authorized it.
• Unknown: there is not enough ASPA data along the path to reach a verdict, so no negative conclusion is drawn.

The logic differs by where the route came from:

Routes learned from a customer or a peer should, in a healthy internet, only contain an "up-ramp": a chain of customer-to-provider hops climbing from the origin toward you. If somewhere in that chain an AS appears above a customer that never listed it as a provider, the customer relationship is not authorized, and a route that should have stayed inside a customer cone has leaked outward. That is the signal ASPA catches.

Routes learned from a provider may legitimately contain both an up-ramp and a down-ramp (the route climbed to a common point, then descended). The algorithm applies the same provider-authorization checks with that shape in mind.

The important architectural point: validation happens at the receiving network, based on objects published by the networks in the path. You publish your ASPA once. Every network that has deployed verification can then evaluate any path containing your AS, without asking you anything. It is the same publish-once, verify-everywhere model that made ROA deployment scale.

Verifying paths needs a validator and a router that both understand ASPA. On the validator side, rpki-client validates ASPA objects, Routinator supports them but ships with the feature off (the enable-aspa setting turns it on), and FORT added ASPA validation in version 1.7.0 in July 2026. On the router side, BIRD (since 2.16) and OpenBGPD verify paths; FRRouting has no native ASPA verification as of September 2026, although it supports the BGP Roles of RFC 9234. Routers receive ASPA data over version 2 of the RPKI-to-Router protocol, which is still a draft (draft-ietf-sidrops-8210bis); the published RFC 8210 is version 1 and does not carry ASPA.

What does ASPA prevent, and what does it not?

Being precise here matters, because ASPA is often oversold.

ASPA does prevent or detect:

• Route leaks by intermediate networks. As the verification draft states, if two ISPs both publish ASPAs and run the procedures, a route received from one and leaked to the other by any AS in their overlapping customer cones is automatically detected and mitigated.
• Forged-origin hijacks from an AS outside the victim's declared provider set. If an attacker fabricates a path but is not one of your authorized providers, the forged customer-to-provider hop becomes visible.
• Forged-path-segment attacks where a fraudulent contiguous AS sequence is prepended, when that sequence contradicts published provider relationships.

ASPA does not, on its own:

• Stop you from leaking a route yourself. The verification method detects leaks created by preceding ASes in the path. It cannot stop the local AS from initiating a leak toward its own neighbor. That gap is filled by the Only to Customer (OTC) attribute and BGP Roles, standardized in RFC 9234 (a published Standards Track RFC from May 2022). The ASPA verification draft explicitly recommends deploying OTC to complement ASPA.
• Give perfect protection against every hijack. ASPA raises the cost and narrows the space of successful path forgeries. It does not make BGP unspoofable.
• Work well in a world where nobody else has adopted it. Path validation is a network effect. Your ASPA is only as useful as the number of verifiers reading it, and a path is only fully checkable when the relevant ASes along it have published objects. Early adoption produces mostly "Unknown" verdicts, which is expected and harmless.

What is the current standardization and RIR status? (2026)

This is the part that dates fastest, so here is the state on 25 September 2026, with sources at the end.

IETF status. ASPA is not yet a published RFC. Working Group Last Call on both core drafts in the SIDROPS working group closed on 3 August 2026, and both now wait for the shepherd write-up before they go to the IESG; a document shepherd was assigned on 25 September 2026. The working group's March 2026 milestone for that step was missed. APNIC's review of 2025 said the specifications might be published in late 2026, which is a forecast, not a date.

• The profile (the binary object layout) is at draft-ietf-sidrops-aspa-profile revision 29, posted 29 July 2026.
• The verification procedure is at draft-ietf-sidrops-aspa-verification revision 28, posted 24 August 2026.

The RIPE NCC considers ASPA "ready for use in signing" even though the RFC numbers are not assigned yet; the object format has not changed in the recent revisions.

RIR support.

Deployment is small but growing fast. On 25 September 2026 the global RPKI held 3,243 valid ASPA objects, about 2,000 of them in the RIPE NCC's hosted repositories (rpki-client console). At the end of 2025 there were 556, which APNIC put at about 0.5% of the ASes in the global routing table (APNIC, RPKI's 2025 year in review).

RIPE NCC's own guidance is worth repeating: the dashboard lets you create ASPA objects alongside your ROAs, but it does not guess or infer your provider set for you, and it does not tell you which providers are currently seen for your AS in live BGP. You have to know your own upstreams and keep the list correct as they change.

What should a small ASN holder do today?

If you hold a single ASN and a modest set of prefixes, ASPA is not urgent, but preparing for it is cheap and sensible. Here is a practical order of operations.

1. Get ROAs right first. ASPA complements origin validation; it does not replace it. If you have not yet created ROAs for your prefixes, that is the higher-priority job: how to create RPKI ROAs in the RIPE Database covers it, and the RPKI checker shows whether a prefix and origin validate. If you are still assembling your ASN and address resources, our complete ASN registration guide walks through the sequence.
2. Write down your real transit providers. ASPA forces you to state, precisely, which ASNs are your upstreams. For most small networks that is one or two transit providers. Confirm the exact AS numbers, including any backup transit you only use during failover, because a provider missing from your ASPA will make legitimate failover paths look Invalid to strict verifiers. The ASN lookup tool lists the neighbors seen for your AS in BGP, a quick cross-check against your transit contracts.
3. Decide whether to sign now or wait. Signing an accurate ASPA early is low-risk: where other networks in a path have not signed, the verdict is Unknown, and Unknown draws no negative conclusion. The risk sits in an incomplete provider list, which makes your own routes Invalid at every network that verifies, however few networks have signed. If you are in the ARIN, RIPE NCC or APNIC region, you can publish an accurate ASPA now (as of September 2026 all three offer it in production) and add to the network effect. If you would rather wait for the RFCs to be final, that is a defensible choice too, as long as your ROAs are solid. If Via-Registry sponsors and manages your ASN, you publish it from your dashboard: you pick the providers and we sign the list in your RIPE NCC hosted CA (ASN registration service).
4. Plan to keep it current. ASPA is explicitly not "set and forget." Every time you add, drop, or change a transit provider, the ASPA must be updated in the same change window, or it will start contradicting reality. Fold it into your provider-onboarding and offboarding checklist.
5. Pair it with OTC where you can. If your router platform supports BGP Roles and the OTC attribute from RFC 9234, enabling it closes the one leak direction ASPA cannot: your own accidental announcements. Together they give both directions of route-leak protection.

For networks still choosing how to hold their number resources, this is also the moment to think about provider independence. An ASN registered to you keeps its number when you change transit providers and when you change sponsoring LIR (keep your ASN when your LIR closes); only the provider list in your ASPA changes. If you are weighing that decision, our guide on PI versus PA resources covers the trade-offs, and Via-Registry sponsors ASNs for organizations and individuals as a RIPE NCC member LIR, at €130 per year (as of September 2026) through our ASN registration service.

Frequently asked questions

Is ASPA a replacement for RPKI? No. ASPA is an RPKI object type. It uses the same certificate hierarchy and the same hosted infrastructure as your ROAs. Think of ASPA as RPKI extended from the origin to the path.

Do I need special routers to publish an ASPA? No. Publishing an ASPA happens in RPKI, not on your routers: in your RIR's hosted RPKI interface (RIPE NCC, ARIN or APNIC as of September 2026), or in your own delegated CA if you run one, exactly like a ROA. Your routers are only involved if you also want to verify incoming paths, which requires a validator and a router that understand ASPA (the validation section above names the ones that do as of September 2026).

Will ASPA break my routing if I get it wrong? A missing or incorrect ASPA can cause your legitimate routes to be seen as Invalid by networks that enforce verification, potentially degrading reachability through the affected paths. This is why an accurate, maintained provider list matters more than early adoption.

Is ASPA final yet? No. As of September 2026 both drafts have finished Working Group Last Call but are not yet RFCs. The RIPE NCC considers ASPA ready for use in signing, and ARIN, RIPE NCC and APNIC all offer it in production.

Can my sponsoring LIR publish the ASPA for me? Only if it operates your hosted certificate, and the provider list stays yours to decide. Via-Registry customers on a managed ASN publish it from the ASN page of their dashboard; we sign what they chose and never pick the providers.

How does ASPA relate to the OTC attribute? They are complementary. ASPA (path validation via RPKI) catches leaks made by other networks in the path. OTC and BGP Roles (RFC 9234) stop you from leaking to your own neighbors. Deploy both, one for each direction.

Official References

• IETF, draft-ietf-sidrops-aspa-profile (A Profile for Autonomous System Provider Authorization): https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/
• IETF, draft-ietf-sidrops-aspa-verification (BGP AS_PATH Verification Based on ASPA Objects): https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/
• RFC 9234, Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages (Standards Track, May 2022): https://www.rfc-editor.org/rfc/rfc9234.html
• RIPE NCC, Autonomous System Provider Authorization (ASPA): https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/aspa/
• RIPE Labs, ASPA in the RPKI Dashboard (15 December 2025): https://labs.ripe.net/author/tim_bruijnzeels/aspa-in-the-rpki-dashboard-a-new-layer-of-routing-security/
• ARIN, Autonomous System Provider Authorizations (ASPAs): https://www.arin.net/resources/manage/rpki/aspa/
• APNIC Blog, RPKI's 2025 year in review (ASPA counts at the end of 2025 and the publication forecast): https://blog.apnic.net/2026/02/20/rpkis-2025-year-in-review/
• NRO / RIPE Labs, NRO RPKI Program 2025 in Review: https://labs.ripe.net/author/sofia_silva_berenguer/nro-rpki-program-2025-in-review/
• APNIC Blog, ASPA at APNIC: strengthening BGP path validation (9 July 2026): https://blog.apnic.net/2026/07/09/aspa-at-apnic-strengthening-bgp-path-validation/
• ARIN, ASPA now fully available in ARIN Online (20 January 2026): https://www.arin.net/announcements/20260120/
• rpki-client console, ASPA objects in the global RPKI: https://console.rpki-client.org/aspa.html
• IETF, draft-ietf-sidrops-8210bis (RPKI-to-Router protocol version 2): https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/
• Routinator changelog (enable-aspa): https://github.com/NLnetLabs/routinator/blob/main/Changelog.md
• LACNIC, FORT validator 1.7.0 with ASPA: https://blog.lacnic.net/en/fort-aspa/
• FRRouting, ASPA feature request (issue 23430, opened 21 September 2026): https://github.com/FRRouting/frr/issues/23430