]> Huawei

Beijing China gengnan@huawei.com

Huawei

Beijing China zhuangshunwan@huawei.com

China Telecom

Beijing China fuy44@chinatelecom.cn

Zhongguancun Laboratory

Beijing China huangmq@mail.zgclab.edu.cn

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 unnecessary transmissions. The router can receive only the data that it really needs.

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

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)
• 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
• Autonomous System Relationship Authorization (ASRA)

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.

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.

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 , which outlines the structure and arrangement of each field within the PDU.

Format of Subscribing Data PDU

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 .

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

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.

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

Security Considerations The security considerations of also applies to this document.

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. Arrcus, DRL, & IIJ Research Dragon Research Labs Asia Pacific Network Information Centre In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data, Router Keys, and ASPA data from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. n.d. 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. BSD Software Development 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 (the subject AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the subject AS 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 the subject AS. China Telecom China Telecom CERNET Center/Tsinghua University APNIC ZDNS 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 Zhongguancun Laboratory 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. Huawei NIST Zhongguancun Laboratory This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Relationship Authorization (ASRA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASRA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier) can authorize one or more other Autonomous Systems (ASes) as its customers and lateral peers. When validated, an ASRA's eContent can be used for detection and mitigation of BGP AS path manipulation attacks together with Autonomous System Provider Authorization (ASPA). ASRA is complementary to ASPA.