RPKI was supposed to be the fix for one of BGP’s oldest problems: nothing stops a network from announcing someone else’s IP addresses, on purpose or by accident. More than a decade into the project, adoption numbers finally look good, and yet RPKI invalid routes haven’t gone away. Route hijacks still happen, leaks still happen, and (this is the part that surprised me when I dug into the research) the tools built to catch all this still cry wolf constantly.
Here’s the short version: RPKI did its job. It just wasn’t as big a job as everyone hoped, and thousands of invalid routes a day are proof that the story doesn’t end at “deployed.”
The good part: RPKI actually got deployed
A Route Origin Authorization (ROA) is a cryptographic statement from an IP address holder saying, “this AS, and only this AS, is allowed to originate this prefix.” Routers that check incoming announcements against ROAs sort them into three buckets (Valid, Invalid, or Not Found) through a process called Route Origin Validation (ROV).
That’s the whole mechanism. Simple in concept, it took the industry years to actually roll it out at scale. It’s happened now: a majority of IPv4 prefixes are covered by ROAs, with some trackers putting the figure north of 60%. Every major RIR has pushed hard on this, and most large transit providers, IXPs, and hyperscalers now run ROV on their edges.
The history of validation results for unique Prefix/Origin pairs. (https://rpki-monitor.antd.nist.gov/)
If you’ve spent any time in this field, that’s a real milestone. Ten years ago, this was a niche practice among a handful of security-conscious networks. Now it’s closer to table stakes.
So why are there still thousands of RPKI invalid routes every day?
This is where it gets interesting, and where a lot of coverage of RPKI stops short.
A team from Virginia Tech, working with CableLabs, published research this year digging into exactly this question: why RPKI-invalid routes haven’t declined even as ROA coverage climbed. Their finding: more than 6,000 invalid routes show up in the global routing table on a typical day, and the trend line is flat.
They traced the vast majority of these, over 96%, back to two operational patterns that have nothing to do with attacks:
IP leasing. IPv4 space is scarce, so leasing prefixes instead of owning them outright has become common. The lessor usually keeps control of the RPKI records; the lessee is the one actually announcing the prefix in BGP. If nobody updates the ROA to reflect that, a legitimate announcement gets flagged invalid, not because anything is wrong, just because two parties didn’t coordinate their paperwork.
Opaque transit. Think DDoS scrubbing services or traffic tunneling arrangements, where a provider announces a customer’s prefix on the customer’s behalf while quietly forwarding traffic back to them. From RPKI’s point of view, the origin AS doesn’t match what’s authorized, so the route gets marked invalid, even though the setup is working exactly as intended.
There’s a real lesson buried in that: invalid does not mean hijacked, and valid does not mean safe. Origin validation checks one specific thing (is this AS allowed to originate this prefix), and nothing about whether the path getting to you is sane.
The researchers didn’t stop at counting invalid routes; they measured what these misclassified routes actually do to traffic, using ping and traceroute from thousands of RIPE Atlas probes. The numbers are worth sitting with: 3.1% of the invalid prefixes they tested lost connectivity from at least one vantage point, 18.5% experienced unplanned rerouting (often bypassing the very security services, like DDoS scrubbing, the traffic was supposed to go through), and among the prefixes that saw rerouting, 39.2% picked up more than 100 milliseconds of extra latency. That’s not a paperwork problem anymore. That’s a customer-facing outage or a slow app, and it’s happening under the “invalid” label that operators are often trained to just filter and forget.
Leaks and hijacks haven’t gone anywhere
If RPKI closed the book on routing security, global BGP incidents would be rare by now. They aren’t. Qrator Labs’ Q1 2026 report counted seven global route leaks and one global BGP hijack in a single quarter, numbers that are, if anything, elevated for the period.
None of this contradicts what RPKI is designed to do. ROV validates origin. It says nothing about AS path correctness, valley-free routing, transit authorization, or whether a route represents a leak instead of legitimate traffic engineering. Those are different problems entirely, which is exactly why ASPA (Autonomous System Provider Authorization) exists: it lets a network cryptographically declare its legitimate upstream providers, so a receiving AS can catch a path that doesn’t match. ASPA moved from IETF draft to actual production support at ARIN, RIPE NCC, and (as of mid-2026) APNIC. But publishing an ASPA object and having routers actually enforce path validation against it are two different milestones, and the second one is still early. As of early 2026, published ASPA records covered well under 1% of the global ASN space. It’s roughly where ROV itself was around 2019 or 2020: the standard exists, a few pioneers have adopted it, and the payoff scales with how many other networks join in.
The alerts nobody trusts anymore
There’s a second, quieter problem: the systems built to flag hijacks in real time are noisy enough that operators have started tuning them out. Academic evaluations of control-plane hijack detectors have repeatedly found false-positive rates north of 80%, meaning for every real incident flagged, several false alarms are drowning it out. That’s a hard number to build an incident-response process around.
The practical result is familiar to anyone who’s worked on an on-call rotation: after enough false alarms, people stop reacting to the pager. And the next real hijack shows up right when the team has learned to ignore that particular alert.
Validation answers one question. Operators need answers to a dozen
RPKI, at its best, answers: is this AS authorized to originate this prefix? That’s necessary, but it leaves a long list of questions operators actually lose sleep over. Is this path degrading? Is loss creeping up on a specific provider? Did traffic just shift somewhere unexpected? Is a technically valid route quietly the worst-performing option on the table?
Those aren’t security questions. They’re performance questions, and they need continuous measurement, not a one-time cryptographic check. A route can pass RPKI validation cleanly and still be the reason a customer’s page loads three seconds slower than it should.
This is where Noction IRP comes into the picture, not as a substitute for RPKI, but as the layer that monitors how validated paths actually perform and automatically reroutes traffic when latency or packet loss on a path becomes worse than the available alternatives. RPKI tells you whether a route’s origin is authorized; it says nothing about whether it’s the best-performing path to use at that moment.
Where this leaves operators
None of this is an argument against RPKI. Quite the opposite. Adoption is real, ROV is genuinely more common than it was five years ago, and casual origin hijacks are measurably harder to pull off than they used to be. But the last decade also made something clear: “valid” and “invalid” were never going to be the whole story.
Thousands of RPKI invalid routes show up every day, most of them harmless, alongside a smaller but real number that do cause outages. Leaks keep happening at a rate that hasn’t meaningfully dropped. Detection tools are loud enough that people have learned to ignore them. None of that is a knock on RPKI’s design. It’s just a reminder that cryptographic trust and operational awareness are solving two different problems, and a resilient network needs both running at the same time.
Outside of RPKI, IRR-based prefix filtering has arguably done more to keep routing sane than any single tool. Long before RPKI adoption took off, operators were already building and validating route objects against IRR databases, and that practice remains widespread today, catching bogus announcements before they’re even accepted. Peer locking and max-prefix limits add another layer on top, capping the blast radius of a leak or misconfiguration at the session level. Community initiatives like MANRS push operators toward a broader set of routing hygiene practices, anti-spoofing, filtering, and coordinated incident response that go beyond what any cryptographic check can enforce on its own. And when something does look wrong, a lot of detection still happens the old-fashioned way: NANOG threads, peering coordination, and operators calling each other directly, since automated alerts alone still don’t carry enough weight to be trusted on their own.
.
