Certificates and ROAs
RPKI has three layers:
- Trust anchors. Each of the five RIRs (AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC) operates a root certificate. Relying-party software ships with each one's TAL (Trust Anchor Locator): a URL plus the root's public key.
- Resource certificates. The RIR issues each member a certificate whose extension lists exactly the IP prefixes and ASNs it holds (RFC 3779). Sub-allocations can be certified further down the chain.
- Signed objects. With its certificate, a holder signs objects. The important one is the ROA: a prefix, a maximum length and one origin AS (profile in RFC 9582). Manifests and CRLs make it possible to detect missing or revoked objects.
Signed objects are published in repositories, at the RIR (hosted RPKI) or on your own server (delegated RPKI). Validators fetch them over RRDP (HTTPS, RFC 8182), with rsync as a fallback.
Hosted or delegated?
- Hosted: the RIR keeps your keys and you manage ROAs in its web portal. Simplest, and the right choice for almost everyone.
- Delegated: you run your own CA (for example NLnet Labs' Krill) and publish yourself. Useful for large organisations with many resources or automation needs, but publication outages become your problem.
- The trust anchor. Each of the five RIRs runs a root certificate. Validators ship with a Trust Anchor Locator (TAL), a tiny file saying where to fetch that root and what its public key is.
- Your resource certificate. The RIR issues you a certificate listing exactly the IP space and ASNs you hold. It is the cryptographic equivalent of your registration, and you can't sign for space that isn't on it.
- You sign a ROA. In the RIR portal you create a Route Origin Authorization: "203.0.113.0/24, maxLength 24, may be originated by AS64501". It is signed under your certificate and published to a repository.
- The validator checks everything. Your validator downloads every RIR's repository tree (RRDP over HTTPS, or rsync), verifies every signature back to the trust anchors, and discards anything expired or broken. The output is a list of Validated ROA Payloads (VRPs).
- Routers get VRPs, not crypto. Routers don't do any cryptography. They receive the VRP list over the RPKI-to-Router protocol (RTR) and check every BGP route's origin against it.
Check your understanding
Why can't AS64511 create a valid ROA for 203.0.113.0/24, which is allocated to AS64501's organisation?
- ROAs are reviewed by the RIR before publication
- A ROA must be signed under a certificate that lists 203.0.113.0/24, and only the holder has one
- AS64511 isn't in an IRR
- ROAs can only be created for /24 or shorter