RPKI Explained: How the Internet Checks Who May Announce an IP Address

What is RPKI, in one answer?

RPKI is a signed public registry that answers one question: is this network actually allowed to announce this block of IP addresses? The owner of an address block publishes a signed statement — a ROA — naming the one network (identified by its AS number) that may announce it. Other networks download those statements, check the signatures, and compare every BGP announcement they receive against them. An announcement that matches is trusted. One that flatly contradicts the registry can be dropped.

Think of it as the land registry for internet addresses. Owning a house does not physically stop a stranger from telling people the house is theirs. What stops them is the registry: anyone can look up the official record and see whose name is really on the deed. Before RPKI, BGP — the routing protocol that stitches the internet together — had no registry to consult. If a network announced "send traffic for this address block to me", other networks mostly took its word for it. That trust is exactly what BGP hijacks abuse, whether the announcement is a malicious theft or a tired engineer's typo.

Why BGP needed a registry

BGP was designed when the internet was a small club of cooperating institutions, and it shows: the protocol itself contains no check that the network announcing a prefix owns it or was given it. Filters and registries of good intentions grew around that hole, but the announcement itself was never signed. So when a network — by attack or by accident — announces someone else's prefix, or a more specific slice of it, routers around the world have to decide with no authoritative evidence. Because more specific prefixes win in routing, announcing a small slice of someone else's block is often enough to pull their traffic toward you.

RPKI adds the missing evidence, and it deliberately checks a narrow thing well: origin validation. It does not try to prove the whole journey a route claims to have taken. It proves the starting point — that the network at the end of the path, the origin AS, was authorised by the address holder to announce a prefix of that length. A narrow check, done cryptographically, at internet scale.

The chain of trust, link by link

RPKI's authority flows from the same hierarchy that hands out addresses in the first place. At the top sit the five Regional Internet Registries (RIRs) — AFRINIC, APNIC, ARIN, LACNIC and RIPE NCC — each acting as a trust anchor. An RIR issues a resource certificate to each address holder, cryptographically stating "these prefixes and AS numbers are allocated to this holder." Only that holder, using that certificate, can sign a valid ROA for those addresses. A forged ROA fails the signature check, the same way a forged deed fails against the registry's records.

The last two links deserve a closer look, because they are where the engineering gets sensible. Routers are busy forwarding packets; nobody wants them fetching repositories and verifying certificate chains. So separate relying-party software — the validator — does that heavy work: it continuously downloads the global RPKI repositories, verifies every signature back to the five trust anchors, and distils the survivors into a plain list of authorised (prefix, maximum length, AS) triples called Validated ROA Payloads (VRPs). Routers fetch just that list from their local validator over the RPKI-to-Router protocol (RTR, RFC 8210) and can then judge an announcement with a table lookup.

Anatomy of a ROA: three fields that matter

A ROA (format in RFC 9582) is a small signed object, and operationally it says exactly three things. The prefix it covers, for example 192.0.2.0/24 — an example block from the documentation range, used throughout this guide with the documentation AS numbers AS64496 and AS64497 so no real network is named. The origin AS authorised to announce it, say AS64496. And maxLength: the longest — most specific — prefix length that AS may announce inside the covered block. A ROA for 192.0.2.0/24 with maxLength 24 authorises exactly that /24 and nothing smaller. A ROA covering a larger block, with a maxLength well beyond the prefixes actually announced, authorises every in-between slice too — a looseness with real consequences, covered in the mistakes section below.

Creating ROAs is normally a few clicks in your RIR's portal (most registries offer a hosted system where the RIR runs the certificate machinery for you), and the standing advice is boring on purpose: one ROA per prefix you actually announce, per origin AS that actually announces it, with maxLength set equal to the announced prefix length unless you genuinely deaggregate (RFC 9319 calls these "minimal ROAs").

The three verdicts: Valid, Invalid, NotFound

When a router receives a BGP announcement, Route Origin Validation (RFC 6811) compares the announcement's prefix, length and origin AS against the VRP list and stamps it with one of three states:

Work the example. The ROA says AS64496 may announce 192.0.2.0/24, maxLength 24. An announcement of 192.0.2.0/24 from AS64496 is Valid — claim and registry agree. The same prefix announced from AS64497 is Invalid — the registry covers this prefix and names someone else. And an announcement of a prefix nobody has published a ROA for is NotFound — the registry is silent, which is absence of evidence, not evidence of theft.

That distinction drives real policy. Networks that enforce ROV typically drop Invalid — the registry has spoken and the announcement contradicts it — and accept NotFound, because a large share of the world's prefixes still have no ROA, and dropping them all would cut off legitimate destinations. Valid versus NotFound can still inform preference, but the bright line most operators draw is at Invalid.

What RPKI does not do

RPKI is one lock, not the whole door, and three limits matter. It validates the origin only. ROV checks the last AS in the path and the prefix length; it does not verify the rest of the path the route claims to have travelled, so an attacker who forges a path ending in the authorised origin can still pass — that gap is what path-validation work such as BGPsec (RFC 8205) addresses, and what the maxLength deep-dive linked below dissects with a real incident. It does not stop route leaks, where a network accidentally passes along routes it legitimately received in ways that break policy — the origin in a leak is usually genuine. And it only protects you twice over if both sides do their part: holders must publish correct ROAs, and receiving networks must actually validate and drop Invalid. Your ROAs stop validating networks from accepting a hijack of your prefixes; your own validation stops you from accepting hijacks of everyone else's.

Four mistakes that make RPKI bite its owner

1. Announcing before the ROA exists. Publish the ROA first, wait for it to propagate to validators, then announce. Announce first and validating networks will stamp your own brand-new route Invalid and drop it — RPKI working exactly as designed, against you.

2. A stale ROA after a provider change. If a new provider originates your prefix on your behalf, the ROA must name their AS as the origin. Forget to add it — or forget to remove the old provider's — and you have either an outage or a lingering permission you no longer intend.

3. A loose maxLength "to be safe". Setting maxLength to /24 on a large block feels flexible and quietly authorises every more-specific slice inside it, including slices you never announce, which a forged-origin hijack can hide behind. Minimal ROAs — maxLength equal to what you actually announce — close that space.

4. Dropping NotFound. Tempting in a fit of strictness, catastrophic in practice: you would refuse every prefix whose holder has not deployed RPKI yet. Drop Invalid, monitor NotFound, and let coverage grow.