The internet's routing system is finally getting secured — two decades after the first major hijacks
On February 24, 2008, Pakistan Telecom took YouTube offline for the entire world. Not with a DDoS attack, not with a court order — but by accidentally broadcasting a more specific route for YouTube's IP space. Within minutes, traffic destined for YouTube.com was flowing into Pakistan Telecom's network and disappearing into a void. The outage lasted two hours.
The incident wasn't unique. It was a textbook demonstration of why the Border Gateway Protocol — the routing system that underpins the entire internet — is fundamentally insecure. Fifteen years on, engineers are finally doing something serious about it.
The problem with BGP
BGP is the protocol that autonomous systems (AS) — networks operated by ISPs, cloud providers, universities, and companies — use to announce reachability. When your traffic travels from one part of the internet to another, it hops between these autonomous systems according to BGP routing tables. The problem is that BGP was designed in 1989 with a simple assumption: that all participants are honest.
Any network can announce that it owns IP address space it doesn't actually own. Other routers have no way to verify this without external validation infrastructure. The result is route hijacking — either accidental (misconfigurations, fat fingers) or deliberate (traffic interception, surveillance, denial of service).
The incidents pile up year after year. In 2010, China Telecom briefly announced routes for 15% of the internet's address space, rerouting traffic through Chinese networks for 18 minutes. In 2018, traffic for Google's services was hijacked through Nigeria. In 2020, Rostelecom hijacked over 8,800 prefixes belonging to Amazon, Google, Cloudflare, and Akamai — affecting roughly 200 organizations.
RPKI: cryptographic anchors for routing
Resource Public Key Infrastructure (RPKI) is the industry's most mature solution to BGP route origin validation. The concept is straightforward: IP address holders create digitally signed records — called Route Origin Authorizations (ROAs) — that cryptographically attest which Autonomous System number is authorized to announce a given IP prefix.
When a router receives a BGP update, it can check it against the RPKI repository. If a network announces a prefix it isn't authorized for, the route is marked "RPKI Invalid" and can be dropped. The cryptographic chain leads back to Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) — the authoritative databases of IP address allocation.
The technology itself has been standardized since 2012 through a series of IETF RFCs. What's changed recently is deployment at scale. As of early 2026, over 50% of the global routing table has valid ROA coverage — a threshold that was considered aspirational just three years ago. Major IXPs including AMS-IX, DE-CIX, and LINX now enforce RPKI filtering. Cloudflare, AWS, Azure, Google, and the major tier-1 carriers have all deployed origin validation.
MANRS: the social layer of routing security
RPKI solves the technical problem of proving who owns what. MANRS — Mutually Agreed Norms for Routing Security — tackles the coordination problem of getting networks to actually implement it.
Launched by the Internet Society in 2014, MANRS is a framework of four actions: filtering (only accepting legitimate routes), anti-spoofing (preventing forged source IP addresses), coordination (maintaining accurate contact information for incident response), and global validation (implementing RPKI). As of 2026, over 1,000 networks have joined MANRS, including the largest cloud providers and ISPs.
The commercial incentive is gradually aligning. Large cloud providers and enterprises increasingly require MANRS participation from their ISPs as a procurement criterion. Regulatory interest is growing too — the FCC's 2024 BGP security inquiry put ISPs on notice that voluntary adoption may not remain voluntary indefinitely.
What RPKI doesn't solve
RPKI validates route origins — that AS64496 is legitimately announcing 192.0.2.0/24. What it cannot validate is the path that traffic takes to get there. BGPsec, a more ambitious extension that cryptographically signs the entire AS path, has been standardized but faces a chicken-and-egg deployment problem: it only works if most of the path supports it, so early adopters see no benefit. Incremental deployment is nearly impossible.
Route hijacks that involve the legitimate originating AS (but manipulate the downstream path) remain invisible to RPKI. And even with RPKI, a router configured to accept "RPKI Invalid" routes — perhaps for legacy compatibility reasons — provides no protection at all. The technology is only as strong as consistent enforcement.
What this means for enterprises
Organizations with their own IP address space — typically enterprises large enough to hold an ASN — should be creating ROAs for every prefix they originate. The process takes hours, not weeks, and involves creating records through your Regional Internet Registry portal. Failing to do so means a misconfiguration by any upstream ISP could accidentally make your IP space look like a more-specific route, hijacking your traffic with no cryptographic basis for challenge.
For companies without their own ASN, the question is whether your ISP has deployed RPKI filtering on your behalf. Most tier-1 providers now do; transit ISPs vary. The Cloudflare RPKI validator and RIPE's RPKI monitor offer public dashboards to check whether your prefixes are properly covered.
The internet routing system won't be fully secured by RPKI alone — BGPsec and path validation remain open problems. But after two decades of route hijacking incidents and voluntary inaction, the cryptographic foundation is finally being laid. The Pakistan Telecom incident of 2008 would be significantly harder to pull off today. Progress is real, even if the work isn't done.