idnits 2.17.1 draft-sidrops-bruijnzeels-deprecate-rsync-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 ([RFC6481], [RFC6487], [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 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 -- The document date (November 4, 2019) is 1635 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 143, 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 (~~), 2 warnings (==), 2 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 (if approved) November 4, 2019 5 Intended status: Standards Track 6 Expires: May 7, 2020 8 Resource Public Key Infrastructure (RPKI) Repository Requirements 9 draft-sidrops-bruijnzeels-deprecate-rsync-00 11 Abstract 13 This document updates the profile for the structure of the Resource 14 Public Key Infrastructure (RPKI) distributed repository [RFC6481] by 15 describing how the RPKI Repository Delta Protocol (RRDP) [RFC8182] 16 can be used, and stipulating that repositories which are made 17 available over RRDP are no longer required to be available over 18 rsync. 20 The Profile for X.509 PKIX Resource Certificates [RFC6487] uses rsync 21 URIs in the Authority Information Access, Subject Information Access, 22 and CRL Distribution Points extensions. This document leaves this 23 unchanged, meaning that rsync URIs are still used for naming and 24 finding objects in the RPKI. However, it is no longer guaranteed 25 that objects can be retrieved using these URIs. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 7, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 62 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. Rsync URIs as object identifiers . . . . . . . . . . . . . . 3 64 4. Updates to RFC6481 . . . . . . . . . . . . . . . . . . . . . 3 65 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 66 5.1. RRDP support in RPKI Repositories . . . . . . . . . . . . 4 67 5.2. RRDP support in Relying Party software . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 71 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in BCP 79 14 [RFC2119] [RFC8174] when, and only when, they appear in all 80 capitals, as shown here. 82 2. Motivation 84 The Resource Public Key Infrastructure (RPKI) [RFC6480] as originally 85 defined uses rsync as its distribution protocol, as outlined in 86 [RFC6481]. Later, the RPKI Repository Delta Protocol (RRDP) 87 [RFC8182] was designed to provide an alternative. In order to 88 facilitate incremental deployment RRDP has been deployed as an 89 additional optional protocol, while rsync was still mandatory to 90 implement. 92 RPKI Repository operators are still required to provide 24/7 up-time 93 to their rsync infrastructure, as long as the requirement to support 94 rsync stands. Thus, the benefit that they get from supporting RRDP, 95 which enables the use of content delivery networks (CDNs) for this 96 purpose, is limited. 98 And as long as not all RPKI Repositories support RRDP, Relying Party 99 software is still required to support rsync. Because there is a lack 100 of rsync client libraries, this is typically implemented by calling a 101 system installed rsync binary. This is inefficient, and has issues 102 with regards to versioning of the rsync binary, as well as reporting 103 errors reliably. 105 This document requires that all RPKI repositories and all Relying 106 Parties support RRDP. It also stipulates that these parties are no 107 longer required to support rsync. This way all parties are freed of 108 direct operational dependencies on rsync. 110 3. Rsync URIs as object identifiers 112 [RFC6481] defines a profile for the Resource Certificate Repository 113 Structure. In this profile objects are identified through rsync 114 URIs. E.g. a CA certificate has an Subject Information Access 115 descriptor which uses an rsync URI to identify its manifest 116 [RFC6486]. The manifest enumerates the relative names and hashes, 117 for all objects published under the private key of the CA 118 certificate. This the full rsync URI identifiers for each object can 119 be resolved relative to the manifest URI. 121 Though it would be possible in principle to build up an RPKI tree 122 hierarchy of objects based on key identifiers and hashes [RFC8488], 123 most Relying Party implementations have found it very useful to use 124 rsync URIs for this purpose. Furthermore, these identifiers make it 125 much easier to name object in case of validation problems, which help 126 operators to address issues. 128 For these reasons, RRDP still includes rsync URIs in the definition 129 of the publish, update and withdraw elements in the snapshot and 130 delta files that it uses. See section 3.5 of [RFC8182]. Thus, 131 objects retrieved through RRDP can be mapped easily to files and 132 URIs, similar to as though rsync would have been used to retrieve 133 them. 135 4. Updates to RFC6481 137 OLD: 139 o The publication repository SHOULD be hosted on a highly available 140 service and high-capacity publication platform. 142 o The publication repository MUST be available using rsync [RFC5781] 143 [RSYNC]. Support of additional retrieval mechanisms is the choice 144 of the repository operator. The supported retrieval mechanisms 145 MUST be consistent with the accessMethod element value(s) 146 specified in the SIA of the associated CA or EE certificate. 148 NEW: 150 o The publication repository MUST be available using the RPKI 151 Repository Delta Protocol [RFC8182]. The RRDP server SHOULD be 152 hosted on a highly available platform. 154 o The publication repository MAY be available using rsync [RFC5781]. 156 o Support of additional retrieval mechanisms is the choice of the 157 repository operator. The supported retrieval mechanisms MUST be 158 consistent with the accessMethod element value(s) specified in the 159 SIA of the associated CA or EE certificate. 161 5. Deployment Considerations 163 Relying Parties can drop support for rsync only when all RPKI 164 repositories support RRDP. 166 RPKI repositories can drop support for rsync only when Relying 167 Parties support RRDP. Even when all actively maintained RP software 168 packages support RRDP, there will still be old versions of the 169 software in operational use. It is most likely impossible to find 170 that all deployed software supports RRDP, but since RRDP SHOULD be 171 used when it is available [section 3.4.1 of @!RFC8182] it will be 172 possible to measure adoption. 174 5.1. RRDP support in RPKI Repositories 176 [This section can be updated during discussion of this document, and 177 may be removed before possible publication.] 179 +---------------------------+-------------------+ 180 | Repository Implementation | Support for RRDP | 181 +---------------------------+-------------------+ 182 | afrinic | planned | 183 | apnic | yes | 184 | arin | under development | 185 | lacnic | planned | 186 | ripe ncc | yes | 187 | rpki.net | yes(1) | 188 | krill | yes(2) | 189 +---------------------------+-------------------+ 191 (1) in use at various National Internet Registries, as well as other 192 resource holders under RIRs. (2) Software under development. 194 5.2. RRDP support in Relying Party software 196 [This section can be updated during discussion of this document, and 197 may be removed before possible publication.] 199 +------------------------------+------------------+ 200 | Relying Party Implementation | Support for RRDP | 201 +------------------------------+------------------+ 202 | FORT | no | 203 | OctoRPKI | yes | 204 | rcynic | yes | 205 | RIPE NCC RPKI Validator 2.x | yes | 206 | RIPE NCC RPKI Validator 3.x | yes | 207 | Routinator | yes | 208 | rpki-client | no | 209 | RPSTIR | yes | 210 +------------------------------+------------------+ 212 6. IANA Considerations 214 This document has no IANA actions. 216 7. Security Considerations 218 TBD 220 8. Acknowledgements 222 TBD 224 9. Normative References 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, 228 DOI 10.17487/RFC2119, March 1997, 229 . 231 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 232 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 233 . 235 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 236 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 237 February 2012, . 239 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 240 Resource Certificate Repository Structure", RFC 6481, 241 DOI 10.17487/RFC6481, February 2012, 242 . 244 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 245 "Manifests for the Resource Public Key Infrastructure 246 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 247 . 249 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 250 X.509 PKIX Resource Certificates", RFC 6487, 251 DOI 10.17487/RFC6487, February 2012, 252 . 254 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 255 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 256 May 2017, . 258 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 259 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 260 DOI 10.17487/RFC8182, July 2017, 261 . 263 [RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's 264 Implementation of Resource Public Key Infrastructure 265 (RPKI) Certificate Tree Validation", RFC 8488, 266 DOI 10.17487/RFC8488, December 2018, 267 . 269 Author's Address 271 Tim Bruijnzeels 272 NLnet Labs 274 Email: tim@nlnetlabs.nl 275 URI: https://www.nlnetlabs.nl/