What Is RPKI? A Beginner’s Guide to Routing Security
How RPKI checks route origins, what its results mean, and why Lu Heng argues that reliable security also needs limits on registry power.
A website can be working perfectly and still become unreachable. Somewhere between its network and its visitors, another network may announce the wrong route. Traffic then heads towards a place that cannot deliver it—or towards someone trying to intercept it.
RPKI, short for Resource Public Key Infrastructure, helps networks check one important claim: is this network authorised to announce these IP addresses? Understanding that check also reveals a deeper question. Who controls the records on which the check depends?
Start with the claim a network makes
The Internet is a network of networks. BGP, the Border Gateway Protocol, lets them exchange announcements about how to reach groups of IP addresses. Such a group is called a prefix. Each independently operated routing network is identified by an autonomous system number, or ASN.
Imagine a delivery company announcing, “We can deliver to this neighbourhood.” Other companies need some way to check that claim. In routing, an incorrect announcement can result from a typing mistake or a deliberate hijack. BGP announcements alone do not prove that the network named as the route’s origin has permission to originate it.
What RPKI, ROAs and validation each do
RPKI supplies a certificate framework for Internet number resources. An address holder can publish a signed Route Origin Authorisation, or ROA. It identifies an ASN allowed to originate a particular prefix and, where specified, how narrowly that address range may be subdivided in announcements. The technical definition is in RFC 9582.
Publishing a ROA and checking incoming routes are separate jobs. Validation software checks certificates and signed records, then supplies the verified authorisation data to routers. Routers compare route announcements with those data; operators choose the routing policy that follows. This comparison is called Route Origin Validation, or ROV. RIPE NCC’s operator guide explains this division of work.
In the delivery example, one party publishes who may serve the neighbourhood; other parties check that permission. A certificate is evidence within this system. It is not proof that every subsequent delivery will be safe.
Three results, not a simple yes or no
Valid: at least one verified authorisation covers the announced prefix and permits both the stated origin ASN and the prefix length. Invalid: covering authorisations exist, but none permits that combination. NotFound: there is no covering authorisation in the validation data.
NotFound does not mean an attacker has been detected. Invalid does not, by itself, explain whether the cause is an attack or a configuration error. These states describe the comparison, as defined in RFC 6811.
What this protection can—and cannot—tell you
Origin validation can help networks reject unauthorised origins. It does not authenticate every network along a route, encrypt a visitor’s connection or guarantee that a website stays available. A route leak can retain an authorised origin and pass this check. Filtering and monitoring still have work to do; RPKI is one part of routing security.
For operators, useful preparation starts with their actual announcements: which prefixes they originate, through which ASNs, and whether the published authorisations match. Keeping those records and validators working matters as much as enabling a router setting. RFC 7115 discusses the operational considerations.
The records themselves are a point of power
The commonly used RPKI trust hierarchy follows resource allocation, with regional Internet registries at its roots. Verification therefore depends on more than sound mathematics: it also depends on the certificate authorities and publication systems supplying the records.
Changing or withdrawing records can change validation outcomes. That is not automatically an Internet-wide shutdown: the effect depends on other available authorisations and operators’ routing policies. RFC 8211 examines adverse actions and errors by certification authorities and repository managers. A security mechanism can reduce one risk while creating dependencies that deserve scrutiny.
Lu Heng’s argument: protect the network and limit the gatekeeper
In Note 28, Why Registries Must Never Become Enforcers, Lu Heng draws a sharp boundary: maintaining the address book must not turn into a power to punish its users. His objection concerns the authority claimed by administrators, not the need for accurate records. A small, self-selected group does not acquire a mandate over networks across continents merely by operating their coordination service.
Note 64 develops his proposed alternative: shared rules should cover the minimum needed for uniqueness and security, with evidence participants can verify themselves. Records and proofs should be portable; operators should be able to replace a service provider without surrendering their network identity. Future changes should win adoption through their usefulness, rather than through permanent administrative control.
This is a direction for rebuilding coordination, not a claim that an alternative RPKI system is already universally deployed. It still has to preserve compatible records and reliable verification. The demanding part is achieving both: protection against false claims and protection against an unaccountable authority over the evidence.
Why the question matters before an outage
A network’s customers depend on its familiar addresses every day. If it discovers a dependency only when its records change or disappear, recovery is already a live service problem. Lu Heng’s case for change begins here: build continuity, independent verification and the ability to leave into the system before they are needed in a dispute.
To follow that argument from criticism to design, read Lu Heng’s Note 64 on minimum shared rules, local decisions and voluntary adoption.