ASPA sits at 3% ASN deployment while 99% of BGP route leaks go unblocked

June 2019. A route leak sends European traffic through China Telecom for 2 hours 15 minutes. August 2026. RPKI route origin validation (ROV) tops 60% deployment at major transit carriers — and route leaks keep happening. The reason fits in one sentence: RPKI never validates the path, only the origin.

For a network operator, that is the difference between a hijack — which a ROV filter blocks — and a leak, invisible to RPKI. The fix exists, it is called ASPA, and it is deployed on only 3% of ASNs.

RPKI validates the origin, not the path

The mechanism is precise. RPKI (Resource Public Key Infrastructure) relies on ROAs (Route Origin Authorizations): a signed record that says “prefix 192.0.2.0/24 may only be announced by AS 65000.” Route Origin Validation checks every incoming BGP announcement against that database and marks the prefix Valid, Invalid, or NotFound.

What RPKI never tells you is whether the path the announcement traveled is legitimate. A route can have a valid origin and a leaked path. If AS 65000 announces 192.0.2.0/24 to a customer, and that customer re-announces it to another provider, the origin is still AS 65000, the ROA is still valid, and RPKI sees no violation. Traffic still flows through the wrong AS.

That is exactly what separates a leak from a hijack. A hijack forges the origin; a leak keeps the origin but breaks the topology. RPKI solved the first problem. It is structurally blind to the second.

Two incidents, two defenses

The distinction between a leak and a hijack is not a matter of taxonomy: it changes which defense you deploy. A hijack — an unauthorized AS announcing a prefix — is fought with ROV. A leak — re-announcing a route beyond its legitimate scope — is fought with ASPA.

The two protections are complementary and stack cleanly. ROV answers “who is allowed to announce this prefix”; ASPA answers “does this route take a plausible path.” A network that deploys both filters origin spoofing and topology violations alike.

That is the point late adopters grasp too late: RPKI has bred a false sense of security. At 53% ROA coverage, many operators believe they have “done their part.” But their prefixes can still leak through a careless customer or peer, and ROV will not lift a finger.

ASPA, the missing path-validation layer

ASPA (Autonomous System Provider Authorization, RFC 9234) is RPKI’s counterpart for the path. An ASPA record says “AS 65000 authorizes AS 65100 as a provider.” With ASPA records for every AS along a path, a router can verify that the path makes topological sense: traffic should flow customer → provider → provider → customer, never sideways between two providers.

A route that crosses a valley — the provider → customer → provider pattern — is the signature of a leak. An ASPA-aware router detects that pattern and drops the route. That is exactly what pure RPKI cannot do.

The distinction is not academic. It determines which incidents your network can block automatically, and which ones it will absorb silently until a human notices them on a monitoring graph.

PeerCortex numbers: 99% of leaks on paths without ASPA

The PeerCortex platform measured deployment across 70,847 ASNs. The picture is stark:

The number that summarizes everything: of 1,247 leak events over 90 days, 99% traveled paths with no ASPA coverage. The 12 that crossed protected paths are partial-deployment edge cases — one AS in the path has records, an intermediate one does not. Protecting a path requires covering the whole path.

The contrast with RPKI is telling: 53.6% ROA coverage versus 3% for ASPA. The first half of the problem — the origin — is on its way to being solved. The second — the path — has barely started.

The 99% figure is not an abstraction. Every leak that crosses an unprotected path is a window during which another network’s traffic transits an AS that should never have carried it — measurable, billable, and potentially sniffable. The 12 leaks on protected paths are a different kind of failure: partial ASPA deployment catches some edge cases but lets others through, which is exactly why full-path coverage matters.

Why only 3%

The operational burden of ASPA is low. Documenting your transit relationships: four upstream providers means four ASPA records, a one-time setup, then occasional maintenance when a provider changes. For a stable network, it is thirty minutes.

The barrier lies elsewhere: awareness and tooling. Most network engineers who know RPKI do not know ASPA exists. The major RPKI management platforms — Krill, the Cloudflare RPKI Portal — added ASPA support in 2024–2025, but operational documentation remains thin. The standard is young: RFC 9234 dates from May 2022, and router implementations take time to propagate.

This is a classic collective-action problem. ASPA works best when widely deployed: at 3% it blocks leaks between networks that are already covered; at 30% it would cover most major transit paths. The first movers do the internet a service.

What to do: publish your ASPA records

The action is concrete and measurable. If you operate an AS, publish ASPA records for your upstream relationships with your RIR, alongside your existing ROAs. The cost is thirty minutes for a network with stable transit — less than writing the post-mortem for a leak.

To see where you stand, PeerCortex exposes your ASPA status next to RPKI health, leak history, and other indicators, without registration. That is the first thing to check before touching any configuration.

If you do not control your routing — cloud hosting, purchased IP transit — the question to ask your provider is simple: “do you publish ASPA records and validate the paths you receive?” A provider that blocks hijacks but lets leaks through only protects you halfway.

Verdict

If you operate an AS, publishing ASPA records is the best effort-to-protection move of the year: thirty minutes to close the blind spot RPKI will never cover. Start with your stable transit relationships, check your status on PeerCortex, and extend as providers change.

If you buy transit, add ASPA to your provider evaluation criteria. A carrier that validates origin without validating path leaves its customers exposed to half of routing incidents — and probably does not know it itself.

The underlying signal: RPKI took a decade to reach 53%. ASPA starts from lower, but the problem it solves — the leak, not the hijack — is the one still causing the most silent incidents. Half the job of securing BGP remains, and it will not do itself.

References

• Fichtmueller.org — Route Leaks in 2026: Still Happening, Still Causing Outages, accessed August 17, 2026
• RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages, IETF, May 2022
• PeerCortex — Network Intelligence Platform, data accessed August 17, 2026