



SIDROPS                                                           J. Shi
Internet-Draft                                       Tsinghua University
Intended status: Informational                                    L. Liu
Expires: 3 August 2026                                            L. Qin
                                                 Zhongguancun Laboratory
                                                                   D. Li
                                                     Tsinghua University
                                                         30 January 2026


  Considerations for On-Demand Retrieval of Multiple RPKI Object Types
                  draft-shi-sidrops-rpki-on-demand-00

Abstract

   The Resource Public Key Infrastructure (RPKI) RFC6480 [RFC6481]
   relies on Publication Points (PPs) to distribute cryptographically
   verifiable objects.  Under the current design, Relying Parties (RPs)
   retrieve the complete set of RPKI objects from repositories, even
   when their operational requirements are limited to a specific subset,
   for example, ROAs only.  This all-or-nothing retrieval model may
   result in increased bandwidth consumption, higher synchronization
   latency, and unnecessary computational overhead.  This document
   examines these challenges and discusses directions for enabling more
   selective and efficient access to RPKI data.

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 3 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Shi, et al.               Expires 3 August 2026                 [Page 1]

Internet-Draft          On-Demand RPKI Retrieval            January 2026


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   4
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Directions and Design Considerations  . . . . . . . . . . . .   5
     5.1.  Direction for Rsync . . . . . . . . . . . . . . . . . . .   5
     5.2.  Direction for RRDP  . . . . . . . . . . . . . . . . . . .   5
     5.3.  Direction for Erik  . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   As securing the Internet’s routing infrastructure becomes
   increasingly critical, the Resource Public Key Infrastructure (RPKI)
   RFC6480 [RFC6481] provides a framework for validating the
   authenticity and integrity of routing information.  RPKI relies on
   cryptographically verifiable objects published at Publication Points
   (PPs) [RFC8182], which are retrieved and processed by Relying Parties
   (RPs) [RFC6480] 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



Shi, et al.               Expires 3 August 2026                 [Page 2]

Internet-Draft          On-Demand RPKI Retrieval            January 2026


   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.

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

   ROA (Route Origin Authorization) [RFC6481]: 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)
   [I-D.ietf-sidrops-aspa-verification]: 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) [I-D.ietf-sidrops-moa-profile]: 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) [RFC6480]: A system that downloads and validates
   RPKI data from a repository.

   PP (Publication Point) [RFC8182]: The location where RPKI objects are
   published and stored, accessible via rsync or RRDP.

   RRDP (RPKI Repository Delta Protocol) [RFC8182]: A pull-based
   protocol used by RPs to synchronize with RPKI repositories.








Shi, et al.               Expires 3 August 2026                 [Page 3]

Internet-Draft          On-Demand RPKI Retrieval            January 2026


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

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










Shi, et al.               Expires 3 August 2026                 [Page 4]

Internet-Draft          On-Demand RPKI Retrieval            January 2026


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

5.1.  Direction for Rsync

   In Rsync servers [RSYNC], 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.

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







Shi, et al.               Expires 3 August 2026                 [Page 5]

Internet-Draft          On-Demand RPKI Retrieval            January 2026


5.3.  Direction for Erik

   The Erik Synchronization Protocol
   [I-D.spaghetti-sidrops-rpki-erik-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.

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

7.  IANA Considerations

   This document has no IANA requirements.

8.  Appendix

   The data referenced in Section 4 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.

9.  References



Shi, et al.               Expires 3 August 2026                 [Page 6]

Internet-Draft          On-Demand RPKI Retrieval            January 2026


9.1.  Normative References

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

9.2.  Informative References

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure", RFC 6481,
              DOI 10.17487/RFC6481, February 2012,
              <https://www.rfc-editor.org/info/rfc6481>.

   [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
              "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
              DOI 10.17487/RFC8182, July 2017,
              <https://www.rfc-editor.org/info/rfc8182>.

   [I-D.ietf-sidrops-aspa-verification]
              Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
              J., and K. Sriram, "BGP AS_PATH Verification Based on
              Autonomous System Provider Authorization (ASPA) Objects",
              Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
              verification-24, 19 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-verification-24>.

   [I-D.ietf-sidrops-moa-profile]
              Xie, C., Dong, G., Li, X., Huston, G., and D. Ma, "A
              Profile for Mapping Origin Authorizations (MOAs)", Work in
              Progress, Internet-Draft, draft-ietf-sidrops-moa-profile-
              03, 11 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              moa-profile-03>.

   [I-D.spaghetti-sidrops-rpki-erik-protocol]
              Snijders, J., Bruijnzeels, T., Harrison, T., and W. Ohgai,
              "The Erik Synchronization Protocol for use with the
              Resource Public Key Infrastructure (RPKI)", Work in



Shi, et al.               Expires 3 August 2026                 [Page 7]

Internet-Draft          On-Demand RPKI Retrieval            January 2026


              Progress, Internet-Draft, draft-spaghetti-sidrops-rpki-
              erik-protocol-04, 15 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-spaghetti-
              sidrops-rpki-erik-protocol-04>.

   [RSYNC]    "The rsync web pages", n.d., <https://rsync.samba.org>.

Authors' Addresses

   Jiayi Shi
   Tsinghua University
   Beijing
   China
   Email: sjy23@mails.tsinghua.edu.cn


   Libin Liu
   Zhongguancun Laboratory
   Beijing
   China
   Email: liulb@zgclab.edu.cn


   Lancheng Qin
   Zhongguancun Laboratory
   Beijing
   China
   Email: qinlc@mail.zgclab.edu.cn


   Dan Li
   Tsinghua University
   Beijing
   China
   Email: tolidan@tsinghua.edu.cn
















Shi, et al.               Expires 3 August 2026                 [Page 8]
