| Internet-Draft | Selective Synchronization for RTR | March 2023 |
| Geng, et al. | Expires 14 September 2023 | [Page] |
The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to the router. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid some unnecessary synchronization overhead. The router can obtain only the data that it needs, and does not need to save the data that it does not need.¶
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 14 September 2023.¶
Copyright (c) 2023 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 RPKI-to-Router (RTR) protocol is a simple but reliable approach, which help 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 |
The RTR protocol keeps the synchronization of all types of data, and selective synchronization is not supported. However, routers may be interested in a part of data types, instead of all. In such cases, storing unused data on the router is unreasonable, and synchronizing all types of data will induce some unnecessary transmission and storage overhead. Since multiple types of data are transmitted together, the router cannot use any type of these data unless it waits for all data to complete transmission. Furthermore, there may be more types of data in the cache [I-D.van-beijnum-sidrops-pathrpki][I-D.ietf-grow-rpki-as-cones][I-D.spaghetti-sidrops-rpki-asgroup], which makes the above issue worse.¶
This document describes the synchronization problem of the RTR protocol and provides some possible solutions.¶
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.¶
The RTR protocol does not distinguish data types in the cache. Different types of data share one serial number and one End of Data PDU. When the Relay Party (RP) synchronizes the cache to the router, various PDUs, such as IPv4 Prefix, IPv6 Prefix, Router Key, and ASPA, are mixed. The router cannot select one or more really required PDUs or deny receiving a certain kind of PDU. For example, if the router does not support or enable ASPA. The ASPA PDU messages will still be transmitted. The required Data PDU type cannot be flexibly selected by the router.¶
The negative effects of the above problem are as follows:¶
The above negative effects will become worse when there are more kinds of RPKI data available [I-D.van-beijnum-sidrops-pathrpki][I-D.ietf-grow-rpki-as-cones][I-D.spaghetti-sidrops-rpki-asgroup]. The main problem of the RTR protocol is the lack of selective synchronization capability.¶
Another problem of the protocol is the low extension capability. When there are new PDUs defined for transmission, a new RTR version need to be issued. The new version protocol is not well compatible with the older ones, which induces some challenges on implementation and deployment. This document will define some new PDUs that may not necessarily require a new protocol version.¶
This section preliminarily proposes some independent solutions for achiving selective synchronization in the RTR protocol, while trying to keep the protocol's simplicity.¶
Define a new type of PDU called Subcribing Data PDU. The new PDU will indicate the data types that the router is interested in. An example format of the PDU is shown in Figure 1. The field of PDU type is TBD. The Data Type fields indicate the interested data types (i.e., 4: IPv4 Prefix, 6: IPv6 Prefix, 9: Router Key, 11: ASPA).¶
The router can send the Subcribing Data PDU to the cache. After finishing the subscribing, the following PDUs, including Serial Notify, Serial Query, Reset Query, Cache Response, and Cache Reset, are only for the subscribed data. If the router wants to modify the subscription, a new Subcribing Data PDU can be sent for overwriting the previous subscription.¶
0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | | | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | Data | | | Data | | Type 1 | ... | ... | Type N | | | | | | `-------------------------------------------'
The existing PDUs, including Serial Notify, Serial Query, Reset Query, Cache Response, and Cache Reset, can be extended to carry the Data Type field. The values of the Data Type field can be 4 for IPv4 Prefix, for IPv6 Prefix, 9 for Router Key, and 11 for ASPA. An example format of the extended Serial Query PDU is shown in Figure 2. A router can send the extended Serial Query PDU for requesting a specific type of data.¶
0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | 2 | 1 | | +-------------------------------------------+ | | | Length=16 | | | +-------------------------------------------+ | | | Data Type | | | +-------------------------------------------+ | | | Serial Number | | | `-------------------------------------------'
End of Data PDU tells the router that all the requested data are synchronized. The End of Specific Data PDU can be defined for indicating a specific type of data has been synchronized. An example format of End of Specific Data PDU is shown in Figure 3. The field of PDU type is TBD. The Data Type field indicate the interested data types (i.e., 4: IPv4 Prefix, 6: IPv6 Prefix, 9: Router Key, 11: ASPA).¶
The type of data specified in End of Specific Data PDU will become ready for use. The router does not need to wait for all the data to complete transmission before it can use the specified data.¶
0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | | | | +-------------------------------------------+ | | | Length=24 | | | +-------------------------------------------+ | | | Serial Number | | | +-------------------------------------------+ | | | Refresh Interval | | | +-------------------------------------------+ | | | Retry Interval | | | +-------------------------------------------+ | | | Expire Interval | | | +-------------------------------------------+ | | | Data Type | | | `-------------------------------------------'