How Resource Public Key Infrastructure Works
Follow an RPKI authorisation from address holder to router, and understand Lu Heng’s case for keeping the service reliable and its administrator replaceable.
You move a service to a new network. Its servers are healthy, its addresses have not changed, yet some visitors can no longer reach it. One possible cause is surprisingly small: the Internet’s routing records still authorise the old network to announce those addresses.
RPKI turns that permission into something other networks can check. Here is how it travels from an address holder to a router—and why Lu Heng argues that keeping this machinery running must never depend on keeping one administrator in power. For a shorter introduction, start with what RPKI protects.
1. Establish who can authorise the addresses
A group of IP addresses is called a prefix. A network announcing that prefix identifies itself with an autonomous system number, or ASN. RPKI, the Resource Public Key Infrastructure, uses certificates to establish who can issue authorisations for particular address ranges.
Those certificates form a chain back to a trusted root. The hierarchy follows Internet number-resource allocation, as described in RFC 6480. It provides evidence about resources within that system; it does not give a certificate authority a political mandate over the people using the Internet.
2. Publish a signed permission
The address holder publishes a Route Origin Authorisation, or ROA. Its message is specific: this ASN may originate this prefix. Originating means being the network at the start of the advertised route, not every network that carries the traffic afterwards.
A ROA can also set a maximum prefix length: how far the address range may be split into smaller announced ranges. Without that optional setting, it permits only the stated prefix length. This prevents “permission for this range” from silently becoming permission for every possible subdivision. RFC 9582 defines the signed record.
3. Turn published records into verified data
The signed records are made available in publication repositories. Validation software collects them and checks the certificate chain, signatures, expiry and revocation information, together with the manifests describing the published objects. A readable file alone is not enough: its supporting evidence must also pass validation.
The validator produces usable authorisation data, often called Validated ROA Payloads, or VRPs. These contain the prefix, permitted origin ASN and maximum length. Routers receive the results from a trusted cache over the RPKI-to-Router protocol described in RFC 8210. They do not ask a registry for permission each time a visitor opens a page.
4. Compare the route with the permission
BGP is the protocol through which networks advertise routes. A receiving router compares a route’s prefix and origin ASN with its validated authorisations. This is Route Origin Validation, or ROV.
Valid: a covering authorisation permits both the origin and prefix length. Invalid: covering authorisations exist, but none permits that combination. NotFound: no authorisation covers the prefix. These are comparison results, not verdicts about someone’s intentions. The operator decides how to use them in routing policy. See RFC 6811.
Return to the service move. If the old ASN is still authorised and the new one is not, the new announcement can be Invalid. Networks filtering Invalid routes may reject it. The fix is to coordinate the authorisation change with the move, including any period when both networks need permission—not to assume that healthy servers guarantee reachability. RFC 7115 covers operational precautions.
5. Keep the whole chain working
Origin validation helps reject false origin claims. It does not verify every hop, encrypt traffic or catch every route leak. A leak can retain an authorised origin. Other routing protections remain necessary.
The evidence also needs maintenance. Certificates expire; permissions and publication data change. Removing a ROA need not cause an immediate outage: the eventual validation result depends on other available records, and the routing consequence depends on local policy. RFC 8211 examines how errors or adverse actions by certificate authorities and repository operators can affect the system.
Lu Heng’s proposal: preserve the service, replace the administrator
In Note 70, Lu Heng challenges a familiar leap: because a registry service is essential, its current operator must be irreplaceable. Networks need accurate records and working security. That does not establish an institution’s permanent right to control them.
His proposed alternative makes continuity a property of the system: independently auditable records, a tested handover to a qualified successor, and a way to move administration without forcing networks to change their addresses. He explicitly recognises that RPKI cannot be transferred by copying a directory. Keys, certificates, publication and trust must remain coherent throughout the transition.
This is a design requirement he argues for, not a claim that such portability is already available everywhere. It addresses both sides of the problem: careless replacement could disrupt verification; an irreplaceable gatekeeper can turn that dependency into power. Keeping the service dependable and its administrator replaceable must be designed together.
Why build that ability before a crisis?
When a dispute reaches the certificate chain, it can affect people far beyond the disputing parties. Customers did not choose the argument, but they may bear the cost of disrupted connectivity. A succession process improvised during an outage is already too late to protect them from that uncertainty.
Lu Heng’s case is to establish continuity and the right to leave in advance, while keeping administrative disputes from becoming a weapon against working networks. Follow the full argument in Note 70: protect the ledger, not the gatekeeper.