draft-tbruijnzeels-sidr-validation-local-cache-01:
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.
4.3.2.1. 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)
4.3.2.2. 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.
4.3.2.3. 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.
4.3.2.4. 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.
4.3.3.1. 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.
4.3.3.2. rrdp
The local cache will attempt to get the update notification for rrdp
publication points every 5 minutes, and process any updates if
applicable.
4.3.3.3. 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: tim@ripe.net
Carlos Martinez
LACNIC
Email: carlos@lacnic.net
Andy Newton
ARIN
Email: andy@arin.net
Bruijnzeels, et al. Expires August 28, 2013 [Page 11]
