On this page
01 What RPKI proves about a route
RPKI, the Resource Public Key Infrastructure, lets a router decide whether a BGP announcement was authorised by the holder of the prefix it names. BGP itself has no such check: any autonomous system can announce any prefix, and the internet learns the route on the strength of the peering relationships that carried it. A mistyped prefix and a deliberate hijack look identical. RFC 6480 fixes one part of the problem, the origin, with a chain of X.509 certificates that follows the allocation of address space.
The idea is narrow on purpose. RPKI answers one question: is the AS at the far end of this AS_PATH allowed to originate this prefix? That catches the common accidents and the crudest attacks, using objects a registry already knows how to issue. This page belongs to the lane index for network-layer authenticity, which treats the network as evidence of where things came from.
02 What an ROA states
The signed object at the centre of the system is the Route Origin Authorization, or ROA, profiled in RFC 6482 and revised in RFC 9582. It is a Cryptographic Message Syntax object signed with a key whose certificate is issued down the allocation chain: a regional registry's trust anchor, then the registry, then the holder. The certificate carries the address blocks the holder is entitled to, so an ROA can only cover space the signer actually holds.
An ROA has three pieces of content: one origin AS number, one or more IP prefixes, and per prefix an optional maxLength, which says how much more specific an announcement may be and still match: an ROA for 203.0.113.0/22 with maxLength 24 authorises the /22, the two /23s and the four /24s. Without it, only the exact length is authorised. An ROA with origin AS 0 authorises nobody, which is how a holder declares that a prefix should not appear in the routing table at all.
03 From ROA to VRP: the relying-party validator
Routers do not fetch or check ROAs. That work belongs to a relying-party validator, software the operator runs on a server. It starts from a trust anchor locator per regional registry, fetches the certificate tree and signed objects from each repository, and checks every signature, validity period and resource containment on the way. Objects that fail are discarded; the survivors are reduced to prefix, maxLength and origin AS. RFC 6811 calls each such tuple a Validated ROA Payload, or VRP.
The validator repeats this every few minutes, because ROAs change constantly and every object expires, and it keeps the last good set if a repository is unreachable. The output is a plain list of hundreds of thousands of lines across both address families, and that list is what the routers consume.
04 Feeding routers over RTR (RFC 8210)
The RPKI to Router protocol, RTR, version 1 in RFC 8210, carries the VRP list from the validator (the cache, in the RFC's vocabulary) to each router. The router sends a Reset Query and receives a Cache Response, one IPv4 or IPv6 Prefix PDU per VRP, and an End of Data PDU. Afterwards the cache sends a Serial Notify when its data changes and the router fetches the delta with a Serial Query. End of Data also sets three timers: Refresh (default 3600 seconds), Retry (default 600) and Expire (default 7200), after which the router must treat the data as gone.
The registered port is 323. RFC 8210 recommends TCP-AO, SSH or TLS and permits plain TCP only where cache and router share a trusted network, in practice a management VLAN. Run two caches and point every router at both; a router that loses its only cache drops all state after the expire interval and marks every route NotFound.
05 The three RPKI validation states
RFC 6811 defines the comparison precisely. A VRP covers a route when the VRP prefix is the same as or less specific than the route prefix. A VRP matches a route when it covers it, the route length is no longer than the VRP maxLength, and the route's origin AS (the rightmost AS in the final AS_SEQUENCE) equals the VRP AS. Three states follow.
| State | Condition (RFC 6811) | Meaning | Usual policy |
|---|---|---|---|
| Valid | At least one VRP matches the route | The holder authorised this origin and length | Accept; optionally prefer |
| NotFound | No VRP covers the route prefix | No ROA exists for this space | Accept as before |
| Invalid | A VRP covers the route but none matches | Wrong origin AS, or more specific than maxLength | Reject, once your own routes are confirmed Valid |
What to do with Invalid is the operator's decision, and the standards are emphatic. RFC 8481 clarifies two things early implementations got wrong: the router must set the state of every route from every source, including iBGP and redistributed statics, and must apply no policy on that state unless the operator configures it. Common practice is to reject Invalid routes at every eBGP border; RFC 7115 collects the operational advice.
06 Creating an ROA at a regional registry
The steps are the same at every regional registry; only the portal differs. In the hosted model, which almost everyone uses, the registry acts as the certificate authority; a delegated model with your own CA exists for the few who need it.
- Sign in to the registry portal with the account that administers the block and open the RPKI or resource certification section; some registries require a separate terms document first.
- List the prefixes you originate and the AS that originates each, taken from what the routers announce rather than what the address plan says.
- Create one ROA per prefix and origin AS. Leave maxLength unset; if you announce more specifics, create ROAs for exactly those (RFC 9319 explains why).
- Use the portal's preview of the effect on routes currently seen for that space. An ROA that would mark your own announcements Invalid is the commonest mistake.
- Publish, allow an hour for validators to refresh, then confirm on a public looking glass. Repeat for IPv6.
07 What RPKI does not protect
Origin validation checks the last AS in the path and nothing else. An attacker who announces your prefix with your AS number at the end of a forged path passes, because the origin looks right. RPKI does not detect route leaks, where a customer re-announces a provider's routes to another provider, since every AS in a leaked path may be legitimate. And it says nothing about a prefix with no ROA, which is why NotFound must remain acceptable.
Path protection was specified as BGPsec (RFC 8205), which signs each AS hop but has seen little deployment. The more practical work is ASPA, in which a network publishes its providers so a validator can spot a leak; it is still in the IETF SIDR Operations working group. Neither changes the control-plane design of a core router, which still needs its route policy and prefix filters; RPKI adds an input to that policy rather than replacing it.
08 Worked example: one prefix from ROA to a router
Take the documentation prefix 203.0.113.0/24, announced from AS 64496 through an upstream at AS 64500. The holder signs an ROA in the registry portal: prefix 203.0.113.0/24, maxLength unset, origin AS 64496. The object appears in the repository; on its next run the validator verifies the chain and adds the VRP 203.0.113.0/24-24 AS64496, and every router with an RTR session receives the new IPv4 Prefix PDU after the next Serial Notify. On a router receiving the route, the picture looks like this.
router# show ip bgp 203.0.113.0/24 BGP routing table entry for 203.0.113.0/24 Paths: 1 available, best #1 64500 64496 198.51.100.1 from 198.51.100.1 (198.51.100.1) Origin IGP, localpref 100, external, best RPKI validation state: valid router# show rpki roa 203.0.113.0/24 Prefix MaxLen Origin Cache 203.0.113.0/24 24 64496 192.0.2.10:323
Now suppose AS 64511 announces 203.0.113.0/25. The VRP covers the /25 but does not match it: the length exceeds maxLength 24 and the origin differs. The route is Invalid on every router running the reject policy and travels no further than the networks that do not. The holder made one statement, once, and every validating network enforces it.
09 Pitfalls: max-length, stale caches, forgotten IPv6
- Loose maxLength. An ROA for a /16 with maxLength 24 authorises 256 possible /24s, and anyone who spoofs your AS can announce any of them as Valid. RFC 9319 recommends a ROA per announced prefix and no maxLength.
- Stale or single caches. A validator that has stopped fetching serves an ageing list; a router with one cache drops to NotFound when it goes away. Monitor the session serial and the age of the last successful validator run.
- Forgetting IPv6. Coverage is per address family. The IPv6 address planning and transition guide should include ROAs in its checklist.
- Rejecting before checking your own routes. Enable the reject policy only after a looking glass shows every prefix you announce as Valid, including traffic-engineering specifics.
Provider networks carrying customer routes in VRFs should validate at the provider edge too; MP-BGP in a provider VPN core can carry the state as an extended community (RFC 8097). RPKI is the one authenticity check in this lane that the network performs entirely on its own behalf; the natural next step is to sign ROAs for every prefix you hold and watch a public looking glass until each shows Valid.
Route origin is the outermost layer of the authenticity-at-the-network-layer lane. Inside it sit mutual TLS proving each end of a connection, digests and Subresource Integrity proving the payload and a retained log proving what the router decided.
10 Questions
What is RPKI in simple terms?
A system of digital certificates that follows the way IP addresses are allocated. The holder of a block signs a statement, the ROA, naming which AS may announce it. Routers compare announcements against those statements and mark each route Valid, NotFound or Invalid.
Does RPKI stop BGP hijacks?
It stops the common ones, where a misconfigured or hostile router announces someone else's prefix from the wrong AS. It does not stop a forged path ending in the legitimate AS, and it does nothing for prefixes with no ROA. Path protection needs BGPsec or ASPA.
What happens to a route marked Invalid?
Nothing, unless the operator configures a policy. RFC 8481 requires routers to set the state and take no action on their own. Most operators reject Invalid routes at their borders, so the announcement is neither installed nor propagated there.
Should I use maxLength in my ROAs?
Usually not. RFC 9319 recommends a ROA for each prefix you actually announce rather than authorising a range of lengths, because a loose maxLength lets anyone who spoofs your AS announce a more specific and have it validate.
How does the router get the ROA data?
It does not read ROAs. A validator you run fetches and checks the objects and sends the resulting prefix, length and AS list to the router over RTR (RFC 8210), usually on port 323, with updates whenever the list changes.