RPKI and the RTR protocol

RPKI’s Last Mile: The RTR Protocol

The Resource Public Key Infrastructure (RPKI) system uses cryptographically signed records—Route Origin Authorizations (ROAs)—to assert which Autonomous Systems (ASes) are authorized to announce specific IP prefixes. Validators process these records from the five Regional Internet Registries to build a list of validated routes. But getting that list onto a router’s control plane requires a separate, much lighter protocol.

That protocol is the RPKI to Router Protocol (RTR), specified in RFC 8210. This article covers version 1 of the protocol.

Why RTR Exists

Routers are not designed for the heavy cryptographic workload of RPKI certificate validation. The RTR protocol offloads that work to a dedicated validator or cache server. The router receives only the processed result: a simple list of CIDR prefixes, ASNs, and optional MaxLength parameters. With that data, the router can make a yay-or-nay decision when a BGP announcement arrives, without ever touching certificate chains or signature algorithms.

This separation has a second benefit. The cryptographic machinery of RPKI (fetching, storing, and checking certificates from global repositories) can run in an isolated environment, often on a protected network. The router’s control plane stays focused on BGP convergence and other routing protocols.

When Cloudflare operates RPKI, for example, validation is performed by OctoRPKI, while RTR communication is handled separately by GoRTR, both open source. RTR implementations are also bundled with several other validation packages:

• Cloudflare RPKI Validator Tools and Libraries (OctoRPKI & GoRTR)
• Dragon Research Labs RPKI Toolkit
• NIC Mexico and LACNIC FORT project, including the FORT validator
• NLnet Labs Routinator 3000
• RIPE NCC RPKI Validator version 2 (deprecated)
• RIPE NCC RPKI Validator version 3
• rpki-client by OpenBSD

Because GoRTR reads a common JSON file format, it can be paired with different validators, giving operators flexibility in mixing and matching tools.

Protocol Mechanics

RTR keeps things simple. A router establishes a TCP connection to an RTR cache server, then exchanges serial numbers and data records to synchronize the validated route database between the two. The protocol is deliberately free of cryptographic data; it transfers only the validated prefix-origin mapping.

The synchronization is driven by two values: a session ID created by the cache server and serial numbers exchanged between cache and router. This allows the router’s route authentication data to stay fresh while transferring a minimal amount of data. Router configuration varies by vendor; a Cisco example would enable the RTR session with straightforward commands, and other platforms (Juniper, Arista, Bird 2.0) have their own syntax. The protocol handles both IPv4 and IPv6 prefix data.

Transport Security Considerations

RTR is the point where RPKI’s cryptographic trust chain ends. The authoritative data is verified at the validator, but the onward link to the router carries only the stripped-down result. It is the network operator’s responsibility to ensure that this final hop remains trustworthy.

RFC 8210 defines several transport options:

• Plain TCP—acceptable only when cache and router reside on the same trusted, controlled network
• TCP with TCP-AO
• Secure Shell version 2 (SSHv2)
• TCP with MD5 (obsoleted by TCP-AO)
• IPsec
• TLS

In practice, TCP-AO has seen little production deployment, leaving early implementations often running plain text. Better options exist. SSH requires keys to be exchanged out of band. TLS—per the RFC—requires client-side certificates so that a cache can authenticate routers and reject unauthorized connections, helping manage load. When these measures are properly configured, the protocol connection becomes resistant to man-in-the-middle attacks.

Exercising RTR Without a Router

For operators with a test lab, configuring a router to run RTR against a cache is enough to observe RPKI-based route filtering in action. But for those without one, Cloudflare has released rpki-rtr-client, a Python implementation that plays the router’s side of the protocol. Written directly from the RFC and tested against Cloudflare’s public RTR cache, the tool outputs debug information and can serve as a reference for testing new caches or existing implementations.

Since there is no actual router to drop invalid routes, the client merely writes the received records to data files for later review. Valid ROAs are listed in the output, and the code can dump the raw binary protocol for replay-based debugging.

Looking Ahead

The current RFC specifies version 1, but work is underway toward version 2, tied to the ASPA (Autonomous System Provider Authorization) drafts. ASPA extends RPKI data structures to carry BGP AS-path information, which today’s Route Origin Validation—and ROAs—do not cover. RTR version 2 will add messaging to deliver ASPA data to routers.

IRR-based filtering, the current mainstream approach, relies on non-cryptographic route definitions and is typically implemented through massive static filter lists in router configuration files—not through a dynamic protocol like RTR. If RPKI is to become the standard method, RTR support needs to be present and current across all BGP-speaking router platforms, including secure transport options and timely adoption of protocol revisions.