]> Huawei

Beijing China gengnan@huawei.com

Huawei

Beijing China zhuangshunwan@huawei.com

Individual

Beijing China huangmq@vip.sina.com

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 . The supported types of data that can be transferred increase, which is shown in . 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)
• Signed Prefix Lists
• Autonomous Systems Cones
• Mapping Origin Authorizations (MOAs)
• Signed SAVNET-Peering Information (SiSPI)
• Path validation with RPKI
• Signed Groupings of Autonomous System Numbers

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

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 . A router can send the extended Serial Query PDU for requesting a specific type of data.

An example format of extended Serial Query PDU

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

Security Considerations TBD

IANA Considerations TBD

References Normative References In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK] In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810. IIJ Research, Arrcus, & DRL Dragon Research Labs In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document is compatible with both. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on Routing Policy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects. BGPexpert.com This memo adds the capability to validate the full BGP AS path to the RPKI mechanism. NTT Ltd. Independent Juniper Networks This document describes a way to define groups of Autonomous System numbers in RPKI [RFC6480]. We call them AS-Cones. AS-Cones provide a mechanism to be used by operators for filtering BGP-4 [RFC4271] announcements. Fastly Amazon Web Services This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of Autonomous System Numbers (ASNs) and/or pointers to other groupings of ASNs, called an ASGroup. Additionally, the document specifies a mechanism for ASN holders to opt-out of being listed in a given ASGroup. The objective is to offer a RPKI-based successor to plain-text RFC 2622 'as-set' class objects. When validated, an ASGroup confirms that the respective ASN holder produced the ASGroup object. Fastly APNIC This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the listed ASN produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by this AS. China Telecom China Telecom CERNET Center/Tsinghua University For the authenticity of the mapping origin of IPv4 address block in IPv6-only networks, this document defines a standard profile for Mapping Origin Authorizations (MOAs). MOA is a cryptographically signed object that provides a means of verifying that the holder of a set of IPv4 prefixes has authorized an IPv6 mapping prefix to originate mapping for those prefixes. When receiving the MOA objects from the relying parties, PE devices can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. Zhongguancun Laboratory Zhongguancun Laboratory Tsinghua University Tsinghua University This document defines a "Signed SAVNET-Peering Information" (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object which carries the list of Autonomous Systems (ASes) deploying inter-domain SAVNET. When validated, the eContent of a SiSPI object confirms that the holder of the listed ASN produces the object and the AS has deployed inter- domain SAV and is ready to establish neighbor relationship for preventing source address spoofing.

Acknowledgements TBD