What is RTR?

RTR (the RPKI to Router protocol) is the simple TCP protocol that RPKI validators use to send validated route origin data to routers, and keep it up to date.

Routers don't check RPKI signatures themselves. A validator (or a separate cache such as StayRTR) produces a list of VRPs, each a prefix, a maximum length and an authorised origin AS, and serves it over RTR. The protocol was first defined in RFC 6810 and revised as version 1 in RFC 8210, which added router keys for BGPsec and timer values that the cache can suggest to the router. A session works like this:

1. The router connects and sends a Reset Query to ask for everything.
2. The cache replies with a Cache Response, one prefix record per VRP, and End of Data with a session ID and serial number.
3. When the data changes, the cache sends a Serial Notify. The router replies with a Serial Query quoting its last serial, and receives only the additions and withdrawals since then.

The router also polls on its own refresh timer, and stops trusting the data if it can't reach a cache before the expire timer runs out.

IANA assigned TCP port 323 for RTR, but most deployments run it on an unprivileged high port; StayRTR defaults to 8282, and Routinator is conventionally run on 3323. RTR itself is unencrypted and unauthenticated in its plain TCP form, so keep caches close to the routers on a trusted management network. Point each router at two or more caches, ideally different implementations, and monitor the sessions: when every session is down and the data expires, ROV silently stops protecting you, because routes fall back to NotFound. See also RPKI. The RPKI and Route Origin Validation lesson runs a real RTR session between FRR and StayRTR.