The Scope and Limits of RPKI and ROV

The Scope and Limits of RPKI and ROV

RPKI Route Origin Validation is the cornerstone of modern routing defense, but it is not a silver bullet. Understanding what RPKI can and cannot prove is essential for architects designing resilient network perimeters.

What Origin Validation Proves and What It Does Not

The scope of RPKI ROV is strictly limited to the rightmost element of the BGP announcement:

Security Claim	Can RPKI ROV Prove It?	Explanation
Origin ASN Authorization	YES	Proves the rightmost ASN in AS_PATH is authorized by the resource holder to originate the prefix.
Prefix Length Authorization	YES	Enforces that announced prefix mask does not exceed maxLength.
Path Authenticity / Integrity	NO	Cannot verify whether intermediate ASNs in AS_PATH actually forwarded or received the route.
Data Plane Forwarding	NO	A router with a Valid route may still drop, blackhole, or snoop packets in the data plane.
Prevention of Route Leaks	NO	In a route leak, the origin ASN is legitimate; therefore, the route evaluates as Valid under ROV.

Why RPKI Cannot Prevent All Route Leaks

Consider the classic route leak scenario: - Google originates 8.8.8.0/24 with origin AS15169. - Google creates a valid ROA: (8.8.8.0/24, maxLength=24, Origin=15169). - Transit Provider \(A\) sends the route to Customer \(B\). - Customer \(B\) leaks the route to Transit Provider \(C\) with AS_PATH: [Customer_B, Provider_A, 15169].

When Transit Provider \(C\) receives the route: 1. It inspects the origin ASN: 15169. 2. It compares 8.8.8.0/24 against the VRP cache. 3. The origin matches 15169. The prefix length matches /24. 4. Result: Valid.

Provider \(C\) installs the leaked route, directing its traffic into Customer \(B\)’s saturated connection. RPKI ROV validated the route as legitimate because the origin was never altered.

The Dependency on Accurate, Complete ROA Data

RPKI is entirely dependent on human operators keeping their registry data synchronized with physical network changes: - If a network migrates its data center from one transit provider to another but forgets to update its ROA, legitimate traffic will be dropped as Invalid. - If an enterprise delegates address management to a regional branch that fails to pay its RIR maintenance fees, the parent RIR can revoke the resource certificate, instantly invalidating the enterprise’s global routing.

Cryptographic Soundness vs. Operational Fragility

RPKI introduces an explicit coupling between interdomain routing (traditionally a distributed, loosely coupled control plane) and centralized cryptographic infrastructure: - Centralized Dependencies: If an RIR’s publication server or TAL repository goes offline for extended periods or suffers DNS failures, validator caches decay. - Clock Drift: Because X.509 certificates and manifests rely on UTC timestamps, routers or validator servers with unsynchronized clocks (NTP drift) will reject valid certificates as either expired or not yet valid.

Misconceptions About What RPKI “Solves”

1. “RPKI encrypts Internet traffic.” — False. RPKI validates BGP control-plane assertions; it does not touch or encrypt data-plane payload packets.
2. “If I enable ROV, nobody can hijack my traffic.” — False. An attacker can execute a forged-origin path hijack by prepending your ASN to their announcement (AS_PATH: [Attacker_AS, Victim_AS]), tricking ROV into evaluating your ASN as the origin.
3. “RPKI eliminates the need for prefix filtering.” — False. Strict customer prefix-lists, IRR filters, and maximum-prefix limits remain essential complementary controls.