RPKI Explained: Securing BGP Route Origins

In plain BGP, any network can announce any prefix, and its neighbors have no built-in way to check whether the announcing network actually holds those addresses. Before RPKI, the main defense was filtering based on Internet Routing Registry (IRR) data - useful, but anyone can create IRR objects in some databases, and nothing ties them cryptographically to the address holder.

RPKI closes that gap by attaching cryptographic certificates to the same allocation chain that hands out the addresses. The five Regional Internet Registries know who holds which prefix, so they can certify it. A statement signed with the holder's certificate is therefore strong evidence that the holder really authorized it.

The architecture is described in RFC 6480. It has four parts:

• Trust anchors: each of the five RIRs (AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC) operates a root certificate. Validators are configured with a Trust Anchor Locator (TAL) file for each of them.
• Resource certificates: below each trust anchor, certificates bind address blocks and ASNs to their holders, following the allocation hierarchy (RIR, then member, sometimes national registry or sub-allocation).
• Signed objects: holders use their certificate to sign objects such as ROAs (and newer object types such as ASPA). Most holders use the hosted RPKI service of their RIR; larger ones can run delegated RPKI and publish from their own infrastructure.
• Relying party software (validators): programs that download all published objects (over RRDP, RFC 8182, or rsync), verify every signature back to a trust anchor, and output the list of validated authorizations. Routers receive that list from the validator over the RPKI-to-Router (RTR) protocol, RFC 8210.

The router never handles certificates itself. It only receives a compact list of validated entries - prefix, maximum length, origin AS - and applies it to incoming routes.

A ROA (profile in RFC 9582) says: "AS X may originate this prefix, and more-specifics of it up to length Y". It has three fields that matter for validation:

A prefix can have several ROAs, one per authorized origin. That is how anycast setups or customers announcing provider space are expressed. A ROA with origin AS0 is a special case (RFC 6483, RFC 7607): AS0 never appears as a real origin, so an AS0 ROA marks a prefix that should not be routed at all - unless another ROA for a real AS also covers it.

ROV is defined in RFC 6811. For every route it receives, the router takes the prefix and the origin AS (the right-most ASN of the AS-path) and checks them against the validated ROA list:

1. Find all ROAs whose prefix covers the route's prefix (equal or less specific). If there are none, the route is NotFound.
2. If any covering ROA has the same origin AS and a maxLength at least as long as the route's prefix length, the route is Valid.
3. Otherwise - covered, but no ROA matches both origin and length - the route is Invalid.

Take a single ROA for 203.0.113.0/24, maxLength 24, origin AS64500, and four announcements:

The third row is the one that surprises people: the legitimate origin announcing a more-specific is still invalid if the ROA does not allow that length. The usual policy is to accept Valid and NotFound routes and reject Invalid ones. NotFound has to be accepted because a large part of the address space still has no ROA.

maxLength decides which more-specifics are authorized. If a ROA for 203.0.113.0/24 had maxLength 32, anyone able to forge the origin AS64500 at the end of an AS-path could announce 203.0.113.0/25 and 203.0.113.128/25, ROV would mark those routes valid, and every network that accepts them would send the traffic to the attacker. (Many networks filter IPv4 prefixes longer than /24, which limits this particular example, but the same problem applies to a /22 with maxLength 24.) This is called a forged-origin sub-prefix hijack.

RFC 9319 (BCP 185) therefore recommends avoiding maxLength unless every more-specific it permits is actually announced. In practice: create one ROA per prefix you really announce, with maxLength equal to that prefix's length. If you deaggregate for traffic engineering, add a ROA for each more-specific instead of opening a wide maxLength. Loose maxLength values are a common RPKI misconfiguration and worth checking.

The RPKI and ROA lookup shows, for any prefix or ASN, the covering ROAs and the validation state of the announced routes. The prefix pages show the same per prefix, and the ASN pages summarize how many of a network's announcements are valid, invalid or not covered.

From a terminal, the plain-text interface prints the state of the prefix that routes an address:

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

$ curl ipctl.io/prefix/1.1.1.0/24
Prefix:          1.1.1.0/24
Origin AS:       AS13335
RPKI:            valid
...

For automation, the REST API returns the ROAs (prefix, origin_asn, max_length, trust_anchor) and the RPKI status of each BGP route in the prefix endpoint; the API documentation has the details.

If you hold address space: create ROAs

1. List every prefix you announce and the AS that originates it, including more-specifics and prefixes announced by customers or DDoS protection services on your behalf.
2. Create the ROAs in your RIR's hosted RPKI (or your delegated CA). Use maxLength equal to the announced length.
3. Wait for the objects to propagate (validators typically refresh within an hour), then check that every announcement shows as valid and none as invalid.
4. Keep ROAs in your change process: before you move a prefix to a new origin or start announcing a more-specific, create the matching ROA first.

If you run routers: validate and drop invalids

1. Run at least two validator instances, independently of each other, so a single failure does not leave routers without data.
2. Connect the routers to the validators over RTR and start by only tagging routes with their state, to see what would be dropped.
3. Once the impact is understood, reject Invalid routes on eBGP sessions. If all validators become unreachable, routers keep using their cached data until it expires and then treat every route as NotFound, so the network keeps working.

RPKI ROV validates only the origin - the last ASN in the path - and it can only see a wrong origin, not a forged one. An attacker who announces the prefix with the legitimate origin AS placed at the end of a fake path passes ROV, and a route leak keeps the correct origin and passes as well.

Closing that gap is the job of path validation. ASPA uses the same RPKI hierarchy to publish customer-to-provider relationships so routers can detect implausible paths and leaks; BGPsec signs the path hop by hop but has seen little deployment. ROV remains the foundation: ASPA complements it, it does not replace it.