BGP Security: We Built a Tracker So You Can See Who’s Blocking Bad Routes
Border Gateway Protocol (BGP) has been the Internet’s route-exchange workhorse since the 1980s, but its lack of built-in security has long been treated as an inevitable cost of doing business. Route leaks and hijacks don’t just corrupt traffic—they often take entire IP ranges offline. Upper-layer protections like TLS and DNSSEC can’t help when a router is sending your packets to the wrong place. The fix has to happen at the routing layer itself.
The industry’s primary answer is Resource Public Key Infrastructure (RPKI), a framework that cryptographically validates that a network is authorized to announce a given prefix. RPKI has matured considerably since Cloudflare deployed it in mid-2018. The ecosystem now includes production-grade open-source software and validation tools, and Cloudflare has fully deployed Origin Validation on all peer BGP sessions while signing all of its own prefixes.
But RPKI only works if the major network operators enforce it. Those are the networks with the largest customer cones, meaning they have the power to propagate a bad route across huge portions of the Internet. Early adopters like AT&T and Telia led the way in 2019, followed by Cogent and NTT in 2020. Hundreds of other networks have since joined, yet the math remains sobering: when you consider the customer cones of RPKI-deploying networks, roughly 50% of the Internet is more resilient against route leaks. That’s an achievement, but it’s not close to good enough.
A Public Scorecard for Route Filtering
To make the remaining gap visible and actionable, Cloudflare is launching isBGPSafeYet.com, a public site that tracks whether major networks are actually filtering invalid RPKI routes. The information will be community-sourced, and the code is available on GitHub for contributions and suggestions. The goal is to make RPKI deployment status transparent enough that customers can push their ISPs, hosting providers, and transit networks to catch up.
Announcing Deliberately Invalid Prefixes
To support real-world testing, Cloudflare now announces two prefixes that are intentionally invalid per RPKI. They are routed from its 200+ data centers and across its 233+ connected Internet Exchange Points:
103.21.244.0/242606:4700:7000::/48
Any network that has properly implemented RPKI should drop routes to these prefixes. They are deliberately flagged as invalid via Route Origin Authorizations, for example 103.21.244.0/24 on rpki.cloudflare.com.
Anyone can run a quick check at isBGPSafeYet.com. The page attempts to fetch two resources:
valid.rpki.cloudflare.com, which sits behind an RPKI-valid prefix.invalid.rpki.cloudflare.com, which sits behind the RPKI-invalid prefix.
The test has two outcomes:
- Both load: your ISP accepted the invalid route, meaning it is not filtering per RPKI.
- Only the valid one loads: your ISP is enforcing RPKI, and you are less exposed to route leaks.
Beyond the browser test, Cloudflare is probing these prefixes broadly to track their propagation. Past traceroute and probing efforts produced useful visualizations of how far invalid routes travel before they are blocked.
One simple indicator is the number of networks that pass the invalid route along to peers and collectors.
In December 2019, Cloudflare also released a Hilbert curve map of the IPv4 address space where each pixel maps to a /20 block. The color indicates reachability: yellow means the prefix responded only to a probe from RPKI-valid IP space, while blue means it responded to probes from both valid and invalid space. In short: blue regions are IP space behind networks that don’t yet filter invalid prefixes. The Internet won’t be truly safe until all the blue turns yellow.
Credit is due to every network that has already deployed RPKI and to the developers who built the underlying validator software. The past two years prove that routing security improvement is possible, and with the new tracking site and test prefixes, the remaining laggards are now easier to identify.
