idnits 2.17.1 draft-sidrops-bruijnzeels-deprecate-rsync-01.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 (April 25, 2020) is 1456 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: 'RSYNC' is mentioned on line 332, 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) ** Downref: Normative reference to an Informational RFC: RFC 8488 Summary: 6 errors (**), 0 flaws (~~), 3 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: October 27, 2020 G. Michaelson 7 APNIC 8 April 25, 2020 10 Resource Public Key Infrastructure (RPKI) Repository Requirements 11 draft-sidrops-bruijnzeels-deprecate-rsync-01 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 In short this plan consists of the following phases. 22 In phase 0, today's deployment, RRDP is supported by most, but not 23 all Repositories, and most but not all RP software. 25 In the proposed phase 1 RRDP will become mandatory to implement for 26 Repositories, in addition to rsync. This phase can start as soon as 27 this document is published. 29 Once the proposed updates are implemented by all Repositories phase 2 30 will start. In this phase RRDP will become mandatory to implement 31 for all RP software, and rsync must no longer be used. 33 Measurements will need to be done to help determine when it will be 34 safe to transition to the final phase of this plan. During this 35 phase Repositories will no longer be required to provide rsync access 36 for RPKI validation purposes. However, they may still provide rsync 37 access for direct access to files for other purposes, if desired, at 38 a best effort basis. 40 Although this document currently includes descriptions and updates to 41 RFCs for each of these phases, we may find that it will be beneficial 42 to have separate documents for the plan, and each phase, so that it 43 might be more clear to all when the updates to RFCs take effect. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on October 27, 2020. 62 Copyright Notice 64 Copyright (c) 2020 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 80 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 81 3. Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3.1. Phase 0 - RPKI repositories support rsync, and optionally 83 RRDP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 3.2. Phase 1 - RPKI repositories support both rsync and RRDP . 4 85 3.2.1. Current Support for RRDP in Repository Software . . . 4 86 3.2.2. Updates to RFC 6481 . . . . . . . . . . . . . . . . . 5 87 3.2.3. Measurements . . . . . . . . . . . . . . . . . . . . 6 88 3.3. Phase 2 - All RP software prefers RRDP . . . . . . . . . 6 89 3.3.1. RRDP support in Relying Party software . . . . . . . 6 90 3.3.2. Updates to RFC 8182 . . . . . . . . . . . . . . . . . 6 91 3.3.3. Measurements . . . . . . . . . . . . . . . . . . . . 7 92 3.4. Phase 3 - RPKI repositories support RRDP, and optionally 93 rsync . . . . . . . . . . . . . . . . . . . . . . . . . . 7 94 3.4.1. Updates to RFC 6481 . . . . . . . . . . . . . . . . . 7 95 4. Rsync URIs as object identifiers . . . . . . . . . . . . . . 8 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 98 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 99 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 102 1. Requirements notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 2. Motivation 112 The Resource Public Key Infrastructure (RPKI) [RFC6480] as originally 113 defined uses rsync as its distribution protocol, as outlined in 114 [RFC6481]. Later, the RPKI Repository Delta Protocol (RRDP) 115 [RFC8182] was designed to provide an alternative. In order to 116 facilitate incremental deployment RRDP has been deployed as an 117 additional optional protocol, while rsync was still mandatory to 118 implement. 120 A number of issues observed with rsync motivated the design of RRDP, 121 e.g.: 123 o rsync is CPU and memory heavy, and easy to DoS 125 o rsync library support is lacking 127 o rsync makes it somewhat difficult to publish sets of object 128 atomically 130 RRDP was designed to leverage HTTPS CDN infrastructure to provide 131 RPKI Repository content in a resilient way, while reducing the load 132 on the Repository server. It supports that updates are published as 133 atomic deltas, which can help prevent most of the issues described in 134 section 6 of [RFC6486]. 136 For a longer discussion please see section 1 of [RFC8182]. 138 In conclusion: we believe that RRDP is the better solution. 139 Therefore, this document outlines a transition plan where RRDP 140 becomes mandatory to implement, and rsync becomes optional and 141 eventually deprecated. 143 3. Plan 145 Changing the RPKI infrastructure to rely on RRDP instead of rsync is 146 a delicate operation. There is current deployment of Certification 147 Authorities, Repository Servers and Relying Party software which 148 relies on rsync, and which may not yet support RRDP. 150 Therefore we need to have a plan that ultimately updates the relevant 151 RFCs, but which uses a phased approach combined with measurements to 152 limit the operational impact of doing this to (almost) zero. 154 The general outline of the plan is as follows. We will describe each 155 step in more detail below. 157 +-------+------------------------------------------------------+ 158 | Phase | Description | 159 +-------+------------------------------------------------------+ 160 | 0 | RPKI repositories support rsync, and optionally RRDP | 161 | 1 | RPKI repositories support both rsync and RRDP | 162 | 2 | All RP software prefers RRDP | 163 | 3 | RPKI repositories support RRDP, and optionally rsync | 164 +-------+------------------------------------------------------+ 166 3.1. Phase 0 - RPKI repositories support rsync, and optionally RRDP 168 This is the situation at the time of writing this document. Relying 169 Parties can prefer RRDP over rsync today, but they need to support 170 rsync until all RPKI repositories support RRDP. Therefore all 171 repositories should support RRDP at their earliest convenience. 173 3.2. Phase 1 - RPKI repositories support both rsync and RRDP 175 During this phase we will make RRDP mandatory to support for 176 Repository Servers, and measure whether the deployed Repository 177 Servers have been upgraded to do so, in as far as they don't support 178 RRDP already. 180 3.2.1. Current Support for RRDP in Repository Software 182 The currently known support for RRDP for repositories is as follows: 184 +---------------------------+------------------+ 185 | Repository Implementation | Support for RRDP | 186 +---------------------------+------------------+ 187 | afrinic | yes | 188 | apnic | yes | 189 | arin | yes | 190 | lacnic | planned | 191 | ripe ncc | yes | 192 | Dragon Research Labs | yes(1,2) | 193 | krill | yes(1) | 194 +---------------------------+------------------+ 196 (1) in use at various National Internet Registries, as well as other 197 resource holders under RIRs. (2) not all organizations using this 198 software have upgraded to using RRDP. 200 3.2.2. Updates to RFC 6481 202 During this phase the updates are applied to section 3 of [RFC6481]. 204 OLD: 206 o The publication repository SHOULD be hosted on a highly available 207 service and high-capacity publication platform. 209 o The publication repository MUST be available using rsync [RFC5781] 210 [RSYNC]. Support of additional retrieval mechanisms is the choice 211 of the repository operator. The supported retrieval mechanisms 212 MUST be consistent with the accessMethod element value(s) 213 specified in the SIA of the associated CA or EE certificate. 215 NEW: 217 o The publication repository MUST be available using the RPKI 218 Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be 219 hosted on a highly available platform. 221 o The publication repository MUST be available using rsync [RFC5781] 222 [RSYNC]. The rsync server SHOULD be hosted on a highly available 223 platform. 225 o Support of additional retrieval mechanisms is the choice of the 226 repository operator. The supported retrieval mechanisms MUST be 227 consistent with the accessMethod element value(s) specified in the 228 SIA of the associated CA or EE certificate. 230 3.2.3. Measurements 232 We can find out whether all RPKI repositories support RRDP by running 233 (possibly) modified Relying Party software that keeps track of this. 235 When it is found that Repositories do not yet support RRDP, outreach 236 should be done to them individually. Since the number of 237 Repositories is fairly low, and it is in their interest to run RRDP 238 because it addresses availability concerns, we have confidence that 239 we will find these Repositories willing to make changes. 241 3.3. Phase 2 - All RP software prefers RRDP 243 Once all Repositories support RRDP we can proceed to make RRDP 244 mandatory to implement for Relying Party software. 246 3.3.1. RRDP support in Relying Party software 248 The currently known support for RRDP in Relying Party software is as 249 follows: 251 +------------------------------+------+---------+----------+ 252 | Relying Party Implementation | RRDP | version | since | 253 +------------------------------+------+---------+----------+ 254 | FORT | yes | ? | ? | 255 | OctoRPKI | yes | ? | ? | 256 | rcynic | yes | ? | ? | 257 | RIPE NCC RPKI Validator 2.x | yes | ? | ? | 258 | RIPE NCC RPKI Validator 3.x | yes | ? | ? | 259 | Routinator | yes | 0.6.0 | Sep 2019 | 260 | rpki-client | no | ? | ? | 261 | RPSTIR | yes | ? | ? | 262 +------------------------------+------+---------+----------+ 264 The authors kindly request Relying Party software implementers to let 265 us know in which version of their tool support for RRDP was 266 introduced, and when that version was released. 268 3.3.2. Updates to RFC 8182 270 From this phase onwards the updates are applied to section 3.4.1 of 271 [RFC8182]. 273 OLD: When a Relying Party performs RPKI validation and learns about a 274 valid certificate with an SIA entry for the RRDP protocol, it SHOULD 275 use this protocol as follows. 277 NEW: When a Relying Party performs RPKI validation and learns about a 278 valid certificate with an SIA entry for the RRDP protocol, it MUST 279 use this protocol. It MUST NOT depend on object retrieval for this 280 certificate over rsync for validation, although it MAY still use 281 rsync access for other purposes under the understanding that 282 availability is not guaranteed. 284 3.3.3. Measurements 286 Although the tools may support RRDP, users will still need to install 287 updated versions of these tools in their infrastructure. Any 288 Repository operator can measure this transition by observing access 289 to their RRDP and rsync repositories respectively. 291 But even after new versions have been available, it is expected that 292 there will be long, low volume, tail of users who did not upgrade and 293 still depend on rsync. 295 It is hard to quantify here now, what would be an acceptable moment 296 to conclude that it's safe to move to the next phase and make rsync 297 optional. A parallel to the so-called DNS Flag Day comes to mind. 299 3.4. Phase 3 - RPKI repositories support RRDP, and optionally rsync 301 The end goal of this phase is that there will be no operational 302 dependencies on rsync for Repositories, although they MAY still 303 choose to operate rsync at a best effort basis. 305 3.4.1. Updates to RFC 6481 307 From this phase onwards these updates are applied to section 3 of 308 [RFC6481] as it was updated during Phase 2 described above: 310 OLD: 312 o The publication repository MUST be available using the RPKI 313 Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be 314 hosted on a highly available platform. 316 o The publication repository MUST be available using rsync [RFC5781] 317 [RSYNC]. The rsync server SHOULD be hosted on a highly available 318 platform. 320 o Support of additional retrieval mechanisms is the choice of the 321 repository operator. The supported retrieval mechanisms MUST be 322 consistent with the accessMethod element value(s) specified in the 323 SIA of the associated CA or EE certificate. 325 NEW: 327 o The publication repository MUST be available using the RPKI 328 Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be 329 hosted on a highly available platform. 331 o The publication repository MAY be available using rsync [RFC5781] 332 [RSYNC]. 334 o Support of additional retrieval mechanisms is the choice of the 335 repository operator. The supported retrieval mechanisms MUST be 336 consistent with the accessMethod element value(s) specified in the 337 SIA of the associated CA or EE certificate. 339 4. Rsync URIs as object identifiers 341 If and when RPKI Repositories no longer need to support rsync, this 342 begs the question whether rsync should still be used in URIs used in 343 RPKI objects. 345 [RFC6481] defines a profile for the Resource Certificate Repository 346 Structure. In this profile objects are identified through rsync 347 URIs. E.g. a CA certificate has an Subject Information Access 348 descriptor which uses an rsync URI to identify its manifest 349 [RFC6486]. The manifest enumerates the relative names and hashes for 350 all objects published under the private key of the CA certificate. 351 The full rsync URI identifiers for each object can be resolved 352 relative to the manifest URI. 354 Though it would be possible in principle to build up an RPKI tree 355 hierarchy of objects based on key identifiers and hashes [RFC8488], 356 most Relying Party implementations have found it very useful to use 357 rsync URIs for this purpose. Furthermore, these identifiers make it 358 much easier to name object in case of validation problems, which help 359 operators to address issues. 361 For these reasons, RRDP still includes rsync URIs in the definition 362 of the publish, update and withdraw elements in the snapshot and 363 delta files that it uses. See section 3.5 of [RFC8182]. Thus, 364 objects retrieved through RRDP can be mapped easily to files and 365 URIs, similar to as though rsync would have been used to retrieve 366 them. 368 Even though objects are no longer guaranteed to be available over 369 rsync, we still use rsync as the mandatory scheme in the CRL 370 Distribution Points, Authority Information Access, and Subject 371 Information Access defined in [RFC6487]. Changing this would 372 introduce breaking changes which make deployment very hard indeed: we 373 would need to invent an alternative naming scheme, which would need 374 to be supported by all Relying Parties, before Certification 375 Authorities can issue any certificate or RPKI signed objects using 376 these schemes. 378 Furthermore, it is very convenient to have direct access to RPKI 379 objects using rsync for troubleshooting, debugging and research 380 purposes. Therefore Repository operators MAY still choose to make an 381 rsync repository available for these purposes. 383 5. IANA Considerations 385 This document has no IANA actions. 387 6. Security Considerations 389 TBD 391 7. Acknowledgements 393 TBD 395 8. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, 399 DOI 10.17487/RFC2119, March 1997, 400 . 402 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 403 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 404 . 406 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 407 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 408 February 2012, . 410 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 411 Resource Certificate Repository Structure", RFC 6481, 412 DOI 10.17487/RFC6481, February 2012, 413 . 415 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 416 "Manifests for the Resource Public Key Infrastructure 417 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 418 . 420 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 421 X.509 PKIX Resource Certificates", RFC 6487, 422 DOI 10.17487/RFC6487, February 2012, 423 . 425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 427 May 2017, . 429 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 430 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 431 DOI 10.17487/RFC8182, July 2017, 432 . 434 [RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's 435 Implementation of Resource Public Key Infrastructure 436 (RPKI) Certificate Tree Validation", RFC 8488, 437 DOI 10.17487/RFC8488, December 2018, 438 . 440 Authors' Addresses 442 Tim Bruijnzeels 443 NLnet Labs 445 Email: tim@nlnetlabs.nl 446 URI: https://www.nlnetlabs.nl/ 448 Randy Bush 449 Internet Initiative Japan & Arrcus, Inc. 451 Email: randy@psg.com 453 George Michaelson 454 APNIC 456 Email: ggm@apnic.net 457 URI: http://www.apnic.net