idnits 2.17.1 draft-sidrops-rpkimaxlen-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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC7115]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 35 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2018) is 2187 days in the past. Is this intentional? 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) ** Downref: Normative reference to an Informational RFC: RFC 6480 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Gilad 3 Internet-Draft S. Goldberg 4 Intended status: Best Current Practice Boston University 5 Expires: October 31, 2018 K. Sriram 6 USA NIST 7 J. Snijders 8 NTT 9 B. Maddison 10 Workonline Communications 11 April 29, 2018 13 The Use of Maxlength in the RPKI 14 draft-sidrops-rpkimaxlen-00 16 Abstract 18 This document recommends that operators avoid using the maxLength 19 attribute when issuing Route Origin Authorizations (ROAs) in the 20 Resource Public Key Infrastructure (RPKI). These recommendations 21 complement those in [RFC7115]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 31, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Forged Origin Subprefix Hijack . . . . . . . . . . . . . . . 3 61 4. Measurements of Today's RPKI . . . . . . . . . . . . . . . . 5 62 5. Use Minimal ROAs without Maxlength . . . . . . . . . . . . . 6 63 5.1. When a Minimal ROA Cannot Be Used? . . . . . . . . . . . 6 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The RPKI [RFC6480] uses Route Origin Authorizations (ROAs) to create 73 a cryptographically verifiable mapping from an IP prefix to a set of 74 autonomous systems (ASes) that are authorized to originate this 75 prefix. Each ROA contains a set of IP prefixes, and an AS number of 76 an AS authorized originate all the IP prefixes in the set [RFC6482]. 77 The ROA is cryptographically signed by the party that holds a 78 certificate for the set of IP prefixes. 80 The ROA format also supports a maxLength attribute. According to 81 [RFC6482], "When present, the maxLength specifies the maximum length 82 of the IP address prefix that the AS is authorized to advertise." 83 Thus, rather than requiring the ROA to list each prefix the AS is 84 authorized to originate, the maxLength attribute provides a shorthand 85 that authorizes an AS to originate a set of IP prefixes. 87 However, measurements of current RPKI deployments have found that use 88 of the maxLength in ROAs tends to lead to security problems. 89 Specifically, as of June 2017, 84% of the prefixes specified in ROAs 90 that use the maxLength attribute, are vulnerable to a forged-origin 91 subprefix hijack [HARMFUL]. The forged-origin subprefix hijack, as 92 described below, can be launched against any IP prefix that is 93 authorized in ROA but is not originated in BGP. The impact of such 94 an attack is the same as that of a subprefix hijack in the absence of 95 ROA-based protection. 97 For this reason, this document recommends that, whenever possible, 98 operators SHOULD use "minimal ROAs" that include only those IP 99 prefixes that are actually originated in BGP, and no other prefixes. 100 Operators SHOULD also avoid using the maxLength attribute in their 101 ROAS whenever possible. One ideal place to implement these 102 recommendations is in the user interfaces for configuring ROAs: thus 103 this document further recommends that designers and/or providers of 104 such user interfaces SHOULD provide warnings to draw the user's 105 attention to the risks of using the maxLength attribute. 107 The recommendations in this document clarify and extend the following 108 recommendation from [RFC7115]: 110 One advantage of minimal ROA length is that the forged origin 111 attack does not work for sub-prefixes that are not covered by 112 overly long max length. For example, if, instead of 113 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged 114 origin attack cannot succeed against 10.0.666.0/24. They must 115 attack the whole /16, which is more likely to be noticed because 116 of its size. 118 This best current practice requires no changes to the RPKI 119 specification and will not increase the number of signed ROAs in the 120 RPKI, because ROAs already support lists of IP prefixes [RFC6482]. 122 1.1. Requirements 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Suggested Reading 130 It is assumed that the reader understands BGP [RFC4271], the RPKI 131 [RFC6480] Route Origin Authorizations (ROAs) [RFC6482], RPKI-based 132 Prefix Validation [RFC6811], and BGPSEC [RFC8205]. 134 3. Forged Origin Subprefix Hijack 136 The forged-origin subprefix hijack is relevant to a scenario in which 137 (1) the RPKI [RFC6480] is deployed, and (2) routers use RPKI origin 138 validation to drop invalid routes [RFC6811], but (3) BGPSEC [RFC8205] 139 (or any similar method to validate the truthfulness of the BGP 140 AS_PATH attribute) is not deployed. 142 We describe the forged-origin subprefix hijack [RFC7115] [GCHSS] 143 using a running example. 145 Consider the IP prefix 168.122.0.0/16 which is allocated to an 146 organization that also operates AS 64496. In BGP, AS 64496 147 originates the IP prefix 168.122.0.0/16 as well as its subprefix 148 168.122.225.0/24. Therefore, the RPKI should contain a ROA 149 authorizing AS 64496 to originate these two IP prefixes. That is, 150 the ROA should be 152 ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496) 154 This ROA is "minimal" because it includes only those IP prefixes that 155 AS 64496 originates in BGP, but no other IP prefixes [RFC6907]. 157 Now suppose an attacking AS 64511 originates a BGP announcement for a 158 subprefix 168.122.0.0/24. This is a standard "subprefix hijack". 160 In the absence of the minimal ROA above, AS 64511 could intercept 161 traffic for the addresses in 168.122.0.0/24. This is because routers 162 perform a longest-prefix match when deciding where to forward IP 163 packets, and 168.122.0.0/24 originated by AS 64511 is a longer prefix 164 than 168.122.0.0/16 originated by AS 64496. 166 However, the minimal ROA renders AS 64511's BGP announcement invalid, 167 because (1) this ROA "covers" the attacker's announcement (since 168 168.122.0.0/24 is a subprefix of 168.122.0.0/16), and (2) there is no 169 ROA "matching" the attacker's announcement (there is no ROA for AS 170 64511 and IP prefix 168.122.0.0/24) [RFC6811]. If routers ignore 171 invalid BGP announcements, the minimal ROA above ensures that the 172 subprefix hijack will fail. 174 Now suppose that the "minimal ROA" was replaced with a "loose ROA" 175 that used maxLength as a shorthand for set of IP prefixes that AS 176 64496 is authorized to originate. The "loose ROA" would be: 178 ROA:(168.122.0.0/16-24, AS 64496) 180 This "loose ROA" authorizes AS 64496 to originate any subprefix of 181 168.122.0.0/16, up to length /24. That is, AS 64496 could originate 182 168.122.225.0/24 as well as all of 168.122.0.0/17, 168.122.128.0/17, 183 ..., 168.122.255.0/24 but not 168.122.0.0/25. 185 However, AS 64496 only originates two prefixes in BGP: 168.122.0.0/16 186 and 168.122.255.0/24. This means that all other prefixes authorized 187 by the "loose ROA" (for instance, 168.122.0.0/24), are vulnerable to 188 the following forged-origin subprefix hijack [RFC7115], [GCHSS]: 190 The hijacker AS 64511 sends a BGP announcement "168.122.0.0/24: AS 191 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 192 AS 64496 and falsely claiming that AS 64496 originates the IP 193 prefix 168.122.0.0/24. In fact, the IP prefix 168.122.0.0/24 is 194 not originated by AS 64496. 196 The hijacker's BGP announcement is valid according to the RPKI, since 197 the ROA (168.122.0.0/16-24, AS 64496) authorizes AS 64496 to 198 originate BGP routes for 168.122.0.0/24. Because AS 64496 does not 199 actually originate a route for 168.122.0.0/24, the hijacker's route 200 is the *only* route to the 168.122.0.0/24. Longest-prefix-match 201 routing ensures that the hijacker's route to the subprefix 202 168.122.0.0/24 is always preferred over the legitimate route to 203 168.122.0.0/16 originated by AS 64496. Thus, the hijacker's route 204 propagates through the Internet, the traffic destined for IP 205 addresses in 168.122.0.0/24 will be delivered to the hijacker. 207 The forged origin *subprefix* hijack would have failed if the 208 "minimal ROA" described above was used instead of the "loose ROA". 209 If the "minimal ROA" had been used instead, the attacker would be 210 forced to launch a forged origin *prefix* hijack in order to attract 211 traffic, as follows: 213 The hijacker AS 64511 sends a BGP announcement "168.122.0.0/16: AS 214 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 215 AS 64496. 217 This forged-origin *prefix* hijack is significantly less damaging 218 than the forged-origin *subprefix* hijack. With a forged-origin 219 *prefix* hijack, AS 64496 legitimately originates 168.122.0.0/16 in 220 BGP, so the hijacker AS 64511 is not presenting the *only* route to 221 168.122.0.0/16. Moreover, the path originated by AS 64511 is one hop 222 longer than the path originated by the legitimate origin AS 64496. 223 As discussed in [LSG16], this means that the hijacker will attract 224 less traffic than he would have in the forged origin *subprefix* 225 hijack, where the hijacker presents the *only* route to the hijacked 226 subprefix. 228 In sum, a forged-origin subprefix hijack has the same impact as a 229 regular subprefix hijack. A forged-origin *subprefix* hijack is also 230 more damaging than forged-origin *prefix* hijack. 232 4. Measurements of Today's RPKI 234 Network measurements from June 1, 2017 show that 12% of the IP 235 prefixes authorized in ROAs have a maxLength longer than their prefix 236 length. The vast majority of these (84%) of these are vulnerable to 237 forged-origin subprefix hijacks. Even large providers are vulnerable 238 to these attacks. See [GSG17] for details. 240 These measurements suggest that operators commonly misconfigure the 241 maxLength attribute, and unwittingly open themselves up to forged- 242 origin subprefix hijacks. 244 5. Use Minimal ROAs without Maxlength 246 Operators SHOULD avoid using the maxLength attribute in their ROAs. 248 Operators SHOULD use "minimal ROAs" whenever possible. A minimal ROA 249 contains only those IP prefixes that are actually originated by an AS 250 in BGP, and no other IP prefixes. (See Section 3 for an example.) 252 This practice requires no changes to the RPKI specification and will 253 not increase the number of signed ROAs in the RPKI, because ROAs 254 already support lists of IP prefixes [RFC6482]. See also [GSG17] for 255 further discussion of why this practice will have minimal impact on 256 the performance of the RPKI ecosystem. 258 5.1. When a Minimal ROA Cannot Be Used? 260 Sometimes, it is not possible to use a "minimal ROA", because an 261 operator wants to issue a ROA that includes an IP prefix that is 262 sometimes (but not always) originated in BGP. 264 In this case, the ROA SHOULD include (1) the set of IP prefixes that 265 are always originated in BGP, and (2) the set IP prefixes that are 266 sometimes, but not always, originated in BGP. The ROA SHOULD NOT 267 include any IP prefixes that the operator knows will not be 268 originated in BGP. Whenever possible, the ROA SHOULD also avoid the 269 use of the maxlength attribute. 271 We now extend our running example to illustrate one situation where 272 where it is not possible to issue a minimal ROA. 274 Consider the following scenario prior to deployment of RPKI. Suppose 275 AS 64496 announced 168.122.0.0/16 and has a contract with a DDoS 276 mitigation service provider that holds AS 64500. Further, assume 277 that the DDoS mitigation service contract applies to all IP addresses 278 covered by 168.122.0.0/22. When a DDoS attack is detected and 279 reported by AS 64496, AS 64500 immediately originates 168.122.0.0/22, 280 thus attracting all the DDoS traffic to itself. The traffic is 281 scrubbed at AS 64500 and then sent back to AS 64496 over a backhaul 282 data link. Notice that, during a DDoS attack, the DDoS mitigation 283 service provider AS 64500 originates a /22 prefix that is longer than 284 than AS 64496's /16 prefix, and so all the traffic (destined to 285 addresses in 168.122.0.0/22) that normally goes to AS 64496 goes to 286 AS 64500 instead. 288 First, suppose the RPKI only had the minimal ROA for AS 64496, as 289 described in Section 3. But, if there is no ROA authorizing AS 64500 290 to announce the /22 prefix, then the traffic-scrubbing scheme would 291 not work. That is, if AS 64500 originates the /22 prefix in BGP 292 during a DDoS attack, the announcement would be invalid [RFC6811]. 294 Therefore, the RPKI should have two ROAs: one for AS 64496 and one 295 for AS 64500. 297 ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496) 299 ROA:(168.122.0.0/22, AS 64500) 301 Neither ROA uses the maxLength attribute. But, the second ROA is not 302 "minimal" because it contains a /22 prefix that is not originated by 303 anyone in BGP during normal operations. The /22 prefix is only 304 originated by AS 64500 as part of its DDoS mitigation service during 305 a DDoS attack. 307 Notice, however, that this scheme does not come without risks. 308 Namely, all IP addresses in 168.122.0.0/22 are vulnerable to a 309 forged-origin subprefix hijack during normal operations, when the /22 310 prefix is not originated. (The hijacker AS 64511 would send the BGP 311 announcement "168.122.0.0/22: AS 64511, AS 64500", falsely claiming 312 that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS 313 64500 originates 168.122.0.0/22.) 315 In some situations, the DDoS mitigation service at AS 64500 might 316 want to limit the amount of DDoS traffic that it attracts and scrubs. 317 Suppose that a DDoS attack only targets IP addresses in 318 168.122.0.0/24. Then, the DDoS mitigation service at AS 64500 only 319 wants to attract the traffic designated for the /24 prefix that is 320 under attack, but not the entire /22 prefix. To allow for this, the 321 RPKI should have two ROAs: one for AS 64496 and one for AS 64500. 323 ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496) 325 ROA:(168.122.0.0/22-24, AS 64500) 327 The second ROA uses the maxLength attribute because it is designed to 328 explicitly enable AS 64500 to originate *any* /24 subprefix of 329 168.122.0.0/22. 331 As before, the second ROA is also not "minimal" because it contains 332 prefixes that are not originated by anyone in BGP during normal 333 operations. As before, all IP addresses in 168.122.0.0/22 are 334 vulnerable to a forged-origin subprefix hijack during normal 335 operations, when the /22 prefix is not originated. 337 The use of maxLength in this second ROA also comes with an additional 338 risk. While it permits the DDoS mitigation service at AS 64500 to 339 originate prefix 168.122.0.0/24 during a DDoS attack in that space, 340 it also makes the *other* /24 prefixes covered by the /22 prefix 341 (i.e., 168.122.1.0/24, 168.122.2.0/24, 168.122.3.0/24) vulnerable to 342 a forged-origin subprefix attacks. 344 6. Acknowledgments 346 The authors would like to thank the following people for their review 347 and contributions to this document: Omar Sagga (Boston University) 348 and Aris Lambrianidis (AMS-IX). 350 7. References 352 7.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 360 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 361 DOI 10.17487/RFC4271, January 2006, 362 . 364 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 365 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 366 February 2012, . 368 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 369 Origin Authorizations (ROAs)", RFC 6482, 370 DOI 10.17487/RFC6482, February 2012, 371 . 373 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 374 Austein, "BGP Prefix Origin Validation", RFC 6811, 375 DOI 10.17487/RFC6811, January 2013, 376 . 378 7.2. Informative References 380 [GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 381 Shulman, "Are We There Yet? On RPKI's Deployment and 382 Security", in NDSS 2017, February 2017, 383 . 385 [GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "Maxlength 386 Considered Harmful to the RPKI", in ACM CoNEXT 2017, 387 December 2017, . 389 [HARMFUL] Gilad, Y., Sagga, O., and S. Goldberg, "MaxLength 390 Considered Harmful to the RPKI", 2017, 391 . 393 [LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking 394 Security for Internet Routing", in Communications of the 395 ACM, October 2016, . 399 [RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and 400 Interpretations of Resource Public Key Infrastructure 401 (RPKI) Objects for Issuers and Relying Parties", RFC 6907, 402 DOI 10.17487/RFC6907, March 2013, 403 . 405 [RFC7115] Bush, R., "Origin Validation Operation Based on the 406 Resource Public Key Infrastructure (RPKI)", BCP 185, 407 RFC 7115, DOI 10.17487/RFC7115, January 2014, 408 . 410 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 411 Specification", RFC 8205, DOI 10.17487/RFC8205, September 412 2017, . 414 Authors' Addresses 416 Yossi Gilad 417 Boston University 418 111 Cummington St, MCS135 419 Boston, MA 02215 420 USA 422 EMail: yossigi@bu.edu 424 Sharon Goldberg 425 Boston University 426 111 Cummington St, MCS135 427 Boston, MA 02215 428 USA 430 EMail: goldbe@cs.bu.edu 431 Kotikalapudi Sriram 432 USA National Institute of Standards and Technology 433 100 Bureau Drive 434 Gaithersburg, MD 20899 435 USA 437 EMail: kotikalapudi.sriram@nist.gov 439 Job Snijders 440 NTT Communications 441 Theodorus Majofskistraat 100 442 Amsterdam 1065 SZ 443 The Netherlands 445 EMail: job@ntt.net 447 Ben Maddison 448 Workonline Communications 449 30 Waterkant St 450 Cape Town 8001 451 South Africa 453 EMail: benm@workonline.co.za