Push Mode Extension for the RPKI to Router Protocol

Introduction The Resource Public Key Infrastructure (RPKI) to Router Protocol (RTR), defined in , updated by , provides a mechanism for routers to receive validated RPKI data from Relying Parties (RPs). The current RTR protocol operates in a pull-based model: routers (acting as RTR clients) periodically send Serial Query or Reset Query PDUs to the RP (acting as RTR server) to retrieve updates. In most scenarios, this pull-based design offers clear benefits-it is simple and robust, gives clients control over update timing, avoids maintaining persistent per-client push state on the server, and is well suited to environments where updates are relatively infrequent or where eventual consistency is acceptable. However, in scenarios that require fast propagation of routing-origin changes, or that involve many clients and high update rates, the same pull-based model can introduce significant update-propagation latency and impose continuous polling overhead on both routers and RPs. This document defines a push mode extension for RTR that allows RPs to proactively push RPKI data updates to routers. The extension introduces two complementary push mechanisms: event-driven push, and periodic push.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Motivation of Push Mode As RTR deployments scale and network operations become more dynamic, certain critical scenarios demand a more immediate and efficient synchronization mechanism between routers and RPs. The introduction of Push Mode is specifically motivated by the requirements of these operational scenarios.

Rapid Response to Critical Security Incidents: In scenarios involving critical security events-such as the urgent revocation of a compromised CA certificate or the rapid deployment of emergency ROAs-routing updates must propagate across the network within seconds. To address this, Push Mode introduces an event-driven mechanism. It enables the RP to proactively notify routers of critical updates the moment the data changes, dramatically reducing the window of vulnerability to routing security incidents. This ensures that consistent routing security policies are enforced across the network without delay.
Scalability in Large-Scale Deployments: In environments where RP servers must serve a large number of RTR clients, managing control-plane resources efficiently is paramount. Push Mode eliminates the periodic serial number negotiations (e.g., Serial Query and Reset Query) between routers and the RP. Instead of continuously polling, routers receive updates as they become available. This reduces control-plane message volume, lowers processing overhead on both routers and RPs, and improves overall protocol efficiency, allowing the RP to scale gracefully to serve massive numbers of clients.
Immediate Synchronization during State Changes: During dynamic network events-such as session resets or cache rebuilds-routers must immediately reflect the latest state to maintain routing integrity. Push Mode allows the RP to proactively inform routers of such state changes. Rather than waiting for the next scheduled polling cycle, routers can react immediately to these notifications. This ensures deterministic and timely synchronization, eliminating transient exposure to stale or invalid routing data.

To meet these varied scenario requirements, this document introduces two push modes: event-driven and periodic push. Together, they provide a robust extension that ensures rapid propagation for urgent updates, efficient resource utilization for large-scale networks, and immediate awareness of dynamic state changes.

Protocol Push Modes The push mode extension introduces a subscription model layered on top of the existing RTR session. After standard session establishment and initial cache synchronization, the router may request a subscription to receive pushed updates. Once subscribed, the RP delivers updates via either event-driven or periodic push mechanisms. The router may cancel its subscription at any time, reverting to standard pull mode. The push mode extension defines two complementary push mechanisms that may be used individually or in combination: Event-Driven Push: the RP sends a Push Notify PDU to the router immediately upon detecting a significant change in the validated RPKI data. Periodic Push: the RP sends updates at regular, negotiated intervals.

New PDU Formats This section defines six new PDU types for the push mode extension. All new PDUs use the standard RTR PDU header format defined in and .

Subscribe Request The Subscription ID identifies the push subscription contract. It is chosen by the router, and is distinct from the Session ID, which is allocated by the RP and used to identify the RTR session.

Subscribe Request PDU Format Protocol Version (8bits): MUST be 2 (or higher) for push mode sessions. PDU Type (16bits): TBD1 Session ID (16bits): The session ID as defined in and . Length (32btis): The length of this PDU. Flags (8bits): Bit flags specifying requested push modes: Bit 0 (0x01) used for event-driven push mode; Bit 1 (0x02) used for periodic push mode; Bit 2-7 are reserved, MUST be set to zero and ignored on receipt. A router MAY set both bits to request both push modes simultaneously. Min Interval (8bits): The minimum acceptable periodic update interval, in seconds. A value of 0 indicates no minimum preference. Ignored if periodic push is not requested. Max Interval (8 bits): The maximum acceptable periodic update interval, in seconds. A value of 0 indicates no maximum preference. The RP MUST NOT exceed this interval if it grants periodic push mode. Reserved (8 bits): Reserved for future use Subscription ID (32 bits): A unique identifier chosen by the router for this subscription. The RP MUST echo this value in the Subscribe Response

Subscribe Response The Subscribe Response PDU is sent by the RP in response to a Subscribe Request. It indicates whether the subscription was granted and, if so, the parameters under which push mode will operate:

Subscribe Response PDU Format Protocol Version: 2 (or higher) PDU Type: TBD2 Result (8bits): The result of the subscription request. Granted Interval (8 bits): The periodic update interval, in seconds, that the RP will use. Meaningful only if Result is Success and periodic push was requested. Granted Mode (8 bits): The push mode(s) granted by the RP. Bit 0 (0x01) used for Event-driven mode granted. Bit 1 (0x02) used for periodic push mode granted; Bit 2-7 are reserved, MUST be set to zero and ignored on receipt. Reserved (8 bits): Reserved for future use Subscription ID (32 bits): Echoed from the Subscribe Request.

Unsubscribe Request The Unsubscribe Request PDU is sent by the router to cancel an active subscription. Upon receipt, the RP MUST cease sending push updates for this session.

Unsubscribe Request PDU Format

Unsubscribe Response The Unsubscribe Response PDU is sent by the RP to acknowledge the cancellation of a subscription.

Unsubscribe Response PDU Format

Push Notify The Push Notify PDU is sent by the RP to the router to indicate that significant RPKI data changes have occurred. This PDU is used in event-driven push mode. The notify type of change that triggered this notification. It may involve ROA, ASPA, router Key change, etc.

Push Notify PDU Format

Periodic Update The Periodic Update PDU is sent by the RP to the router at negotiated intervals in periodic push mode. This PDU carries the actual RPKI data updates, eliminating the need for the router to send a Serial Query. The PDU format is showed as follows. Following the Periodic Update header, the RP sends a Cache Response PDU, zero or more data PDUs containing the incremental changes, and an End of Data PDU. If there are no changes, the RP MAY send the header followed immediately by an End of Data PDU as a keepalive.

Periodic Update PDU Format The serial number that the RP believes the router currently holds. The router MUST compare this value against its actual current serial number. If they do not match, the router MUST NOT process the data PDUs.

Backward Compatibility The push mode extension is designed for full backward compatibility with existing RTR implementations as defined in . Push mode is only activated if both parties explicitly advertise support for it during the version negotiation at the beginning of an RTR session. The router indicates its push-mode capability in the initial Serial Query, and the RP confirms support in its Serial Notify; if either party does not advertise support, the session operates in standard pull mode without any protocol changes. If the negotiation is unsuccessful (e.g., one party does not support push mode), an error notification MAY be sent to inform the peer. The error Report PDU format refers to RFC8210bis, a new error code allocated by IANA is required.

Security Considerations The security considerations of , , and apply to this document.

IANA Considerations This document requests IANA to assign the following PDU types in the "rpki-rtr-pdu" registry: PDU Types

PDU Type	Name	Reference
TBD1	Subscribe Request	This document
TBD2	Subscribe Response	This document
TBD3	Unsubscribe Request	This document
TBD4	Unsubscribe Response	This document
TBD5	Push Notify	This document
TBD6	Periodic Update	This document

Acknowledgements The authors would like to express their appreciation to Taoran Zhou for his helpful comments.