RPKI-to-Router (RTR) and Route Origin Validation (ROV)
RPKI-to-Router (RTR) and Route Origin Validation (ROV)
Once an RPKI validator has downloaded, cryptographically verified, and extracted the global set of Validated ROA Payloads (VRPs), this data must be delivered into router memory. The protocol that bridges external validators and router control planes is the RPKI-to-Router (RTR) protocol, defined in RFC 6810 (RTRv0) and RFC 8210 (RTRv1).
The RPKI-to-Router Protocol: Messages and Mechanics
RTR is a lightweight, binary client-server protocol running over TCP (default port 323 for plaintext; port 3323 when wrapped in TLS or SSH).
The protocol operates using explicit Protocol Data Units (PDUs):
+-------------------------------------------------------+
| RTR Session Lifecycle |
| |
| Router (Client) Validator (Server)|
| | | |
| | -------- Reset Query (PDU 2) --> | |
| | <------- Cache Response (PDU 3)- | |
| | <------- IPv4/IPv6 Prefix PDUs - | |
| | <------- End of Data (PDU 7) --- | |
| | | |
| | --- [Wait Refresh Timer] ------- | |
| | | |
| | <------- Serial Notify (PDU 0) - | (Changes)|
| | -------- Serial Query (PDU 1) -> | |
| | <------- Incremental Deltas ---- | |
| | <------- End of Data ----------- | |
+-------------------------------------------------------+| PDU Type | Name | Purpose |
|---|---|---|
| 0 | Serial Notify |
Sent asynchronously by the validator to inform routers that the VRP cache has been updated to a new Serial Number. |
| 1 | Serial Query |
Sent by the router requesting incremental changes (adds/deletes) since its last known Serial Number. |
| 2 | Reset Query |
Sent by the router upon initial startup or cache corruption, requesting a complete, full dump of all VRPs. |
| 3 | Cache Response |
Acknowledges a query and precedes payload transmission. |
| 4 | IPv4 Prefix |
Transmits an IPv4 VRP: [Flags (Add/Del), Prefix, Length, MaxLength, OriginASN]. |
| 6 | IPv6 Prefix |
Transmits an IPv6 VRP with identical fields formatted for 128-bit addresses. |
| 7 | End of Data |
Marks the conclusion of a data transfer and specifies refresh, retry, and expire timers. |
| 8 | Cache Reset |
Sent by the validator if the router’s requested serial is too old to compute an incremental delta, forcing a Reset Query. |
| 10 | Error Report |
Signals an encapsulation, syntax, or cryptographic error. |
Session Establishment, Keepalive and Data Transfer
When a router boots: 1. It establishes a TCP session to the configured RTR validator IP on port 323. 2. It sends a Reset Query (PDU 2). 3. The validator responds with Cache Response (PDU 3), followed by a stream of IPv4 Prefix and IPv6 Prefix PDUs (over 500,000 records). 4. The validator terminates the transfer with End of Data (PDU 7), containing: - Refresh Interval: How often the router should query for updates (default: 3600 seconds). - Retry Interval: How long to wait before retrying after a failed query (default: 600 seconds). - Expire Interval: How long the router may continue using its cached VRPs if all RTR sessions fail before purging them (default: 7200 seconds).
How VRPs Become Route Decision Criteria: Route Origin Validation (ROV)
With the VRP table resident in router memory, the router executes Route Origin Validation (ROV) (RFC 6811) on every incoming BGP route received from peers.
For an incoming route advertisement \(R = (\text{Prefix } P, \text{Length } L, \text{Origin AS } O)\): The router queries its local VRP database for any entry \(V = (P_V, L_V, M_V, O_V)\) that covers \(P\) (where \(P\) is a subprefix of or equal to \(P_V\)):
+--------------------------------+
| Incoming Route Update: |
| Prefix P, Length L, Origin O |
+---------------+----------------+
|
v
Does any VRP in memory cover Prefix P?
|
+------------------+------------------+
| No | Yes
v v
+-----------+ Does at least ONE covering VRP match:
| NotFound | - Origin AS == O AND
| (Unknown) | - Length L <= MaxLength?
+-----------+ |
+---------------+---------------+
| Yes | No
v v
+-----------+ +-----------+
| Valid | | Invalid |
+-----------+ +-----------+Valid: At least one covering VRP exists where the VRP ASN matches the origin ASN (\(O_V == O\)) AND the route prefix length is less than or equal to the VRP maximum length (\(L \le M_V\)).Invalid: At least one covering VRP exists, but neither the origin ASN matches nor the prefix length satisfies the maximum length requirement (\(L > M_V\)).NotFound(Unknown): No covering VRP exists in the database for prefix \(P\).
ROV Integration with the BGP Decision Process
ROV states are integrated into the BGP decision engine via router policy (route-maps):
! Standard Production ROV Policy (FRR / Cisco Syntax)
route-map BGP-PEER-IN permit 10
match rpki invalid
set local-preference 10 <-- Or direct drop: drop / reject
!
route-map BGP-PEER-IN permit 20
match rpki valid
set local-preference 200 <-- Prefer cryptographically validated routes
!
route-map BGP-PEER-IN permit 30
match rpki notfound
set local-preference 100 <-- Neutral default preference for unvalidated spaceIn strict production hardening (RFC 7454), all Invalid routes are immediately dropped upon receipt:
route-map BGP-TRANSIT-IN deny 10
match rpki invalid
!
route-map BGP-TRANSIT-IN permit 20Handling State Transitions: Valid, Invalid, NotFound and Pending
When a new ROA is published or revoked: - The validator pushes an update over RTR. - The router dynamically re-evaluates all affected routes in its Adj-RIB-In. - If a currently installed route transitions from NotFound \(\to\) Invalid, the router drops it and re-runs the BGP best-path selection algorithm to pick an alternative path. - During initial session bring-up, routes reside in a temporary Pending state for a few seconds until the initial RTR sync concludes, preventing premature route drops.