idnits 2.17.1 draft-manderson-sidr-fetch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2008) is 5680 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.huston-sidr-repos-struct' is defined on line 332, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-huston-sidr-repos-struct-01 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-13 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-03 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing T. Manderson 3 Internet-Draft terrym.net pty ltd 4 Intended status: Standards Track G. Michaelson 5 Expires: April 8, 2009 APNIC 6 October 5, 2008 8 RPKI Repository Retrieval Mechanism 9 draft-manderson-sidr-fetch-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 8, 2009. 36 Abstract 38 This document proposes a mechanism for a relying party to synchronise 39 a local cache of the RPKI repository using a HTTPS retrieval 40 mechanism. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 47 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2.1. RPKI Repository . . . . . . . . . . . . . . . . . . . . . 3 49 2.2. Publication Points . . . . . . . . . . . . . . . . . . . . 3 50 2.3. RPKI Manifests . . . . . . . . . . . . . . . . . . . . . . 3 51 2.4. Object URI . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.5. CA and Manifest Relationship . . . . . . . . . . . . . . . 4 53 2.6. Traversing a RPKI Repository . . . . . . . . . . . . . . . 4 54 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2. Other Protocols . . . . . . . . . . . . . . . . . . . . . 6 57 4. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Retrieval Algorithm . . . . . . . . . . . . . . . . . . . 6 59 4.1.1. Post-Fetch Validated (PFV) . . . . . . . . . . . . . . 6 60 5. Client Considerations . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Hash Comparison . . . . . . . . . . . . . . . . . . . . . 8 62 5.2. Hash Mismatch . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8.1. RRS and Manifest Integrity . . . . . . . . . . . . . . . . 8 67 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 Intellectual Property and Copyright Statements . . . . . . . . . . 11 71 1. Introduction 73 This document details a mechanism and algorithm for a relying party 74 to synchronise a local cache of RPKI objects against the collection 75 of original publication points. 77 1.1. Terminology 79 It is assumed that the reader is familiar with the terms and concepts 80 described in "Internet X.509 Public Key Infrastructure Certificate 81 and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile 82 for X.509 PKIX Resource Certificates" [I-D.ietf-sidr-res-certs] 83 "Manifests for the Resource Public Key Infrastructure" 84 [I-D.ietf-sidr-rpki-manifests], "X.509 Extensions for IP Addresses 85 and AS Identifiers" [RFC3779], "Hypertext Transfer Protocol -- 86 HTTP/1.1" [RFC2616], "HTTP Over TLS" [RFC2818], and related regional 87 Internet registry address management policy documents. 89 1.2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119. 95 2. Overview 97 2.1. RPKI Repository 99 An RPKI Repository is a collection of RPKI Publication Points. 101 2.2. Publication Points 103 A Publication Point is the location where RPKI objects exist for 104 public use. The Publication Point also contains a manifest of all 105 the RPKI objects that are published at that location. The 106 Publication Point URI is held in the SIA of the RPKI Certificate that 107 signed the objects at that Publication Point. 109 2.3. RPKI Manifests 111 A manifest is a signed object, listing of all of the RPKI objects at 112 a publication point in the RPKI Repository, excluding the manifest 113 itself. The manifest contains the file name and a hash of the 114 contents of the RPKI object file. 116 The URI to the manifest exists in the manifest SIA from the 117 Certificate that signed the manifest. 119 Manifest validation SHOULD be done according to "Manifests for the 120 Resource Public Key Infrastructure" [I-D.ietf-sidr-rpki-manifests]. 122 2.4. Object URI 124 The object location URI is constructed by using the Publish Point 125 from the Signing RPKI Certificate SIA and the File (name) in the 126 manifest signed by the Signing RPKI Certificate. The exception to 127 this is the Certificate Authority (CA) certificate and manifest 128 relationship. 130 2.5. CA and Manifest Relationship 132 In the situation that the certificate in focus is the Certificate 133 Authority (CA) certificate: 135 o Like all RPKI certificates [I-D.ietf-sidr-res-certs] the CA 136 contains a SIA that identifies a Publish Point and a Manifest. 138 o The CA signs an End Entity (EE) Certificate for the single purpose 139 of signing the CA manifest. 141 o The EE certificate has an SIA that also identifies the manifest. 143 2.6. Traversing a RPKI Repository 145 A generalised RPKI hierarchy structure of a resource repository, 146 including the out of band collected Trust Anchor (CA), can be 147 represented as: 149 CA Certificate CA Publication Point 150 SIA --Repository------->+------------------------------+ 151 --Manifest-----------> manifest.cms<-------------------------+ 152 | CRL | | 153 | subord CA certs | | 154 | subord multi-sign EE certs | | 155 | SIA ------Repository-------+ | 156 | ------Manifest-------+ | | 157 | subord 1:1 Manifest EE cert | | | | 158 | SIA --Object-------------------+ 159 | subord 1:1 EE certs | | | 160 | SIA --Object--+ | | | 161 | | | | | 162 | +-----------+ | | | 163 | V | | | 164 | signed Object | | | 165 | | | | 166 +------------------------------+ | | 167 | | 168 ----------------------+ | 169 | | 170 +------------|---------------------+< 171 | V | 172 | manifest.cms | 173 | signed objects | 174 +----------------------------------+ 175 EE Publication Point 176 (for multi-sign EEs) 178 The following broad algorithm MAY be used to traverse the hierarchy, 179 starting with the Trust Anchor or CA RPKI Certificate. 181 1. Collect the manifest referenced in the id-ad-rpkiManifest 182 [I-D.ietf-sidr-res-certs] Manifest AccessMethod of the SIA of the 183 Certificate. 185 2. Collect, from the Publication Point, every valid object listed in 186 the manifest. 188 3. For each subordinate object with id-ad-signedObjectRepository 189 [I-D.ietf-sidr-res-certs] and id-ad-rpkiManifest access method 190 SIA values repeat fom step 1. 192 Processing of each subordinate Publish Point MAY be done in parallel, 193 provided sufficient RPKI material has been collected for Manifest and 194 RPKI validation. 196 3. Transport Protocol 198 3.1. HTTPS 200 When transferring a RPKI objects HTTPS [RFC2818] based transfers MUST 201 be used in order to ensure the integrity of the repository site or to 202 encrypt the retrieval of the RPKI objects. Various HTTPS methods MAY 203 be used to minimise the number of simultaneous fetches and data 204 transfers over the transport connection. It is further recommended 205 that the RRRM client make efforts to reduce the number of 206 simultaneous connections such that a balance exists between the 207 number of open TCP connections and the number of objects retrieved 208 per connection for each publication point. 210 3.2. Other Protocols 212 The retrieval algorithm specified in this document can also be used 213 by other protocols as an effecient way to synchronise the RPKI 214 repository with a local cache, provided HTTP specifics such as (and 215 not limited to) redirects, http pragma, connection behaviours and 216 pipe-lining are addresed. 218 4. Retrieval 220 4.1. Retrieval Algorithm 222 If the SIA for the Publish Point of the RPKI Certificate Authority 223 (CA) Certificate or End Entity Certificate defines a HTTPS access 224 method in the URI then the following algorithm MAY be used by a 225 Retrieval Client for any initial and subsequent fetch of certificates 226 and signed outcomes (objects) from an RPKI Repository Server (RRS). 228 4.1.1. Post-Fetch Validated (PFV) 230 a. Fetch the appropriate manifest [I-D.ietf-sidr-rpki-manifests] 231 from the RRS. The RC MAY maintain the connection to the RRS with 232 a persistent connection. 234 b. Confirm the manifest's validity. 236 * If the manifest is invalid, or the manifest is empty, 237 terminate processing and close any RRS connections 239 c. Construct a list of URIs to be retrieved by comparing hash values 240 in the downloaded manifest, with the hash values of the locally 241 cached object: 243 * If a local manifest does not exist then all objects contained 244 in the manifest MUST be listed for retrieval. 246 * If an object entry in the downloaded manifest does not exist 247 locally, the URI SHOULD be added to the retrieval list. 249 * If an object exists locally and does not appear in the 250 manifest, it SHOULD be deleted from the local cache. 252 * If the hash value of the object in the downloaded manifest 253 does not match the hash value of the local copy of the object, 254 the URI of the object SHOULD be added to the retrieval list. 256 * If the retrieval list is empty, terminate processing and close 257 any RRS connections. 259 d. Fetch the list of objects using pipe-lined GET requests. 261 * HTTP redirects SHOULD be honoured by the client and followed 262 using a separate RRS connection for the object if located at a 263 different RSS endpoint. 265 e. Confirm that all of the objects listed in the downloaded manifest 266 have been retrieved. Should one or more objects fail to 267 retrieve, it is then a matter of local cache policy to continue 268 with the intent of RPKI validating retrieved objects. The client 269 (and cache policy) should realise that it would be unlikely that 270 enough RPKI information would then exist locally to fully 271 validate objects from that publication point, and as such 272 processing in this condition may be wasteful. It is also 273 possible that an object may have been removed from the 274 publication point between retrival of the manifest and the 275 attempted retrieval of the object. 277 f. Confirm the hash of the downloaded object file contents matches 278 the hash stored in the downloaded manifest 280 * If the hash does not match, the object MAY be newer than the 281 manifest and the object SHOULD be RPKI validated. 283 g. Close any RRS connections. 285 h. RPKI Validate the retrieved objects and store the validated 286 objects in the local cache. 288 5. Client Considerations 290 5.1. Hash Comparison 292 As described in the PFV algorithm, if the hash does not match, the 293 object may be newer than the manifest. It is RECOMMENDED that 294 suitable warnings be generated by the retrieval client to alert to 295 any issues of a hash mismatch. 297 5.2. Hash Mismatch 299 To minimise the occurrences of hash values that do not match, the RC 300 MAY consider postponing retrieval of a RPKI Repository for some 301 period of time either side of the "nextUpdate" time detailed in the 302 manifest. 304 6. Acknowledgements 306 Due recognition needs to be given to all the individuals involved in 307 the inter-RIR Resource Certificate working group. 309 7. IANA Considerations 311 This memo includes no request to IANA. 313 8. Security Considerations 315 8.1. RRS and Manifest Integrity 317 A scenario exists where a malicious attack could place an invalid 318 RPKI certificate on the RRS in the Publication Point prior to the 319 manifest creation. While this does not represent a high risk to the 320 overall Resource Certificate system as the object will fail to 321 validate, it may affect the Relying Party as: 323 o An object is extremely large and RC retrieval of the object may 324 cause resource, network, or other types of congestion. 326 o Many invalid objects, which the RC must download, may affect 327 overall performance or the RC or the overall Resource Certificate 328 system. 330 9. Normative References 332 [I-D.huston-sidr-repos-struct] 333 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 334 Resource Certificate Repository Structure", 335 draft-huston-sidr-repos-struct-01 (work in progress), 336 February 2008. 338 [I-D.ietf-sidr-res-certs] 339 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 340 X.509 PKIX Resource Certificates", 341 draft-ietf-sidr-res-certs-13 (work in progress), 342 September 2008. 344 [I-D.ietf-sidr-rpki-manifests] 345 Austein, R., Huston, G., Kent, S., and M. Lepinski, 346 "Manifests for the Resource Public Key Infrastructure", 347 draft-ietf-sidr-rpki-manifests-03 (work in progress), 348 September 2008. 350 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 351 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 352 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 354 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 356 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 357 Addresses and AS Identifiers", RFC 3779, June 2004. 359 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 360 Housley, R., and W. Polk, "Internet X.509 Public Key 361 Infrastructure Certificate and Certificate Revocation List 362 (CRL) Profile", RFC 5280, May 2008. 364 Authors' Addresses 366 Terry Manderson 367 terrym.net pty ltd 368 AU 370 Phone: +61 4 1127 5673 371 Email: terry@terrym.net 372 George Michaelson 373 APNIC 374 AU 376 Phone: +61 7 3858 3100 377 Email: ggm@apnic.net 379 Full Copyright Statement 381 Copyright (C) The IETF Trust (2008). 383 This document is subject to the rights, licenses and restrictions 384 contained in BCP 78, and except as set forth therein, the authors 385 retain all their rights. 387 This document and the information contained herein are provided on an 388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 390 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 391 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 392 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 Intellectual Property 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org.