SIDROPS L. Gong Internet-Draft China Mobile Intended status: Standards Track X. Song Expires: 1 May 2027 ZTE Corp. 28 October 2026 Push Mode Extension for the RPKI to Router Protocol draft-gong-sidrops-rtr-push-00 Abstract 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. Status of This Memo 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 Notice 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. Gong & Song Expires 1 May 2027 [Page 1] Internet-Draft RTR for TOA October 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Motivation of Push Mode . . . . . . . . . . . . . . . . . . . 3 4. Protocol Push Modes . . . . . . . . . . . . . . . . . . . . . 4 5. New PDU Formats . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Subscribe Request . . . . . . . . . . . . . . . . . . . . 4 5.2. Subscribe Response . . . . . . . . . . . . . . . . . . . 6 5.3. Unsubscribe Request . . . . . . . . . . . . . . . . . . . 7 5.4. Unsubscribe Response . . . . . . . . . . . . . . . . . . 7 5.5. Push Notify . . . . . . . . . . . . . . . . . . . . . . . 8 5.6. Periodic Update . . . . . . . . . . . . . . . . . . . . . 9 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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. Gong & Song Expires 1 May 2027 [Page 2] Internet-Draft RTR for TOA October 2026 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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. Gong & Song Expires 1 May 2027 [Page 3] Internet-Draft RTR for TOA October 2026 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. 4. 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. 5. 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 [RFC8210] and [I-D.ietf-sidrops-8210bis]. 5.1. 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. Gong & Song Expires 1 May 2027 [Page 4] Internet-Draft RTR for TOA October 2026 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | | TBD1 | | +-------------------------------------------+ | | | Length=32 | | | +-------------------------------------------+ | | Min | Max | Reserved | | Flags | Interval| Interval| | +-------------------------------------------+ | | | Subscription ID | | | '-------------------------------------------' Figure 1: 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 [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 Gong & Song Expires 1 May 2027 [Page 5] Internet-Draft RTR for TOA October 2026 Subscription ID (32 bits): A unique identifier chosen by the router for this subscription. The RP MUST echo this value in the Subscribe Response 5.2. 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 | | | '-------------------------------------------' Figure 2: 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. Gong & Song Expires 1 May 2027 [Page 6] Internet-Draft RTR for TOA October 2026 Reserved (8 bits): Reserved for future use Subscription ID (32 bits): Echoed from the Subscribe Request. 5.3. 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. 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | | TBD3 | | +-------------------------------------------+ | | | Length=32 | | | +-------------------------------------------+ | | | Subscription ID | | | '-------------------------------------------' Figure 3: Unsubscribe Request PDU Format 5.4. Unsubscribe Response The Unsubscribe Response PDU is sent by the RP to acknowledge the cancellation of a subscription. Gong & Song Expires 1 May 2027 [Page 7] Internet-Draft RTR for TOA October 2026 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | | TBD4 | | +-------------------------------------------+ | | | Length=32 | | | +-------------------------------------------+ | | | Subscription ID | | | '-------------------------------------------' Figure 4: Unsubscribe Response PDU Format 5.5. 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. 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | | TBD5 | | +-------------------------------------------+ | | | Length=32 | | | +-------------------------------------------+ | | | Subscription ID | | | +-------------------------------------------+ | | | | Notify | Serial Number | | Type | | '-------------------------------------------' Gong & Song Expires 1 May 2027 [Page 8] Internet-Draft RTR for TOA October 2026 Figure 5: Push Notify PDU Format 5.6. 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. 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | | TBD6 | | +-------------------------------------------+ | | | Length=32 | | | +-------------------------------------------+ | | | Subscription ID | | | +-------------------------------------------+ | Router Serial | | | '-------------------------------------------' Figure 6: 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. 6. Backward Compatibility The push mode extension is designed for full backward compatibility with existing RTR implementations as defined in [I-D.ietf-sidrops-8210bis]. Gong & Song Expires 1 May 2027 [Page 9] Internet-Draft RTR for TOA October 2026 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. 7. Security Considerations The security considerations of [RFC8210], [I-D.ietf-sidrops-8210bis], and [RFC6810] apply to this document. 8. IANA Considerations This document requests IANA to assign the following PDU types in the "rpki-rtr-pdu" registry: +==========+======================+===============+ | 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 | +----------+----------------------+---------------+ Table 1: PDU Types 9. Acknowledgements The authors would like to express their appreciation to Taoran Zhou for his helpful comments. 10. References 10.1. Normative References Gong & Song Expires 1 May 2027 [Page 10] Internet-Draft RTR for TOA October 2026 [I-D.ietf-sidrops-8210bis] Bush, R., Austein, R., and T. Harrison, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Work in Progress, Internet-Draft, draft-ietf- sidrops-8210bis-27, 13 August 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, . 10.2. Informative References [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, . Authors' Addresses Liyan Gong China Mobile Email: gongliyan@chinamobile.com Xueyan Song ZTE Corp. Email: song.xueyan2@zte.com.cn Gong & Song Expires 1 May 2027 [Page 11]