What Is Route Origin Validation?

Published 22 June 2026Last updated 28 September 2026

Route Origin Validation (ROV) is the check a router makes against RPKI data before accepting a BGP route: does a signed Route Origin Authorization allow this autonomous system to announce this prefix, at this length? Routes that fail are marked invalid and can be dropped, which stops many accidental leaks and simple hijacks from spreading.

How Whisper models it

ROA—ROA_AUTHORIZES_PREFIX→ANNOUNCED_PREFIX←ROUTES—ASN

Each announced prefix carries its validation result as rpkiStatus, next to the ASN that routes it and the ROA that covers it, so an origin check is one lookup.

Validation state of a prefixOpen in Console →

MATCH (p:ANNOUNCED_PREFIX {name:"1.1.1.0/24"}) RETURN p.name, p.rpkiStatus, p.roaAsn, p.roaMaxLength

How validation works

A prefix holder signs a Route Origin Authorization (ROA) naming the ASN allowed to originate the prefix and the longest prefix length it may announce. Validators fetch the signed ROAs from the regional internet registries' repositories, and routers compare each incoming announcement against them. The result is one of three states: valid when a ROA matches both the origin and the length, invalid when a ROA covers the prefix but the origin or length does not match, and not found when no ROA covers the prefix at all.

Only invalid routes are normally dropped. A not-found route is still accepted, which is why unsigned address space stays open to hijacking even where networks enforce ROV. Validation also happens on each network's own routers, so the protection a route gets depends on how many networks along its path enforce it.

Why it matters for infrastructure analysis

ROV answers one narrow question, whether the origin is authorized, and that is also its limit. It does not check the rest of the AS path, so a hijacker who puts the legitimate origin ASN at the end of a forged path still passes. It remains the most widely deployed defence against BGP hijacking, and a prefix's validation state is the first thing to check when a route looks wrong. For your own space, an invalid state usually means a stale or mis-sized ROA, and networks that enforce ROV will drop your routes because of it.

How it appears in the graph

WhisperGraph records the result directly on each `ANNOUNCED_PREFIX` node, and on the ROA that authorizes it:

`rpkiStatus`, `roaAsn` and `roaMaxLength` on the prefix, from the covering ROA.
`rpkiInvalidReason` on the prefix, when the check fails.
`ROA_AUTHORIZES_PREFIX` and `ROA_AUTHORIZES_ORIGIN`, linking the ROA to the prefix and to the authorized network.

The announcement, its origin and its authorization land on the same rows, so narrowing one network's announcements to the invalid ones is a single query.

Where this shows up

See it in a live investigation: How well does this network actually reach the internet? and Which domains would a BGP hijack actually expose?

Go hands-on with the BGP and RPKI recipes.