Skip to content

CONCEPT Cited by 1 source

Route Origin Validation (ROV)

Route Origin Validation is the BGP speaker-side process of checking each received route against RPKI-signed Route Origin Authorizations (ROAs). If the route's origin AS matches a ROA for the prefix (and the prefix length is within the ROA's maxLength), the route is valid. Otherwise it's invalid (rejected) or unknown (passed through, typically).

State machine

Three outcomes per inbound route:

  • Valid — origin AS + prefix + length all match an extant ROA. Route is eligible for best-path selection.
  • Invalid — the origin AS is in conflict with a ROA (e.g. ROA says AS64500 maxLength 24 but route is originated by AS64501, or prefix is more-specific than maxLength). Standard practice: reject.
  • NotFound / Unknown — no ROA exists for this prefix. Accept by default (deployment still incremental).

What it catches, what it misses

Catches: route misorigination / hijacks — an AS claiming to originate a prefix it has no right to.

Misses: - Route leaks where the origin is correct but the path is not (the AS8048 → AS21980 case in the Venezuela post). ROV only validates the rightmost AS in the AS path; it does not validate the intermediate hops. For path checking you need path validation via ASPA. - An attacker forging a path that ends with the legitimate origin ASN but inserts themselves earlier; ROV passes them through because the origin looks correct.

Deployment status

ROV deployment is a multi-year collaborative lift. Cloudflare operates isbgpsafeyet.com to track public ROV deployment per AS. Sparkle (AS6762) was marked unsafe at the time of the Venezuela post (incomplete deployment per APNIC stats) and was marked safe on 2026-02-03 — unrelated to the 01-02 leak, which was a path anomaly not an origin anomaly.

Seen in

Last updated · 200 distilled / 1,178 read