Operational Consequences of ROV: Invalid, Valid, NotFound and Real-World Effects
Operational Consequences of ROV: Invalid, Valid, NotFound and Real-World Effects
Enabling Route Origin Validation (ROV) changes packet forwarding in the global data plane. While ROV provides definitive protection against origin prefix hijacking, its operational enforcement requires navigating nuanced failure modes, operator errors, and unintended collateral reachability loss.
Rejecting Invalid Routes vs. De-Prioritizing Them
When deploying ROV, an operator must choose between two policy philosophies:
Option A: Hard Dropping (Drop Invalids)
route-map INBOUND-POLICY deny 10
match rpki invalid
- Security Guarantee: 100% immune to origin hijacks and unauthorized subprefix injections.
- Operational Risk: If a legitimate content provider misconfigures its ROA, your network will drop all routes to that service, rendering it completely unreachable for your users.
Option B: Soft De-prioritizing (Deprecate Invalids)
route-map INBOUND-POLICY permit 10
match rpki invalid
set local-preference 10
- Security Guarantee: Fails against subprefix hijacks! If an attacker announces a
/24subprefix, Longest Prefix Match overridesLOCAL_PREF = 10. The router still sends traffic to the attacker. - Operational Consensus: The global networking community (MANRS, RFC 7454) firmly rejects Option B. To achieve routing security, operators must drop Invalid routes entirely.
The Risk of Rejecting Legitimate Traffic
The primary barrier preventing hesitant network operators from enabling ROV enforcement is the fear of self-inflicted collateral outages.
If a large university, government agency, or SaaS vendor creates a typo in its ROA (or fails to update its ROA when shifting traffic to a new CDN partner), the route is classified as Invalid. A Tier-1 ISP that drops Invalids will cut off access to that vendor for all its subscribers, prompting support escalation and angry executive inquiries.
NotFound: The Ambiguous Middle State
Currently, approximately 50% to 55% of global IPv4 prefixes have valid ROAs. The remaining 45% reside in the NotFound (Unknown) state.
NotFounddoes not mean a route is legitimate; it merely means the prefix owner has not signed an RPKI ROA.- Routers cannot drop
NotFoundroutes; doing so would break connectivity to nearly half the Internet. - Consequently, attackers targeting
NotFoundaddress space can still execute classic origin prefix hijacks uncontested by ROV.
Max-Length Policy Errors and Collateral Damage
As discussed in Chapter 14, maxLength mismatches account for over 80% of all benign Invalid route states observed globally:
[Legitimate Enterprise Allocation: 203.0.113.0/22]
|
ROA published: 203.0.113.0/22 (No maxLength)
|
Enterprise Network Operations adds DDoS Mitigation:
Announces: 203.0.113.0/24 to Akamai/Cloudflare
|
ROV Evaluation:
Prefix Length (24) > Authorized Length (22)
|
v
ROUTE FLAGGED INVALID AND DROPPED!
The enterprise inadvertently blackholes its own DDoS protection service because its network engineers did not coordinate with the team managing its RPKI portal.
Documented Incidents: When ROV Went Wrong
1. The Cloudflare / AWS Route 53 Incident (2018)
When attackers hijacked Amazon Route 53 DNS IP space (205.251.192.0/24) to drain MyEtherWallet cryptocurrency wallets, authoritative DNS queries were redirected to Russian servers. Networks that had enabled ROV dropped the hijack because Amazon had published valid ROAs, but networks lacking ROV fell victim.
2. The Orange España RPKI Account Takeover (January 2024)
A rogue actor accessed Orange España’s RIPE NCC administrator portal via compromised credentials that lacked Multi-Factor Authentication (MFA). The intruder created fraudulent ROAs for Orange’s primary infrastructure prefixes with bogus origin ASNs. Within minutes, global validators downloaded the new ROAs, flagged Orange España’s legitimate BGP announcements as Invalid, and Tier-1 ISPs dropped the routes, knocking the entire national telco offline for several hours until RIPE administrators manually intervened.