RIPE NCC

tim@ripe.net

RIPE NCC

oleg@ripe.net

rtg SIDR RPKI validation RRDP This document describes the approach to validate the content of the RPKI repository, which is independent of a particular object retrieval mechanism. This allows it to be used with repositories available over rsync protocol (see Section 3 of), and delta protocol ( ), as well as repositories that use a mix of both.

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 .

The validation of one repository is independent from any other repository, and thus, multiple repositories could be validated concurrently. The validation of a repository starts from it's Trust Anchor (TA) certificate. To retrieve the TA, the Trust Anchor Locator (TAL) object is used, as described in . If the TA certificate is retrieved, it is validated according to the Section 2.2 of . Then the TA certificate is validated as a resource certificate, as described in . For all repository objects that were validated during this validation run, their validation timestamp is updated in the local store (see ). Outdated objects are removed from the store as described in . This completes the validation of a repository.

The following steps are performed in order to fetch the Trust Anchor Certificate: If the Trust Anchor Locator contains "prefetch.uris" field, pass the URIs contained there to the fetcher (see ). Pass to the fetcher () the URI from the TAL (see Section 2.1 of ). Retrieve from the local store (see ) all certificate objects, for which the URI matches the URI extracted from the TAL in the previous step, and the public key matches the subjectPublicKeyInfo field of the TAL (Section 2.1 of ). If no, or more than one such objects are found, issue an error and stop validation process. Otherwise, use that object as a Trust Anchor certificate.

The following steps describe the validation of a single resource certificate: If both the caRepository (Section 4.8.8.1 of ), and the id-ad-rpkiNotify (Section 3.5 of ) SIA pointers are present in the given resource certificate, use a local policy to determine which pointer to use. Extract the URI from the selected pointer and pass it to the fetcher (see ). For a given resource certificate, find it's manifest and certificate revocation list (CRL), using the procedure described in . If no such manifest and CRL could be found, issue an error and stop processing current certificate. Compare given resource certificate's manifest URI with the URI of the manifest found in the previous step. If they are different, issue a warning. Get from the local store and validate repository objects that correspond to the manifest entries, using the procedure described in the . Validate all resource certificate objects found on the manifest, using the CRL object found on the manifest, according to Section 7 of . Validate all ROA objects found on the manifest, using the CRL object found on the manifest, according to the Section 4 of . Validate all Ghostbusters Record objects found on the manifest, using the CRL object found on the manifest, according to the Section 7 of . For every valid resource certificate object found on the manifest, apply the procedure described in this section, recursively, provided that this resource certificate (identified by it's SKI) has not yet been validated during current repository validation run.

Fetch from the store (see ) all objects of type manifest, whose certificate's AKI field matches the SKI of the current CA certificate. Find the manifest object with the highest manifest number, for which all following conditions are met: There is only one entry in the manifest for which the store contains exactly one object of type CRL, whose hash matches the hash of the entry. The manifest's certificate AKI equals the above CRL's AKI The above CRL is a valid object according to Section 6.3 of The manifest is a valid object according to Section 4.4 of , using the CRL found above Report an error for every invalid manifest with the number higher than the number of the valid manifest.

For every entry in the manifest object: Construct an entry's URI by appending the entry name to the current CA's publication point URI. Get all objects from the store whose hash attribute equals entry's hash (see ). If no such objects found, issue an error. For every found object, compare it's URI with the URI of the manifest entry. If they do not match, issue a warning. If no objects with matching URI found, issue a warning. If some objects with non-matching URI found, issue a warning.

At the end of repository validation, the store cleanup is performed. Given all objects that were validated during current validation run, it removes from the store () all objects whose URI attribute matches URI of validated object(s), but the hash attribute is different.

The fetcher is responsible for downloading objects from remote repositories. Currently rsync and RRDP repositories are supported.

This operation receives one parameter – a URI. For rsync protocol this URI points to a directory in a remote rsync repository. For RRDP repository it points to the repository's notification file. The fetcher performs following steps: If the given URI has been downloaded recently (as specified by the local policy), do nothing. Download remote objects using the URI provided (for rsync repository use recursive mode). For every new object that is downloaded, try to parse it as an object of specific RPKI type (certificate, manifest, CRL, ROA, Ghostbusters record), based on the object's filename extension (.cer, .mft, .crl, .roa, and .gbr, respectively), and perform basic RPKI object validation, as specified in and . For every downloaded valid object, record it in the local store (), and set it's last fetch time to the time it was downloaded ().

This operation receives one parameter – a URI that points to an object in a remote repository. The fetcher performs following operations: If the given URI has been downloaded recently (as specified by the local policy), do nothing. Download the remote object using the URI provided. Try to parse downloaded object as an object of a specific RPKI type (certificate, manifest, CRL, ROA, Ghostbusters record), based on the object's filename extension (.cer, .mft, .crl, .roa, and .gbr, respectively), and perform basic RPKI object validation, as specified in and . If the downloaded object is not valid, issue an error and skip further steps. Delete objects from the local store () using given URI. Put validated object in the local store (), and set it's last fetch time to the time it was downloaded ().

Put given object in the store, along with it's type, URI, hash, and AKI, if there is no record with the same hash and URI fields.

For all objects in the store whose URI matches the given URI, set the last fetch time attribute to the given timestamp.

Retrieve all objects from the store whose hash attribute matches the given hash.

Retrieve from the store all objects of type certificate, whose URI attribute matches the given URI.

Retrieve from the store all objects of type manifest, whose AKI attribute matches the given AKI.

For a given URI, delete all objects in the store with matching URI attribute.

For a given URI and a list of hashes, delete all objects in the store with matching URI, whose hash attribute is not in the given list of hashes.

For all objects in the store whose hash attribute matches the given hash, set the last validation time attribute to the given timestamp.