Resource Public Key Infrastructure
Follow signed resource authorization from a ROA to the validated data a router uses.
Authorize an origin, not an entire AS path
BGP by itself does not prove that the origin AS is entitled to announce a prefix. Resource Public Key Infrastructure binds resource certificates to signed routing authorizations. A resource holder publishes a Route Origin Authorization (ROA) for an ASN, a prefix and an optional maximum length. This is different from encrypting BGP or validating every transit relationship.
Separate the trust and routing roles
| Stage | Responsibility |
|---|---|
| Resource holder / CA | Create signed authorizations for resources it controls. |
| Repositories and trust anchors | Publish certificates, manifests, revocation information and signed objects. |
| Relying-party validator | Fetch and cryptographically validate the objects against configured trust anchors. |
| Validated ROA payloads (VRPs) | Expose prefix, maxLength and origin-AS tuples from accepted authorizations. |
| Router over RPKI-RTR | Download validated tuples and compare route announcements. |
| Routing policy | Decide how validation state affects acceptance and selection. |
A router normally consumes a validated cache; it does not fetch and validate every repository object for each UPDATE. ROA and VRP describe different stages, although their routing fields overlap.
Read a concrete authorization
| Prefix | maxLength | Authorized origin |
|---|---|---|
| 198.51.100.0/24 | 25 | 64496 |
This is a synthetic documentation-space example, not a statement about the public RPKI database. AS64496 and AS64497 are documentation ASNs. A maxLength of 25 permits this /24 and its two /25s, not /26s. Omitted maxLength ordinarily authorizes only the ROA’s prefix length.
Compute the validation result
| Announcement | Origin | Result | Reason |
|---|---|---|---|
| 198.51.100.0/24 | 64496 | Valid | Covered, length permitted, origin authorized. |
| 198.51.100.0/25 | 64496 | Valid | More specific within maxLength. |
| 198.51.100.0/26 | 64496 | Invalid | A covering VRP exists, but this length is too specific. |
| 198.51.100.0/24 | 64497 | Invalid | Covering VRP does not authorize this origin. |
| 203.0.113.0/24 | 64497 | NotFound | No covering VRP in this synthetic dataset. |
If any covering VRP authorizes both the origin and the announced length, the route is Valid. If there is covering data but no authorizing tuple, it is Invalid. Without any covering VRP it is NotFound. Evaluate all relevant VRPs; do not stop at the first covering record.
Understand scope and cache health
NotFound is not the same as Invalid and is not automatic proof of an attack. Valid does not authorize the full path and does not prevent every route leak. An AS0 authorization intentionally authorizes no normal origin. Cache connectivity, expiration, trust-anchor configuration and redundant validators all influence what data is available. Monitor them rather than equating a disconnected cache with a single fixed route outcome.
Apply policy in the next lesson
The next page connects routers to an RTR cache and makes rejection of Invalid routes explicit. Production changes require the operator’s actual prefixes, AS assignments and authorization data. No public ROA is created or changed by the examples here.
Key Takeaways
- ROAs authorize an origin AS, prefix and allowed length.
- Validators turn accepted signed data into VRPs.
- Routers consume validated cache data over RTR.
- Valid, Invalid and NotFound are different states.
- Origin validation does not validate the whole AS path.
Protocol and command references
RPKI architecture · Origin validation · ROA maxLength guidance · Router-symbol attribution.