Considerations for On-Demand Retrieval of Multiple RPKI Object Types

Introduction As securing the Internet’s routing infrastructure becomes increasingly critical, the Resource Public Key Infrastructure (RPKI) RFC6480 provides a framework for validating the authenticity and integrity of routing information. RPKI relies on cryptographically verifiable objects published at Publication Points (PPs) , which are retrieved and processed by Relying Parties (RPs) to support route validation decisions. While RPKI provides a robust mechanism for publishing and validating routing authorization data, its current data distribution model assumes that RPs retrieve and process the complete repository contents. As the deployment of RPKI-based security mechanisms expands, both the volume and the diversity of data stored at PPs continue to grow. Current RP implementations do not provide sufficient support for selectively retrieving specific types of RPKI objects. Consequently, operators that require only a subset of RPKI functionality must still retrieve and process the complete repository contents, leading to increased bandwidth consumption, longer synchronization latency, and additional computational overhead. For example, an AS that only requires Route Origin Authorization (ROA) for route origin validation will, when using current RPs, also download and process unrelated RPKI objects such as ASPA and MOA. This document analyzes these limitations in the current RPKI data retrieval model 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.

Terminology ROA (Route Origin Authorization) : 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. ASPA (Autonomous System Provider Authorization) : An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other ASes as its upstream providers. MOA (Mapping Origin Authorization) : It provides a means that the address holder can authorize an IPv6 mapping prefix to originate mapping for one or more IPv4 prefixes. RP (Relying Party) : A system that downloads and validates RPKI data from a repository. PP (Publication Point) : The location where RPKI objects are published and stored, accessible via rsync or RRDP. RRDP (RPKI Repository Delta Protocol) : A pull-based protocol used by RPs to synchronize with RPKI repositories.

Scope and Non-Goals This document focuses on identifying limitations in the current RPKI data synchronization model with respect to selective and on-demand retrieval of RPKI objects between Publication Points (PPs) and Relying Parties (RPs). The scope of this document is limited to analyzing the problem space, operational impacts, and high-level directions for improvement. It does not specify new protocols, data formats, or concrete mechanisms. In scope for this document are considerations related to the retrieval of different types of RPKI objects, such as ROAs, ASPA objects, and other signed objects, during RP synchronization. The document examines how existing synchronization mechanisms, including Rsync, RRDP, and Erik, currently assume full repository synchronization and discusses why this model may not scale efficiently as the diversity and volume of RPKI objects increase.

Problem Statement As the diversity and volume of RPKI objects continue to grow, there is an increasing need for Relying Parties (RPs) to retrieve only the objects relevant to their operational requirements. However, the current RPKI data synchronization model assumes that RPs synchronize and process the complete repository contents, without support for selective or on-demand retrieval. As a result, some RPs may retrieve and process unnecessary data, increasing both bandwidth consumption and operational overhead. Based on operational measurements, synchronizing a full repository snapshot currently requires approximately 1.1 GB of bandwidth, while incremental updates require around 10 MB. Assuming that emerging object types such as ASPA and MOA generate data volumes comparable to existing ROA objects, an RP that only requires ROA information would still need to download approximately 3.3 GB for a full synchronization and 30 MB for incremental updates. In addition to bandwidth costs, if RPs process all retrieved data, including signature verification and object parsing, it will further increase computational load. These impacts are particularly pronounced in bandwidth- or resource-constrained environments, such as remote or mobile networks, edge deployments, or smaller Autonomous Systems.

Directions and Design Considerations Type-based on-demand retrieval refers to the ability for Relying Parties (RPs) to selectively retrieve specific categories of RPKI objects, such as ROAs, ASPAs, or other types of signed objects, based on their operational requirements. This section discusses high-level directions and design considerations for enabling such selective retrieval within existing RPKI data synchronization mechanisms. This capability may be particularly beneficial in bandwidth constrained environments, specialized network deployments, or scenarios where rapid enablement of specific validation mechanisms is prioritized over comprehensive RPKI coverage.

Direction for Rsync In Rsync servers , each RPKI object is mapped to a unique URI and can be retrieved individually. This model inherently allows RPs to fetch specific objects without requiring full repository synchronization. However, current RP implementations typically retrieve the complete set of published objects rather than leveraging this capability for selective retrieval. From a design perspective, Rsync-based synchronization could support type-based on-demand retrieval by allowing RPs to identify and retrieve only the object types required for their intended validation functions.

Direction for RRDP In RRDP servers, all RPKI objects are published in aggregated snapshot.xml and delta.xml files, including ROAs, associated certificates, and other signed objects. The current RRDP protocol is designed around full repository synchronization and does not provide mechanisms for selectively retrieving specific object types. As a result, RPs must download and process the complete dataset regardless of their actual requirements. To better accommodate type-based on-demand retrieval, RRDP would need the ability to distinguish between different categories of RPKI objects during both initial synchronization and incremental updates, and to support selective transmission accordingly. This may require reconsideration of how snapshot and delta data are structured or organized, so that object type information can be efficiently exposed and used for selective retrieval.

Direction for Erik The Erik Synchronization Protocol is a proposed mechanism for efficient RPKI data replication. Erik employs Merkle trees to detect differences between local and remote datasets, allowing RPs to efficiently identify and retrieve objects that are missing or out of sync. Similar to Rsync, Erik is primarily designed to support efficient synchronization of complete repository datasets. The current specification does not explicitly consider selective retrieval based on RPKI object types. However, Erik’s use of Merkle tree based difference detection and object-level granularity provides a strong technical foundation for supporting more selective retrieval models. With these considerations, Erik could naturally support type-based on-demand retrieval and offer additional flexibility for deployments where only a subset of RPKI objects is required.

Security Considerations This document is informational in nature and focuses on identifying challenges and discussing potential directions for improving RPKI data retrieval. It 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.

Appendix The data referenced in is based on experiments using Routinator in a production environment, measuring bandwidth consumption during Publication Point (PP) data synchronization. The measurements were conducted in two phases:

Bootstrapping Phase: This phase tests the bandwidth requirements when an RP synchronizes complete PP data without any local cache, measuring the full snapshot download stage.
Update Phase: This phase involves incremental updates performed every 10 minutes to measure the bandwidth consumption when RPs download delta files during routine synchronization operations.