RPKI Repository Retrieval Mechanism

This document details a mechanism and algorithm for a relying party to synchronise a local cache of RPKI objects against the collection of original publication points.

It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", "A Profile for X.509 PKIX Resource Certificates" "Manifests for the Resource Public Key Infrastructure", "X.509 Extensions for IP Addresses and AS Identifiers", "Hypertext Transfer Protocol -- HTTP/1.1", "HTTP Over TLS", and related regional Internet registry address management policy documents.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

An RPKI Repository is a collection of RPKI Publication Points.

A Publication Point is the location where RPKI objects exist for public use. The Publication Point also contains a manifest of all the RPKI objects that are published at that location. The Publication Point URI is held in the SIA of the RPKI Certificate that signed the objects at that Publication Point.

A manifest is a signed object, listing of all of the RPKI objects at a publication point in the RPKI Repository, excluding the manifest itself. The manifest contains the file name and a hash of the contents of the RPKI object file. The URI to the manifest exists in the manifest SIA from the Certificate that signed the manifest. Manifest validation SHOULD be done according to "Manifests for the Resource Public Key Infrastructure".

The object location URI is constructed by using the Publish Point from the Signing RPKI Certificate SIA and the File (name) in the manifest signed by the Signing RPKI Certificate. The exception to this is the Certificate Authority (CA) certificate and manifest relationship.

In the situation that the certificate in focus is the Certificate Authority (CA) certificate: Like all RPKI certificates the CA contains a SIA that identifies a Publish Point and a Manifest. The CA signs an End Entity (EE) Certificate for the single purpose of signing the CA manifest. The EE certificate has an SIA that also identifies the manifest.

A generalised RPKI hierarchy structure of a resource repository, including the out of band collected Trust Anchor (CA), can be represented as:

+------------------------------+ --Manifest-----------> manifest.cms<-------------------------+ | CRL | | | subord CA certs | | | subord multi-sign EE certs | | | SIA ------Repository-------+ | | ------Manifest-------+ | | | subord 1:1 Manifest EE cert | | | | | SIA --Object-------------------+ | subord 1:1 EE certs | | | | SIA --Object--+ | | | | | | | | | +-----------+ | | | | V | | | | signed Object | | | | | | | +------------------------------+ | | | | ----------------------+ | | | +------------|---------------------+< | V | | manifest.cms | | signed objects | +----------------------------------+ EE Publication Point (for multi-sign EEs) ]]> The following broad algorithm MAY be used to traverse the hierarchy, starting with the Trust Anchor or CA RPKI Certificate. Collect the manifest referenced in the id-ad-rpkiManifest Manifest AccessMethod of the SIA of the Certificate. Collect, from the Publication Point, every valid object listed in the manifest. For each subordinate object with id-ad-signedObjectRepository and id-ad-rpkiManifest access method SIA values repeat fom step 1. Processing of each subordinate Publish Point MAY be done in parallel, provided sufficient RPKI material has been collected for Manifest and RPKI validation.

When transferring a RPKI objects HTTPS based transfers MUST be used in order to ensure the integrity of the repository site or to encrypt the retrieval of the RPKI objects. Various HTTPS methods MAY be used to minimise the number of simultaneous fetches and data transfers over the transport connection. It is further recommended that the RRRM client make efforts to reduce the number of simultaneous connections such that a balance exists between the number of open TCP connections and the number of objects retrieved per connection for each publication point.

The retrieval algorithm specified in this document can also be used by other protocols as an effecient way to synchronise the RPKI repository with a local cache, provided HTTP specifics such as (and not limited to) redirects, http pragma, connection behaviours and pipe-lining are addresed.

If the SIA for the Publish Point of the RPKI Certificate Authority (CA) Certificate or End Entity Certificate defines a HTTPS access method in the URI then the following algorithm MAY be used by a Retrieval Client for any initial and subsequent fetch of certificates and signed outcomes (objects) from an RPKI Repository Server (RRS).

Fetch the appropriate manifest from the RRS. The RC MAY maintain the connection to the RRS with a persistent connection. Confirm the manifest's validity. If the manifest is invalid, or the manifest is empty, terminate processing and close any RRS connections Construct a list of URIs to be retrieved by comparing hash values in the downloaded manifest, with the hash values of the locally cached object: If a local manifest does not exist then all objects contained in the manifest MUST be listed for retrieval. If an object entry in the downloaded manifest does not exist locally, the URI SHOULD be added to the retrieval list. If an object exists locally and does not appear in the manifest, it SHOULD be deleted from the local cache. If the hash value of the object in the downloaded manifest does not match the hash value of the local copy of the object, the URI of the object SHOULD be added to the retrieval list. If the retrieval list is empty, terminate processing and close any RRS connections. Fetch the list of objects using pipe-lined GET requests. HTTP redirects SHOULD be honoured by the client and followed using a separate RRS connection for the object if located at a different RSS endpoint. Confirm that all of the objects listed in the downloaded manifest have been retrieved. Should one or more objects fail to retrieve, it is then a matter of local cache policy to continue with the intent of RPKI validating retrieved objects. The client (and cache policy) should realise that it would be unlikely that enough RPKI information would then exist locally to fully validate objects from that publication point, and as such processing in this condition may be wasteful. It is also possible that an object may have been removed from the publication point between retrival of the manifest and the attempted retrieval of the object. Confirm the hash of the downloaded object file contents matches the hash stored in the downloaded manifest If the hash does not match, the object MAY be newer than the manifest and the object SHOULD be RPKI validated. Close any RRS connections. RPKI Validate the retrieved objects and store the validated objects in the local cache.

As described in the PFV algorithm, if the hash does not match, the object may be newer than the manifest. It is RECOMMENDED that suitable warnings be generated by the retrieval client to alert to any issues of a hash mismatch.

To minimise the occurrences of hash values that do not match, the RC MAY consider postponing retrieval of a RPKI Repository for some period of time either side of the "nextUpdate" time detailed in the manifest.

Due recognition needs to be given to all the individuals involved in the inter-RIR Resource Certificate working group.

This memo includes no request to IANA.

A scenario exists where a malicious attack could place an invalid RPKI certificate on the RRS in the Publication Point prior to the manifest creation. While this does not represent a high risk to the overall Resource Certificate system as the object will fail to validate, it may affect the Relying Party as: An object is extremely large and RC retrieval of the object may cause resource, network, or other types of congestion. Many invalid objects, which the RC must download, may affect overall performance or the RC or the overall Resource Certificate system.