The Border Gateway Protocol (BGP) is the glue that holds the internet's tens of thousands of independent networks together. Each network — an "autonomous system," identified by an AS number — uses BGP to tell its neighbors which blocks of IP addresses it can deliver traffic for. Those announcements propagate hop by hop until everyone has a map of where to send packets.
The problem, baked in since BGP's design in the late 1980s, is that the protocol has no built-in way to verify those announcements. If an autonomous system announces a route for address space it doesn't own, neighbors have historically had no cryptographic way to tell the claim is false. We covered the attack itself in depth in BGP hijacking explained. RPKI is the most widely deployed defense against the most common variant of it.
What RPKI Actually Is
RPKI stands for Resource Public Key Infrastructure. It's a public key infrastructure — a hierarchy of certificates — layered onto the existing system of internet number allocation. The core idea: the organizations that hand out IP address blocks already form a chain of authority, and RPKI turns that chain into cryptographic proof.
At the top sit the Regional Internet Registries (RIRs) — the five bodies that allocate address space to networks in their regions. When an RIR allocates a block to a network, it can issue that network a resource certificate binding the address block to the holder's public key. The holder can then sign statements about how those addresses should be used in routing.
The key signed object is the Route Origin Authorization, or ROA. A ROA is a cryptographically signed statement that says, in effect: "Autonomous system X is authorized to originate routes for this address block, up to this prefix length." Because it's signed and chains back to the RIR, anyone can verify it without trusting the network making the announcement.
A ROA is a signed certificate that says "this address block legitimately belongs to this AS number." RPKI is the certificate hierarchy that makes that statement verifiable all the way up to the registry that allocated the addresses.
Route Origin Validation: Using the Certificates
Having signed ROAs is only half the system. The other half is Route Origin Validation (ROV) — routers actually checking incoming BGP announcements against the published ROAs and acting on the result.
The validation flow works like this:
- A network operator runs (or subscribes to) an RPKI validator — software that downloads all the published ROAs from the RIR repositories and verifies their signatures, building a trusted table of "which AS may originate which prefix."
- The validator feeds this table to the operator's routers over a dedicated protocol (RPKI-to-Router, or RTR).
- For each BGP route the router receives, it compares the announced prefix and originating AS against the validated table and assigns a state:
| Validation state | Meaning | Typical action |
|---|---|---|
| Valid | A ROA exists and matches the announced origin and prefix length | Accept, often with a preference |
| Invalid | A ROA exists for the prefix but the origin AS or prefix length doesn't match — a strong signal of hijack or misconfiguration | Reject the route |
| Not Found | No ROA covers this prefix at all | Accept (can't validate, but can't condemn) |
The crucial behavior is "invalid = reject." When a network has both published ROAs for its own space and configured its routers to drop RPKI-invalid routes, a hijacker who announces that space with the wrong origin AS gets their announcement filtered out by every operator doing validation. The forged route simply doesn't propagate. That's the protection.
What RPKI Does Not Solve
Here's where honesty is essential, because RPKI is frequently overstated. Route Origin Validation only checks the origin of a route — the AS at the very end of the path that claims to own the addresses. It says nothing about the rest of the path.
RPKI/ROV verifies who is allowed to originate a prefix. It does not verify that the AS path a route traveled is real. A sophisticated attacker can craft an announcement with a valid-looking origin and a forged path in front of it.
Concretely, RPKI's limits include:
- Path manipulation. An attacker can prepend a legitimate origin AS to a forged path, producing a route that passes origin validation while still hijacking traffic. Defending the full path requires BGPsec, which signs the path itself — and BGPsec remains barely deployed because of its performance and operational costs.
- "Not Found" is the default for unsigned space. Any address block without a ROA is simply accepted. Protection only exists where holders have actually published ROAs and where receiving networks actually validate.
- It's not encryption. RPKI authenticates routing claims; it does nothing to protect the confidentiality of traffic flowing over those routes.
- Repository availability matters. Validation depends on reachable, well-maintained RPKI repositories; outages or misissued ROAs can wrongly invalidate legitimate routes.
Why It Still Matters
None of those limits make RPKI optional. The most common routing incidents are not exotic path-forgery attacks — they're plain origin hijacks and fat-finger misconfigurations where one network accidentally announces another's space. Origin validation catches exactly that dominant case, and adoption has grown substantially: a large and increasing share of the global routing table is now covered by ROAs, and major networks and content providers drop RPKI-invalid routes by default.
The practical upshot for everyone else is that RPKI is part of the quiet infrastructure that makes the rest of the security stack trustworthy. TLS protects your connection to a server — but only if your packets reach the real server. A successful BGP hijack can route your traffic to an impostor before TLS even begins, which is why certificate transparency and routing security are complementary defenses. RPKI raises the cost of that redirection.
The Bigger Picture
RPKI is a good example of how the internet retrofits security onto protocols that were built for a smaller, more trusting world. BGP, DNS, email, and the rest were all designed without authentication; each has since grown a cryptographic immune system bolted on top — RPKI for routing, DNSSEC for DNS, SPF/DKIM/DMARC for email. None is complete on its own, and all depend on adoption to matter.
The lesson for anyone thinking about their own security posture is the same one that runs through every layer: trust has to be anchored in cryptography, not in the good behavior of intermediaries. You can't control whether every network between you and your destination honors RPKI. What you can control is whether the contents of your communication are end-to-end encrypted, so that even a successful hijack yields an attacker nothing but ciphertext. Routing security reduces the odds of misdirection; end-to-end encryption makes misdirection survivable.