SIDROPS Y. Su Internet-Draft L. Qin Updates: RFC8897 (if approved) Zhongguancun Laboratory Intended status: Informational D. Ma Expires: 14 December 2026 ZDNS D. Li Tsinghua University 12 June 2026 Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties draft-su-sidrops-rpki-rp-requirements-00 Abstract This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs and related specifications, making it easier for implementers to become aware of these requirements. This document updates [RFC8897] to reflect changes to the requirements and guidance specified in the relevant RPKI standards, including updates to repository synchronization, certificate and CRL processing, signed object validation, validated cache distribution, local control, and operational and manageability support for RP software. This document is expected to be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein. 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 14 December 2026. Su, et al. Expires 14 December 2026 [Page 1] Internet-Draft Requirements for RPKI RP June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Changes from RFC8897 . . . . . . . . . . . . . . . . . . 5 1.3. Note on Referenced SIDROPS Work . . . . . . . . . . . . . 6 2. Fetching and Caching RPKI Repository Objects . . . . . . . . 7 2.1. Trust Anchor Configuration and Processing . . . . . . . . 7 2.2. Locating and Fetching RPKI Repository Objects . . . . . . 7 2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 8 2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 8 2.5. Strategies for Efficient Cache Maintenance . . . . . . . 8 2.6. Repository Synchronization Protocols . . . . . . . . . . 8 3. Certificate and CRL Processing . . . . . . . . . . . . . . . 9 3.1. Verifying Resource Certificate and Syntax . . . . . . . . 9 3.2. Certificate Path Validation . . . . . . . . . . . . . . . 9 3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 9 4. Processing RPKI Repository Signed Objects . . . . . . . . . . 10 4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 10 4.2. Syntax and Validation for Each Type of Signed Object . . 10 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.3. ASPA . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.4. RSC . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.5. TAK . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.6. Verifying BGPsec Router Certificate . . . . . . . . . 12 4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 12 5. Distributing Validated Cache . . . . . . . . . . . . . . . . 13 6. Local Control . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Operational and Manageability Requirements for RPs . . . . . 14 7.1. Export of Validated Cache State . . . . . . . . . . . . . 14 7.2. Operational Observability and Diagnostics . . . . . . . . 14 7.3. Audit Trail and Historical State Retention . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 Su, et al. Expires 14 December 2026 [Page 2] Internet-Draft Requirements for RPKI RP June 2026 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction RPKI Relying Party (RP) software is used by network operators and others to acquire and verify Internet Number Resource (INR) data stored in the RPKI repository system. RPKI data, when verified, allows an RP to verify assertions about which Autonomous Systems (ASes) are authorized to originate routes for IP address prefixes. RPKI data also establishes a binding between public keys and BGP routers and indicates the AS numbers that each router is authorized to represent, supports validation of Autonomous System Provider Authorizations (ASPAs), and enables validation of other RPKI signed objects such as RPKI Signed Checklists (RSCs) and Trust Anchor Keys (TAKs). The essential requirements imposed on RP software to support secure Internet routing [RFC6480] are scattered throughout numerous protocol-specific RFCs and Best Current Practice RFCs. The following RFCs and related specifications define these requirements: * [RFC6481] (Repository Structure) * [RFC6489] (Key Rollover) * [RFC6916] (Algorithm Agility) * [RFC7935] (Algorithms and Key Sizes for Use in RPKI), as updated by [RFC8608] * [RFC8630] (RPKI Trust Anchor Locators), as updated by [I-D.ietf-sidrops-rpki-ta-tiebreaker] * [RFC9691] (RPKI Trust Anchor Keys (TAKs)) * [RFC6487] (Certificate and CRL profile), as updated by [RFC9829] and [I-D.ietf-sidrops-rpki-validation-update] * [RFC8209] (BGPsec Router Certificates Profile) * [RFC6810] (RPKI to Router Protocol, Version 0) Su, et al. Expires 14 December 2026 [Page 3] Internet-Draft Requirements for RPKI RP June 2026 * [RFC8210] (RPKI to Router Protocol, Version 1), as updated by [I-D.ietf-sidrops-8210bis] (Version 2) * [RFC8416] (RPKI SLURM), as updated by [I-D.ietf-sidrops-aspa-slurm] * [RFC6488] (RPKI Signed Object Template), as updated by [RFC9589] * [RFC9286] (Manifests), as updated by [I-D.ietf-sidrops-manifest-numbers] * [RFC9582] (Route Origin Authorizations (ROAs)), as updated by [I-D.ietf-sidrops-rpki-validation-update] * [RFC9323] (RPKI Signed Checklists (RSCs)) * [I-D.ietf-sidrops-aspa-profile] (ASPA object profile) * [RFC8182] (The RPKI Repository Delta Protocol (RRDP)), as updated by [RFC9674] and [RFC9697] * [I-D.ietf-sidrops-rpki-erik-protocol] (Erik Synchronization Protocol) * [RSYNC] (rsync repository synchronization) * [I-D.ietf-sidrops-rpki-ccr] (RPKI Canonical Cache Representation (CCR)) The distribution of RPKI RP requirements across these documents makes it hard for an implementer to be confident that he/she has addressed all of these requirements. Additionally, good software engineering practice may call for segmenting the RP system into components with orthogonal functionalities so that those components may be distributed. A taxonomy of the collected RP software requirements can help clarify the role of the RP. To consolidate RP software requirements in one document, with pointers to all the relevant RFCs and related specifications, this document outlines a set of baseline requirements imposed on RPs and provides a single reference point for requirements for RP software for use in the RPKI. The requirements are organized into the following groups: * Fetching and Caching RPKI Repository Objects * Processing Certificates and Certificate Revocation Lists (CRLs) Su, et al. Expires 14 December 2026 [Page 4] Internet-Draft Requirements for RPKI RP June 2026 * Processing RPKI Repository Signed Objects * Distributing Validated Cache of the RPKI Data * Local Control * Operational and Manageability Requirements for RPs This document will be updated to reflect new or changed requirements as these RFCs and related specifications are updated or additional RFCs are written. 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. 1.2. Changes from [RFC8897] This document updates [RFC8897] to reflect changes in the RPKI standards that affect RP software. The most significant changes are: * References to obsolete or updated specifications have been revised, including replacement of [RFC6482] by [RFC9582], replacement of [RFC6486] by [RFC9286], update of [RFC6488] by [RFC9589], update of [RFC6487] by [RFC9829], and update of [RFC8182] by [RFC9674] and [RFC9697]. * Requirements related to trust anchor processing have been updated to include [RFC9691] and [I-D.ietf-sidrops-rpki-ta-tiebreaker]. * Requirements related to repository synchronization have been updated to include [RFC8182], [RFC9674], [RFC9697], [I-D.ietf-sidrops-rpki-erik-protocol], and [RSYNC]. * Requirements related to ROA have been updated to reference [RFC9582] and [I-D.ietf-sidrops-rpki-validation-update]. * Requirements related to manifests have been updated to reference [RFC9286] and [I-D.ietf-sidrops-manifest-numbers]. * Requirements related to basic signed object syntax checks have been updated to reflect the changes in [RFC9589]. Su, et al. Expires 14 December 2026 [Page 5] Internet-Draft Requirements for RPKI RP June 2026 * New signed-object requirements have been added for Trust Anchor Keys (TAKs) [RFC9691], RPKI Signed Checklists (RSCs) [RFC9323] and Autonomous System Provider Authorizations (ASPAs) [I-D.ietf-sidrops-aspa-profile]. * Requirements related to Ghostbusters Records have been removed, since [RFC6493] is now Historic. * Requirements related to certificate path validation have been updated to reflect [RFC9829] and [I-D.ietf-sidrops-rpki-validation-update]. * Requirements related to validated cache distribution have been updated to include [I-D.ietf-sidrops-8210bis]. * Requirements related to local control have been updated to include [I-D.ietf-sidrops-aspa-slurm]. * A new set of operational and manageability requirements has been added, including support for validated cache export, operational observability and diagnostics, and audit trail and historical state retention. 1.3. Note on Referenced SIDROPS Work This document references a number of active SIDROPS Working Group Internet-Drafts in addition to published RFCs. These references are included because the referenced work is directly relevant to current RP software requirements and, in several cases, has reached a level of Working Group maturity that is likely to affect the baseline requirements for RP implementations. Accordingly, references to active SIDROPS Working Group Internet- Drafts in this document are provisional. If the status, scope, or content of these drafts changes, the corresponding references and requirements in this document are expected to be updated accordingly. Prior to publication of this document as an RFC, references to Internet-Drafts that do not advance to RFC status are expected to be updated, replaced, or removed as appropriate. This section is editorial in nature and may be removed prior to publication as an RFC. Su, et al. Expires 14 December 2026 [Page 6] Internet-Draft Requirements for RPKI RP June 2026 2. Fetching and Caching RPKI Repository Objects RP software uses one or more repository synchronization protocols supported by targeted repositories, such as rsync [RSYNC], RRDP [RFC8182] as updated by [RFC9674] and [RFC9697], or Erik [I-D.ietf-sidrops-rpki-erik-protocol], to download RPKI objects from the repository system in order to update a local cache. These mechanisms download only those objects that have been added or replaced with new versions since the time when the RP most recently checked the repository. RP software validates the RPKI data and uses it to generate authenticated outputs based on the validated repository contents for use by systems that consume validated RPKI information. 2.1. Trust Anchor Configuration and Processing The requirements of Section 2.1 of [RFC8897] continue to apply, with the following updates: * If multiple valid TA certificates are available for a configured TA, RP software SHOULD apply a deterministic TA certificate selection procedure. Such a procedure is specified in Section 2 of [I-D.ietf-sidrops-rpki-ta-tiebreaker], which updates Section 3 of [RFC8630]. * RP software MUST keep a record of the current public key for each configured TA, as well as the URI(s) where the CA certificate for this public key may be retrieved, as specified in Section 4 of [RFC9691]. * When performing top-down validation, if a TAK object is present, RP software MUST validate and process it before processing other objects issued under the TA, as specified in Sections 2.3 and 4 of [RFC9691]. RP software that supports TAK processing MUST apply the successor-key verification and acceptance-timer procedure specified in Section 4 of [RFC9691]. 2.2. Locating and Fetching RPKI Repository Objects The RPKI repository system is a distributed one, consisting of multiple repository instances. Each repository instance contains one or more repository publication points. RP software locates and fetches RPKI repository objects using the mechanisms defined by the applicable repository synchronization and object-location specifications. Su, et al. Expires 14 December 2026 [Page 7] Internet-Draft Requirements for RPKI RP June 2026 Section 5 of [RFC6481] specifies how RP software locates RPKI repository objects using the Subject Information Access (SIA) and the Authority Information Access (AIA) extensions. For repository synchronization mechanisms such as rsync [RSYNC], RP software uses these extensions to discover the relevant repository publication points and related RPKI objects. Detailed specifications of the SIA and AIA extensions in a resource certificate are described in Sections 4.8.8 and 4.8.7 of [RFC6487], respectively. If RP software supports RRDP, repository object discovery and retrieval are additionally specified in [RFC8182]. If RP software supports Erik Synchronization, repository object discovery and retrieval are additionally specified in Section 4 of [I-D.ietf-sidrops-rpki-erik-protocol]. In Erik Synchronization, RP software acquires an ErikIndex for a given FQDN and then uses the referenced ErikPartition and manifest information to determine which repository objects need to be fetched. 2.3. Dealing with Key Rollover The requirements of Section 2.3 of [RFC8897] continue to apply. In addition, RP software requirements for dealing with TA key rollover and successor key processing are described in Section 4 of [RFC9691]. 2.4. Dealing with Algorithm Transition The requirements of Section 2.4 of [RFC8897] continue to apply. 2.5. Strategies for Efficient Cache Maintenance The requirements of Section 2.5 of [RFC8897] continue to apply. 2.6. Repository Synchronization Protocols RP software uses one or more repository synchronization protocols, such as rsync [RSYNC], RRDP [RFC8182], and Erik [I-D.ietf-sidrops-rpki-erik-protocol], to update its local cache of RPKI repository objects. Requirements for RRDP are specified in [RFC8182]. Additional RRDP requirements for RPs are specified in [RFC9674] and [RFC9697]. In particular, RP software that supports RRDP MUST apply the Same-Origin Policy checks specified in [RFC9674]. RP software that supports RRDP SHOULD also perform the desynchronization detection and recovery procedures specified in [RFC9697]. Su, et al. Expires 14 December 2026 [Page 8] Internet-Draft Requirements for RPKI RP June 2026 If RP software switches from RRDP to rsync, it SHOULD follow the guidance in Section 2.2 of [RFC9589]. If RP software supports Erik Synchronization, repository synchronization procedures are additionally specified in Section 4 of [I-D.ietf-sidrops-rpki-erik-protocol]. 3. Certificate and CRL Processing The requirements of the introductory text of Section 3 of [RFC8897] continue to apply. 3.1. Verifying Resource Certificate and Syntax The requirements of Section 3.1 of [RFC8897] continue to apply. 3.2. Certificate Path Validation Initially, the INRs in the issuer's certificate are required to encompass the INRs in the subject's certificate. This is one of the necessary principles of certificate path validation in addition to cryptographic verification (i.e., verification of the signature on each certificate using the public key of the parent certificate). Section 7.2 of [RFC6487] specifies the procedure that RP software should follow to perform certificate path validation. [RFC9829] updates this procedure. In particular, when determining the revocation status of a resource certificate, RP software MUST use the unique current CRL that is both identified by the certificate's CRL Distribution Points extension and listed on the issuing CA's current manifest with a matching hash, as specified in Section 3.2 of [RFC9829]. Ongoing work to revise the RPKI validation algorithm is described in [I-D.ietf-sidrops-rpki-validation-update], which updates Section 5 of [RFC9582] to reference the validated VRS-IP outcome of EE certificate validation, replaces Section 7.2 of [RFC6487] in its entirety with a revised resource certification path validation procedure, updates Section 9 of [RFC6487], and obsoletes [RFC8360]. 3.3. CRL Processing The CRL processing requirements imposed on CAs and RPs are described in Section 5 of [RFC6487], as updated by Sections 2 and 3.1 of [RFC9829]. CRLs in the RPKI are tightly constrained; only the AuthorityKeyIdentifier (section 4.8.3 of [RFC6487]) and CRLNumber (section 5.2.3 of [RFC5280]) extensions are allowed, and they are required to be present. No other CRL extensions are allowed, and no Su, et al. Expires 14 December 2026 [Page 9] Internet-Draft Requirements for RPKI RP June 2026 CRLEntry extensions are permitted. RP software is required to verify that these constraints have been met. Each CRL in the RPKI must be verified using the public key from the certificate of the CA that issued the CRL. RP software MUST process the AKI extension and MUST ignore the CRL Number extension except for checking that it is marked non-critical and contains a non-negative integer not greater than 2^159-1. In the RPKI, the current CRL relevant to determining the revocation status of a resource certificate is the unique CRL that is both identified by the certificate's CRL Distribution Points extension and listed on the issuing CA's current manifest with a matching hash, as specified in Sections 2 and 3.2 of [RFC9829]. If the CRL is not listed on a valid, current manifest acquired during a fetch, the CRL is considered missing and the fetch has failed. In that case, the RP MUST issue a warning and SHOULD continue to use cached versions of the objects associated with that CA instance, if available, until such time as they become stale or can be replaced by objects from a successful fetch. Until then, the RP MUST NOT attempt to acquire and validate subordinate signed objects for that CA instance, as specified in Section 6.6 of [RFC9286]. 4. Processing RPKI Repository Signed Objects 4.1. Basic Signed Object Syntax Checks The requirements of Section 4.1 of [RFC8897] continue to apply, with the following update: * [RFC9589] updates the checks in Section 3 of [RFC6488]. In particular, Section 4 of [RFC9589] updates Section 3, item 1.f and item 1.g of [RFC6488] by requiring the signedAttrs field to contain the content-type, message-digest, and signing-time attributes, and by disallowing the CMS binary-signing-time attribute. 4.2. Syntax and Validation for Each Type of Signed Object 4.2.1. Manifest To determine whether a manifest is valid, RP software is required to perform manifest-specific checks in addition to the generic signed- object checks specified in [RFC6488], as updated by [RFC9589]. Specific checks for a manifest are described in Sections 4.2.1 and 4.4 of [RFC9286]. If these checks fail, or if manifest acquisition or processing otherwise fails, RP software is required to proceed as specified in Section 6.6 of [RFC9286]. Su, et al. Expires 14 December 2026 [Page 10] Internet-Draft Requirements for RPKI RP June 2026 Additional manifest-number handling requirements are described in [I-D.ietf-sidrops-manifest-numbers], which updates Section 4.2.1 of [RFC9286]. 4.2.2. ROA To validate a Route Origin Authorization (ROA), RP software is required to perform all the checks specified in [RFC6488], as updated by [RFC9589], as well as additional, ROA-specific validation steps. The ROA content type and ROA eContent are specified in Sections 3 and 4 of [RFC9582]. Specific checks for a ROA are described in Section 5 of [RFC9582]. Additional ROA validation requirements are described in Section 3 of [I-D.ietf-sidrops-rpki-validation-update], which updates the ROA validation procedure in Section 5 of [RFC9582]. In particular, it replaces the requirement that each IP address prefix in the ROA be contained within the EE certificate's IP address delegation extension with a requirement that each IP address prefix in the ROA be contained within the VRS-IP set resulting from EE certificate validation. 4.2.3. ASPA To validate an Autonomous System Provider Authorization (ASPA), RP software is required to perform all the checks specified in [RFC6488], as updated by [RFC9589], as well as additional, ASPA- specific validation steps. The ASPA content type and ASPA eContent are specified in Sections 2 and 3 of [I-D.ietf-sidrops-aspa-profile]. Specific checks for an ASPA are described in Section 4 of [I-D.ietf-sidrops-aspa-profile]. 4.2.4. RSC To validate an RPKI Signed Checklist (RSC), RP software is required to perform all the checks specified in [RFC6488], as updated by [RFC9589], as well as additional, RSC-specific validation steps. The RSC profile, eContentType, and eContent are specified in Sections 2, 3, and 4 of [RFC9323]. Specific checks for an RSC are described in Section 5 of [RFC9323]. If RP software makes use of a validated RSC to verify files or data, it can follow the procedures described in Section 6 of [RFC9323]. Su, et al. Expires 14 December 2026 [Page 11] Internet-Draft Requirements for RPKI RP June 2026 4.2.5. TAK To validate a Trust Anchor Key (TAK), RP software is required to perform all the checks specified in [RFC6488], as updated by [RFC9589], as well as additional, TAK-specific validation steps. The TAK object content type and TAK eContent are specified in Sections 2.1 and 2.2 of [RFC9691]. Specific checks for a TAK are described in Section 2.3 of [RFC9691]. RP software requirements for the use of valid TAK objects are described in Section 4 of [RFC9691]. 4.2.6. Verifying BGPsec Router Certificate The requirements of Section 4.2.4 of [RFC8897] continue to apply. 4.3. How to Make Use of Manifest Data A manifest provides an RP with a signed inventory of the current objects published by a CA at a publication point. RP software uses the manifest to determine which files are current and acceptable for validation and, together with the certificate's CRL Distribution Points (CRLDP) extension, to identify the current CRL. For a given publication point, RP software is required to perform the tests specified in Sections 6.1 through 6.6 of [RFC9286] to determine which files at the publication point are acceptable. The tests are performed using the manifest identified by the SIA id-ad-rpkiManifest URI extracted from a CA certificate, and all files referenced by the manifest MUST be located at the publication point identified by the SIA id-ad-caRepository URI in the same certificate. The manifest and the files it references MUST reside at the same publication point. If an RP encounters any files that appear on a manifest but do not reside at the same publication point as the manifest, the RP MUST treat the fetch as failed, and a warning MUST be issued, as specified in Sections 6.1 and 6.6 of [RFC9286]. RP software MUST use the current manifest of a CA to determine which files are current objects for that CA at the corresponding publication point, as specified in Sections 2 and 6.1 of [RFC9286]. Files not listed on the current manifest MUST NOT be used as current objects for that CA at that publication point. During CA key rollover, manifest processing is performed separately for each CA instance, guided by the SIA id-ad-rpkiManifest URI in the corresponding CA certificate, as specified in Sections 2 and 6.1 of [RFC9286]. Su, et al. Expires 14 December 2026 [Page 12] Internet-Draft Requirements for RPKI RP June 2026 If the manifest cannot be retrieved, is invalid, is stale, if any file listed on the manifest cannot be retrieved from the publication point, if a listed file fails hash validation, if the manifest or any listed file does not reside at the same publication point, or if manifest processing otherwise fails, the RP MUST treat the fetch as failed and proceed as specified in Section 6.6 of [RFC9286]. RP software MUST use the issuer's current manifest together with the certificate's CRL Distribution Points (CRLDP) extension to identify the current CRL relevant to determining the revocation status of a resource certificate, as specified in Sections 2 and 3.2 of [RFC9829]. If the CRL is not listed on a valid, current manifest, the RP MUST treat the fetch as failed. 5. Distributing Validated Cache On a periodic basis, BGP speakers within an AS request updated validated cache data from the (local) validated cache of RPKI data. The RP may either transfer the validated data to the BGP speakers directly, or it may transfer the validated data to a cache server that is responsible for provisioning such data to BGP speakers. The specifications of the protocol designed to deliver validated cache data to a BGP speaker are provided in [RFC6810], [RFC8210], and [I-D.ietf-sidrops-8210bis]. [RFC6810] specifies version 0 of the RPKI-Router protocol. [RFC8210] specifies version 1 and updates [RFC6810]. [I-D.ietf-sidrops-8210bis] specifies version 2, updates [RFC8210], and is compatible with both earlier versions. If RP software supports version 2 of the RPKI-Router protocol, RP software is required to follow the additional requirements specified in [I-D.ietf-sidrops-8210bis], including support for ASPA PDUs and the ordering rules for cache responses. 6. Local Control The requirements of Section 6 of [RFC8897] continue to apply, with the following updates: * If an ISP wants to implement SLURM, its RP system can follow the instructions specified in [RFC8416]. * If an ISP wants to apply local filters and local assertions for Autonomous System Provider Authorizations (ASPAs), its RP system can follow the instructions specified in [I-D.ietf-sidrops-aspa-slurm], which updates [RFC8416]. Su, et al. Expires 14 December 2026 [Page 13] Internet-Draft Requirements for RPKI RP June 2026 7. Operational and Manageability Requirements for RPs RP software is often deployed as a continuously operating system component and is expected to support operational use, troubleshooting, and auditing in addition to repository synchronization and object validation. In operational environments, it is desirable for RP software to produce stable and machine- readable information that can be used for interchange, comparison, and audit across different RP implementations. Such information can support exchange of validated cache state, diagnosis of repository synchronization and object validation outcomes, and retention of historical RP results for later analysis. The following sections describe requirements related to export of validated cache state, operational observability, and historical retention of RP outputs. 7.1. Export of Validated Cache State RP software SHOULD support export of validated cache state in a stable, machine-readable form suitable for interchange with other systems. If an RP implementation supports Canonical Cache Representation (CCR), it can follow the instructions specified in [I-D.ietf-sidrops-rpki-ccr]. CCR may be used, for example, for audit trail keeping, validated payload dissemination, and analytics pipelines. 7.2. Operational Observability and Diagnostics RP software SHOULD provide sufficient status and diagnostic information to enable operators to understand the current execution state of the RP, the outcomes of repository synchronization, and the reasons for RPKI object-level rejection. In particular, RP software SHOULD make available log information sufficient to identify repository fetch failures, synchronization failures, and object parsing or validation failures. 7.3. Audit Trail and Historical State Retention RP software SHOULD support retention of historical RP output state, or equivalent audit records, sufficient to enable comparison, replay, or later analysis of validated cache outcomes. 8. Security Considerations The requirements of Section 7 of [RFC8897] continue to apply. Su, et al. Expires 14 December 2026 [Page 14] Internet-Draft Requirements for RPKI RP June 2026 9. IANA Considerations This document has no IANA requests. Acknowledgements References Normative References [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, . [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, . [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, . [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, . [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, . Su, et al. Expires 14 December 2026 [Page 15] Internet-Draft Requirements for RPKI RP June 2026 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, . [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, . [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, . [RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified Local Internet Number Resource Management with the RPKI (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, . [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, August 2019, . [RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, . [RFC9323] Snijders, J., Harrison, T., and B. Maddison, "A Profile for RPKI Signed Checklists (RSCs)", RFC 9323, DOI 10.17487/RFC9323, November 2022, . [RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, . [RFC9589] Snijders, J. and T. Harrison, "On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects", RFC 9589, DOI 10.17487/RFC9589, May 2024, . Su, et al. Expires 14 December 2026 [Page 16] Internet-Draft Requirements for RPKI RP June 2026 [RFC9674] Snijders, J., "Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP)", RFC 9674, DOI 10.17487/RFC9674, December 2024, . [RFC9691] Martinez, C., Michaelson, G., Harrison, T., Bruijnzeels, T., and R. Austein, "A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs)", RFC 9691, DOI 10.17487/RFC9691, December 2024, . [RFC9697] Snijders, J. and T. de Kock, "Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization", RFC 9697, DOI 10.17487/RFC9697, December 2024, . [RFC9829] Snijders, J., Maddison, B., and T. Buehler, "Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions", RFC 9829, DOI 10.17487/RFC9829, July 2025, . [RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", BCP 224, RFC 8634, DOI 10.17487/RFC8634, August 2019, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8608, DOI 10.17487/RFC8608, June 2019, . [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, . Su, et al. Expires 14 December 2026 [Page 17] Internet-Draft Requirements for RPKI RP June 2026 [I-D.ietf-sidrops-8210bis] Bush, R., Austein, R., and T. Harrison, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Work in Progress, Internet-Draft, draft-ietf- sidrops-8210bis-25, 2 March 2026, . [I-D.ietf-sidrops-aspa-profile] Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley, R., and B. Maddison, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-26, 19 April 2026, . [I-D.ietf-sidrops-aspa-slurm] Snijders, J. and B. Cartwright-Cox, "Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA)", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-slurm- 04, 16 November 2025, . [I-D.ietf-sidrops-manifest-numbers] Harrison, T., Michaelson, G., and J. Snijders, "Resource Public Key Infrastructure (RPKI) Manifest Number Handling", Work in Progress, Internet-Draft, draft-ietf- sidrops-manifest-numbers-09, 21 January 2026, . [I-D.ietf-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 Progress, Internet-Draft, draft-ietf-sidrops-rpki-erik- protocol-04, 17 March 2026, . Su, et al. Expires 14 December 2026 [Page 18] Internet-Draft Requirements for RPKI RP June 2026 [I-D.ietf-sidrops-rpki-ta-tiebreaker] Snijders, J., Buehler, T., and T. de Kock, "Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki- ta-tiebreaker-05, 29 May 2026, . [I-D.ietf-sidrops-rpki-validation-update] Snijders, J., Buehler, T., and B. Maddison, "Revision of the RPKI Validation Algorithm", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-validation-update- 03, 16 December 2025, . [RSYNC] "The rsync web pages", n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Informative References [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC8897] Ma, D. and S. Kent, "Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties", RFC 8897, DOI 10.17487/RFC8897, September 2020, . [RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)", RFC 8211, DOI 10.17487/RFC8211, September 2017, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . Su, et al. Expires 14 December 2026 [Page 19] Internet-Draft Requirements for RPKI RP June 2026 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., Newton, A., and D. Shaw, "Resource Public Key Infrastructure (RPKI) Validation Reconsidered", RFC 8360, DOI 10.17487/RFC8360, April 2018, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, . [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, . [I-D.ietf-sidrops-rpki-ccr] Snijders, J., Bakker, B., Bruijnzeels, T., and T. Buehler, "A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-ccr-08, 3 June 2026, . [I-D.snijders-rpkispool-format] Snijders, J. and F. Vompe, "The RPKISPOOL Format for Materializing Resource Public Key Infrastructure (RPKI) Data", Work in Progress, Internet-Draft, draft-snijders- rpkispool-format-00, 2 March 2026, . Authors' Addresses Yingying Su Zhongguancun Laboratory Beijing China Email: suyy@mail.zgclab.edu.cn Su, et al. Expires 14 December 2026 [Page 20] Internet-Draft Requirements for RPKI RP June 2026 Lancheng Qin Zhongguancun Laboratory Beijing China Email: qinlc@mail.zgclab.edu.cn Di Ma ZDNS Beijing China Email: madi@zdns.cn Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Su, et al. Expires 14 December 2026 [Page 21]