RPKI Validation: How Route Origin Authorization Prevents Spoofs
A security architecture guide to the Resource Public Key Infrastructure (RPKI), exploring how cryptographic Route Origin Authorizations (ROAs) eliminate BGP route hijacking.
Quick Answer
Resource Public Key Infrastructure (RPKI, RFC 6480) provides cryptographic security for global Internet routing. By creating digitally signed Route Origin Authorizations (ROAs) through Regional Internet Registries, network owners explicitly bind their IP subnets to authorized Autonomous System Numbers. Border routers running Route Origin Validation (ROV) automatically drop any unauthorized 'RPKI Invalid' BGP announcements.
- Cryptographic Trust Anchors: Anchored across the 5 global RIRs (ARIN, RIPE, APNIC, LACNIC, AFRINIC).
- Automatic Discard: Tier-1 backbones drop "RPKI Invalid" announcements to neutralize hijacks at the edge.
- RFC 9319 Best Practice: Avoid inflated MaxLength fields to eliminate forged-origin sub-prefix vulnerabilities.
1. The Cryptographic Architecture of RPKI
RPKI establishes an X.509 Public Key Infrastructure (PKI) reflecting the hierarchical allocation of IP addresses and Autonomous System Numbers:
2. Comparison of RPKI Validation States
Compare how modern border routers handle the three standardized validation states:
| RPKI Validation State | Matching Condition in ROA Cache | Default Router Policy | Traffic Impact | Security Implication |
|---|---|---|---|---|
| Valid | Prefix, Origin ASN, and Prefix Length match an active signed ROA | Installed in RIB; preferred path | Normal routing | Cryptographically authenticated by address holder |
| Invalid | Covered by a ROA, but Origin ASN is wrong or Length > MaxLength | IMMEDIATELY DROPPED (Filtered at edge) | Traffic blackholed for rogue path | Hijack or misconfiguration neutralized |
| NotFound / Unknown | No ROA exists covering this IP address prefix | Accepted into RIB with standard priority | Normal routing | Legacy un-signed space; vulnerable to hijacking |
RPKI Route Origin Validation Decision Tree
[ Incoming eBGP Route Announcement ]
|
+----------------------+----------------------+
| |
[ Matches Existing ROA ] [ No ROA Signed ]
Prefix covered by RIR trust anchor No cryptographic record
| |
+-------+-------+ |
| | |
[ ASN & Length [ Wrong ASN or [ RPKI NotFound / Unknown ]
Matches ] Exceeds MaxLength ] Evaluated via standard BGP metrics
| | (Vulnerable to BGP hijacking)
[ Valid ] [ Invalid ]
Accepted DROPPED AT BORDER
Preferred Never enters routing table
3. The MaxLength Trap: RFC 9319 Best Practice
When network administrators configure a ROA, they specify an IP prefix (e.g. 198.51.100.0/22) and an optional MaxLength:
Historically, administrators set MaxLength: /24 so they could announce smaller subnets without creating new ROAs. However, RFC 9319 demonstrated that loose MaxLengths enable Forged-Origin Sub-Prefix Hijacking: if an attacker spoofs the authorized ASN on an unannounced /24, routers accept the hijack as RPKI Valid!
Modern Best Practice: Do not use loose MaxLengths. If you announce a /22, set MaxLength to /22. If you de-aggregate into four /24s, publish four distinct explicit /24 ROAs.
4. Practical Diagnostics: Verifying RPKI Status via CLI
Check whether any IP prefix has an authoritative signed ROA and its active validation state:
Frequently Asked Questions
What are the three RPKI validation states evaluated by BGP routers?
Standardized by RFC 6811, a router assigns one of three states to an incoming route: 1) "Valid" (the prefix, origin ASN, and prefix length match an authoritative signed ROA); 2) "Invalid" (a ROA exists covering the prefix, but the origin ASN is incorrect or the prefix length exceeds MaxLength); and 3) "NotFound" or "Unknown" (no ROA has been signed for this address block).
Why do Tier-1 carriers automatically drop "RPKI Invalid" routes?
Dropping RPKI Invalid routes is the primary defense against BGP prefix hijacking and accidental route leaks. When major backbones (such as Cloudflare, AT&T, Telia/Arelion, NTT, and Lumen) drop Invalid routes, malicious or misconfigured route announcements are stopped at the border and never propagated to the global Internet.
What is the risk of setting an inflated "MaxLength" in a Route Origin Authorization?
RFC 9319 warns against using loose MaxLength values (e.g., creating a ROA for a /16 with MaxLength /24). If an attacker manages to spoof the origin ASN, the loose MaxLength allows them to execute a sub-prefix hijack by announcing any /24 within that /16 without triggering an RPKI Invalid error. Best practice is to sign ROAs matching exact announced prefix lengths.
How do routers receive RPKI data without overloading their CPU with cryptography?
Routers do not perform heavy X.509 cryptography directly. Instead, external RPKI Relying Party validators (such as NLnet Labs Routinator, Cloudflare GoRTR, or OctoRPKI) download and cryptographically verify ROAs from the five RIR repositories, and push a pre-computed binary table to edge routers over the lightweight RPKI-to-Router protocol (RTR, RFC 8210).
Data & Technical Sources
- IETF RFC 6480 — An Infrastructure to Support Secure Internet Routing (RPKI Architecture)
- IETF RFC 6811 — BGP Prefix Origin Validation
- IETF RFC 8210 — The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
- IETF RFC 9319 — Best Current Practices for RPKI Route Origin Authorizations (Avoid Inflated MaxLength)