| Internet-Draft | RTR for TOA | October 2026 |
| Gong & Song | Expires 1 May 2027 | [Page] |
The Resource Public Key Infrastructure (RPKI) to Router Protocol (RTR) enables routers to receive validated RPKI data from Relying Parties (RPs). This document defines a push mode extension for RTR that allows RPs to proactively push RPKI data updates to routers, either periodically or event-driven.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Resource Public Key Infrastructure (RPKI) to Router Protocol (RTR), defined in [RFC8210], updated by [I-D.ietf-sidrops-8210bis], 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
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.¶
This section defines six new PDU types for the push mode extension. All new PDUs use the standard RTR PDU header format defined in [RFC8210] and [I-D.ietf-sidrops-8210bis].¶
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.¶
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| | TBD1 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| | Min | Max | Reserved |
| Flags | Interval| Interval| |
+-------------------------------------------+
| |
| Subscription ID |
| |
'-------------------------------------------'
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 [RFC8210] and [I-D.ietf-sidrops-8210bis].¶
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¶
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:¶
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| | TBD2 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| Result | Granted | Granted | Reserved |
| | Interval| Mode | |
+-------------------------------------------+
| |
| Subscription ID |
| |
'-------------------------------------------'
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.¶
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.¶
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| | TBD3 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| |
| Subscription ID |
| |
'-------------------------------------------'
The Unsubscribe Response PDU is sent by the RP to acknowledge the cancellation of a subscription.¶
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| | TBD4 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| |
| Subscription ID |
| |
'-------------------------------------------'
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.¶
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| | TBD5 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| |
| Subscription ID |
| |
+-------------------------------------------+
| | |
| Notify | Serial Number |
| Type | |
'-------------------------------------------'
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.¶
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| | TBD6 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| |
| Subscription ID |
| |
+-------------------------------------------+
| Router Serial |
| |
'-------------------------------------------'
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.¶
The push mode extension is designed for full backward compatibility with existing RTR implementations as defined in [I-D.ietf-sidrops-8210bis].¶
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.¶
The security considerations of [RFC8210], [I-D.ietf-sidrops-8210bis], and [RFC6810] apply to this document.¶
This document requests IANA to assign the following PDU types in the "rpki-rtr-pdu" registry:¶
The authors would like to express their appreciation to Taoran Zhou for his helpful comments.¶