RPKI

Resource Public Key Infrastructure (RPKI) is a cryptographic framework that lets IP address holders publish signed attestations about which autonomous systems are authorized to originate their prefixes in BGP. It is the primary deployed mechanism for defending against accidental and deliberate route origin hijacking.

The Problem RPKI Solves

BGP was designed without built-in mechanisms to verify that an AS announcing a prefix actually owns it. Any router can originate any prefix, and neighbors will accept and propagate it if it looks plausible. This has led to repeated incidents — some accidental misconfigurations, some deliberate — where traffic for a prefix was redirected to an AS that had no business receiving it.

RPKI addresses the origin validation problem: given a BGP route announcement, is the origin ASN actually authorized to announce this prefix? It does not attempt to validate the full AS path.

Route Origin Authorizations (ROAs)

The core object in RPKI is the Route Origin Authorization (ROA). A ROA is a cryptographically signed object that records three things:

• The IP prefix being authorized (e.g., 203.0.113.0/24)
• The origin ASN permitted to announce that prefix
• A maximum prefix length — the longest prefix derived from the covered prefix that the authorization covers

ROAs are signed using private keys that chain up to certificates held by Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC). Because the RIRs are the authoritative source of IP address allocations, their certificates form the trust anchors of the RPKI hierarchy. An organization creates ROAs through their RIR's portal or API after verifying that they hold the address resources in question.

Route Origin Validation States

When a BGP router receives a route announcement and checks it against the validated RPKI cache, each route receives one of three states:

• Valid — a ROA exists that matches the prefix and origin ASN, and the announced prefix length does not exceed the ROA's maximum length. The announcement is consistent with the registered authorization.
• Invalid — a ROA exists for the prefix, but either the origin ASN does not match, or the announced prefix is more specific than the ROA's maximum length permits. This is a strong signal of a misconfiguration or a hijack.
• Not Found — no ROA covers this prefix. The route cannot be validated either way. Most of the internet still falls into this category; not-found routes are typically accepted, since rejecting them would break connectivity for prefixes that simply haven't published ROAs yet.

What RPKI Prevents — and What It Does Not

Networks that perform Route Origin Validation and drop RPKI-invalid routes prevent traffic from being attracted to an AS that has no ROA authorization for a prefix. This stops many accidental mis-origination events (fat-finger misconfigurations that announce someone else's prefix) and a class of deliberate hijacks where the attacker simply originates the victim's prefix from their own AS.

RPKI does not protect against AS path manipulation. An attacker who can insert themselves into the legitimate AS path, or forge path attributes in some other way, is not stopped by route origin validation alone. A separate protocol, BGPsec, was designed to cryptographically sign AS paths, but as of now it sees very limited deployment and is not considered a practical defense at internet scale.

RPKI also does not prevent route leaks where a legitimate AS accidentally re-announces prefixes it learned from one peer to another peer in an unauthorized direction — that is a separate problem addressed by other mechanisms such as BGP communities and prefix filters.

RPKI Adoption

RPKI adoption has grown substantially. Many major networks — including large ISPs, cloud providers, and IXPs — now validate BGP routes against RPKI and drop invalids. Coverage of the address space with ROAs continues to increase, though a significant portion of the internet's prefixes remain in the not-found state.

Check RPKI validation with the BGP tool →