Route origin validation just had its best month on paper. On June 29, 2026, RPKI coverage of the global routing table hit a record 67.43 percent of announced prefixes, per Hurricane Electric's adoption report: 1,065,730 of 1,580,470 routes covered by a signed Route Origin Authorization. Two years ago the community celebrated crossing the halfway mark for IPv4. The curve only points one way.
Three weeks after the record, on July 21, RIPE Labs published Antonio Prado's "Beyond Origin Validation: Four Classes of Routing Attack Nobody Is Validating", and the timing reads like a rebuttal. The paper sorts BGP attacks into four macro-categories: route manipulation, routing consistency, policy violation, and session-based attacks. Origin validation meaningfully addresses part of one of them. For the rest, in the paper's words, entire attack families "have no cryptographic answer at all."
Both things are true at once. RPKI deployment is a genuine success, and a network that relies on it as its routing security story is still exposed to most of the ways routing actually gets attacked.
What a ROA actually asserts
A Route Origin Authorization is a small signed object, anchored in one of the five RIRs' trust hierarchies, that says: this AS number is allowed to originate this prefix, down to this maximum length. Nothing more. A router doing route origin validation (ROV) takes each BGP announcement, looks at the rightmost AS in the path and the prefix length, and checks them against the ROA set. Match: valid. Covered by a ROA but wrong origin or too specific: invalid, and a validating network drops it. No ROA at all: unknown, and the route is accepted as if RPKI never existed.
That last state is why coverage percentage matters so much, and 67 percent is real progress. The distribution is lopsided in an interesting way: 73.52 percent of IPv6 prefixes carry a ROA against 65.58 percent for IPv4, and RIPE NCC leads the registries with 353,777 signed records to APNIC's 289,658 and ARIN's 262,854 (all figures from Hurricane Electric's July 26 snapshot). Coverage even wobbles: between June 29 and July 26 the covered count grew by about 15,000 prefixes, but the table itself grew by 29,000, so the percentage slipped from 67.43 to 67.16. The denominator is a moving target, partly fed by the very deaggregation ROV cannot police.
Signing is only half the transaction, though. Someone has to check. The RIPE Labs analysis cites measurement work showing that only 12.3 percent of ASes achieve full ROV protection on their routes, while 36.2 percent do not validate at all. A ROA you publish protects you only to the extent that the networks between you and an attacker actually drop invalids.
Forged origins arrive marked valid
Here is the structural problem: ROV checks the rightmost AS in the path, and the path is just a field in a BGP message. An attacker who wants to hijack a protected prefix does not fight the ROA. They copy it. Announce the victim's prefix, place the victim's own AS number at the origin position, and prepend your AS in front of it. Every validator on the internet looks up the ROA, finds the origin matches, and stamps the route valid.
This is not theoretical. On August 17, 2022, an attacker used AS209243 (a UK hosting company) to announce 44.235.216.0/24, Amazon address space that hosted DNS infrastructure for the Celer cryptocurrency bridge, with an Amazon ASN forged as the origin. Kentik's analysis notes the relevant Amazon ROA authorized three ASNs (16509, 8987, and 14618) at lengths all the way down to /24, so the forged announcement was RPKI-valid on arrival. The hijack ran from 19:39 to 22:07 UTC, long enough to serve victims a phishing front end and steal roughly $235,000 (Coinbase's incident analysis has the full timeline). A generous maxLength made it easier, which is why RFC 9319 tells operators to keep ROAs as tight as their announcements allow, but a tight ROA only shrinks the target. It does not remove it.
Catching this requires validating the path, not the origin. That was BGPsec's job (RFC 8205, published 2017), and after nine years it remains, as the RIPE Labs paper puts it, essentially undeployed: the per-hop signing cost bought protection nobody was willing to pay for.
Route leaks are policy failures, and a ROA knows nothing about policy
The second gap is the leak: a route announced by the network that legitimately originates it, propagated through a path that violates business relationships, classified into its directional variants by RFC 7908. The textbook case is a multihomed customer re-exporting one transit provider's full table to another, turning a small AS into accidental transit for half the internet. Every one of those announcements carries the correct origin. ROV waves them all through.
Two mechanisms exist to catch leaks, and both are stuck in early adoption. RFC 9234, published back in May 2022, adds an Only-to-Customer attribute so that a route marked "down" can never travel "up" again; Prado's analysis estimates it could suppress over 98 percent of multi-hop leaks if adopted. ASPA, the Autonomous System Provider Authorization, extends the RPKI itself: an AS signs the list of its transit providers, and any path that routes it through a non-provider fails verification, which also happens to break the forged-origin trick above. The same analysis puts the potential reduction in leak-affected ASes at up to 96 percent.
The catch is in the deployment numbers. ASPA objects only became publishable through the RIRs in December 2025, and as of July 26 exactly 2,229 of the 87,892 ASNs in the routing table have one: 2.54 percent. Signing a ROA took the industry a decade to make routine. The ASPA curve starts now.
Instability and session attacks have no answer at all
The last two categories in the taxonomy are the ones nobody validates because nothing exists to validate them with. Routing consistency attacks poison the table's stability rather than its contents: disruptive flapping, churn amplification, and fragmentation floods of ever-more-specific prefixes. The defenses are max-prefix limits, flap damping, and length filters: local knobs the victim of an attack can neither see nor verify. The paper is blunt about it: ask whether you are protected against a fragmentation flood from a peer and "the candid answer is: you have a max-prefix limit and a hope."
Session-based attacks are nastier because they weaponize the protocol machinery itself. A malformed optional transitive attribute gets forwarded, unparsed, by routers that do not understand it, until it reaches an implementation that parses it badly and resets the session. On May 20, 2025, a corrupted Prefix-SID attribute did exactly this in the wild: per the RIPE Labs account, it triggered more than 150,000 route updates and session flaps at networks including Starlink and ByteDance within ten seconds of appearing. No ROA, ASPA object, or path signature would have changed anything, since the attack never lies about routing at all.
Mapping defenses to attacks shows where the floor is
Read the matrix column by column and the strategy writes itself. ROV is deployed but narrow. ASPA and Only-to-Customer are broad against exactly the attacks ROV misses, but barely exist in the wild yet. Which leaves the unglamorous bottom row of operational hygiene: peer-lock, the technique Job Snijders introduced at NTT in 2016, hardcodes which ASes may appear behind which peers and still stops leaks that no cryptography catches. Strict prefix filtering at customer edges, max-prefix limits, and attribute scrubbing at route servers fill in the rest. None of it is verifiable by outsiders. All of it works today.
Checking your own exposure
If you originate address space, three checks cover most of this. First, confirm every prefix you announce has a ROA and that its maxLength matches what you actually announce, not what you might announce someday; RFC 9319 explains why loose maxLength turns a ROA into an invitation. Second, test whether your upstreams actually drop invalids, with Cloudflare's test page or by checking your ASN in RoVista. Third, accept that prevention has holes and monitor: an RPKI-valid forged-origin hijack of your space is invisible to validation by design, so detection means watching for unexpected origins and more-specifics of your prefixes in the global table. If your RIR supports publishing ASPA objects, signing one costs you an afternoon and puts you in the first 2.54 percent.
The uncomfortable takeaway from July's two data points is that the 67 percent number measures the solved problem. Hijackers moved on to forged origins years ago; the Celer attackers read Amazon's ROA and built an announcement to satisfy it. Until ASPA and RFC 9234 get anywhere near ROA-level adoption, the honest description of internet routing security is a strong lock on one door of a building with four.
Routing data is one of the raw inputs behind Ipregistry: every IP lookup returns the originating AS, its prefix, and connection metadata drawn from the same global tables discussed here, which is handy when you need to know who really announces the address knocking on your API. You can try it with 100,000 free lookups to get started.
Keep users in the loop Ship release notes that get read. Try Noticeable