Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties
draft-su-sidrops-rpki-rp-requirements-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yingying Su , Lancheng Qin , Di Ma , Dan Li | ||
| Last updated | 2026-06-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-su-sidrops-rpki-rp-requirements-00
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,
<https://www.rfc-editor.org/info/rfc6481>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
[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,
<https://www.rfc-editor.org/info/rfc6488>.
[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,
<https://www.rfc-editor.org/info/rfc6489>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/info/rfc6810>.
[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, <https://www.rfc-editor.org/info/rfc6916>.
[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, <https://www.rfc-editor.org/info/rfc7935>.
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,
<https://www.rfc-editor.org/info/rfc8182>.
[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,
<https://www.rfc-editor.org/info/rfc8209>.
[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,
<https://www.rfc-editor.org/info/rfc8210>.
[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,
<https://www.rfc-editor.org/info/rfc8416>.
[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, <https://www.rfc-editor.org/info/rfc8630>.
[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,
<https://www.rfc-editor.org/info/rfc9286>.
[RFC9323] Snijders, J., Harrison, T., and B. Maddison, "A Profile
for RPKI Signed Checklists (RSCs)", RFC 9323,
DOI 10.17487/RFC9323, November 2022,
<https://www.rfc-editor.org/info/rfc9323>.
[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,
<https://www.rfc-editor.org/info/rfc9582>.
[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,
<https://www.rfc-editor.org/info/rfc9589>.
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, <https://www.rfc-editor.org/info/rfc9674>.
[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,
<https://www.rfc-editor.org/info/rfc9691>.
[RFC9697] Snijders, J. and T. de Kock, "Detecting RPKI Repository
Delta Protocol (RRDP) Session Desynchronization",
RFC 9697, DOI 10.17487/RFC9697, December 2024,
<https://www.rfc-editor.org/info/rfc9697>.
[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,
<https://www.rfc-editor.org/info/rfc9829>.
[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
Certificate Rollover", BCP 224, RFC 8634,
DOI 10.17487/RFC8634, August 2019,
<https://www.rfc-editor.org/info/rfc8634>.
[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,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8608,
DOI 10.17487/RFC8608, June 2019,
<https://www.rfc-editor.org/info/rfc8608>.
[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,
<https://www.rfc-editor.org/info/rfc3779>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
8210bis-25>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-26>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-slurm-04>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
manifest-numbers-09>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-erik-protocol-04>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-ta-tiebreaker-05>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-validation-update-03>.
[RSYNC] "The rsync web pages", n.d., <https://rsync.samba.org>.
[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>.
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>.
[RFC8897] Ma, D. and S. Kent, "Requirements for Resource Public Key
Infrastructure (RPKI) Relying Parties", RFC 8897,
DOI 10.17487/RFC8897, September 2020,
<https://www.rfc-editor.org/info/rfc8897>.
[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,
<https://www.rfc-editor.org/info/rfc8211>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
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,
<https://www.rfc-editor.org/info/rfc8360>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[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,
<https://www.rfc-editor.org/info/rfc6486>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[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, <https://datatracker.ietf.org/doc/html/draft-ietf-
sidrops-rpki-ccr-08>.
[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,
<https://datatracker.ietf.org/doc/html/draft-snijders-
rpkispool-format-00>.
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]