Selective Synchronization Extension for RPKI-to-Router Protocol

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 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

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.¶

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.¶

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.¶

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    |
|          |          |         |           |
`-------------------------------------------'

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.¶

• 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.¶

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:¶

      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

Authors' Addresses