RPKI validation using a local cache
Author(s): Andrew Newton, Carlos Martinez, Tim Bruijnzeels
This documents specifies validation of rpki using a local cache that is independent of any particular retrieval mechanism of the objects in this cache. This is useful because it allows for agility in the RPKI to define alternative...
Network Working Group T. Bruijnzeels Internet-Draft RIPE NCC Intended status: Informational C. Martinez Expires: August 28, 2013 LACNIC A. Newton ARIN February 24, 2013 RPKI validation using a local cache draft-tbruijnzeels-sidr-validation-local-cache-01 Abstract This documents specifies validation of rpki using a local cache that is independent of any particular retrieval mechanism of the objects in this cache. This is useful because it allows for agility in the RPKI to define alternative fetch algorithms and/or multiple publication points of RPKI data. 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 http://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 August 28, 2013. Copyright Notice Copyright (c) 2013 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 (http://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 Bruijnzeels, et al. Expires August 28, 2013 [Page 1] Internet-Draft RPKI validation using a local cache February 2013 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. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Maintaining a local cache . . . . . . . . . . . . . . . . . . 4 4.1. Local cache structure . . . . . . . . . . . . . . . . . . 4 4.1.1. Object store . . . . . . . . . . . . . . . . . . . . . 4 4.1.2. Manifest Store . . . . . . . . . . . . . . . . . . . . 4 4.2. Retrieving objects from the cache . . . . . . . . . . . . 4 4.2.1. Registering CA publication points . . . . . . . . . . 4 4.2.2. Retrieving manifests from the cache . . . . . . . . . 4 4.2.3. Retrieving object from the cache . . . . . . . . . . . 5 4.2.4. Managing cache size . . . . . . . . . . . . . . . . . 5 4.3. Retrieving objects from the RPKI . . . . . . . . . . . . . 5 4.3.1. Retrieving objects using rsync . . . . . . . . . . . . 5 4.3.2. Retrieving objects using rrdp . . . . . . . . . . . . 5 4.3.3. Pro-active object retrieval . . . . . . . . . . . . . 7 5. Top-down Validation Algorithm . . . . . . . . . . . . . . . . 7 5.1. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Processing a Validated CA Certificate . . . . . . . . . . 7 5.3. Finding the Current Manifest . . . . . . . . . . . . . . . 7 5.4. Finding the Current CRL . . . . . . . . . . . . . . . . . 8 5.5. Finding and Validating Signed Objects . . . . . . . . . . 8 5.6. Recursion Down the PKI Tree . . . . . . . . . . . . . . . 9 6. Impact on existing RFCs . . . . . . . . . . . . . . . . . . . 9 6.1. Resource Certificate Repository Structure (RFC6481) . . . 9 6.2. Manifests (RFC6486) . . . . . . . . . . . . . . . . . . . 9 6.2.1. Missing Manifests . . . . . . . . . . . . . . . . . . 10 6.2.2. Mismatch between Manifest and Publication Point . . . 10 6.2.3. Hash Values Not Matching Manifest . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Bruijnzeels, et al. Expires August 28, 2013 [Page 2] Internet-Draft RPKI validation using a local cache February 2013 1. Requirements notation 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] . 2. Introduction It has been suggested by various people that in order to mitigate availability issues in the RPKI repositories, it would be good to support alternative fetch algorithms (easier to maintain by publication servers), multiple publication points (use multiple publication servers) and sharing of unvalidated objects between validating caches (less dependence on a central publication server). All these approaches share in common that unvalidated RPKI objects can potentially be retrieved in a number of different ways, separate from the actual validation process. And all these approaches face the same challenge: how to perform a top-down validation process if the SIA, AIA and CRLDP pointers don't necessarily point to the locations where the Relying Party retrieved the objects. This document does not intend to describe the one and only way Relying Parties can deal with this challenge. On the contrary, we feel there are more ways to achieve this. However we believe there are two reasons why it's useful to describe our (intended) approach here: (1) it is a show case demonstrating the feasibility of having multiple publication points and alternative fetch algorithms in the rpki, (2) we invite the WG to scrutinise our intended implementation for correctness. The 'rrdp' protocol mentioned in this document refers to the alternative delta protocol described in draft-tbruijnzeels-sidr-delta-protocol. 3. Outline We validate a trust anchor certificate and note the SKI. Then we search for the most recent manifest in our cache that has an AKI that matches this SKI and has a valid signature. We expect that this MFT contains one CRL entry that we will use to check for revocations. We will retrieve all objects mentioned on the manifest from our cache, by using their hash as a key. We then validate all objects as described in the current standards, with some minor caveats detailed below. We will then recursively find manifests, crls and validate signed objects for any certificate we validated this way. Bruijnzeels, et al. Expires August 28, 2013 [Page 3] Internet-Draft RPKI validation using a local cache February 2013 4. Maintaining a local cache 4.1. Local cache structure 4.1.1. Object store We will maintain a an object store of unvalidated objects, where we keep: o The SHA-256 hash of the object as a key o The binary object Note that we do not store the URI of the object itself. If we retrieve the exact same object more than once from the RPKI repositories, we still only store it once in the local cache. 4.1.2. Manifest Store To optimise for how we use manifests we store some additional information for them: o The AKI of the EE certificate o The serial number o A flag to indicate that this MFT has been found to be valid, invalid, or not validated o The hashes of the objects mentioned on it 4.2. Retrieving objects from the cache 4.2.1. Registering CA publication points Whenever a VALID CA certificate is found we store all new SIA rsync directory, or rrdp pointers on this certificate for pro-active retrieval. Rsync directory SIA pointers will NOT be stored in case the directory is sub-directory of and SIA pointer that is already known; the local cache will assume that hierarchical repository lay- out and recursive fetching is supported in this case. 4.2.2. Retrieving manifests from the cache Whenever we need to retrieve a manifest from the store, our implementation will provide the issuing CA certificate for this manifest and ask for the manifest matching the following criteria: o Having an AKI on its EE certificate that matches the SKI of the publishing CA certificate o Must be found valid, or not validated (so NOT invalid) o With the highest serial number o For which all objects mentioned can be found in the cache, by their SHA-256 hash Bruijnzeels, et al. Expires August 28, 2013 [Page 4] Internet-Draft RPKI validation using a local cache February 2013 If no such manifest can be found the local cache SHOULD check that object retrieval from the rpki has been attempted recently. If not, then the local cache SHOULD initiate an ad-hoc retrieval for one or more of the known publication points for the CA certificate that it was asked to return objects for. Note that this triggered retrieval is especially important when the Relying Party tool is first started and the local cache is incomplete or outdated. 4.2.3. Retrieving object from the cache Normal objects are retrieved by their SHA-256 hash. 4.2.4. Managing cache size To save space the local cache MAY find the manifest for each AKI, with the highest serial number that is marked as valid, and proceed to delete all manifests for this AKI with a lower serial number. Any objects in the object store whose SHA-256 is no longer referenced by any manifest may then also be deleted. 4.3. Retrieving objects from the RPKI 4.3.1. Retrieving objects using rsync As described in RFC6481 a CA certificate MUST have two rsync SIA pointers. One pointing to the CA certificate publication directory, and one to its manifest that MUST be published in this directory. For the purpose of this document we will consider the manifest SIA pointer redundant. The local cache will retrieve objects by doing a recursive rsync fetch for the directory SIA pointer. In case of hierarchical repository lay-outs it may turn out that the publication directory has already been retrieved because of a recursive rsync fetch higher up in the tree. In such cases the local cache SHOULD refrain from attempting a new recursive rsync fetch for such sub- directories. All objects retrieved this way will be read from disk, the SHA-256 will be calculated and all NEW objects will be stored in the local cache's object store. Any new objects that have a filename ending with .mft that can be parsed as manifests will be stored in the local cache's manifest store, noting the relevant attributes for retrieval mentioned above, and having validation state 'not validated'. 4.3.2. Retrieving objects using rrdp This delta protocol is described in https://datatracker.ietf.org/doc/ draft-tbruijnzeels-sidr-delta-protocol/ Bruijnzeels, et al. Expires August 28, 2013 [Page 5] Internet-Draft RPKI validation using a local cache February 2013 Note that rrdp pointers may shared by multiple CA certificates. They do not point to a publication point dedicated to any specific CA certificate. Instead they point to the publication point of an update notification file that is managed by the publication server that is used by this CA certificate, as well as a potentially large number of other CA certificates. The local cache will poll the notification file and process it. 18.104.22.168. New or unknown session In case the update notification is for a new rrdp server for which no session was previously known, or in case the session id is different from the one know, the local cache will update the session id to one mentioned in the notification file and process the latest full snapshot mentioned and update the last known version to this version. It will then attempt to update (see below) 22.214.171.124. No path from last known version to current In case there is no delta path mentioned on the update notification file for the last known version, to the current version, the local cache will process the latest full snapshot mentioned on the notification file. Note that the protocol requires that a notification update file MUST include a valid update path for the full snapshots it mentions. 126.96.36.199. Processing deltas The local cache will find the delta with the highest "version-to" to value that includes the last known version, and process it, update the last known version. And repeat until the last known version equals the current version on the notification file. 188.8.131.52. Processing objects from snapshots and deltas All new objects in 'publish' elements that are processed will be stored in the local cache's object store. New objects are objects for which the SHA-256 hash had not been seen before. The local cache will attempt to parse all new objects for which the uri attribute on the publish element ends with .mft, as manifests and store them in manifest store, noting the relevant attributes for retrieval mentioned above, and having validation state 'not validated'. All 'withdraw' elements are ignored. The local cache manages its cache as described in paragraph 4.2.4. Bruijnzeels, et al. Expires August 28, 2013 [Page 6] Internet-Draft RPKI validation using a local cache February 2013 4.3.3. Pro-active object retrieval The local cache will keep a record of all known publication points so that it can pro-actively retrieve objects from each. 184.108.40.206. rsync In case of rsync publication points a conservative 4 hour update interval is chosen, because of known issues with rsync server scalability in relation to repository size and number of connection relying parties. 220.127.116.11. rrdp The local cache will attempt to get the update notification for rrdp publication points every 5 minutes, and process any updates if applicable. 18.104.22.168. Triggering top-down validation Whenever the local cache finds any new unvalidated manifests after a full pro-active retrieval run for any publication point, it will trigger a full top-down validation. 5. Top-down Validation Algorithm 5.1. Trust Anchors The validation process starts with downloading and validating a the Trust Anchor certificate as described in RFC6490. The validated certificate we obtain this way will be used as the first validated certificate in the recursive algorithm outlined below. 5.2. Processing a Validated CA Certificate A validated CA certificate has a unique SKI that we can use to identify it. This SKI will be used as the AKI in any certificates signed by this CA certificate and the CRL it publishes. 5.3. Finding the Current Manifest We retrieve the most recent manifest for this CA certificate as described in section 4.2.2. The RP MUST validate that the manifest lists exactly one CRL and that Bruijnzeels, et al. Expires August 28, 2013 [Page 7] Internet-Draft RPKI validation using a local cache February 2013 this CRL can be retrieved from the cache as described in the next section. This manifest is then validated using the same criteria as described in RFC6486 section 4.4. With the exception that: o The CRLDP is ignored and the CRL retrieved above is used o The SIA and AIA fields are not used for validation If the manifest is reject the RP MUST flag it as invalid and try to fetch the next most recent manifest for this CA certificate. If the manifest is valid then the RP SHOULD flag the manifest as valid in the local cache. Furthermore if all manifests found this way have invalid signatures then the Relying Party MUST conclude that the SKI on the CA certificate was faked and the CA does not hold the private key, and therefore MUST reject this CA certificate. Note that this situation is extremely unlikely to arise by accident as the normal Certificate Sign Request as described in RFC6492 includes proof of possession of the private key by the certificate requester to the issuing CA. 5.4. Finding the Current CRL The manifest MUST list only one CRL that can be retrieved from the local cache by its SHA-256 hash. This CRL MUST pass all validation checks described in RFC5280. This CRL MUST not revoke the EE certificate of the manifest. If no such CRL can be found then the Relying Party MUST fall back to the next most recent manifest in the previous step. 5.5. Finding and Validating Signed Objects All other objects listed on the manifest can be retrieved from the cache by the SHA-256 hash. They are each validated according to the validation rules stipulated for their object type, which we can deduce from the extension in the name, with the exception that: o The CRLDP is ignored and the CRL retrieved above is used o The SIA and AIA fields are not used for validation Because Prefix Origin Validation (RFC Editor queue) needs to loop over *all* the relevant Validated ROA Prefixes to determine Route validity it is RECOMMENDED that Relying Parties first check that all objects listed on the manifest can be retrieved from the cache, and if any objects are missing fall back to the next most recent manifest for processing. If this would result in rejecting a publication point altogether, e.g. because the previous manifest EE certificate has expired, then it's RECOMMENDED that the latest manifest is used Bruijnzeels, et al. Expires August 28, 2013 [Page 8] Internet-Draft RPKI validation using a local cache February 2013 despite the missing objects. All these conditions MUST result in warnings to the users of Relying Party software. 5.6. Recursion Down the PKI Tree Any valid CA certificates found in the previous step can now be processed recursively starting at step 4.3. 6. Impact on existing RFCs 6.1. Resource Certificate Repository Structure (RFC6481) This is all in line with the Resource Certificate Repository Structure as described in RFC6481. However, it could be useful to add the following normative wording to section 2.2: "A CA's publication repository MUST contain the current (non-expired and non-revoked) certificates issued by this CA, the most recent CRL issued by this CA, the current manifest, and all other current signed objects that can be verified using an EE certificate [RFC6487] issued by this CA. A CA MUST list all objects that it desires to be considered for top- down validation on a single manifest, and it MUST NOT divide this list of products over multiple manifests. A CA MUST publish all the objects listed on this manifest. A CA MAY sign other objects that are not intended for publication in the RPKI repository. Such objects MUST NOT appear on the manifest and SHOULD not be published in the repository" 6.2. Manifests (RFC6486) Section 1 of RFC6486 has the following on the main purpose of manifests in the RPKI: "A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point." RFC6486 was written in the context of an rpki repository that assumes single publication points for CAs that can support recursive fetching of all published objects over rsync. Because RPs can get all objects that a CA publishes this way there was no need for any object that lists these objects explicitly for retrieval purposes, and therefore the manifest was not thought to carry this responsibility. Having said that, however, there are a number use cases that warrant that manifests MUST be useful in this way: Bruijnzeels, et al. Expires August 28, 2013 [Page 9] Internet-Draft RPKI validation using a local cache February 2013 o The validation process described in this document is independent of the location where objects are retrieved. Manifests are used to determine which objects are currently published by a CA. o BGP Prefix Origin Validation (RFC editor queue) section 2 describes a process for determining route validity that loops over all Validated Roa Prefixes. Therefore it is very desirable to have an authoritative source of information that instructs the RP which objects MUST be validated. o Other transport protocols, such as http, may be added in the future. These protocols do not necessarily support recursive fetching and therefore they need an authoritative list to determine what to fetch. For this reason we propose to change the standards so that manifests MAY be used as the authoritative list of objects that a CA desires to publish. In the next sections we describe the implications this has on the use of manifests by RPs as currently described in section 6 of RFC6486. 6.2.1. Missing Manifests A missing manifest may be the result of an error by the CA or the publisher. It is most strongly RECOMMENDED that CAs and publishers monitor this and fix the situation should problems arise. If no current manifest can be found by the Relying Party then they SHOULD use the most recent old manifest in their possession, as described in section 4.4 in this document. 6.2.2. Mismatch between Manifest and Publication Point Relying Parties that find that objects listed on the manifest are missing MAY decide to use the most recent manifest in their possession for which all objects could be found, as described in section 4.6 in this document. As described in RFC6481 CAs MUST publish all objects that MUST be considered for top-down validation, and they SHOULD NOT publish any other objects. Therefore Relying Parties MAY ignore any objects found in a repository that are not listed on a manifest. 6.2.3. Hash Values Not Matching Manifest Relying Parties MUST reject current published objects with hash values not matching the validated current manifest. Bruijnzeels, et al. Expires August 28, 2013 [Page 10] Internet-Draft RPKI validation using a local cache February 2013 7. Security Considerations TBD 8. Acknowledgements TBD 9. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Tim Bruijnzeels RIPE NCC Email: email@example.com Carlos Martinez LACNIC Email: firstname.lastname@example.org Andy Newton ARIN Email: email@example.com Bruijnzeels, et al. Expires August 28, 2013 [Page 11]