]> Tsinghua University

Beijing China sjy23@mails.tsinghua.edu.cn

Zhongguancun Laboratory

Beijing China liulb@zgclab.edu.cn

Zhongguancun Laboratory

Beijing China qinlc@mail.zgclab.edu.cn

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Operations and Management SIDROPS RPKI Currently, Relying Parties (RPs) retrieve the complete set of RPKI objects from repositories. This all-or-nothing model increases network traffic, synchronization latency, and computational overhead. This document examines these limitations and outlines directions for enabling more selective and efficient RPKI data access.

Introduction The Resource Public Key Infrastructure (RPKI) provides a framework for validating the authenticity and integrity of routing information. It relies on cryptographically verifiable objects published at Publication Points (PPs), which Relying Parties (RPs) retrieve and process to support route validation. Current RPKI data retrieval assumes that RPs synchronize and cache the complete repository contents. The diversity of RPKI signed objects is expected to grow; beyond ROAs , new object types such as ASPAs and MOAs have already been proposed. Existing RP implementations do not support selective retrieval by object type. Consequently, operators that require only a subset of objects must still download and process the entire repository, increasing network traffic, synchronization latency, and computational overhead. For example, an AS that only requires Route Origin Authorizations (ROAs) will also download and process unrelated objects such as ASPAs and MOAs. This document analyzes these limitations and discusses directions for enabling selective, on-demand retrieval of RPKI objects to improve scalability and operational efficiency.

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 As the diversity and volume of RPKI objects grow, there would be an increasing need for RPs to retrieve only the objects of the required type in order to reduce unnecessary overhead. However, current RPKI transport protocols assume full repository synchronization. As a result, networks must download and process signed objects that are not required for their operational needs. Operational measurements indicate that the current RPKI repository contains roughly 340,000 ROA objects, totaling approximately 655 MB. Assuming the deployment of 70,000 ASPA objects of similar size per object, the additional data would amount to roughly 135 MB. For networks that only require ROAs, retrieving unrelated ASPA objects imposes unnecessary network traffic consumption and computational overhead. As new object types such as MOAs are introduced, these inefficiencies will increase further.

Directions and Design Considerations Type-based on-demand retrieval refers to the ability for RPs to selectively retrieve specific categories of RPKI signed objects. This section discusses high-level directions and design considerations for enabling such on-demand retrieval within existing RPKI transport protocols, including Rsync , RRDP , and Eric Synchronization Protocol .

Rsync and RRDP Both Rsync and RRDP currently do not support type-based on-demand retrieval of RPKI signed objects, because neither protocol provides object-level granularity for fetching. An RP must first retrieve all updated objects before it can parse and identify specific object types. As a result, selective on-demand retrieval by object type is not achievable with current designs. To enable type-based on-demand retrieval, changes may be needed on the PP side, such as reorganizing repository files or exposing explicit object type metadata. With such modifications, RPs could fetch objects of a specific type without downloading the entire repository. Care must be taken to ensure that these changes do not introduce significant complexity or additional transport overhead.

Eric Synchronization Protocol The Erik Synchronization Protocol uses Merkle trees to detect differences between local and remote datasets, enabling RPs to efficiently identify and retrieve only objects that are missing or out of sync. Although the current specification does not explicitly address on-demand retrieval by RPKI object type, Erik’s object-level granularity and manifest-driven design naturally support this functionality. By leveraging object file names in manifests, RPs can filter and fetch only the required categories of signed objects.

Security Considerations This document does not define new protocols, protocol extensions, or modifications to existing RPKI validation procedures or security mechanisms. Therefore, this document does not introduce new security considerations.

IANA Considerations This document has no IANA requirements.

References Normative References 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 an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files. Yandex Qrator Labs Internet Initiative Japan & Arrcus, Inc. Arrcus USA National Institute of Standards and Technology This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations. China Telecom China Telecom CERNET Center/Tsinghua University APNIC ZDNS This document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to verify the authenticity of the mapping origin of an IPv4 address block. MOA is a newly defined cryptographically signed object that provides a means for the address holder can authorize an IPv6 mapping prefix to originate mapping for one or more IPv4 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. BSD Software Development RIPE NCC APNIC JPNIC This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, easy to implement, and robust in the face of partitions or faults in the network. n.d.