idnits 2.17.1 draft-ietf-sidrops-prefer-rrdp-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 (22 October 2021) is 910 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 192, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6480 ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 4 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: 25 April 2022 G. Michaelson 7 APNIC 8 22 October 2021 10 Resource Public Key Infrastructure (RPKI) Repository Requirements 11 draft-ietf-sidrops-prefer-rrdp-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 preferred access protocol, and require rsync as a 19 fallback option only. 21 In phase 0, today's deployment, RRDP is supported by most, but not 22 all Repositories, and most but not all RP software. 24 In the proposed phase 1 RRDP will become mandatory to implement for 25 Repositories, in addition to rsync. This phase can start as soon as 26 this document is published. 28 Phase 2 will start once the proposed updates are implemented by all 29 compliant Repositories. In this phase RRDP will become mandatory to 30 implement for all compliant RP software, and rsync will be required 31 as a fallback option only. 33 It should be noted that although this document currently includes 34 descriptions and updates to RFCs for each of these phases, we may 35 find that it will be beneficial to have one or more separate 36 documents for these phases, so that it might be more clear to all 37 when the updates to RFCs take effect. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 25 April 2022. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 73 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Plan to prefer RRDP . . . . . . . . . . . . . . . . . . . . . 3 75 3.1. Phase 0 - RPKI repositories support rsync, and optionally 76 RRDP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.1.1. Updates to RFC 8182 . . . . . . . . . . . . . . . . . 4 78 3.1.2. Updates to RFC 6481 . . . . . . . . . . . . . . . . . 5 79 3.2. Phase 1 - RPKI repositories support both rsync and 80 RRDP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3.2.1. Updates to RFC 6481 . . . . . . . . . . . . . . . . . 5 82 3.2.2. Measurements . . . . . . . . . . . . . . . . . . . . 5 83 3.3. Phase 2 - All RP software prefers RRDP . . . . . . . . . 6 84 3.3.1. Updates to RFC 8182 . . . . . . . . . . . . . . . . . 6 85 3.3.2. Measurements . . . . . . . . . . . . . . . . . . . . 6 86 4. Appendix - Implementation Status . . . . . . . . . . . . . . 6 87 4.1. Current RRDP Support in Repository Software . . . . . . . 7 88 4.2. Current RRDP Support in Relying Party software . . . . . 7 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 92 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 95 1. Requirements notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Motivation 105 The Resource Public Key Infrastructure (RPKI) [RFC6480] as originally 106 defined uses rsync as its distribution protocol, as outlined in 107 [RFC6481]. Later, the RPKI Repository Delta Protocol (RRDP) 108 [RFC8182] was designed to provide an alternative. In order to 109 facilitate incremental deployment RRDP has been deployed as an 110 additional optional protocol, while rsync was still mandatory to 111 implement. 113 While rsync has been very useful in the initial deployment of RPKI, a 114 number of issues observed with it motivated the design of RRDP, e.g.: 116 * rsync is CPU and memory heavy on the server side, and easy to DoS 118 * rsync library support is lacking, complicating RP efficiency and 119 error logging 121 RRDP was designed to leverage HTTPS CDN infrastructure to provide 122 RPKI Repository content in a resilient way, while reducing the load 123 on the Repository server. It supports updates being published as 124 atomic deltas, which can help prevent most of the issues described in 125 section 6 of [RFC6486]. 127 For a longer discussion please see section 1 of [RFC8182]. 129 In conclusion: we believe that while RRDP is not perfect, and we may 130 indeed need future work to improve it, it is an improvement over 131 using rsync in the context of RPKI. Therefore, this document 132 outlines a transition plan where RRDP becomes mandatory to implement, 133 and the operational dependency on rsync is reduced to that of a 134 fallback option. 136 3. Plan to prefer RRDP 138 Changing the RPKI infrastructure to rely on RRDP instead of rsync is 139 a delicate operation. There is current deployment of Certification 140 Authorities, Repository Servers and Relying Party software which 141 relies on rsync, and which may not yet support RRDP. 143 Therefore we need to have a plan that ultimately updates the relevant 144 RFCs, but which uses a phased approach combined with measurements to 145 limit the operational impact of doing this to (almost) zero. 147 The general outline of the plan is as follows. We will describe each 148 step in more detail below. 150 +=======+======================================================+ 151 | Phase | Description | 152 +=======+======================================================+ 153 | 0 | RPKI repositories support rsync, and optionally RRDP | 154 +-------+------------------------------------------------------+ 155 | 1 | RPKI repositories support both rsync and RRDP | 156 +-------+------------------------------------------------------+ 157 | 2 | All RP software prefers RRDP | 158 +-------+------------------------------------------------------+ 160 Table 1 162 3.1. Phase 0 - RPKI repositories support rsync, and optionally RRDP 164 This is the situation at the time of writing this document. Relying 165 Parties can prefer RRDP over rsync today. Therefore all repositories 166 should support RRDP at their earliest convenience. 168 3.1.1. Updates to RFC 8182 170 Section 3.4.5 of [RFC8182] has the following on "Considerations 171 Regarding Operational Failures in RRDP": 173 Relying Parties could attempt to use alternative repository access 174 mechanisms, if they are available, according to the accessMethod 175 element value(s) specified in the SIA of the associated certificate 176 (see Section 4.8.8 of [RFC6487]). 178 The use of the lower case 'could' in this sentence has led some older 179 versions of RP implementations to conclude that any fallback from 180 RRDP to rsync as an alternative access mechanism is a local choice. 181 However, following discussions on this subject it has become clear 182 that there is a preference to instruct RP software to make use of all 183 possible data sources. The main motivation being that because of 184 RPKI object security using a secondary source of data can never lead 185 to a worse outcome in terms of validation. 187 Per this document text mentioned above is replaced by the following: 189 Relying Parties MUST attempt to use alternative repository access 190 mechanisms, if they are available, according to the accessMethod 191 element value(s) specified in the SIA of the associated certificate 192 (see Section 4.8.8 of [RFC6487]). 194 Note that there is a risk that the rsync repository, as the 195 alternative access mechanism, becomes overloaded in case all Relying 196 Parties fall back to it at roughly the same time due to an issue with 197 RRDP. Therefore it is RECOMMENDED that Relying Parties use a retry 198 strategy and/or random jitter time before falling back to rsync. 199 But, the fallback to rsync MUST NOT be postponed for more than 1 200 hour. 202 3.1.2. Updates to RFC 6481 204 Section 3.3 of [RFC8182] stipulates that RRDP files MUST be made 205 available by repositories which support RRDP. In other words 206 [RFC8182] expects that RRDP repository availability is treated as a 207 critical service wherever it is supported. 209 Per this document the following bullet point is added to the 210 considerations listed in in section 3 of [RFC6481]: 212 * The publication repository MAY be available using the RPKI 213 Repository Delta Protocol [RFC8182]. If RPDP is provided, it 214 SHOULD be hosted on a highly available platform. 216 3.2. Phase 1 - RPKI repositories support both rsync and RRDP 218 During this phase we will make RRDP mandatory to support for 219 Repository Servers, and measure whether the deployed Repository 220 Servers have been upgraded to do so, in as far as they don't support 221 RRDP already. 223 3.2.1. Updates to RFC 6481 225 In this phase the bullet point update to section 3 of [RFC6481] 226 mentioned above, where it was said the publication repository MAY be 227 available using the RPKI Repository Delta Protocol is replaced by: 229 * The publication repository MUST be available using the RPKI 230 Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be 231 hosted on a highly available platform. 233 3.2.2. Measurements 235 We can find out whether all RPKI repositories support RRDP by running 236 (possibly) modified Relying Party software that keeps track of this. 238 When it is found that Repositories do not yet support RRDP, outreach 239 should be done to them individually. Since the number of 240 Repositories is fairly low, and it is in their interest to run RRDP 241 because it addresses availability concerns, we have confidence that 242 we will find these Repositories willing to make changes. 244 3.3. Phase 2 - All RP software prefers RRDP 246 Once all Repositories support RRDP we can proceed to make RRDP 247 mandatory to implement for Relying Party software. But note that RP 248 software is not prohibited from implementing this support sooner. At 249 the time of this writing all known RP software supports RRDP, 250 although it is not known to the authors whether all of them have RRDP 251 enabled and use it as the preferred protocol. 253 3.3.1. Updates to RFC 8182 255 From this phase onwards the first paragraph of section 3.4.1 of 256 [RFC8182] is replaced by the following: 258 When a Relying Party performs RPKI validation and learns about a 259 valid certificate with an SIA entry for the RRDP protocol, it MUST 260 use this protocol with preference. 262 Relying Parties MUST NOT attempt to fetch objects using alternate 263 access mechanisms, if object retrieval through this protocol is 264 successful. 266 However, as stipulated in section 3.4.5, Relying Parties MUST attempt 267 to use alternative repository access mechanisms, if object retrieval 268 through RRDP is unsuccessful. 270 3.3.2. Measurements 272 Although the tools may support RRDP, users will still need to install 273 updated versions of these tools in their infrastructure. Any 274 Repository operator can measure this transition by observing access 275 to their RRDP and rsync repositories respectively. 277 But even after new versions have been available, it is expected that 278 there will be a long, low volume, tail of users who did not upgrade 279 and still depend on rsync. 281 4. Appendix - Implementation Status 283 Note that this section is included for tracking purposes during the 284 discussion phase of this document and is not intended to be included 285 in an RFC. 287 4.1. Current RRDP Support in Repository Software 289 The currently known support for RRDP for repositories is as follows: 291 +===========================+==================+ 292 | Repository Implementation | Support for RRDP | 293 +===========================+==================+ 294 | afrinic | yes | 295 +---------------------------+------------------+ 296 | apnic | yes | 297 +---------------------------+------------------+ 298 | arin | yes | 299 +---------------------------+------------------+ 300 | lacnic | ongoing | 301 +---------------------------+------------------+ 302 | ripe ncc | yes | 303 +---------------------------+------------------+ 304 | Dragon Research Labs | yes(1,2) | 305 +---------------------------+------------------+ 306 | krill | yes(1) | 307 +---------------------------+------------------+ 309 Table 2 311 (1) in use at various National Internet Registries, as well as other 312 resource holders under RIRs. (2) not all organizations using this 313 software have upgraded to using RRDP. 315 4.2. Current RRDP Support in Relying Party software 317 All current versions of known Relying Party software support RRDP: 319 +==============================+=========+=========+=========+ 320 | Relying Party Implementation | support | version | since | 321 +==============================+=========+=========+=========+ 322 | DRL | yes | ? | ? | 323 +------------------------------+---------+---------+---------+ 324 | FORT | yes | 1.2.0 | 02/2021 | 325 +------------------------------+---------+---------+---------+ 326 | OctoRPKI | yes | 1.0.0 | 02/2019 | 327 +------------------------------+---------+---------+---------+ 328 | Routinator | yes | 0.6.0 | 09/2019 | 329 +------------------------------+---------+---------+---------+ 330 | rpki-client | yes | 0.7.0 | 04/2021 | 331 +------------------------------+---------+---------+---------+ 332 | RPSTIR2 | yes | 2.0 | 04/2020 | 333 +------------------------------+---------+---------+---------+ 335 Table 3 337 But, support for RRDP does not necessarily mean that it is also 338 enabled and preferred over rsync by default. The authors kindly 339 request that RP implementors provide the following information: 341 +==============================+========+=========+=========+ 342 | Relying Party Implementation | prefer | version | since | 343 +==============================+========+=========+=========+ 344 | DRL | ? | ? | ? | 345 +------------------------------+--------+---------+---------+ 346 | FORT | yes | ? | ? | 347 +------------------------------+--------+---------+---------+ 348 | OctoRPKI | ? | ? | ? | 349 +------------------------------+--------+---------+---------+ 350 | Routinator | yes | 0.6.0 | 09/2019 | 351 +------------------------------+--------+---------+---------+ 352 | rpki-client | ? | ? | ? | 353 +------------------------------+--------+---------+---------+ 354 | RPSTIR2 | ? | ? | ? | 355 +------------------------------+--------+---------+---------+ 357 Table 4 359 5. IANA Considerations 361 This document has no IANA actions. 363 6. Security Considerations 365 TBD 367 7. Acknowledgements 369 TBD 371 8. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 379 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 380 February 2012, . 382 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 383 Resource Certificate Repository Structure", RFC 6481, 384 DOI 10.17487/RFC6481, February 2012, 385 . 387 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 388 "Manifests for the Resource Public Key Infrastructure 389 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 390 . 392 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 393 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 394 May 2017, . 396 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 397 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 398 DOI 10.17487/RFC8182, July 2017, 399 . 401 Authors' Addresses 403 Tim Bruijnzeels 404 NLnet Labs 406 Email: tim@nlnetlabs.nl 407 URI: https://www.nlnetlabs.nl/ 409 Randy Bush 410 Internet Initiative Japan & Arrcus, Inc. 412 Email: randy@psg.com 413 George Michaelson 414 APNIC 416 Email: ggm@apnic.net 417 URI: http://www.apnic.net