idnits 2.17.1 draft-dseomn-sidr-slurm-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2014) is 3556 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6890' is defined on line 277, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-08 == Outdated reference: A later version (-07) exists of draft-ietf-sidr-lta-use-cases-01 == Outdated reference: A later version (-04) exists of draft-kent-sidr-suspenders-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing D. Mandelberg 3 Internet-Draft BBN Technologies 4 Intended status: Best Current Practice July 3, 2014 5 Expires: January 4, 2015 7 Simplified Local internet nUmber Resource Management with the RPKI 8 draft-dseomn-sidr-slurm-01 10 Abstract 12 The Resource Public Key Infrastructure (RPKI) is a global 13 authorization infrastructure that allows the holder of Internet 14 Number Resources (INRs) to make verifiable statements about those 15 resources. Internet Service Providers (ISPs) can use the RPKI to 16 validate BGP route origination assertions. Some ISPs locally use BGP 17 with private address space or private AS numbers (see RFC6890). 18 These local BGP routes cannot be verified by the global RPKI, and 19 SHOULD be considered invalid based on the global RPKI (see RFC6491). 20 The mechanisms described below provide ISPs with a way to make local 21 assertions about private (reserved) INRs while using the RPKI's 22 assertions about all other INRs. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Validation Output Filtering . . . . . . . . . . . . . . . . . 3 61 3. Locally Adding Assertions . . . . . . . . . . . . . . . . . . 4 62 4. Configuring SLURM . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Combining Mechanisms . . . . . . . . . . . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 9.1. Informative References . . . . . . . . . . . . . . . . . 6 69 9.2. Normative References . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Example SLURM File . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The Resource Public Key Infrastructure (RPKI) is a global 76 authorization infrastructure that allows the holder of Internet 77 Number Resources (INRs) to make verifiable statements about those 78 resources. For example, the holder of a block of IP(v4 or v6) 79 addresses can issue a Route Origination Authorization (ROA) [RFC6482] 80 to authorize an Autonomous System (AS) to originate routes for that 81 block. 83 Internet Service Providers (ISPs) can then use the RPKI to validate 84 BGP routes. However, some ISPs locally use BGP with private address 85 space ([RFC1918], [RFC4193], [RFC6598]) or private AS numbers 86 ([RFC1930], [RFC6996]). These local BGP routes cannot be verified by 87 the global RPKI, and SHOULD be considered invalid when using the 88 RPKI. For example, [RFC6491] recommends the creation of ROAs that 89 would invalidate routes for reserved and unallocated address space. 91 This document specifies two new mechanisms to enable ISPs to make 92 local assertions about some INRs while using the RPKI's assertions 93 about all other INRs. These mechanisms support the second and third 94 use cases in [I-D.ietf-sidr-lta-use-cases]. The second use case 95 describes use of [RFC1918] addresses or use of public address space 96 not allocated to the ISP that is using it. The third use case 97 describes a situation in which an ISP publishes a variant of the RPKI 98 hierarchy (for its customers). In this variant some prefixes and/or 99 AS numbers are different from what the RPKI repository system 100 presents to the general ISP population. The result is that routes 101 for consumers of this variant hierarchy will be re-directed (via 102 routing). 104 Both mechanisms are specified in terms of abstract sets of 105 assertions. For Origin Validation [RFC6483], an assertion is a tuple 106 of {IP prefix, prefix length, maximum length, AS number} as used by 107 rpki-rtr [RFC6810]. Output Filtering, described in Section 2, 108 filters out any assertions by the RPKI about locally reserved INRs. 109 Locally Adding Assertions, described in Section 3, adds local 110 assertions about locally reserved INRs. Note that both of these 111 mechanisms can later be extended to cover any assertions made by the 112 RPKI for use in BGPSEC [I-D.ietf-sidr-bgpsec-protocol]. 114 In general, the primary output of an RPKI relying party is the data 115 it sends to routers over the rpki-rtr protocol. The rpki-rtr 116 protocol enables routers to query a relying party for all Origin 117 Validation assertions it knows about (Reset Query) or for an update 118 of only the changes in Origin Validation assertions (Serial Query). 119 The mechanisms specified in this document are to be applied to the 120 result set for a Reset Query, and to both the old and new sets that 121 are compared for a Serial Query. Relying party software MAY modify 122 other forms of output in comparable ways, but that is outside the 123 scope of this document. 125 This document is intended to supersede [I-D.ietf-sidr-ltamgmt] while 126 focusing only on local management of private INRs. Another draft 127 [I-D.kent-sidr-suspenders] focuses on the other aspects of local 128 management. 130 1.1. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Validation Output Filtering 138 To prevent the global RPKI from affecting routes with locally 139 reserved INRs, a relying party is locally configured with a list of 140 IP prefixes and/or AS numbers that are used locally, and taken from 141 the reserved INR spaces. Any Origin Validation assertions where the 142 IP prefix is equal to or subsumed by a locally reserved IP prefix, 143 are removed from the relying party's output. Any Origin Validation 144 assertions where the IP prefix contains a locally reserved IP prefix 145 are removed and the relying party software SHOULD issue a warning. 147 3. Locally Adding Assertions 149 Each relying party is locally configured with a (possibly empty) list 150 of Origin Validation assertions. This list is added to the relying 151 party's output. 153 4. Configuring SLURM 155 Relying party software SHOULD support the following configuration 156 format for Validation Output Filtering and Locally Adding Assertions. 157 The format is defined using the Augmented Backus-Naur Form (ABNF) 158 notation and core rules from [RFC5234] and the rules 159 and from Appendix A of [RFC3986]. Each command 160 specifies an INR to use for Validation Output Filtering. Each 161 command specifies an assertion to use for Locally Adding Assertions. 162 See Appendix A for an example SLURM file. 164 SLURMFile = header *line 166 header = %x53.4c.55.52.4d SP "1.0" CRLF ; "SLURM 1.0" 168 line = *WSP [comment] CRLF 169 / *WSP command [ 1*WSP [comment] ] CRLF 171 comment = "#" *(VCHAR / WSP) 173 command = add / del 175 add = %x61.64.64 1*WSP IPprefixMaxLen 1*WSP ASnum 177 del = %x64.65.6c 1*WSP inr 179 inr = IPprefix / ASnum 181 IPprefix = IPv4prefix / IPv6prefix 183 IPprefixMaxLen = IPv4prefixMaxLen / IPv6prefixMaxLen 185 IPv4prefix = IPv4address "/" 1*2DIGIT 187 IPv6prefix = IPv6address "/" 1*3DIGIT 189 ; In the following two rules, if the maximum length component is 190 ; missing, it is treated as equal to the prefix length. 191 IPv4prefixMaxLen = IPv4prefix ["-" 1*2DIGIT] 192 IPv6prefixMaxLen = IPv6prefix ["-" 1*3DIGIT] 194 ASnum = 1*DIGIT 196 5. Combining Mechanisms 198 In the typical use case, a relying party uses both output filtering 199 and locally added assertions. In this case, the resulting assertions 200 MUST be the same as if output filtering were performed before locally 201 adding assertions. I.e., locally added assertions MUST NOT be 202 removed by output filtering. 204 If a relying party chooses to use both SLURM and Suspenders 205 [I-D.kent-sidr-suspenders], the SLURM mechanisms MUST be performed on 206 the output of Suspenders. 208 6. IANA Considerations 210 TBD 212 7. Security Considerations 214 The mechanisms described in this document provide an ISP additional 215 control over its own network. Care should be taken in how that 216 control is used. 218 8. Acknowledgements 220 The author would like to thank Stephen Kent for his guidance and 221 detailed reviews of this document. 223 9. References 225 9.1. Informative References 227 [I-D.ietf-sidr-bgpsec-protocol] 228 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 229 sidr-bgpsec-protocol-08 (work in progress), November 2013. 231 [I-D.ietf-sidr-lta-use-cases] 232 Bush, R., "RPKI Local Trust Anchor Use Cases", draft-ietf- 233 sidr-lta-use-cases-01 (work in progress), June 2014. 235 [I-D.ietf-sidr-ltamgmt] 236 Reynolds, M., Kent, S., and M. Lepinski, "Local Trust 237 Anchor Management for the Resource Public Key 238 Infrastructure", draft-ietf-sidr-ltamgmt-08 (work in 239 progress), April 2013. 241 [I-D.kent-sidr-suspenders] 242 Kent, S. and D. Mandelberg, "Suspenders: A Fail-safe 243 Mechanism for the RPKI", draft-kent-sidr-suspenders-01 244 (work in progress), March 2014. 246 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 247 E. Lear, "Address Allocation for Private Internets", BCP 248 5, RFC 1918, February 1996. 250 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 251 selection, and registration of an Autonomous System (AS)", 252 BCP 6, RFC 1930, March 1996. 254 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 255 Addresses", RFC 4193, October 2005. 257 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 258 Origin Authorizations (ROAs)", RFC 6482, February 2012. 260 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 261 Origination Using the Resource Certificate Public Key 262 Infrastructure (PKI) and Route Origin Authorizations 263 (ROAs)", RFC 6483, February 2012. 265 [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public 266 Key Infrastructure (RPKI) Objects Issued by IANA", RFC 267 6491, February 2012. 269 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 270 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 271 Space", BCP 153, RFC 6598, April 2012. 273 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 274 Infrastructure (RPKI) to Router Protocol", RFC 6810, 275 January 2013. 277 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 278 "Special-Purpose IP Address Registries", BCP 153, RFC 279 6890, April 2013. 281 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 282 Private Use", BCP 6, RFC 6996, July 2013. 284 9.2. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 290 Resource Identifier (URI): Generic Syntax", STD 66, RFC 291 3986, January 2005. 293 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 294 Specifications: ABNF", STD 68, RFC 5234, January 2008. 296 Appendix A. Example SLURM File 297 SLURM 1.0 299 # Reserve 192.0.2.0/24 and 2001:DB8::/32 for local use. 300 del 192.0.2.0/24 301 del 2001:DB8::/32 303 # Allow either 65536 or 65537 to originate routes to 192.0.2.0/24. 304 add 192.0.2.0/24 65536 305 add 192.0.2.0/24 65537 307 add 2001:DB8::/48-52 65536 # 65536 originates 2001:DB8::/48 and 308 # sub-prefixes down to length 52. 309 add 2001:DB8:0:42::/64 65537 # However, 65537 originates 310 # 2001:DB8:0:42::/64. 311 add 2001:DB8:1::/48 65537 # 65537 also originates 2001:DB8:1::/48 313 Author's Address 315 David Mandelberg 316 BBN Technologies 317 10 Moulton St. 318 Camridge, MA 02138 319 US 321 Email: david@mandelberg.org