The RPKI-to-router protocol lets routers retrieve Route Origin Authorisation data and related validation information from an RPKI cache. Routers use that data to assess whether BGP announcements are authorised. Practitioners should protect the cache-to-router channel, monitor validation failures, and understand that stale or unavailable data can affect routing decisions.
How the protocol moves validation data from cache to router
RPKI-to-router is a simple distribution protocol: a router opens a session to an RPKI cache and asks for route origin validation state, then keeps that state updated as the cache changes. The router does not validate certificates itself in this exchange, it relies on the cache as the source of truth for authorised origins and related validation outcomes.
The operational value is separation of concerns. The cache performs the heavy RPKI processing, while the router consumes the resulting state to make routing decisions. That makes the protocol lightweight for routers, but it also means the quality of downstream routing decisions depends on the freshness, completeness, and integrity of the cache feed.
Because the protocol is about retrieving validation data, the practical question is less “what does the wire format look like?” and more “can the router trust what it receives right now?” A stale cache, a broken session, or a partial dataset can leave the router operating on outdated authorisation state even when the BGP session itself appears healthy.
What the router uses the data for in BGP
The router uses the cache-supplied data to check whether a BGP announcement matches an authorised origin for the prefix being advertised. That lets operators apply route origin validation logic before accepting, preferring, or de-prioritising routes. In practice, the protocol supports the policy decision, while the router’s local routing policy determines how strict that decision becomes.
This is why the protocol matters even though it is not the validator itself. Without a current feed of validation results, the router cannot reliably tell the difference between an authorised announcement, an unauthorised announcement, and a case where it simply lacks enough information. The distinction affects whether you treat a route as valid, invalid, or unknown.
For operators, the protocol therefore sits at the boundary between routing security and routing policy. A correctly functioning cache-to-router path improves confidence in accepted routes, but it does not by itself solve route leaks, hijacks, or bad upstream policy. It only supplies the evidence the router needs to make a better choice.
What makes the channel and the cache operationally sensitive
The channel between cache and router is sensitive because it is a trust path for security decisions. If that channel is disrupted, spoofed, or delayed, the router may make decisions on incomplete or incorrect data. BGP and Routing Security Guide provides broader context on how RPKI fits into routing security and why route validation is only one part of the control stack.
That sensitivity is not only about attack activity. Simple operational faults matter too, including clock skew, reachability problems, software bugs, and cache rollovers that are not reflected promptly on the router. When the validation feed drifts away from current reality, the router may keep using old authorisation state long enough to distort routing posture.
Another practical issue is scope. If the cache serves multiple routers or multiple policy domains, a failure can fan out widely. In other words, the protocol creates a central point for validation distribution, so resilience and monitoring matter as much as protocol correctness.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Applies to protecting the cache-to-router trust path and access to validation data. |
| DE.CM-01 — Networks and Network Services Are Monitored to Find Potential Cybersecurity Events | Relevant because cache outages or stale validation feeds must be monitored. | |
| Recommendation — Restrict cache-to-router access and authenticate the management channel. Monitor router validation feed health and alert on stale or unavailable cache data. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Supports secure handling of routing infrastructure and protocol dependencies. |
| Recommendation — Harden and monitor routing infrastructure that carries validation data. | ||
| MITRE ATT&CK | T1565 — Data Manipulation | Manipulated validation data can alter routing decisions if the trust path is compromised. |
| Recommendation — Validate integrity of routing data feeds and investigate unexpected state changes. | ||
Practitioner Guidance
What to verify: Confirm which cache each router trusts, how often validation data refreshes, and what the router does when the cache is unreachable. Treat “unknown” handling as an explicit policy choice, not an implicit default.
What to measure: Watch for validation state age, session uptime, and the rate of invalid or unknown route outcomes. Sudden shifts in those signals often indicate cache staleness, reachability loss, or upstream publication problems rather than a pure routing event.
Decision rule: If the cache feed is stale or unavailable, prioritise restoring trust in the validation path before assuming a BGP policy problem. If route validation data is inconsistent across routers, investigate cache synchronisation and routing-policy divergence together.
Practitioner takeaway: RPKI-to-router is only as trustworthy as the freshness and integrity of the cache feed, so operators should manage it as a routing-security dependency, not a background transport detail.