SIDR T. Bruijnzeels
Internet-Draft O. Muravskiy
Intended status: Informational RIPE NCC
Expires: April 21, 2016 October 19, 2015

RPKI Repository Validation Using Local Cache


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[RFC6481]), and delta protocol ( [I-D.tbruijnzeels-sidr-delta-protocol]), as well as repositories that use a mix of both.

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

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 April 21, 2016.

Copyright Notice

Copyright (c) 2015 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 ( 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

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 [RFC2119].

2. Top-down Validation of a Single Repository

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 Section 2.1.

If the TA certificate is retrieved, it is validated according to the Section 2.2 of [RFC6490].

Then the TA certificate is validated as a resource certificate, as described in Section 2.2.

For all repository objects that were validated during this validation run, their validation timestamp is updated in the local store (see Section 4.1.8).

Outdated objects are removed from the store as described in Section 2.3. This completes the validation of a repository.

2.1. Fetching Trust Anchor Certificate Using Trust Anchor Locator

The following steps are performed in order to fetch the Trust Anchor Certificate:

2.2. Resource Certificate Validation

The following steps describe the validation of a single resource certificate:

2.2.1. Finding most recent valid manifest and CRL

Fetch from the store (see Section 4.1.5) 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:

Report an error for every invalid manifest with the number higher than the number of the valid manifest.

2.2.2. Manifest entries validation

For every entry in the manifest object:

2.3. Store Cleanup

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 (Section 4.1.7) all objects whose URI attribute matches URI of validated object(s), but the hash attribute is different.

3. Remote Objects Fetcher

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

3.1. Fetcher Operations

3.1.1. Fetch repository objects

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:

3.1.2. Fetch single repository object

This operation receives one parameter – a URI that points to an object in a remote repository.

The fetcher performs following operations:

4. Local Object Store

4.1. Store Operations

4.1.1. Store Repository Object

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.

4.1.2. Update object's last fetch time

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

4.1.3. Get objects by hash

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

4.1.4. Get certificate objects by URI

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

4.1.5. Get manifest objects by AKI

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

4.1.6. Delete objects for URI

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

4.1.7. Delete outdated objects

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.

4.1.8. Update object's validation time

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

5. Acknowledgements

6. IANA Considerations

7. Security Considerations

8. References

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[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.
[RFC6481] Huston, G., Loomans, R. and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012.
[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.
[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.
[RFC6490] Huston, G., Weiler, S., Michaelson, G. and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, DOI 10.17487/RFC6490, February 2012.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012.

8.2. Informative References

[I-D.tbruijnzeels-sidr-delta-protocol] Bruijnzeels, T., Muravskiy, O., Weber, B., Austein, R. and D. Mandelberg, "RPKI Repository Delta Protocol", Internet-Draft draft-tbruijnzeels-sidr-delta-protocol-03, December 2014.

Authors' Addresses

Tim Bruijnzeels RIPE NCC EMail:
Oleg Muravskiy RIPE NCC EMail: