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, not just its origin, which lets them detect route leaks and certain forged-path hijacks that plain RPKI origin validation cannot catch.

If you already run RPKI Route Origin Authorizations (ROAs), you have solved half of the routing security problem. 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 in late 2025 and the first half of 2026 it moved from a working-group discussion into something you can actually sign at the RIPE NCC, ARIN and APNIC. This article explains what ASPA declares, how path validation works, exactly what it does and does not prevent, and what a small ASN holder should do about it today.

Why is RPKI origin validation not enough?

RPKI Route Origin Validation (ROV) 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 routinely pass origin validation for exactly this reason: in the well-known 2019 incident, validating networks only dropped the leaked more-specifics that happened to violate maxLength limits in published ROAs, while origin-valid leaked routes propagated untouched.

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, version 27 as of June 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.

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. Peer and lateral relationships are handled differently in the verification algorithm; in operator practice, some settlement-free peers choose to model the relationship by each side listing the other as a provider, a convention rather than something the verification draft prescribes.

How does ASPA path validation work?

The verification procedure is defined in a companion draft (draft-ietf-sidrops-aspa-verification, version 26 as of July 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.

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. The two are companions, not competitors.
• 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 as verified in July 2026, with sources at the end.

IETF status. ASPA is not yet a published RFC. Both core documents are active Internet-Drafts in the SIDROPS working group and were in Working Group Last Call in mid-2026, with an IESG-submission milestone targeted around March 2026:

• The profile (the binary object layout) is at draft-ietf-sidrops-aspa-profile version 27, dated June 2026.
• The verification procedure is at draft-ietf-sidrops-aspa-verification version 26, dated July 2026.

The drafts are mature and their object format and algorithm are considered stable enough for production signing, even though the RFC numbers are not final.

RIR support.

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. 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.

3. Decide whether to sign now or wait. Signing early is low-risk: the worst outcome for an incomplete ecosystem is an "Unknown" verdict, which changes nobody's routing decision. If you are in the ARIN, RIPE NCC or APNIC region, you can publish an accurate ASPA today and contribute 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.

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 a good moment to think about provider independence. A directly held, sponsored ASN with your own address space gives you a clean, stable identity to build RPKI and ASPA policy around. 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.

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 is done at your RIR (RIPE NCC, ARIN or APNIC today) through the hosted RPKI interface, exactly like a ROA. Your routers are only involved if you also want to verify incoming paths, which requires an RPKI validator that understands ASPA and router support to act on the result.

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? As of July 2026, no. The profile and verification drafts are in IETF Working Group Last Call and not yet published as RFCs, though the object format is stable and ARIN, RIPE NCC and APNIC all support production signing.

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 for full coverage.

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 (APNIC ASPA roadmap; publishing has since gone live via MyAPNIC and the Registry API): 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/

Facts checked July 2026.