Secure Inter-Domain Routing T. Manderson Internet-Draft terrym.net pty ltd Intended status: Standards Track G. Michaelson Expires: April 8, 2009 APNIC October 5, 2008 RPKI Repository Retrieval Mechanism draft-manderson-sidr-fetch-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 8, 2009. Abstract This document proposes a mechanism for a relying party to synchronise a local cache of the RPKI repository using a HTTPS retrieval mechanism. Manderson & Michaelson Expires April 8, 2009 [Page 1] Internet-Draft RRRM October 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. RPKI Repository . . . . . . . . . . . . . . . . . . . . . 3 2.2. Publication Points . . . . . . . . . . . . . . . . . . . . 3 2.3. RPKI Manifests . . . . . . . . . . . . . . . . . . . . . . 3 2.4. Object URI . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5. CA and Manifest Relationship . . . . . . . . . . . . . . . 4 2.6. Traversing a RPKI Repository . . . . . . . . . . . . . . . 4 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 6 3.1. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Other Protocols . . . . . . . . . . . . . . . . . . . . . 6 4. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Retrieval Algorithm . . . . . . . . . . . . . . . . . . . 6 4.1.1. Post-Fetch Validated (PFV) . . . . . . . . . . . . . . 6 5. Client Considerations . . . . . . . . . . . . . . . . . . . . 8 5.1. Hash Comparison . . . . . . . . . . . . . . . . . . . . . 8 5.2. Hash Mismatch . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8.1. RRS and Manifest Integrity . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Manderson & Michaelson Expires April 8, 2009 [Page 2] Internet-Draft RRRM October 2008 1. Introduction 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. 1.1. Terminology 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" [RFC5280], "A Profile for X.509 PKIX Resource Certificates" [I-D.ietf-sidr-res-certs] "Manifests for the Resource Public Key Infrastructure" [I-D.ietf-sidr-rpki-manifests], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "Hypertext Transfer Protocol -- HTTP/1.1" [RFC2616], "HTTP Over TLS" [RFC2818], and related regional Internet registry address management policy documents. 1.2. Requirements Language 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. Overview 2.1. RPKI Repository An RPKI Repository is a collection of RPKI Publication Points. 2.2. 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. 2.3. RPKI Manifests 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. Manderson & Michaelson Expires April 8, 2009 [Page 3] Internet-Draft RRRM October 2008 Manifest validation SHOULD be done according to "Manifests for the Resource Public Key Infrastructure" [I-D.ietf-sidr-rpki-manifests]. 2.4. Object URI 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. 2.5. CA and Manifest Relationship In the situation that the certificate in focus is the Certificate Authority (CA) certificate: o Like all RPKI certificates [I-D.ietf-sidr-res-certs] the CA contains a SIA that identifies a Publish Point and a Manifest. o The CA signs an End Entity (EE) Certificate for the single purpose of signing the CA manifest. o The EE certificate has an SIA that also identifies the manifest. 2.6. Traversing a RPKI Repository A generalised RPKI hierarchy structure of a resource repository, including the out of band collected Trust Anchor (CA), can be represented as: Manderson & Michaelson Expires April 8, 2009 [Page 4] Internet-Draft RRRM October 2008 CA Certificate CA Publication Point SIA --Repository------->+------------------------------+ --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. 1. Collect the manifest referenced in the id-ad-rpkiManifest [I-D.ietf-sidr-res-certs] Manifest AccessMethod of the SIA of the Certificate. 2. Collect, from the Publication Point, every valid object listed in the manifest. 3. For each subordinate object with id-ad-signedObjectRepository [I-D.ietf-sidr-res-certs] 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 Manderson & Michaelson Expires April 8, 2009 [Page 5] Internet-Draft RRRM October 2008 RPKI validation. 3. Transport Protocol 3.1. HTTPS When transferring a RPKI objects HTTPS [RFC2818] 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. 3.2. Other Protocols 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. 4. Retrieval 4.1. Retrieval Algorithm 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). 4.1.1. Post-Fetch Validated (PFV) a. Fetch the appropriate manifest [I-D.ietf-sidr-rpki-manifests] from the RRS. The RC MAY maintain the connection to the RRS with a persistent connection. b. Confirm the manifest's validity. * If the manifest is invalid, or the manifest is empty, terminate processing and close any RRS connections Manderson & Michaelson Expires April 8, 2009 [Page 6] Internet-Draft RRRM October 2008 c. 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. d. 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. e. 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. f. 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. g. Close any RRS connections. h. RPKI Validate the retrieved objects and store the validated objects in the local cache. Manderson & Michaelson Expires April 8, 2009 [Page 7] Internet-Draft RRRM October 2008 5. Client Considerations 5.1. Hash Comparison 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. 5.2. 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. 6. Acknowledgements Due recognition needs to be given to all the individuals involved in the inter-RIR Resource Certificate working group. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations 8.1. RRS and Manifest Integrity 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: o An object is extremely large and RC retrieval of the object may cause resource, network, or other types of congestion. o Many invalid objects, which the RC must download, may affect overall performance or the RC or the overall Resource Certificate system. Manderson & Michaelson Expires April 8, 2009 [Page 8] Internet-Draft RRRM October 2008 9. Normative References [I-D.huston-sidr-repos-struct] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", draft-huston-sidr-repos-struct-01 (work in progress), February 2008. [I-D.ietf-sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-13 (work in progress), September 2008. [I-D.ietf-sidr-rpki-manifests] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure", draft-ietf-sidr-rpki-manifests-03 (work in progress), September 2008. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [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, May 2008. Authors' Addresses Terry Manderson terrym.net pty ltd AU Phone: +61 4 1127 5673 Email: terry@terrym.net Manderson & Michaelson Expires April 8, 2009 [Page 9] Internet-Draft RRRM October 2008 George Michaelson APNIC AU Phone: +61 7 3858 3100 Email: ggm@apnic.net Manderson & Michaelson Expires April 8, 2009 [Page 10] Internet-Draft RRRM October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Manderson & Michaelson Expires April 8, 2009 [Page 11]