idnits 2.17.00 (12 Aug 2021) /tmp/idnits5750/draft-ietf-sidr-iana-objects-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 16, 2011) is 4111 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) == Outdated reference: draft-ietf-sidr-arch has been published as RFC 6480 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: draft-ietf-sidr-cp has been published as RFC 6484 == Outdated reference: draft-ietf-sidr-ghostbusters has been published as RFC 6493 == Outdated reference: draft-ietf-sidr-res-certs has been published as RFC 6487 == Outdated reference: draft-ietf-sidr-roa-format has been published as RFC 6482 == Outdated reference: draft-ietf-sidr-roa-validation has been published as RFC 6483 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-roa-validation (ref. 'I-D.ietf-sidr-roa-validation') == Outdated reference: draft-ietf-sidr-rpki-manifests has been published as RFC 6486 ** Downref: Normative reference to an Informational RFC: RFC 2860 ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) ** Downref: Normative reference to an Informational RFC: RFC 3849 ** Downref: Normative reference to an Informational RFC: RFC 5180 ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) ** Obsolete normative reference: RFC 5736 (Obsoleted by RFC 6890) == Outdated reference: A later version (-08) exists of draft-ietf-sidr-ltamgmt-00 == Outdated reference: draft-ietf-sidr-usecases has been published as RFC 6907 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Manderson 3 Internet-Draft L. Vegoda 4 Intended status: Standards Track ICANN 5 Expires: August 20, 2011 S. Kent 6 BBN 7 February 16, 2011 9 RPKI Objects issued by IANA 10 draft-ietf-sidr-iana-objects-01.txt 12 Abstract 14 This document provides specific direction to IANA as to the Resource 15 Public Key Infrastructure (RPKI) objects it should issue. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 20, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Reserved Resources . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Unallocated Resources . . . . . . . . . . . . . . . . . . . . 8 57 7. Special Purpose Registry Resources . . . . . . . . . . . . . . 9 58 8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 9. Informational Objects . . . . . . . . . . . . . . . . . . . . 11 60 10. Certificates and CRLs . . . . . . . . . . . . . . . . . . . . 12 61 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 64 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 66 14.2. Informative References . . . . . . . . . . . . . . . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 69 1. Requirements Notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Introduction 77 An Infrastructure to Support Secure Internet Routing 78 [I-D.ietf-sidr-arch] directs IANA [RFC2860] to issue Resource Public 79 Key Infrastructure (RPKI) objects for which it is authoritative. 80 This document describes the objects IANA will issue. 82 The signed objects described here that IANA will issue are the 83 unallocated, reserved, special use IPv4 and IPv6 address blocks, and 84 reserved Autonomous System numbers. These number resources are 85 managed by IANA for the IETF, and thus IANA bears the responsibility 86 of issuing the corresponding RPKI objects. The reader is encouraged 87 to consider the technical effects on the public routing system of the 88 signed object issuance proposed for IANA in this document. 90 This document does not deal with localized BGP [RFC4271] routing 91 systems as those are under the policy controls of the organizations 92 that operate them. Readers are directed to Local Trust Anchor 93 Management for the Resource Public Key Infrastructure 94 [I-D.ietf-sidr-ltamgmt] for a description of how to locally override 95 IANA issued objects, e.g. to enable use of unallocated, reserved, and 96 special use IPv4 and IPv6 address blocks in a local context. 98 The direction to IANA contained herein follows the ideal that it 99 should represent the perfect technical behavior in registry, and 100 related registry, actions. 102 3. Suggested Reading 104 Readers should be familiar with the RPKI, the RPKI Repository 105 Structure, and the various RPKI objects, uses and interpretations 106 described in the following: [I-D.ietf-sidr-arch], 107 [I-D.ietf-sidr-res-certs], [I-D.ietf-sidr-roa-format], 108 [I-D.ietf-sidr-ghostbusters], [I-D.ietf-sidr-ltamgmt], 109 [I-D.ietf-sidr-roa-validation], [I-D.ietf-sidr-usecases], 110 [I-D.ietf-sidr-cp], and [I-D.ietf-sidr-rpki-manifests]. 112 NOTE: The addresses used in this document are not example addresses 113 therefore they are not compliant with [RFC3849], [RFC5735], and 114 [RFC5771]. This is intentional as the practices described in this 115 document affect real world addresses. 117 4. Definitions 119 Internet Number Resources (INR): The number identifiers for IPv4 120 [RFC0791] and IPv6 [RFC2460] addresses, and for Autonomous Systems. 122 IANA: Internet Assigned Numbers Authority (a traditional name, used 123 here to refer to the technical team making and publishing the 124 assignments of Internet protocol technical parameters). The 125 technical team of IANA is currently a part of ICANN [RFC2860]. 127 RPKI: Resource Public Key Infrastructure. A Public Key 128 Infrastructure designed to provide a secure basis for assertions 129 about holdings of Internet numeric resources. Certificates issued 130 under the RPKI contain additional attributes that identify IPv4, 131 IPv6, and Autonomous System Number (ASN) resources. 133 ROA: Route Origination Authorization. A ROA is an RPKI object that 134 enables the holder of the address prefix to specify an AS that is 135 permitted to originate (in BGP) routes for that prefix. 137 AS0 ROA: Validation of Route Origination using the Resource 138 Certificate PKI and ROAs [I-D.ietf-sidr-roa-validation] states "A ROA 139 with a subject of AS0 (AS0-ROA) is an attestation by the holder of a 140 prefix that the prefix described in the ROA, and any more specific 141 prefix, should not be used in a routing context." 143 "Not intended to be (publicly) routed": This phrase refers to 144 prefixes that are not meant to be represented in the global Internet 145 routing table (for example 192.168/16, [RFC1918]). 147 5. Reserved Resources 149 Reserved IPv4 and IPv6 resources are held back for various reasons by 150 IETF action. Generally such resources are not intended to be 151 globally routed. An example of such a reservation is 127.0.0.0/8 152 [RFC5735]. 154 IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources 155 not intended to be routed. 157 There are a small number of reserved resources which are intended to 158 be routed, for example 192.88.99.0/24 [RFC3068]. 160 IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved 161 resources that are expected to be globally routed. 163 6. Unallocated Resources 165 Internet Number Resources that have not yet been allocated for 166 special purposes [RFC5736], to Regional Internet Registries (RIRs), 167 or to others are considered as not intended to be globally routed. 169 IANA MUST issue an AS0 ROA for all Unallocated Resources. 171 7. Special Purpose Registry Resources 173 Special Registry Resources [RFC5736] fall into one of two categories 174 in terms of routing. Either the resource is intended to be seen in 175 the global Internet routing table in some fashion, or it isn't. An 176 example of a special purpose registry INR that is intended for global 177 routing is 2001:0000::/32 [RFC4380]. An example of an INR not 178 intended to be seen would be 2001:002::/48 [RFC5180]. 180 IANA MUST NOT issue any ROAs (AS0 or otherwise) for Special Purpose 181 Registry Resources that are intended to be globally routed. 183 IANA MUST issue an AS0 ROA for Special Purpose Registry Resources 184 that are not intended to be globally routed. 186 8. Multicast 188 Within the IPv4 Multicast [RFC5771] and IPv6 Multicast [RFC4291] 189 registries there are a number of Multicast registrations that are not 190 intended to be globally routed. 192 IANA MUST issue an AS0 ROA covering the following IPv4 and IPv6 193 multicast INRs: 195 IPv4: 196 - Local Network Control Block 197 224.0.0.0 - 224.0.0.255 (224.0.0/24) 198 - IANA Reserved portions of RESERVED 199 224.1.0.0-224.1.255.255 (224.1/16) 200 - RESERVED 201 224.5.0.0-224.251.255.255 (251 /16s) 202 225.0.0.0-231.255.255.255 (7 /8s) 204 IPv6: 205 - Node-Local Scope Multicast Addresses 206 - Link-Local Scope Multicast Addresses 208 IANA MUST NOT issue any ROAs (AS0 or otherwise) for any other 209 multicast addresses unless directed. 211 9. Informational Objects 213 One informational object that can exist at a publication point of an 214 RPKI repository is the Ghostbusters Record 215 [I-D.ietf-sidr-ghostbusters]. 217 IANA MUST issue a ghostbusters object appropriate in content for the 218 resources IANA maintains. 220 10. Certificates and CRLs 222 Before IANA can issue a ROA it MUST first establish a RPKI 223 Certificate Authority (CA) that covers unallocated, reserved, and 224 special use INRs by containing RFC 3379 extensions [RFC3779] for 225 those corresponding number resources in the CA Certificate. This CA 226 MUST issue single use End Entity (EE) certificates for each ROA. The 227 EE certificate will conform to the Resource Certificate Profile 228 [I-D.ietf-sidr-res-certs] and the additional constraints specified in 229 [I-D.ietf-sidr-roa-format]. IANA MUST maintain a publication point 230 for this CA's use and publish manifests 231 [I-D.ietf-sidr-rpki-manifests] (with its corresponding EE 232 certificate). A Certificate Revocation List (CRL) will be issued 233 under this CA certificate. All objects issued by this CA will 234 conform to a published Certificate Policy [I-D.ietf-sidr-cp]. 236 11. IANA Considerations 238 This document directs IANA to issue, or refrain from issuing, the 239 specific objects described here for the current set of reserved, 240 unallocated, and special registry Internet Number Resources. Further 241 it MUST notify all other INR registries that RPKI objects have been 242 issued for specific Internet Number Resources to avoid duplicates 243 being issued thus reducing the burden on any relying party. 245 12. Security Considerations 247 This document does not alter the security profile of the RPKI from 248 that already discussed in SIDR-WG documents. 250 13. Acknowledgements 252 The authors acknowledge Dave Meyer for helpful direction with regard 253 to multicast assignments. 255 14. References 257 14.1. Normative References 259 [I-D.ietf-sidr-arch] 260 Lepinski, M. and S. Kent, "An Infrastructure to Support 261 Secure Internet Routing", draft-ietf-sidr-arch-11 (work in 262 progress), September 2010. 264 [I-D.ietf-sidr-cp] 265 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 266 Policy (CP) for the Resource PKI (RPKI", 267 draft-ietf-sidr-cp-16 (work in progress), December 2010. 269 [I-D.ietf-sidr-ghostbusters] 270 Bush, R., "The RPKI Ghostbusters Record", 271 draft-ietf-sidr-ghostbusters-00 (work in progress), 272 December 2010. 274 [I-D.ietf-sidr-res-certs] 275 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 276 X.509 PKIX Resource Certificates", 277 draft-ietf-sidr-res-certs-21 (work in progress), 278 December 2010. 280 [I-D.ietf-sidr-roa-format] 281 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 282 Origin Authorizations (ROAs)", 283 draft-ietf-sidr-roa-format-09 (work in progress), 284 November 2010. 286 [I-D.ietf-sidr-roa-validation] 287 Huston, G. and G. Michaelson, "Validation of Route 288 Origination using the Resource Certificate PKI and ROAs", 289 draft-ietf-sidr-roa-validation-10 (work in progress), 290 November 2010. 292 [I-D.ietf-sidr-rpki-manifests] 293 Austein, R., Huston, G., Kent, S., and M. Lepinski, 294 "Manifests for the Resource Public Key Infrastructure", 295 draft-ietf-sidr-rpki-manifests-09 (work in progress), 296 November 2010. 298 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 299 E. Lear, "Address Allocation for Private Internets", 300 BCP 5, RFC 1918, February 1996. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 306 Understanding Concerning the Technical Work of the 307 Internet Assigned Numbers Authority", RFC 2860, June 2000. 309 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 310 RFC 3068, June 2001. 312 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 313 Addresses and AS Identifiers", RFC 3779, June 2004. 315 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 316 Reserved for Documentation", RFC 3849, July 2004. 318 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 319 Protocol 4 (BGP-4)", RFC 4271, January 2006. 321 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 322 Architecture", RFC 4291, February 2006. 324 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 325 Network Address Translations (NATs)", RFC 4380, 326 February 2006. 328 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 329 Dugatkin, "IPv6 Benchmarking Methodology for Network 330 Interconnect Devices", RFC 5180, May 2008. 332 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 333 BCP 153, RFC 5735, January 2010. 335 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 336 Purpose Address Registry", RFC 5736, January 2010. 338 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 339 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 340 March 2010. 342 14.2. Informative References 344 [I-D.ietf-sidr-ltamgmt] 345 Kent, S. and M. Reynolds, "Local Trust Anchor Management 346 for the Resource Public Key Infrastructure", 347 draft-ietf-sidr-ltamgmt-00 (work in progress), 348 November 2010. 350 [I-D.ietf-sidr-usecases] 351 Manderson, T., Sriram, K., and R. White, "Use Cases and 352 interpretation of RPKI objects for issuers and relying 353 parties", draft-ietf-sidr-usecases-01 (work in progress), 354 December 2010. 356 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 357 September 1981. 359 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 360 (IPv6) Specification", RFC 2460, December 1998. 362 Authors' Addresses 364 Terry Manderson 365 ICANN 367 Email: terry.manderson@icann.org 369 Leo Vegoda 370 ICANN 372 Email: leo.vegoda@icann.org 374 Steve Kent 375 BBN 377 Email: kent@bbn.com