RPKI and BGP Route Origin Validation
RPKI and BGP Route Origin Validation
How the Resource Public Key Infrastructure prevents route hijacks — covering the ROA trust chain, validation states, the RTR protocol, and where deployment stands today.
1. Why BGP Has No Native Origin Validation
BGP was designed for a cooperative internet where all participants were trusted. A router accepts an UPDATE message and propagates it with no cryptographic verification that the originating AS is actually authorized to announce those IP prefixes. This means any AS — through misconfiguration or malice — can announce someone else's prefixes, and that announcement may propagate globally within minutes.
Notable incidents that accelerated RPKI adoption:
- 2008 — Pakistan Telecom: PTCL accidentally announced a more-specific prefix for YouTube's address space (208.65.153.0/24), blackholing YouTube globally for ~2 hours before upstream providers withdrew the route.
- 2010 — China Telecom: China Telecom originated ~50,000 prefixes belonging to US military, government, and commercial networks for ~18 minutes. Whether accidental or deliberate was never confirmed.
- 2018 — Amazon Route 53 DNS hijack: An attacker used BGP to hijack 205.251.196.0/24 (Amazon DNS), redirecting cryptocurrency wallet traffic to steal funds. The attack used a BGP UPDATE from eNet (AS10297).
- 2019 — European traffic re-routed through China Telecom: European mobile traffic (including Vodafone and Switzerland's Swisscom) was re-routed through China Telecom for approximately 2 hours due to a BGP route leak.
2. The RPKI Trust Hierarchy
RPKI (RFC 6480) builds a hierarchy of X.509 certificates mirroring how IP address space is delegated:
- IANA holds the root trust anchor. It issues resource certificates to the five RIRs (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), each covering their address space.
- RIRs issue certificates to their members (ISPs, enterprises) for the address space those members hold.
- Members issue End Entity (EE) certificates and sign Route Origin Authorizations (ROAs) — signed attestations authorizing a specific ASN to originate specific prefixes.
Verifiers download this signed object hierarchy from five RIR repositories (plus any delegated repositories), validate the certificate chain, and build a validated ROA payload (VRP) table. Routers then query a local RPKI cache via the RTR protocol (RFC 8210) to get this table and perform origin validation on incoming BGP UPDATEs.
3. Route Origin Authorizations (ROAs)
A ROA (RFC 6482) is a signed object containing three fields:
- ASN: The Autonomous System authorized to originate the prefix.
- Prefix: The IP prefix (IPv4 or IPv6) being authorized.
- maxLength: The maximum prefix length that the ASN is authorized to announce. If not specified, only the exact prefix is authorized. If set to, say, 24 for a /20 prefix, the ASN may also announce any more-specific between /20 and /24.
A single ROA can authorize multiple prefixes for the same ASN, but one ROA cannot authorize multiple ASNs for a single prefix. To allow a secondary ASN (e.g., a transit provider or CDN) to originate your prefix, create a separate ROA for that ASN.
4. Validation States
When a router receives a BGP UPDATE, it performs origin validation (RFC 6811) against its local VRP table:
| State | Condition | Typical Local-Preference treatment |
|---|---|---|
| Valid | At least one ROA covers the prefix (prefix ⊆ ROA prefix AND prefix-length ≤ maxLength) AND the ROA's ASN matches the BGP UPDATE's origin ASN | +20 or preferred (common) |
| Invalid | At least one ROA covers the prefix, but no covering ROA has a matching ASN and a maxLength ≥ the announced prefix length | Set local-pref 0 or drop (operator choice; RFC 6811 recommends allowing but marking) |
| NotFound | No ROA exists that covers the announced prefix | Unchanged (treated as before RPKI existed) |
The key insight: Invalid is stronger evidence of a problem than NotFound. NotFound simply means the prefix owner hasn't created a ROA yet. Invalid means a ROA exists saying this ASN is not authorized — a strong signal of either misconfiguration or hijack.
5. The RTR Protocol
Routers do not validate X.509 certificate chains themselves — that would be computationally expensive and require keeping a full RPKI cache. Instead, a dedicated RPKI validator (Routinator, OctoRPKI, Fort, rpki-client) downloads and validates the full RPKI repository and exports just the resulting Validated ROA Payloads (VRPs) to routers via the RTR protocol (RFC 8210).
RTR uses TCP (IANA-assigned port 323; validators such as Routinator default to port 3323 to avoid requiring root privileges) with an incremental sync mechanism: the validator sends serial numbers, and routers request only the delta since their last sync. This keeps bandwidth low even for large VRP tables (currently ~400,000+ IPv4 entries globally).
6. Deployment and Statistics
As of early 2026, RPKI deployment has reached significant scale:
- Over 50% of globally routed IPv4 prefixes have at least one covering ROA (up from ~10% in 2019).
- A majority of Tier-1 and Tier-2 ISPs now perform Route Origin Validation and drop or deprioritize Invalid routes.
- MANRS (Mutually Agreed Norms for Routing Security) requires RPKI ROA creation as a prerequisite for membership and publishes a per-AS conformance dashboard.
Live statistics: NIST RPKI Monitor, ROV++, APNIC RPKI Stats.
7. Beyond ROV: ASPA and BGPsec
RPKI Route Origin Validation only verifies that the origin ASN is authorized to announce the prefix. It does not validate the AS_PATH — an attacker can still construct a false AS_PATH with a legitimate origin AS at the end. Two IETF standards address this:
- BGPsec (RFC 8205): Each AS in the path cryptographically signs the UPDATE, creating an unbreakable chain of custody. Requires all transit ASes to support BGPsec — a significant deployment barrier. Rarely deployed as of 2026.
- ASPA (Autonomous System Provider Authorization, draft-ietf-sidrops-aspa-profile): An AS signs an object listing its authorized upstream providers. Verifiers can detect invalid valley-free paths (e.g., a customer announcing routes as if it were a provider). Simpler to deploy than BGPsec and gaining traction as of 2025–2026.
References
- RFC 6480 — An Infrastructure to Support Secure Internet Routing (RPKI overview)
- RFC 6482 — A Profile for Route Origin Authorizations (ROAs)
- RFC 6811 — BGP Prefix Origin Validation
- RFC 8210 — The RPKI to Router Protocol, Version 1 (RTR)
- RFC 8416 — Simplified Local Internet Number Resource Management with the RPKI (SLURM — local overrides)
- RFC 9286 — Manifests for the Resource Public Key Infrastructure (RPKI)
- RFC 8205 — BGPsec Protocol Specification
- MANRS — Mutually Agreed Norms for Routing Security
- Cloudflare RPKI Portal — live ROA lookup