ASPA (RFC 9234): The BGP Verification Nobody Implements Yet

RPKI was supposed to fix BGP. It fixed exactly one BGP problem: somebody else announcing your prefix from an AS that doesn't own it. That's origin hijack. Important problem. Not the only problem.

The other big BGP problem — route leaks — is where a customer or peer accidentally re-announces routes they shouldn't, redirecting traffic through paths the announcing networks never agreed to. Origin is correct. Path is wrong. RPKI doesn't catch it.

ASPA does. RFC 9234 ratified the standard in 2024. Three large transit operators have it in production. The rest of the internet is waiting for someone else to go first, the way every BGP improvement has played out for the last fifteen years.

What ASPA actually says

The mechanism is straightforward. Each AS publishes an Autonomous System Provider Authorisation — a signed record listing the upstream providers it considers authorised. A receiving router can then check, for any incoming announcement, whether the AS-path is consistent with the published provider relationships of every AS on the path.

If AS A's published ASPA says "my providers are X and Y", and a path arrives showing "Z → A → … → us", and Z is not in A's ASPA list, the path is a leak. The router can downprefer, log, or reject.

That's the whole idea. Publish the relationships, check the paths. Same conceptual structure as RPKI ROAs, applied to paths instead of origins.

Why route leaks are a real problem

Route leaks are not theoretical. They happen monthly. They typically cost the leaking AS nothing — somebody else's traffic gets redirected, somebody else's latency goes up, and the leaking operator only notices when a customer complains.

The 2024 large-scale leak that pushed Asian traffic through a small Indonesian carrier for forty minutes was a route leak. The 2023 incident where a US carrier's customer-cone routes got re-advertised globally through a peer was a route leak. Most of these don't make headlines because the impact is fragmented — some users on some paths see degraded latency, the rest of the network barely notices.

The aggregate impact is significant. The per-incident impact is just diffuse enough that nobody assigns it serious operational weight.

Where adoption is and isn't

Three transit operators have ASPA validation in production, dropping or downpreferring paths that don't validate. They've reported the data: a small but persistent fraction of received routes (low single digits) fail ASPA validation. Most of those are operational misconfigurations rather than malicious. Catching them at ingress is cheap and prevents propagation.

The rest of the transit market is on the fence. The technical work is done — most major routers support ASPA validation in current software. The business reason for waiting is that the first movers absorb the cost of false positives while the laggards reap the network-wide benefit. Same chicken-and-egg as RPKI in its early years.

The thing that finally moved RPKI was hyperscaler peering policy. Cloudflare, Google, and Meta started requiring valid ROAs as a condition of peering. The same pressure on ASPA hasn't materialised yet. When it does — and it will, probably 2027 — the laggard transits will move in a six-month window.

What you can do right now

Three things, in order of effort.

Publish your ASPA records. Even if your transits don't enforce, your records become a public asset. When enforcement turns on, your relationships are already documented. RIPE and ARIN both support ASPA publication today.

Enable validation on your own routers if your software supports it. Even non-enforcing logging gives you data on which of your received paths are leaks. The first surprise is usually how many of your own customers leak occasionally.

Ask your transits what their ASPA roadmap is. Most of them have one. None of them advertise it because the conversation is "we're not first". Asking the question in an RFP shifts that.

The likely 2026-2027 timeline

By Q4 2026, my read is that one hyperscaler announces ASPA as a peering preference (not a requirement). That nudges three or four more transits to enable it. By mid-2027, the requirement turns into a "preference becomes requirement at renewal" line in peering contracts. By end-2027, the lagging transits are publicly named in NANOG and RIPE sessions, and the social pressure does the rest.

The technical path is clear. The political path is what's slow. ASPA is the cleanest BGP improvement available right now and nobody's going first because nobody wants to be first.

The route-leak problem doesn't fix itself. ASPA is the fix that's been sitting on the shelf for two years. The question for any network operator reading this is whether your AS's records exist in the public ASPA database, or whether you're one of the operators the future audits will name.

Publish your records. The rest of the timeline is somebody else's problem until it isn't.