RPKI Validators and Route Origin Validation (ROV)

The RPKI (RFC 6480) is a certificate hierarchy: each RIR runs a trust anchor, resource holders receive certificates for their space, and they sign objects such as ROAs. Checking those signatures, revocation lists and manifests for every object in the world is too much work to do inside a router, and routers should not have to fetch files from dozens of repositories.

The work is therefore split in two. A validator, running on an ordinary server, does all cryptographic checking. The router receives only the result: a compact list of Validated ROA Payloads (VRPs), as RFC 6811 calls them, and applies it to BGP routes. If you are new to the overall system, start with RPKI explained.

1. Start at the trust anchors. The validator is configured with a Trust Anchor Locator (TAL) for each of the five RIRs: AFRINIC, APNIC, ARIN, LACNIC and RIPE NCC. A TAL tells it where to fetch the trust anchor certificate and which public key to expect.
2. Fetch the repositories. Starting from each trust anchor, it follows the publication points of every certificate and downloads their objects, using RRDP (RFC 8182) over HTTPS or rsync.
3. Validate. Each certificate must chain up to a trust anchor, be within its validity period, not be revoked, and only claim resources that its parent certificate actually holds. Each publication point's manifest lists the files that should be there, so missing or substituted files are detected.
4. Extract the payloads. Every ROA that passes produces one VRP per prefix: prefix, maxLength and origin AS.
5. Serve the result. Routers connect over the RPKI-to-Router protocol (RTR, RFC 6810 and RFC 8210) and receive the VRP list plus incremental updates. Most validators can also export the list as JSON or CSV for monitoring and scripts.
6. Repeat. The validator refreshes on a schedule, typically every few minutes, so new and deleted ROAs reach routers without manual work.

Validators also accept local exceptions in a standard format called SLURM (RFC 8416): an operator can locally ignore a particular VRP or add an assertion, for example to work around a known mistake in someone else's ROA while it is being fixed.

RFC 6811 defines how a router derives a state from the VRPs. It takes the prefix of the route and its origin AS, which is the right-most AS in the AS-path:

Example with one VRP for 203.0.113.0/24, maxLength 24, origin AS64500: an announcement of 203.0.113.0/24 from AS64500 is Valid, the same prefix from AS64511 is Invalid, 203.0.113.0/25 from AS64500 is Invalid because it is longer than the maxLength, and 198.51.100.0/24 is NotFound because nothing covers it. The ROA guide explains why the maxLength case catches so many operators.

The state is not stored in the route. Routers recompute it whenever the VRP set changes, so a route accepted as NotFound in the morning can become Invalid an hour after its holder publishes a ROA that does not match it.

Enforcing ROV is mostly about avoiding self-inflicted outages. The usual path:

1. Run at least two validators, ideally on separate hosts and in separate locations. Many operators also mix two different implementations so that a bug in one does not take out all route validation at once.
2. Connect the routers to all validators over RTR. Routers merge the lists, so one validator can fail without effect.
3. Start in monitoring mode: compute the state but do not act on it yet. Most router platforms can tag routes, for example with a community, so you can see which routes would be dropped and whether any of them carry real traffic.
4. Fix your own house first. Make sure every prefix you announce is Valid; publish or correct ROAs before you start rejecting other networks' Invalid routes.
5. Reject Invalid routes on external sessions: transit, peers and customers. Keep accepting Valid and NotFound.
6. Monitor the validators: their last successful refresh, the number of VRPs, and the RTR sessions. A validator that keeps serving a list from days ago is worse than one that is down.

What happens if all validators fail

RTR data has an expiry time. If a router cannot reach any validator for longer than that, it discards the VRPs, every route becomes NotFound and is accepted again. The network keeps forwarding traffic, only without origin protection, which is the reason the design is considered safe to deploy. The real risk is the opposite case: a validator that is up but serves stale or incomplete data, which is why monitoring its freshness matters.

Where to apply the policy

Rejecting Invalid routes at the network edge protects your own customers. Validating routes you send to others as well, as described in RFC 8893, also stops your network from propagating Invalid routes that entered through an internal path or a static configuration.

You do not need your own validator to see how a route validates. ipctl.io validates the announced routes in the global BGP table against the published ROAs and shows the result on every lookup page:

• The RPKI & ROA lookup takes a prefix or an ASN and shows the covering ROAs, their maxLength and the state of each announced route.
• Prefix pages such as 1.1.1.0/24 list the ROAs that cover the prefix next to the BGP announcements.
• ASN pages such as AS13335 summarize how many of a network's announcements are Valid, Invalid or NotFound.
• BGP statistics show the share of each state across the whole routing table.

From a terminal, the plain-text interface returns the state of the route that covers an address:

$ curl ipctl.io/ip/1.1.1.1/rpki
valid

This shows the state computed from published ROAs. It does not tell you whether a particular network enforces ROV: a route can be Invalid in the RPKI and still be accepted by networks that do not drop Invalid routes. To test enforcement, operators compare reachability of deliberately Invalid test prefixes from inside the network in question.

ROV checks only the origin AS. A route with a forged AS-path that ends in the legitimate origin is Valid, and a route leak that keeps the correct origin passes as well. Path-level checks are the job of ASPA: ASPA objects are published in the same RPKI and validated by the same kind of software, and a newer version of RTR that also carries them to routers is being standardized. ROV is also only as good as the published ROAs: a prefix without a ROA stays NotFound and gets no protection, no matter how many networks validate.

Within those limits, dropping Invalid routes is a widely recommended baseline for networks of every size. The difference between the published data and the check is summarized in ROA vs ROV.