idnits 2.17.1 draft-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 422. 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 (June 23, 2008) is 5783 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 336, 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-10 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-00 ** 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) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 4 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 G. Michaelson 4 Intended status: Standards Track APNIC 5 Expires: December 25, 2008 June 23, 2008 7 Alternative RPKI Repository Retrieval Mechanism 8 draft-sidr-fetch-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 25, 2008. 35 Abstract 37 This document proposes a mechanism for a relying party to synchronise 38 a local cache of the RPKI repository using a HTTP retrieval 39 mechanism. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 46 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2.1. RPKI Repository . . . . . . . . . . . . . . . . . . . . . 3 48 2.2. Publication Points . . . . . . . . . . . . . . . . . . . . 3 49 2.3. RPKI Manifests . . . . . . . . . . . . . . . . . . . . . . 3 50 2.4. Object URI . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.5. CA and Manifest Relationship . . . . . . . . . . . . . . . 4 52 2.6. Traversing a RPKI Repository . . . . . . . . . . . . . . . 4 53 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.2. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.3. Other Protocols . . . . . . . . . . . . . . . . . . . . . 6 57 4. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Retrieval Algorithm . . . . . . . . . . . . . . . . . . . 6 59 4.1.1. Post RPKI Validated (PRV) . . . . . . . . . . . . . . 6 60 5. Client Considerations . . . . . . . . . . . . . . . . . . . . 7 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. RC to RRS Channel Attacks . . . . . . . . . . . . . . . . 8 67 8.2. RRS and Manifest Integrity . . . . . . . . . . . . . . . . 8 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 Intellectual Property and Copyright Statements . . . . . . . . . . 11 72 1. Introduction 74 This document details a mechanism and algorithm for a relying party 75 to synchronise a local cache of RPKI objects against the collection 76 of original publication points. 78 1.1. Terminology 80 It is assumed that the reader is familiar with the terms and concepts 81 described in "Internet X.509 Public Key Infrastructure Certificate 82 and Certificate Revocation List (CRL) Profile" [RFC3280], "A Profile 83 for X.509 PKIX Resource Certificates" [I-D.ietf-sidr-res-certs] 84 "Manifests for the Resource Public Key Infrastructure" 85 [I-D.ietf-sidr-rpki-manifests], "X.509 Extensions for IP Addresses 86 and AS Identifiers" [RFC3779], "Hypertext Transfer Protocol -- 87 HTTP/1.1" [RFC2616], "HTTP Over TLS" [RFC2818], and related regional 88 Internet registry address management policy documents. 90 1.2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119. 96 2. Overview 98 2.1. RPKI Repository 100 An RPKI Repository is a collection of RPKI Publication Points. 102 2.2. Publication Points 104 A Publication Point is the location where RPKI objects exist for 105 public use. The Publication Point also contains a manifest of all 106 the RPKI objects that are published at that location. The 107 Publication Point URI is held in the SIA of the RPKI Certificate that 108 signed the objects at that Publication Point. 110 2.3. RPKI Manifests 112 A manifest is a signed object, listing of all of the RPKI objects at 113 a publication point in the RPKI Repository, excluding the manifest 114 itself. The manifest contains the file name and a hash of the 115 contents of the RPKI object file. 117 The URI to the manifest exists in the manifest SIA from the 118 Certificate that signed the manifest. 120 Manifest validation SHOULD be done according to "Manifests for the 121 Resource Public Key Infrastructure" [I-D.ietf-sidr-rpki-manifests]. 123 2.4. Object URI 125 The object location URI is constructed by using the Publish Point 126 from the Signing RPKI Certificate SIA and the File (name) in the 127 manifest signed by the Signing RPKI Certificate. The exception to 128 this is the Certificate Authority (CA) certificate and manifest 129 relationship. 131 2.5. CA and Manifest Relationship 133 In the situation that the certificate in focus is the Certificate 134 Authority (CA) certificate: 136 o Like all RPKI certificates [I-D.ietf-sidr-res-certs] the CA 137 contains a SIA that identifies a Publish Point and a Manifest. 139 o The CA signs an End Entity (EE) Certificate for the single purpose 140 of signing the CA manifest. 142 o The EE certificate has an SIA that also identifies the manifest. 144 2.6. Traversing a RPKI Repository 146 A generalised RPKI hierarchy structure of a resource repository, 147 including the out of band collected Trust Anchor (CA), can be 148 represented as: 150 CA Certificate CA Publication Point 151 SIA --Repository------->+------------------------------+ 152 --Manifest-----------> manifest.cms<-------------------------+ 153 | CRL | | 154 | subord CA certs | | 155 | subord multi-sign EE certs | | 156 | SIA ------Repository-------+ | 157 | ------Manifest-------+ | | 158 | subord 1:1 Manifest EE cert | | | | 159 | SIA --Object-------------------+ 160 | subord 1:1 EE certs | | | 161 | SIA --Object--+ | | | 162 | | | | | 163 | +-----------+ | | | 164 | V | | | 165 | signed Object | | | 166 | | | | 167 +------------------------------+ | | 168 | | 169 ----------------------+ | 170 | | 171 +------------|---------------------+< 172 | V | 173 | manifest.cms | 174 | signed objects | 175 +----------------------------------+ 176 EE Publication Point 177 (for multi-sign EEs) 179 The following broad algorithm MAY be used to traverse the hierarchy, 180 starting with the Trust Anchor or CA RPKI Certificate. 182 1. Collect the manifest referenced in the id-ad-rpkiManifest 183 [I-D.ietf-sidr-res-certs] Manifest AccessMethod of the SIA of the 184 Certificate. 186 2. Collect, from the Publication Point, every valid object listed in 187 the manifest. 189 3. For each subordinate object with id-ad-signedObjectRepository 190 [I-D.ietf-sidr-res-certs] and id-ad-rpkiManifest access method 191 SIA values repeat fom step 1. 193 Processing of each subordinate Publish Point MAY be done in parallel, 194 provided sufficient RPKI material has been collected for Manifest and 195 RPKI validation. 197 3. Transport Protocol 199 3.1. HTTP 201 When transferring a RPKI objects HTTP 1.1 [RFC2616]SHOULD be used as 202 the underlying transport mechanism, as specified by the URI in the 203 SIA field. Various HTTP methods MAY be used to minimise the number 204 of fetches and data transfers over the transport connection. 206 3.2. HTTPS 208 HTTPS [RFC2818] based transfers MAY be used in order to ensure the 209 integrity of the repository site or to encrypt the retrieval of the 210 RPKI objects. It is therefore up to the resource certificate issuer 211 to understand any potential operational performance issues associated 212 with using A HTTPS URI in the RPKI certificate SIA fields. 214 3.3. Other Protocols 216 The retrieval algorithm specified in this document can also be used 217 by other protocols as an effecient way to synchronise the RPKI 218 repository with a local cache, provided HTTP specifics such as (but 219 not limited to) redirects, http pragma, connection behaviours and 220 pipe-lining are addresed. 222 4. Retrieval 224 4.1. Retrieval Algorithm 226 If the SIA for the Publish Point of the RPKI Certificate Authority 227 (CA) Certificate or End Entity Certificate defines a HTTP or HTTPS 228 access method in the URI then the following algorithm MAY be used by 229 a Retrieval Client for any initial and subsequent fetch of 230 certificates and signed outcomes (objects) from an RPKI Repository 231 Server (RRS). 233 4.1.1. Post RPKI Validated (PRV) 235 a. Fetch the appropriate manifest [I-D.ietf-sidr-rpki-manifests] 236 from the RRS. The RC MAY maintain the connection to the RRS with 237 a persistent connection. 239 b. Confirm the manifest's validity. 241 * If the manifest is invalid, or the manifest is empty, 242 terminate processing and close any RRS connections 244 c. Construct a list of URIs to be retrieved by comparing hash values 245 in the downloaded manifest, with the hash values of the locally 246 cached object: 248 * If a local manifest does not exist then all objects contained 249 in the manifest MUST be listed for retrieval. 251 * If an object entry in the downloaded manifest does not exist 252 locally, the URI SHOULD be added to the retrieval list. 254 * If an object exists locally and does not appear in the 255 manifest, it SHOULD be deleted from the local cache. 257 * If the hash value of the object in the downloaded manifest 258 does not match the hash value of the local copy of the object, 259 the URI of the object SHOULD be added to the retrieval list. 261 * If the retrieval list is empty, terminate processing and close 262 any RRS connections. 264 d. Fetch the list of objects using pipe-lined GET requests. 266 * HTTP redirects SHOULD be honoured by the client and followed 267 using a separate RRS connection for the object. 269 e. Confirm that all of the objects listed in the downloaded manifest 270 have been retrieved. 272 f. Confirm the hash of the downloaded object file contents matches 273 the hash stored in the downloaded manifest 275 * If the hash does not match, the object MAY be newer than the 276 manifest and the object SHOULD be RPKI validated. 278 g. Close any RRS connections. 280 h. RPKI Validate the retrieved objects and store the validated 281 objects in the local cache. 283 5. Client Considerations 284 5.1. Hash Comparison 286 As described in the PRV algorithm, if the hash does not match, the 287 object may be newer than the manifest. It is RECOMMENDED that 288 suitable warnings be generated by the retrieval client to alert to 289 any issues of a hash mismatch. 291 5.2. Hash Mismatch 293 To minimise the occurrences of hash values that do not match, the RC 294 MAY consider postponing retrieval of a RPKI Repository for some 295 period of time either side of the "nextUpdate" time detailed in the 296 manifest. 298 6. Acknowledgements 300 Due recognition needs to be given to all the individuals involved in 301 the inter-RIR Resource Certificate working group. 303 7. IANA Considerations 305 This memo includes no request to IANA. 307 8. Security Considerations 309 8.1. RC to RRS Channel Attacks 311 Using an unencrypted channel could expose the relying party to either 312 man-in-the-middle or remote Denial of Service (DoS) HTTP/TCP attacks 313 against the channel between the RC and the RRS. 315 The certificate issuer should consider the potential for disruption 316 to the relying party operations in selecting the preferred SIA access 317 methods. 319 8.2. RRS and Manifest Integrity 321 A scenario exists where a malicious attack could place an invalid 322 RPKI certificate on the RRS in the Publication Point prior to the 323 manifest creation. While this does not represent a high risk to the 324 overall Resource Certificate system as the object will fail to 325 validate, it may affect the Relying Party as: 327 o An object is extremely large and RC retrieves the object this may 328 cause resource network or other types of congestion. 330 o Many invalid objects, which the RC must download, may affect 331 overall performance or the RC or the overall Resource Certificate 332 system. 334 9. Normative References 336 [I-D.huston-sidr-repos-struct] 337 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 338 Resource Certificate Repository Structure", 339 draft-huston-sidr-repos-struct-01 (work in progress), 340 February 2008. 342 [I-D.ietf-sidr-res-certs] 343 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 344 X.509 PKIX Resource Certificates", 345 draft-ietf-sidr-res-certs-10 (work in progress), 346 June 2008. 348 [I-D.ietf-sidr-rpki-manifests] 349 Austein, R., Huston, G., Kent, S., and M. Lepinski, 350 "Manifests for the Resource Public Key Infrastructure", 351 draft-ietf-sidr-rpki-manifests-00 (work in progress), 352 January 2008. 354 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 355 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 356 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 358 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 360 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 361 X.509 Public Key Infrastructure Certificate and 362 Certificate Revocation List (CRL) Profile", RFC 3280, 363 April 2002. 365 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 366 Addresses and AS Identifiers", RFC 3779, June 2004. 368 Authors' Addresses 370 Terry Manderson 371 APNIC 372 AU 374 Phone: +61 7 3858 3100 375 Email: terry@apnic.net 377 George Michaelson 378 APNIC 379 AU 381 Phone: +61 7 3858 3100 382 Email: ggm@apnic.net 384 Full Copyright Statement 386 Copyright (C) The IETF Trust (2008). 388 This document is subject to the rights, licenses and restrictions 389 contained in BCP 78, and except as set forth therein, the authors 390 retain all their rights. 392 This document and the information contained herein are provided on an 393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 394 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 395 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 396 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 397 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 400 Intellectual Property 402 The IETF takes no position regarding the validity or scope of any 403 Intellectual Property Rights or other rights that might be claimed to 404 pertain to the implementation or use of the technology described in 405 this document or the extent to which any license under such rights 406 might or might not be available; nor does it represent that it has 407 made any independent effort to identify any such rights. Information 408 on the procedures with respect to rights in RFC documents can be 409 found in BCP 78 and BCP 79. 411 Copies of IPR disclosures made to the IETF Secretariat and any 412 assurances of licenses to be made available, or the result of an 413 attempt made to obtain a general license or permission for the use of 414 such proprietary rights by implementers or users of this 415 specification can be obtained from the IETF on-line IPR repository at 416 http://www.ietf.org/ipr. 418 The IETF invites any interested party to bring to its attention any 419 copyrights, patents or patent applications, or other proprietary 420 rights that may cover technology that may be required to implement 421 this standard. Please address the information to the IETF at 422 ietf-ipr@ietf.org.