The Resource Public Key Infrastructure (RPKI) to Router Protocol
updated by
- rfc-8210 — The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
Extracted elements (29)
As of publication, there is no mandatory-to-implement transport providing authentication and integrity protection because no single such protocol was available on all current ISP router platforms. TCP-AO is identified as the long-term mandatory transport once universally deployed.
The protocol requires the router to make an explicit Reset Query request when it cannot receive incremental updates (rather than having the cache initiate a full transfer), because the cache has no way of knowing whether the router has established sessions with other caches that might provide better service.
The protocol is extensible to support new PDU types and versions should deployment experience indicate a need. New PDU/version registrations require RFC Required action in the rpki-rtr-pdu registry.
A router MUST send either a Serial Query or a Reset Query no less frequently than once an hour, to limit cache storage requirements for incremental updates and to serve as an application-layer keep-alive.
An Error Report PDU MUST NOT be sent in response to another Error Report PDU. If an erroneous Error Report PDU is received, the session SHOULD be dropped.
Cache servers MUST be correct to a tolerance of approximately one hour, as they must evaluate time-dependent certificates and Route Origin Attestations (ROAs).
Caches and routers MUST implement unprotected transport over TCP using port rpki-rtr (323). If unprotected TCP is the transport, the cache and routers MUST be on the same trusted and controlled network.
Client routers using TLS transport MUST present client-side certificates to authenticate themselves to the cache. The cache MUST check the IP address of the TLS connection against iPAddress identities in the client certificate's subjectAltName extension.
If at any time either the router or the cache finds the session identifier value is not the same as the other's, they MUST completely drop the session and the router MUST flush all data learned from that cache.
If data from multiple caches are held, implementations MUST NOT distinguish between data sources when performing validation, per the multi-origin coverage rules of RFC 6811.
rpki-rtr TLS server certificates MUST include a subjectAltName DNS-ID identifier (dNSName). rpki-rtr implementations using TLS MUST NOT use CN-ID identifiers for authentication. DNS names in server certificates SHOULD NOT contain wildcard characters.
TCP-AO implementations MUST support key lengths of at least 80 printable ASCII bytes and hexadecimal sequences of at least 32 characters. MAC lengths of at least 96 bits MUST be supported per RFC 5925 Section 5.1. The cryptographic algorithms described in RFC 5926 MUST be supported.
The cache MUST rate-limit Serial Notifies to no more than one per minute. The cache SHOULD send a Notify PDU when its serial changes, as a hint for the router to poll sooner.
The cache server MUST ensure that it has told the router client to have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, ASN} at any one point in time. Should the router receive a duplicate, it SHOULD raise a Duplicate Announcement Received error.
When a router receives a Cache Reset, it SHOULD attempt to connect to any more preferred caches. If no more preferred caches exist, it MUST issue a Reset Query to get an entire new load from the cache.
When replying to a Reset Query, the withdraw/announce Flags field in all payload PDUs MUST have the value 1 (announce), since the full database contains only currently active records.
Serial Number is a 32-bit strictly increasing unsigned integer that wraps from 2^32-1 to 0, denoting the logical version of a cache. A cache increments it when successfully completing a validated update from a parent cache or the Global RPKI. Serial Number arithmetic follows RFC 1982.
Session ID is generated when a cache server starts, uniquely identifying the cache instance and binding it to the sequence of Serial Numbers that instance will generate. It allows a router to restart a failed session knowing its Serial Numbers remain commensurate with the cache.
IANA created the 'rpki-rtr-error' registry for Error Codes 0-255. Registration policy is Expert Review. Initial entries define codes 0-7 (Corrupt Data, Internal Error, No Data Available, Invalid Request, Unsupported Protocol Version, Unsupported PDU Type, Withdrawal of Unknown Record, Duplicate Announcement Received) and 255 (Reserved).
IANA created the 'rpki-rtr-pdu' registry for Protocol Version/PDU Type tuples (each 0-255). Registration policy is RFC Required (Standards Track or Experimental). Initial entries define Protocol Version 0 with PDU Types 0-10 and 255 (Reserved).
Cache peer identification by IP address or FQDN is vulnerable to DNS or address spoofing attacks that could make the correct cache unreachable; however, no session would be established since authorization keys would not match. Consistent trust anchors must be distributed to all caches out-of-band.
The RPKI relies on object security, not transport security, for inter-cache trust. However, routers cannot perform RPKI cryptographic validation, so the cache-to-router link relies on server authentication and transport-level security — a fundamentally weaker threat model. The cache SHOULD be topologically and administratively close to the router.
Protocol sequences define three flows: (1) Start/Restart: Reset Query → Cache Response → zero or more IPvX Prefix PDUs → End of Data; (2) Typical Exchange: optional Notify → Serial Query → Cache Response → IPvX Prefixes → End of Data; (3) No Incremental Update: Serial Query → Cache Reset → Reset Query → full data sequence.
End of Data PDU (Type 7): 12-byte message containing Protocol Version (8-bit), PDU Type (8-bit), Session ID (16-bit), Length (32-bit, value 12), and Serial Number (32-bit). The Session ID MUST be the same as that of the corresponding Cache Response that began the sequence.
Error Report PDU (Type 10): Variable-length message containing Error Code (16-bit in header), total Length (32-bit), Length of Encapsulated PDU (32-bit), copy of the erroneous PDU (variable), Length of Error Text (32-bit), and optional UTF-8 diagnostic text.
IPv4 Prefix PDU (Type 4): 20-byte fixed-length payload containing Flags (8-bit, low-order bit 1=announce/0=withdraw), Prefix Length (8-bit, 0..32), Max Length (8-bit, 0..32), zero pad (8-bit), IPv4 Prefix (32-bit), and Autonomous System Number (32-bit).
IPv6 Prefix PDU (Type 6): 32-byte fixed-length payload analogous to IPv4 Prefix, with Flags (8-bit), Prefix Length (8-bit, 0..128), Max Length (8-bit, 0..128), zero pad (8-bit), IPv6 Prefix (128-bit), and Autonomous System Number (32-bit).
Serial Notify PDU (Type 0): 12-byte fixed-length message containing Protocol Version (8-bit), PDU Type (8-bit), Session ID (16-bit), Length (32-bit, value 12), and Serial Number (32-bit). The only cache-initiated unsolicited message.
Serial Query PDU (Type 1): 12-byte fixed-length message containing Protocol Version (8-bit), PDU Type (8-bit), Session ID (16-bit), Length (32-bit, value 12), and Serial Number (32-bit). Requests all payload PDUs with Serial Numbers higher than specified.