Selective Synchronization for RPKI to Router Protocol
draft-geng-sidrops-rtr-selective-sync-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Nan Geng , Shunwan Zhuang , Mingqing(Michael) Huang | ||
| Last updated | 2023-03-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-geng-sidrops-rtr-selective-sync-00
sidrops N. Geng
Internet-Draft S. Zhuang
Intended status: Standards Track M. Huang
Expires: 14 September 2023 Huawei
13 March 2023
Selective Synchronization for RPKI to Router Protocol
draft-geng-sidrops-rtr-selective-sync-00
Abstract
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.
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 14 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Geng, et al. Expires 14 September 2023 [Page 1]
Internet-Draft Selective Synchronization for RTR March 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Preliminary Solutions . . . . . . . . . . . . . . . . . . . . 4
3.1. Subcribing Data PDU . . . . . . . . . . . . . . . . . . . 4
3.2. PDUs with Data Type Field . . . . . . . . . . . . . . . . 5
3.3. End of Specific Data PDU . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. 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.
+=============+=============+=============+
| 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
Geng, et al. Expires 14 September 2023 [Page 2]
Internet-Draft Selective Synchronization for RTR March 2023
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.
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.
2. 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 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:
* 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.
Geng, et al. Expires 14 September 2023 [Page 3]
Internet-Draft Selective Synchronization for RTR March 2023
The above negative effects will become worse when there are more
kinds of RPKI data available [I-D.van-beijnum-sidrops-pathrpki][I-D.i
etf-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.
3. Preliminary Solutions
This section preliminarily proposes some independent solutions for
achiving selective synchronization in the RTR protocol, while trying
to keep the protocol's simplicity.
3.1. Subcribing Data PDU
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 |
| | | | |
`-------------------------------------------'
Geng, et al. Expires 14 September 2023 [Page 4]
Internet-Draft Selective Synchronization for RTR March 2023
Figure 1: An example format of Subcribing Data PDU
3.2. 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.
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 2 | 1 | |
+-------------------------------------------+
| |
| Length=16 |
| |
+-------------------------------------------+
| |
| Data Type |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
Figure 2: An example format of extended Serial Query PDU
3.3. 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.
Geng, et al. Expires 14 September 2023 [Page 5]
Internet-Draft Selective Synchronization for RTR March 2023
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| | | |
+-------------------------------------------+
| |
| Length=24 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
+-------------------------------------------+
| |
| Refresh Interval |
| |
+-------------------------------------------+
| |
| Retry Interval |
| |
+-------------------------------------------+
| |
| Expire Interval |
| |
+-------------------------------------------+
| |
| Data Type |
| |
`-------------------------------------------'
Figure 3: An example format of End of Specific Data PDU
4. Security Considerations
TBD
5. IANA Considerations
TBD
6. References
6.1. Normative References
Geng, et al. Expires 14 September 2023 [Page 6]
Internet-Draft Selective Synchronization for RTR March 2023
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/info/rfc6810>.
[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,
<https://www.rfc-editor.org/info/rfc8210>.
[I-D.ietf-sidrops-8210bis]
Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 2", Work
in Progress, Internet-Draft, draft-ietf-sidrops-8210bis-
10, 16 June 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-sidrops-8210bis-10>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[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,
<https://datatracker.ietf.org/doc/html/draft-van-beijnum-
sidrops-pathrpki-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-
rpki-as-cones-02>.
[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-
Geng, et al. Expires 14 September 2023 [Page 7]
Internet-Draft Selective Synchronization for RTR March 2023
asgroup-00, 16 November 2022,
<https://datatracker.ietf.org/doc/html/draft-spaghetti-
sidrops-rpki-asgroup-00>.
Acknowledgements
TBD
Authors' Addresses
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Shunwan Zhuang
Huawei
Beijing
China
Email: zhuangshunwan@huawei.com
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Geng, et al. Expires 14 September 2023 [Page 8]