sidrops N. Geng Internet-Draft S. Zhuang Intended status: Standards Track Huawei Expires: 3 September 2026 Y. Fu China Telecom M. Huang Zhongguancun Laboratory 2 March 2026 Selective Synchronization Extension for RPKI-to-Router Protocol draft-geng-sidrops-rtr-selective-sync-06 Abstract The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to routers. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid unnecessary transmissions. The router can receive only the data that it really needs. 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 3 September 2026. 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 Geng, et al. Expires 3 September 2026 [Page 1] Internet-Draft Selective Synchronization for RTR March 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Subscribing Data PDU . . . . . . . . . . . . . . . . . . . . 4 3. Process of Subscribing Data . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The RPKI-to-Router (RTR) protocol helps synchronize the validated RPKI data from a trusted cache to routers. There are already several versions of the protocol [RFC6810][RFC8210][I-D.ietf-sidrops-8210bis]. The supported types of data that can be transferred increase, which is shown in Table 1. +=============+=============+=============+ | Version 0 | Version 1 | Version 2 | +=============+=============+=============+ | IPv4 Prefix | IPv4 Prefix | IPv4 Prefix | +-------------+-------------+-------------+ | IPv6 Prefix | IPv6 Prefix | IPv6 Prefix | +-------------+-------------+-------------+ | | Router Key | Router Key | +-------------+-------------+-------------+ | | | ASPA | +-------------+-------------+-------------+ Table 1: Supported data types in different versions of the RTR protocol However, in some cases, routers may be interested in a part of RPKI data types, instead of all. In such cases, synchronizing all types of data to routers is unreasonable. Geng, et al. Expires 3 September 2026 [Page 2] Internet-Draft Selective Synchronization for RTR March 2026 Furthermore, there may be more types of RPKI data in the RPKI repositories and RPs in the future. Ignoring the router's requirements and directly synchronizing all types of data to the router may induce unnecessary and non-negligible transmission overheads. The followings are example types, and some of them may be possibly supported in the RPKI system in the future: * Secured Routing Policy Specification Language (RPSL) [RFC7909] * Signed Prefix Lists [I-D.ietf-sidrops-rpki-prefixlist] * Autonomous Systems Cones [I-D.ietf-grow-rpki-as-cones] * Mapping Origin Authorizations (MOAs) [I-D.xie-sidrops-moa-profile] * Signed SAVNET-Peering Information (SiSPI) [I-D.chen-sidrops-sispi] * Path validation with RPKI [I-D.van-beijnum-sidrops-pathrpki] * Signed Groupings of Autonomous System Numbers [I-D.spaghetti-sidrops-rpki-asgroup] * Autonomous System Relationship Authorization (ASRA) [I-D.geng-sidrops-asra-profile] This document extends the RTR protocol to support selective data synchronization. The RTR client can subscribe to specific types of RPKI data from the server via the Subscribe PDU. After a successful subscription, the server will only synchronize the subscribed types of RPKI data to the corresponding client, reducing unnecessary data transmission and improving efficiency. The extension is valuable for scenarios where routers require only specific RPKI data types to meet their operational needs. 1.1. 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. Geng, et al. Expires 3 September 2026 [Page 3] Internet-Draft Selective Synchronization for RTR March 2026 2. Subscribing Data PDU This document defines a new type of PDU for the RTR protocol, specifically named the Subscribing Data PDU. The purpose of this new RTR PDU is to enable a router to explicitly indicate to the RTR server the specific types of RPKI data it is interested in receiving. The format of the Subscribing Data PDU is illustrated in Figure 1, which outlines the structure and arrangement of each field within the PDU. 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Zero | | | | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | Data | | | Data | | Type 1 | ... | ... | Type N | | | | | | `-------------------------------------------' Figure 1: Format of Subscribing Data PDU The Subscribing Data PDU contains the following data elements. Note that all fields within the Subscribing Data PDU, except for the newly introduced PDU Type field and Data Type fields, retain the same meanings as defined in the existing RTR protocol [I-D.ietf-sidrops-8210bis]. * Protocol Version: An 8-bit unsigned integer. To support this new PDU type, a new version of the RTR protocol (e.g., 3) will be required, as the existing protocol version does not include provisions for this subscription mechanism. * PDU Type: An 8-bit unsigned integer. A new PDU Type value (TBD) is required for the Subscribing Data PDU. * Zero: All bits SHOULD be set to 0. The field MUST be ignored when parsing the PDU. * Length: A 32-bit unsigned integer which has as its value the count of the octets in the entire PDU, including the 8 octets of header which includes the length field. The meaning and limitation keep same as the existing RTR protocol. Geng, et al. Expires 3 September 2026 [Page 4] Internet-Draft Selective Synchronization for RTR March 2026 * Data Types: A list of 8-bit unsigned integers, where each integer specifies a Data Type that the router intends to subscribe to. It is explicitly defined that the values assigned to these Data Type fields are consistent with the PDU Type values that have already been allocated to different types of RTR data in the existing RTR protocol, ensuring consistency with the existing RTR protocol specifications and avoiding any ambiguity in data type identification. Currently, the valid values for the Data Type fields (corresponding to the supported RTR data types) are as follows: 4 for IPv4 Prefix data, 6 for IPv6 Prefix data, 9 for Router Key data, and 11 for Autonomous System Provider Authorization (ASPA) data. Additional valid values may be added in future protocol versions as new RTR data types are defined. If the Subscribing Data PDU does not carry any Data Type fields, this indicates that the router subscribes to all data types supported by the current version of the RTR protocol. 3. Process of Subscribing Data A router may send a Subscribing Data PDU to subscribe to specific RTR data at any stage after establishing an RTR session with the RTR server. It is required that a single Subscribing Data PDU carry the complete subscription information. The subscription information MUST NOT be split and carried across multiple Subscribing Data PDUs. If the router intends to update its existing subscription, it can send a new Subscribing Data PDU, which will overwrite the previous subscription entirely. When the router changes its subscription information, it shall determine how to handle the data it has already received and stored locally that is not within the scope of the new subscription (e.g., deleting data that is no longer in the new subscription scope). If a router does not send any Subscribing Data PDU after establishing the RTR session, or if the sent Subscribing Data PDU does not carry any Data Type fields, this indicates that the router subscribes to all data types supported by the current version of the RTR protocol. If the Data Type fields carried in the Subscribing Data PDU contain duplicate values, the RTR server shall simply ignore the duplicate entries and only process each unique Data Type value once, ensuring that the subscription configuration is consistent and free of redundant entries. Geng, et al. Expires 3 September 2026 [Page 5] Internet-Draft Selective Synchronization for RTR March 2026 The RTR server is required to maintain subscription information for each active RTR session individually. When synchronizing data (either full synchronization or incremental synchronization) to the router through a session, the server shall check the subscription information corresponding to that session and only synchronize the data types that the router has subscribed to, thereby avoiding the transmission of unnecessary data. It is important to note that the server's implementation of the Serial Number remains unchanged. The cache still maintains a single Serial Number, regardless of the subscription configurations of different sessions. This design minimizes the need for extensive modifications to existing RTR protocol implementations. There may be scenarios where data on the RTR server is updated, and the server sends a Serial Notify PDU to the router to inform it of the new data availability. However, when the router sends a Serial Query PDU to request the updated data, all requested data may be filtered out by the server. This occurs when the updated data does not match any of the data types the router has subscribed to. 4. IANA Considerations The proposal requires a new version value (e.g., 3) for the RTR protocol. All of the PDU types in the IANA "rpki-rtr-pdu" registry [iana-pdu] in protocol versions 0, 1, and 2 are also allowed in protocol version 3, with the addition of the new Subscribing Data PDU. The type value of the new PDU needs to be allocated. The "rpki-rtr-pdu" registry needs to be updated as follows: Geng, et al. Expires 3 September 2026 [Page 6] Internet-Draft Selective Synchronization for RTR March 2026 Protocol PDU Version Type Description -------- ---- --------------- 0-2 0 Serial Notify 0-2 1 Serial Query 0-2 2 Reset Query 0-2 3 Cache Response 0-2 4 IPv4 Prefix 0-2 6 IPv6 Prefix 0-2 7 End of Data 0-2 8 Cache Reset 0 9 Reserved 1-2 9 Router Key 0-2 10 Error Report 0-1 11 Reserved 2 11 ASPA 3 TBD Subscribing Data 0-3 255 Reserved 5. Security Considerations The security considerations of [I-D.ietf-sidrops-8210bis] also applies to this document. 6. References 6.1. Normative References [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, . [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, . [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-24, 5 February 2026, . [iana-pdu] "rpki-rtr-pdu", n.d., . Geng, et al. Expires 3 September 2026 [Page 7] Internet-Draft Selective Synchronization for RTR March 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, . 6.2. Informative References [RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures", RFC 7909, DOI 10.17487/RFC7909, June 2016, . [I-D.van-beijnum-sidrops-pathrpki] van Beijnum, I., "Path validation with RPKI", Work in Progress, Internet-Draft, draft-van-beijnum-sidrops- pathrpki-00, 20 June 2019, . [I-D.ietf-grow-rpki-as-cones] Snijders, J., stucchi-lists@glevia.com, and M. Aelmans, "RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering", Work in Progress, Internet-Draft, draft-ietf- grow-rpki-as-cones-02, 24 April 2020, . [I-D.spaghetti-sidrops-rpki-asgroup] Snijders, J. and F. Korsbäck, "A profile for RPKI Signed Groupings of Autonomous System Numbers (ASGroup)", Work in Progress, Internet-Draft, draft-spaghetti-sidrops-rpki- asgroup-00, 16 November 2022, . [I-D.ietf-sidrops-rpki-prefixlist] Snijders, J. and G. Huston, "A profile for Signed Prefix Lists for Use in the Resource Public Key Infrastructure (RPKI)", Work in Progress, Internet-Draft, draft-ietf- sidrops-rpki-prefixlist-05, 10 December 2025, . Geng, et al. Expires 3 September 2026 [Page 8] Internet-Draft Selective Synchronization for RTR March 2026 [I-D.xie-sidrops-moa-profile] Xie, C., Dong, G., Li, X., Huston, G., and D. Ma, "A Profile for Mapping Origin Authorizations (MOAs)", Work in Progress, Internet-Draft, draft-xie-sidrops-moa-profile- 06, 26 September 2024, . [I-D.chen-sidrops-sispi] Chen, L., Liu, L., Li, D., and L. Qin, "A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET", Work in Progress, Internet-Draft, draft-chen-sidrops-sispi-04, 14 September 2025, . [I-D.geng-sidrops-asra-profile] Geng, N., Sriram, K., and M. Huang, "A Profile for Autonomous System Relationship Authorization (ASRA)", Work in Progress, Internet-Draft, draft-geng-sidrops-asra- profile-02, 17 October 2025, . Authors' Addresses Nan Geng Huawei Beijing China Email: gengnan@huawei.com Shunwan Zhuang Huawei Beijing China Email: zhuangshunwan@huawei.com Yu Fu China Telecom Beijing China Email: fuy44@chinatelecom.cn Geng, et al. Expires 3 September 2026 [Page 9] Internet-Draft Selective Synchronization for RTR March 2026 Mingqing Huang Zhongguancun Laboratory Beijing China Email: huangmq@mail.zgclab.edu.cn Geng, et al. Expires 3 September 2026 [Page 10]