Selective Synchronization for RPKI to Router Protocol
Internet-Draft draft-geng-sidrops-rtr-selective-sync-04
Nan Geng
Huawei
Beijing
China
gengnan@huawei.com
Shunwan Zhuang
Huawei
Beijing
China
zhuangshunwan@huawei.com
Yu Fu
China Unicom
Beijing
China
fuy186@chinaunicom.cn
Mingqing Huang
Zhongguancun Laboratory
Beijing
China
huangmq@mail.zgclab.edu.cn
11 October 2024
ops
sidrops
Internet-Draft
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 some unnecessary synchronizations. The router can obtain only the data that it really needs, and it does not need to save the data that are not needed.
Introduction
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.
Supported data types in different versions of the RTR protocol
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, which makes the above issue more significant and worse. The followings are example types, and some of them may be possibly supported in the RTR protocol 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.sriram-sidrops-asra-verification]
This document describes the synchronization problem of the RTR protocol and provides some possible solutions.
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.
Problem Statement
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 Relying 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 supports RTR v2 but does not support or enable ASPA, the ASPA PDU messages will still be transmitted. Another example is the router in an IPv6-only network unreasonably has to receive IPv4 RPKI data. Overall, the transimitted Data PDU type cannot be flexibly selected by the router.
The negative effects of the above problem are as follows:
- Storing unused data on the router, which is unreasonable.
- Unnecessary transmission and storage overhead.
- Inefficient end-of-transmission acknowledgment. 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.
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.
How about using different RTR versions for controlling the synchronized data, e.g., using RTR v0 if ASPA data are unwanted? This is not a good solution. First, the data selection is restricted to RTR versions and thus is not flexible either. Second, upgrading the version of RTR for future new RPKI data is not a proper choice, which is also a problem of existing RTR design. Specifically, existing RTR protocol has low extension capability. When there are new PDUs defined for transmission, a new RTR version needs to be issued. The new version protocol is not well compatible with the older ones, which induces some challenges on version negotiation, protocol implementation, and deployment. This document will primarily focus on the solving the inflexible synchronization problem. How to define an extensible protocol needs to be further discussed.
Preliminary Solutions
This section preliminarily proposes some independent solutions for achieving selective synchronization in the RTR protocol, while trying to keep the protocol's simplicity. A new protocol version may not necessarily be required.
Subscribing Data PDU
Define a new type of PDU called Subscribing 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 Subscribing 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 Subscribing Data PDU can be sent for overwriting the previous subscription.
An example format of Subscribing Data PDU

0          8          16         24        31
.-------------------------------------------.
| Protocol |   PDU    |                     |
| Version  |   Type   |         zero        |
|          |          |                     |
+-------------------------------------------+
|                                           |
|                  Length                   |
|                                           |
+-------------------------------------------+
|  Data    |          |         | Data      |
|  Type 1  | ...      | ...     | Type N    |
|          |          |         |           |
`-------------------------------------------'

PDUs with Data Type Field
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.
An example format of extended Serial Query PDU

0          8          16         24        31
.-------------------------------------------.
| Protocol |   PDU    |                     |
| Version  |   Type   |     Session ID      |
|    2     |    1     |                     |
+-------------------------------------------+
|                                           |
|                 Length=16                 |
|                                           |
+-------------------------------------------+
|                                           |
|                  Data Type                |
|                                           |
+-------------------------------------------+
|                                           |
|               Serial Number               |
|                                           |
`-------------------------------------------'

End of Specific Data PDU
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.
An example format of End of Specific Data PDU

0          8          16         24        31
.-------------------------------------------.
| Protocol |   PDU    |                     |
| Version  |   Type   |     Session ID      |
|          |          |                     |
+-------------------------------------------+
|                                           |
|                 Length=24                 |
|                                           |
+-------------------------------------------+
|                                           |
|               Serial Number               |
|                                           |
+-------------------------------------------+
|                                           |
|              Refresh Interval             |
|                                           |
+-------------------------------------------+
|                                           |
|               Retry Interval              |
|                                           |
+-------------------------------------------+
|                                           |
|              Expire Interval              |
|                                           |
+-------------------------------------------+
|                                           |
|                 Data Type                 |
|                                           |
`-------------------------------------------'

Security Considerations
TBD
IANA Considerations
TBD
References
Normative References
[RFC6810]

The Resource Public Key Infrastructure (RPKI) to Router Protocol
R. Bush
R. Austein
January 2013
RFC 6810
DOI 10.17487/RFC6810
[RFC8210]

The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
R. Bush
R. Austein
September 2017
RFC 8210
DOI 10.17487/RFC8210
[I-D.ietf-sidrops-8210bis]

The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2
Randy Bush
IIJ Research, Arrcus, & DRL
Rob Austein
Dragon Research Labs
27 September 2024
Internet-Draft draft-ietf-sidrops-8210bis-16
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC7909]

Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures
R. Kisteleki
B. Haberman
June 2016
RFC 7909
DOI 10.17487/RFC7909
[I-D.van-beijnum-sidrops-pathrpki]

Path validation with RPKI
Iljitsch van Beijnum
BGPexpert.com
20 June 2019
Internet-Draft draft-van-beijnum-sidrops-pathrpki-00
[I-D.ietf-grow-rpki-as-cones]

RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering
Job Snijders
NTT Ltd.
stucchi-lists@glevia.com
Independent
Melchior Aelmans
Juniper Networks
24 April 2020
Internet-Draft draft-ietf-grow-rpki-as-cones-02
[I-D.spaghetti-sidrops-rpki-asgroup]

A profile for RPKI Signed Groupings of Autonomous System Numbers (ASGroup)
Job Snijders
Fastly
Fredrik Korsbäck
Amazon Web Services
16 November 2022
Internet-Draft draft-spaghetti-sidrops-rpki-asgroup-00
[I-D.ietf-sidrops-rpki-prefixlist]

A profile for Signed Prefix Lists for Use in the Resource Public Key Infrastructure (RPKI)
Job Snijders
Fastly
Geoff Huston
APNIC
16 September 2024
Internet-Draft draft-ietf-sidrops-rpki-prefixlist-04
[I-D.xie-sidrops-moa-profile]

A Profile for Mapping Origin Authorizations (MOAs)
Chongfeng Xie
China Telecom
Guozhen Dong
China Telecom
Xing Li
CERNET Center/Tsinghua University
Geoff Huston
APNIC
Di Ma
ZDNS
26 September 2024
Internet-Draft draft-xie-sidrops-moa-profile-06
[I-D.chen-sidrops-sispi]

A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET
Li Chen
Zhongguancun Laboratory
Libin Liu
Zhongguancun Laboratory
Dan Li
Tsinghua University
Lancheng Qin
Zhongguancun Laboratory
25 September 2024
Internet-Draft draft-chen-sidrops-sispi-02