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:

  1. 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.
  2. RIRs issue certificates to their members (ISPs, enterprises) for the address space those members hold.
  3. 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.
maxLength is a common misconfiguration vector. Setting maxLength = 32 (IPv4) or maxLength = 128 (IPv6) on a ROA allows the ASN to announce any more-specific subnet, including /32 host routes that could be used in a hijack. Best practice: set maxLength to the longest prefix you actually announce (often the same as the prefix length).

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:

StateConditionTypical Local-Preference treatment
ValidAt 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)
InvalidAt least one ROA covers the prefix, but no covering ROA has a matching ASN and a maxLength ≥ the announced prefix lengthSet local-pref 0 or drop (operator choice; RFC 6811 recommends allowing but marking)
NotFoundNo ROA exists that covers the announced prefixUnchanged (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