Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties

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 are scattered throughout numerous protocol-specific RFCs and Best Current Practice RFCs. The following RFCs and related specifications define these requirements:

(Repository Structure)
(Key Rollover)
(Algorithm Agility)
(Algorithms and Key Sizes for Use in RPKI), as updated by
(RPKI Trust Anchor Locators), as updated by
(RPKI Trust Anchor Keys (TAKs))
(Certificate and CRL profile), as updated by and
(BGPsec Router Certificates Profile)
(RPKI to Router Protocol, Version 0)
(RPKI to Router Protocol, Version 1), as updated by (Version 2)
(RPKI SLURM), as updated by
(RPKI Signed Object Template), as updated by
(Manifests), as updated by
(Route Origin Authorizations (ROAs)), as updated by
(RPKI Signed Checklists (RSCs))
(ASPA object profile)
(The RPKI Repository Delta Protocol (RRDP)), as updated by and
(Erik Synchronization Protocol)
(rsync repository synchronization)
(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)
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.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Changes from This document updates 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 by , replacement of by , update of by , update of by , and update of by and .
Requirements related to trust anchor processing have been updated to include and .
Requirements related to repository synchronization have been updated to include , , , , and .
Requirements related to ROA have been updated to reference and .
Requirements related to manifests have been updated to reference and .
Requirements related to basic signed object syntax checks have been updated to reflect the changes in .
New signed-object requirements have been added for Trust Anchor Keys (TAKs) , RPKI Signed Checklists (RSCs) and Autonomous System Provider Authorizations (ASPAs) .
Requirements related to Ghostbusters Records have been removed, since is now Historic.
Requirements related to certificate path validation have been updated to reflect and .
Requirements related to validated cache distribution have been updated to include .
Requirements related to local control have been updated to include .
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.

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.

Fetching and Caching RPKI Repository Objects RP software uses one or more repository synchronization protocols supported by targeted repositories, such as rsync , RRDP as updated by and , or Erik , 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.

Trust Anchor Configuration and Processing The requirements of Section 2.1 of 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 , which updates Section 3 of .
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 .
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 . RP software that supports TAK processing MUST apply the successor-key verification and acceptance-timer procedure specified in Section 4 of .

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. Section 5 of 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 , 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 , respectively. If RP software supports RRDP, repository object discovery and retrieval are additionally specified in . If RP software supports Erik Synchronization, repository object discovery and retrieval are additionally specified in Section 4 of . 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.

Dealing with Key Rollover The requirements of Section 2.3 of continue to apply. In addition, RP software requirements for dealing with TA key rollover and successor key processing are described in Section 4 of .

Dealing with Algorithm Transition The requirements of Section 2.4 of continue to apply.

Strategies for Efficient Cache Maintenance The requirements of Section 2.5 of continue to apply.

Repository Synchronization Protocols RP software uses one or more repository synchronization protocols, such as rsync , RRDP , and Erik , to update its local cache of RPKI repository objects. Requirements for RRDP are specified in . Additional RRDP requirements for RPs are specified in and . In particular, RP software that supports RRDP MUST apply the Same-Origin Policy checks specified in . RP software that supports RRDP SHOULD also perform the desynchronization detection and recovery procedures specified in . If RP software switches from RRDP to rsync, it SHOULD follow the guidance in Section 2.2 of . If RP software supports Erik Synchronization, repository synchronization procedures are additionally specified in Section 4 of .

Certificate and CRL Processing The requirements of the introductory text of Section 3 of continue to apply.

Verifying Resource Certificate and Syntax The requirements of Section 3.1 of continue to apply.

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 specifies the procedure that RP software should follow to perform certificate path validation. 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 . Ongoing work to revise the RPKI validation algorithm is described in , which updates Section 5 of to reference the validated VRS-IP outcome of EE certificate validation, replaces Section 7.2 of in its entirety with a revised resource certification path validation procedure, updates Section 9 of , and obsoletes .

CRL Processing The CRL processing requirements imposed on CAs and RPs are described in Section 5 of , as updated by Sections 2 and 3.1 of . CRLs in the RPKI are tightly constrained; only the AuthorityKeyIdentifier (section 4.8.3 of ) and CRLNumber (section 5.2.3 of ) extensions are allowed, and they are required to be present. No other CRL extensions are allowed, and no 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 . 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 .

Processing RPKI Repository Signed Objects

Basic Signed Object Syntax Checks The requirements of Section 4.1 of continue to apply, with the following update:

updates the checks in Section 3 of . In particular, Section 4 of updates Section 3, item 1.f and item 1.g of 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.

Syntax and Validation for Each Type of Signed Object

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 , as updated by . Specific checks for a manifest are described in Sections 4.2.1 and 4.4 of . 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 . Additional manifest-number handling requirements are described in , which updates Section 4.2.1 of .

ROA To validate a Route Origin Authorization (ROA), RP software is required to perform all the checks specified in , as updated by , as well as additional, ROA-specific validation steps. The ROA content type and ROA eContent are specified in Sections 3 and 4 of . Specific checks for a ROA are described in Section 5 of . Additional ROA validation requirements are described in Section 3 of , which updates the ROA validation procedure in Section 5 of . 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.

ASPA To validate an Autonomous System Provider Authorization (ASPA), RP software is required to perform all the checks specified in , as updated by , as well as additional, ASPA-specific validation steps. The ASPA content type and ASPA eContent are specified in Sections 2 and 3 of . Specific checks for an ASPA are described in Section 4 of .

RSC To validate an RPKI Signed Checklist (RSC), RP software is required to perform all the checks specified in , as updated by , as well as additional, RSC-specific validation steps. The RSC profile, eContentType, and eContent are specified in Sections 2, 3, and 4 of . Specific checks for an RSC are described in Section 5 of . If RP software makes use of a validated RSC to verify files or data, it can follow the procedures described in Section 6 of .

TAK To validate a Trust Anchor Key (TAK), RP software is required to perform all the checks specified in , as updated by , 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 . Specific checks for a TAK are described in Section 2.3 of . RP software requirements for the use of valid TAK objects are described in Section 4 of .

Verifying BGPsec Router Certificate The requirements of Section 4.2.4 of continue to apply.

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 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 . 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 . 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 . 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 . 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 . If the CRL is not listed on a valid, current manifest, the RP MUST treat the fetch as failed.

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 , , and . specifies version 0 of the RPKI-Router protocol. specifies version 1 and updates . specifies version 2, updates , 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 , including support for ASPA PDUs and the ordering rules for cache responses.

Local Control The requirements of Section 6 of continue to apply, with the following updates:

If an ISP wants to implement SLURM, its RP system can follow the instructions specified in .
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 , which updates .

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.

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 . CCR may be used, for example, for audit trail keeping, validated payload dissemination, and analytics pipelines.

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.

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.

Security Considerations The requirements of Section 7 of continue to apply.

IANA Considerations This document has no IANA requests.

Acknowledgements