idnits 2.17.1 draft-ietf-sidrops-prefer-rrdp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([RFC8182]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC8182, but the abstract doesn't seem to directly say this. It does mention RFC8182 though, so this could be OK. -- The draft header indicates that this document updates RFC6841, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended status: Standards TrackInternet Initiative Japan & Arrcus, Inc.', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (February 22, 2021) is 1152 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) == Missing Reference: 'RFC6487' is mentioned on line 213, but not defined == Missing Reference: 'RSYNC' is mentioned on line 400, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5781 ** Downref: Normative reference to an Informational RFC: RFC 6480 ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bruijnzeels 3 Internet-Draft NLnet Labs 4 Updates: 6841, 8182 (if approved) R. Bush 5 Intended status: Standards TrackInternet Initiative Japan & Arrcus, Inc. 6 Expires: August 26, 2021 G. Michaelson 7 APNIC 8 February 22, 2021 10 Resource Public Key Infrastructure (RPKI) Repository Requirements 11 draft-ietf-sidrops-prefer-rrdp-00 13 Abstract 15 This document formulates a plan of a phased transition to a state 16 where RPKI repositories and Relying Party software performing RPKI 17 Validation will use the RPKI Repository Delta Protocol (RRDP) 18 [RFC8182] as the only mandatory to implement access protocol. 20 The first objective is to make RRDP the preferred access protocol, 21 and require rsync as a fallback option only. This will greatly 22 reduce the operational burden and concerns for RPKI repository 23 operators. 25 In phase 0, today's deployment, RRDP is supported by most, but not 26 all Repositories, and most but not all RP software. 28 In the proposed phase 1 RRDP will become mandatory to implement for 29 Repositories, in addition to rsync. This phase can start as soon as 30 this document is published. 32 Once the proposed updates are implemented by all Repositories phase 2 33 will start. In this phase RRDP will become mandatory to implement 34 for all RP software, and rsync will be required as a fallback option 35 only. 37 It should be noted that although this document currently includes 38 descriptions and updates to RFCs for each of these phases, we may 39 find that it will be beneficial to have one or more separate 40 documents for these phases, so that it might be more clear to all 41 when the updates to RFCs take effect. 43 Furthermore, this document currently includes an early discussion of 44 a future objective, which would be to change the RPKI standards such 45 that names in RPKI objects are no longer tightly coupled to rsync. 46 By using transport independent names and validation, we will obtain 47 the agility needed to phase out rsync altogether and/or introduce 48 other future access protocols. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at https://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on August 26, 2021. 67 Copyright Notice 69 Copyright (c) 2021 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (https://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 85 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 86 3. Plan to prefer RRDP . . . . . . . . . . . . . . . . . . . . . 4 87 3.1. Phase 0 - RPKI repositories support rsync, and optionally 88 RRDP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 89 3.1.1. Updates to RFC 8182 . . . . . . . . . . . . . . . . . 4 90 3.1.2. Updates to RFC 6481 . . . . . . . . . . . . . . . . . 5 91 3.2. Phase 1 - RPKI repositories support both rsync and RRDP . 6 92 3.2.1. Updates to RFC 6481 . . . . . . . . . . . . . . . . . 6 93 3.2.2. Measurements . . . . . . . . . . . . . . . . . . . . 7 94 3.3. Phase 2 - All RP software prefers RRDP . . . . . . . . . 7 95 3.3.1. Updates to RFC 8182 . . . . . . . . . . . . . . . . . 7 96 3.3.2. Rsync URIs as object identifiers . . . . . . . . . . 7 97 3.3.3. Measurements . . . . . . . . . . . . . . . . . . . . 8 99 4. Future Objective: Remove the dependency on rsync . . . . . . 8 100 4.1. Phase 3 - RPKI repositories support RRDP, and optionally 101 rsync . . . . . . . . . . . . . . . . . . . . . . . . . . 8 102 4.1.1. Updates to RFC 6481 . . . . . . . . . . . . . . . . . 8 103 4.2. Transport agnostic RPKI object names . . . . . . . . . . 9 104 5. Appendix - Implementation Status . . . . . . . . . . . . . . 10 105 5.1. Current RRDP Support in Repository Software . . . . . . . 10 106 5.2. Current RRDP Support in Relying Party software . . . . . 11 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 109 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 110 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 111 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 112 9.2. Informative References . . . . . . . . . . . . . . . . . 12 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 115 1. Requirements notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. Motivation 125 The Resource Public Key Infrastructure (RPKI) [RFC6480] as originally 126 defined uses rsync as its distribution protocol, as outlined in 127 [RFC6481]. Later, the RPKI Repository Delta Protocol (RRDP) 128 [RFC8182] was designed to provide an alternative. In order to 129 facilitate incremental deployment RRDP has been deployed as an 130 additional optional protocol, while rsync was still mandatory to 131 implement. 133 While rsync has been very useful in the initial deployment of RPKI, a 134 number of issues observed with it motivated the design of RRDP, e.g.: 136 o rsync is CPU and memory heavy on the server side, and easy to DoS 138 o rsync library support is lacking, complicating RP efficiency and 139 error logging 141 o we cannot ensure that RPs get atomic sets of updated objects 143 RRDP was designed to leverage HTTPS CDN infrastructure to provide 144 RPKI Repository content in a resilient way, while reducing the load 145 on the Repository server. It supports that updates are published as 146 atomic deltas, which can help prevent most of the issues described in 147 section 6 of [RFC6486]. 149 For a longer discussion please see section 1 of [RFC8182]. 151 In conclusion: we believe that while RRDP is not perfect, and we may 152 indeed need future work to improve on it, it is an improvement over 153 using rsync in the context of RPKI. Therefore, this document 154 outlines a transition plan where RRDP becomes mandatory to implement, 155 and the operational dependency on rsync is reduced to that of a 156 fallback option. 158 3. Plan to prefer RRDP 160 Changing the RPKI infrastructure to rely on RRDP instead of rsync is 161 a delicate operation. There is current deployment of Certification 162 Authorities, Repository Servers and Relying Party software which 163 relies on rsync, and which may not yet support RRDP. 165 Therefore we need to have a plan that ultimately updates the relevant 166 RFCs, but which uses a phased approach combined with measurements to 167 limit the operational impact of doing this to (almost) zero. 169 The general outline of the plan is as follows. We will describe each 170 step in more detail below. 172 +-------+------------------------------------------------------+ 173 | Phase | Description | 174 +-------+------------------------------------------------------+ 175 | 0 | RPKI repositories support rsync, and optionally RRDP | 176 | 1 | RPKI repositories support both rsync and RRDP | 177 | 2 | All RP software prefers RRDP | 178 +-------+------------------------------------------------------+ 180 3.1. Phase 0 - RPKI repositories support rsync, and optionally RRDP 182 This is the situation at the time of writing this document. Relying 183 Parties can prefer RRDP over rsync today, but they need to support 184 rsync until all RPKI repositories support RRDP. Therefore all 185 repositories should support RRDP at their earliest convenience. 187 3.1.1. Updates to RFC 8182 189 Repositories which support RRDP MUST ensure that RRDP resources are 190 available to Relying Parties (section 3.3 of [RFC8182]). 191 Furthermore, the RRDP repository MUST include all current repository 192 objects. Because of this the choice of falling back to alternative 193 repository access mechanisms was left as a local policy choice of RP 194 software. 196 However, following discussions on this subject it has become clear 197 that there is a preference to instruct RP software to make use of all 198 possible data sources. The main motivation being that because of 199 RPKI object security using a secondary source of data can never lead 200 to a worse outcome in terms of validation. 202 The following update is therefore applicable to section 3.4.5 203 "Considerations Regarding Operational Failures in RRDP" of [RFC8182]: 205 OLD: Relying Parties could attempt to use alternative repository 206 access mechanisms, if they are available, according to the 207 accessMethod element value(s) specified in the SIA of the associated 208 certificate (see Section 4.8.8 of [RFC6487]). 210 NEW: Relying Parties MUST attempt to use alternative repository 211 access mechanisms, if they are available, according to the 212 accessMethod element value(s) specified in the SIA of the associated 213 certificate (see Section 4.8.8 of [RFC6487]). 215 3.1.2. Updates to RFC 6481 217 As noted above section 3.3 of [RFC8182] already stipulates that RRDP 218 files MUST be made available by repositories which support RRDP. In 219 other words the RRDP service must be treated as a critical service 220 wherever it is supported. 222 During this phase the updates are applied to section 3 of [RFC6481], 223 to make this abundantly clear: 225 OLD: 227 o The publication repository SHOULD be hosted on a highly available 228 service and high-capacity publication platform. 230 o The publication repository MUST be available using rsync [RFC5781] 231 [RSYNC]. Support of additional retrieval mechanisms is the choice 232 of the repository operator. The supported retrieval mechanisms 233 MUST be consistent with the accessMethod element value(s) 234 specified in the SIA of the associated CA or EE certificate. 236 NEW: 238 o The publication repository MAY be available using the RPKI 239 Repository Delta Protocol [RFC8182]. If RPDP is provided, it 240 SHOULD be hosted on a highly available platform. 242 o The publication repository MUST be available using rsync [RFC5781] 243 [RSYNC]. The rsync server SHOULD be hosted on a highly available 244 platform. 246 o Support of additional retrieval mechanisms is the choice of the 247 repository operator. The supported retrieval mechanisms MUST be 248 consistent with the accessMethod element value(s) specified in the 249 SIA of the associated CA or EE certificate. 251 3.2. Phase 1 - RPKI repositories support both rsync and RRDP 253 During this phase we will make RRDP mandatory to support for 254 Repository Servers, and measure whether the deployed Repository 255 Servers have been upgraded to do so, in as far as they don't support 256 RRDP already. 258 3.2.1. Updates to RFC 6481 260 During this phase the updates are applied to section 3 of [RFC6481]. 262 OLD: 264 o The publication repository SHOULD be hosted on a highly available 265 service and high-capacity publication platform. 267 o The publication repository MUST be available using rsync [RFC5781] 268 [RSYNC]. Support of additional retrieval mechanisms is the choice 269 of the repository operator. The supported retrieval mechanisms 270 MUST be consistent with the accessMethod element value(s) 271 specified in the SIA of the associated CA or EE certificate. 273 NEW: 275 o The publication repository MUST be available using the RPKI 276 Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be 277 hosted on a highly available platform. 279 o The publication repository MUST be available using rsync [RFC5781] 280 [RSYNC]. The rsync server SHOULD be hosted on a highly available 281 platform. 283 o Support of additional retrieval mechanisms is the choice of the 284 repository operator. The supported retrieval mechanisms MUST be 285 consistent with the accessMethod element value(s) specified in the 286 SIA of the associated CA or EE certificate. 288 3.2.2. Measurements 290 We can find out whether all RPKI repositories support RRDP by running 291 (possibly) modified Relying Party software that keeps track of this. 293 When it is found that Repositories do not yet support RRDP, outreach 294 should be done to them individually. Since the number of 295 Repositories is fairly low, and it is in their interest to run RRDP 296 because it addresses availability concerns, we have confidence that 297 we will find these Repositories willing to make changes. 299 3.3. Phase 2 - All RP software prefers RRDP 301 Once all Repositories support RRDP we can proceed to make RRDP 302 mandatory to implement for Relying Party software. 304 3.3.1. Updates to RFC 8182 306 From this phase onwards the updates are applied to section 3.4.1 of 307 [RFC8182]. 309 OLD: When a Relying Party performs RPKI validation and learns about a 310 valid certificate with an SIA entry for the RRDP protocol, it SHOULD 311 use this protocol as follows. 313 NEW: When a Relying Party performs RPKI validation and learns about a 314 valid certificate with an SIA entry for the RRDP protocol, it MUST 315 use this protocol with preference. 317 Relying Parties MUST NOT attempt to fetch objects using alternate 318 access mechanisms, if object retrieval through this protocol is 319 successful. 321 However, as stipulated in section 3.4.5, Relying Parties MUST attempt 322 to use alternative repository access mechanisms, if object retrieval 323 through this protocol is unsuccessful. 325 3.3.2. Rsync URIs as object identifiers 327 Rsync URIs are used in the RPKI to name objects and hierarchies, and 328 they are as such very useful when doing RPKI object validation, as 329 well as for error reporting on validation issues. 331 Note that RRDP includes rsync URIs in its structure. See section 3.5 332 of [RFC8182]. Theoretically, RRDP servers could include any rsync 333 URI. However, Relying Party software knows which RRDP server to is 334 expected to include the rsync URIs for RPKI objects issued under any 335 given CA certificate, because of the id-ad-rpkiNotify SIA extenion, 336 see section 3.2 of [RFC8182]. 338 Thus, objects retrieved through RRDP can be mapped easily to files 339 and URIs, similar to as though rsync would have been used to retrieve 340 them. 342 3.3.3. Measurements 344 Although the tools may support RRDP, users will still need to install 345 updated versions of these tools in their infrastructure. Any 346 Repository operator can measure this transition by observing access 347 to their RRDP and rsync repositories respectively. 349 But even after new versions have been available, it is expected that 350 there will be long, low volume, tail of users who did not upgrade and 351 still depend on rsync. 353 It is hard to quantify here now, what would be an acceptable moment 354 to conclude that it's safe to move to the next phase and make rsync 355 optional. A parallel to the so-called DNS Flag Day comes to mind. 357 4. Future Objective: Remove the dependency on rsync 359 Note that, while we discuss this here, we would probably do well to 360 separate this section into a separate follow-up document. 362 4.1. Phase 3 - RPKI repositories support RRDP, and optionally rsync 364 The end goal of this phase would be that there will be no operational 365 dependencies on rsync for Repositories, although they MAY still 366 choose to operate rsync at a best effort basis. 368 The most pragmatic way to deal with rsync URIs in the RPKI would be 369 to continue to use them as namespaces, but no longer require that 370 rsync is available. Much like how https based namespaces are used in 371 XML. 373 4.1.1. Updates to RFC 6481 375 From this phase onwards these updates are applied to section 3 of 376 [RFC6481] as it was updated during Phase 2 described above: 378 OLD: 380 o The publication repository MUST be available using the RPKI 381 Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be 382 hosted on a highly available platform. 384 o The publication repository MUST be available using rsync [RFC5781] 385 [RSYNC]. The rsync server SHOULD be hosted on a highly available 386 platform. 388 o Support of additional retrieval mechanisms is the choice of the 389 repository operator. The supported retrieval mechanisms MUST be 390 consistent with the accessMethod element value(s) specified in the 391 SIA of the associated CA or EE certificate. 393 NEW: 395 o The publication repository MUST be available using the RPKI 396 Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be 397 hosted on a highly available platform. 399 o The publication repository MAY be available using rsync [RFC5781] 400 [RSYNC]. 402 o Support of additional retrieval mechanisms is the choice of the 403 repository operator. The supported retrieval mechanisms MUST be 404 consistent with the accessMethod element value(s) specified in the 405 SIA of the associated CA or EE certificate. 407 Note that this means that RP software is still required to try to 408 fall back to rsync if RRDP is unavailable, but it may find that the 409 rsync repository is not available. 411 4.2. Transport agnostic RPKI object names 413 We could develop a new naming scheme for RPKI objects. Perhaps based 414 on Universal Resource Names ([RFC8141]). Doing so, would allow us to 415 use names which are independent from retrieval mechanisms, and thus 416 they could be less confusing in some regards, and provide more 417 agility with regards to future changes in those mechanisms. However, 418 this would require that many updates are made to existing RFCs. An 419 incomplete list: 421 o RFC6487 New names would have be allowed in the SIA, or perhaps an 422 X509 extension, could be used. But, the latter would have a 423 direct impact on the deployability of updated CA certificates - RP 424 software would reject these certificates if the extension is 425 marked as critical by the CA and not understood by the RP. 427 o RFC6492 New names (in whatever form) would need to be included 428 certificate sign requests sent to a parent CA. The parent CA will 429 need to include a 'cert_url', indicating where an issued 430 certificate is published, in a different format. 432 o RFC8181 The RPKI publication protocol is based rsync URIs, and it 433 assumes that publishers have access to a specific directory in 434 rsync space. This would need to be changed. 436 o RFC8183 This RFC defines the identity exchange between an RPKI CA 437 and Publication Server. The server's response includes an 438 'sia_base', in the form of an rsync directory, under which a CA is 439 supposed to name its objects. 441 o RFC8182 The RRDP protocol uses rsync URIs for compatibility with 442 rsync as a retrieval method. This would need to be updated. 444 Obviously this needs more discussion. 446 The exercise would not be trivial. But, arguably doing this work 447 will not become easier by postponing it, and once done would leave 448 the RPKI better positioned to use alternative access methods in 449 future as well. 451 5. Appendix - Implementation Status 453 Note that this section is included for tracking purposes during the 454 discussion phase of this document and is not intended to be included 455 in an RFC. 457 5.1. Current RRDP Support in Repository Software 459 The currently known support for RRDP for repositories is as follows: 461 +---------------------------+------------------+ 462 | Repository Implementation | Support for RRDP | 463 +---------------------------+------------------+ 464 | afrinic | yes | 465 | apnic | yes | 466 | arin | yes | 467 | lacnic | ongoing | 468 | ripe ncc | yes | 469 | Dragon Research Labs | yes(1,2) | 470 | krill | yes(1) | 471 +---------------------------+------------------+ 473 (1) in use at various National Internet Registries, as well as other 474 resource holders under RIRs. (2) not all organizations using this 475 software have upgraded to using RRDP. 477 5.2. Current RRDP Support in Relying Party software 479 The currently known support for RRDP in Relying Party software is as 480 follows: 482 +------------------------------+---------+---------+---------+ 483 | Relying Party Implementation | RRDP | version | since | 484 +------------------------------+---------+---------+---------+ 485 | FORT | yes | 1.2.0 | 02/2021 | 486 | OctoRPKI | yes | 1.0.0 | 02/2019 | 487 | rcynic | yes | ? | ? | 488 | RIPE NCC RPKI Validator 2.x | yes | 2.18 | 07/2015 | 489 | RIPE NCC RPKI Validator 3.x | yes | 3.0 | 03/2018 | 490 | Routinator | yes | 0.6.0 | 09/2019 | 491 | rpki-client | ongoing | ? | ? | 492 | RPSTIR2 | yes | 2.0 | 04/2020 | 493 +------------------------------+---------+---------+---------+ 495 The authors kindly request Relying Party software implementers to let 496 us know in which version of their tool support for RRDP was 497 introduced, and when that version was released. 499 6. IANA Considerations 501 This document has no IANA actions. 503 7. Security Considerations 505 TBD 507 8. Acknowledgements 509 TBD 511 9. References 513 9.1. Normative References 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 521 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 522 . 524 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 525 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 526 February 2012, . 528 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 529 Resource Certificate Repository Structure", RFC 6481, 530 DOI 10.17487/RFC6481, February 2012, 531 . 533 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 534 "Manifests for the Resource Public Key Infrastructure 535 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 536 . 538 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 539 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 540 May 2017, . 542 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 543 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 544 DOI 10.17487/RFC8182, July 2017, 545 . 547 9.2. Informative References 549 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 550 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 551 . 553 Authors' Addresses 555 Tim Bruijnzeels 556 NLnet Labs 558 Email: tim@nlnetlabs.nl 559 URI: https://www.nlnetlabs.nl/ 561 Randy Bush 562 Internet Initiative Japan & Arrcus, Inc. 564 Email: randy@psg.com 565 George Michaelson 566 APNIC 568 Email: ggm@apnic.net 569 URI: http://www.apnic.net