Why RPKI
Cryptographically signed routing origins: the RPKI trust chain, creating safe ROAs, Valid/Invalid/NotFound, validators and RTR, a real FRR + StayRTR lab, and what ROV can't stop (forged origins, leaks), plus where ASPA comes in.
By the end you will be able to:
- Explain what RPKI proves that IRR data can't, and how the two complement each other
- Trace the chain from RIR trust anchor to resource certificate to ROA to VRP
- Create ROAs safely, choosing maxLength and handling multiple origins and AS0
- Classify any route as Valid, Invalid or NotFound by hand
- Run validators and RTR, and configure FRR to drop Invalid routes
- Explain forged-origin hijacks and route leaks, and how ASPA addresses them
Prerequisites: IRR, RPSL and AS-SETs
The IRR tells you what networks say they'll announce. But nothing signs IRR data, non-authoritative registries accept anyone's objects, and plenty of objects are years out of date. The Resource Public Key Infrastructure (RPKI) answers a narrower question with much stronger guarantees:
Has the holder of this address space authorised this AS to originate it?
RPKI mirrors the address allocation hierarchy with X.509 certificates. The RIR that gave you your space also gives you a certificate for it, and with that certificate you sign Route Origin Authorizations (ROAs). Anyone can verify those signatures back to the RIR's trust anchor, without trusting any database operator.
| IRR | RPKI | |
|---|---|---|
| Answers | Which prefixes does this AS or as-set intend to announce? | May this AS originate this prefix? |
| Trust | Whoever controls the maintainer; non-auth IRRs check nothing | Cryptographic, chained to the RIR that allocated the space |
| Covers | Origin, set membership and (optionally) policy | Origin and maximum prefix length only |
| Used for | Building per-customer prefix-lists | Route Origin Validation of every route, from every neighbour |
| Failure mode | Stale or bogus data | Missing ROAs (NotFound); bad ROAs make your own routes Invalid |
They complement each other: build customer filters from the IRR, and drop RPKI-invalid routes on every session.
Adoption is now mainstream. Most large transit providers and clouds drop RPKI-invalid routes, and a majority of announced IPv4 and IPv6 space is covered by ROAs. If your space has no ROA, someone else can hijack it while still looking "NotFound" rather than "Invalid".
Check your understanding
Your prefix has no ROA. Someone else starts originating it. What do networks that drop RPKI-invalids do with the hijacked route?
- Drop it, because it's Invalid
- Accept it, because it's NotFound
- Accept it with lower preference
- Look up the IRR to decide