idnits 2.17.1 draft-yossigi-rpkimaxlen-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 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 34 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 (September 7, 2017) is 2422 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: March 11, 2018 K. Sriram 6 NIST 7 J. Snijders 8 NTT 9 September 7, 2017 11 The Use of Maxlength in the RPKI 12 draft-yossigi-rpkimaxlen-01 14 Abstract 16 This document recommends that operators avoid using the maxLength 17 attribute when issuing Route Origin Authorizations (ROAs) in the 18 Resource Public Key Infrastructure (RPKI). These recommendations 19 complement those in [RFC7115]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 11, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Forged Origin Subprefix Hijack . . . . . . . . . . . . . . . 3 59 4. Measurements of Today's RPKI . . . . . . . . . . . . . . . . 5 60 5. Use Minimal ROAs without Maxlength . . . . . . . . . . . . . 6 61 5.1. When a Minimal ROA Cannot Be Used? . . . . . . . . . . . 6 62 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 8.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 The RPKI [RFC6480] uses Route Origin Authorizations (ROAs) to create 72 a trusted mapping from an IP prefix to a set of autonomous systems 73 (ASes) that are authorized to originate this prefix. Each ROA 74 contains a set of IP prefixes, and an AS number of an AS authorized 75 originate all the IP prefixes in the set [RFC6482]. Each ROA is 76 cryptographically signed by the party that is authorized to allocate 77 the set of IP prefixes. 79 The RPKI also supports a maxLength attribute. According to 80 [RFC6482], "When present, the maxLength specifies the maximum length 81 of the IP address prefix that the AS is authorized to advertise." 82 Thus, rather than requiring the ROA to explictly list each prefix the 83 AS is authorized to originate, the maxLength attribute provides a 84 shorthand that authorizes an AS to originate a set of IP prefixes. 86 However, measurements of current RPKI deployments have found that use 87 of the maxLength in ROAs tends to lead to security problems. 88 Specifically, as of June 2017, 84% of the prefixes specified in ROAs 89 that use the maxLength attribute, are vulnerable to a forged-origin 90 subprefix hijack. The forged-origin subprefix hijack can be launched 91 against any IP prefix that is authorized in ROA but is not originated 92 in BGP. The impact of such an attack is the same as standard 93 subprefix hijack on an IP prefix that is unprotected by a ROA in the 94 RPKI. 96 For this reason, this document recommends that, whenever possible, 97 operators SHOULD use "minimal ROAs" that include only those IP 98 prefixes that are actually originated in BGP, and no other prefixes. 99 Operators SHOULD also avoid using the maxLength attribute in their 100 ROAS whenever possible. One ideal place to implement these 101 recommendations is in the user interfaces for configuring ROAs. 103 The recommendations in this document clarify and extend the following 104 recommendation from [RFC7115]: 106 One advantage of minimal ROA length is that the forged origin 107 attack does not work for sub-prefixes that are not covered by 108 overly long max length. For example, if, instead of 109 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged 110 origin attack cannot succeed against 10.0.666.0/24. They must 111 attack the whole /16, which is more likely to be noticed because 112 of its size. 114 This best current practice requires no changes to the RPKI 115 specification and will not increase the number of signed ROAs in the 116 RPKI, because ROAs already support lists of IP prefixes [RFC6482]. 118 1.1. Requirements 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Suggested Reading 126 It is assumed that the reader understands BGP [RFC4271], the RPKI 127 [RFC6480] Route Origin Authorizations (ROAs) [RFC6482], RPKI-based 128 Prefix Validation [RFC6811], and BGPSEC 129 [I-D.ietf-sidr-bgpsec-protocol]. 131 3. Forged Origin Subprefix Hijack 133 The forged-origin subprefix hijack is relevant to a scenario in which 134 (1) the RPKI [RFC6480] is deployed, and (2) routers use RPKI origin 135 validation to drop invalid routes [RFC6811], but (3) BGPSEC 136 [I-D.ietf-sidr-bgpsec-protocol] is not deployed. 138 We describe the forged-origin subprefix hijack [RFC7115] [GCHSS] 139 using a running example. 141 Consider the IP prefix 168.122.0.0/16 which is allocated to an 142 organization that also operates AS 111. In BGP, AS 111 originates 143 the IP prefix 168.122.0.0/16 as well as its subprefix 144 168.122.225.0/24. Therefore, the RPKI should contain a ROA 145 authorizing AS 111 to originate these two IP prefixes. That is, the 146 ROA should be 148 ROA:(168.122.0.0/16,168.122.225.0/24, AS 111) 150 This ROA is "minimal" because it includes only those IP prefixes that 151 AS 111 originates in BGP, but no other IP prefixes. [RFC6907] 153 Now suppose an attacking AS 666 originates a BGP announcement for a 154 subprefix 168.122.0.0/24. This is a standard "subprefix hijack". 156 In the absence of the minimal ROA above, AS 666 could intercept 157 traffic for the addresses in 168.122.0.0/24. This is because routers 158 perform a longest-prefix match when deciding where to forward IP 159 packets, and 168.122.0.0/24 originated by AS 666 is a longer prefix 160 than 168.122.0.0/16 originated by AS 111. 162 However, the minimal ROA renders AS 666's BGP announcement invalid, 163 because (1) this ROA "covers" the attacker's announcement (since 164 168.122.0.0/24 is a subprefix of 168.122.0.0/16), and (2) there is no 165 ROA "matching" the attacker's announcement (there is no ROA for AS 166 666 and IP prefix 168.122.0.0/24) [RFC6811]. If routers ignore 167 invalid BGP announcements, the minimal ROA above ensures that the 168 subprefix hijack will fail. 170 Now suppose that instead the "minimal ROA" was replaced with a "loose 171 ROA" that used maxLength as a shorthand for set of IP prefixes that 172 AS 111 is authorized to originate. The "loose ROA" would be: 174 ROA:(168.122.0.0/16-24, AS 111) 176 This "loose ROA" authorizes AS 111 to originate any subprefix of 177 168.122.0.0/16, up to length /24. That is, AS 111 could originate 178 168.122.225.0/24 as well as all of 168.122.0.0/17, 168.122.128.0/17, 179 ..., 168.122.255.0/24 but not 168.122.0.0/25. 181 However, AS 111 only originates two prefixes in BGP: 168.122.0.0/16 182 and 168.122.255.0/24. This means that all other prefixes authorized 183 by the "loose ROA" (for instance, 168.122.0.0/24), are vulnerable to 184 the following forged-origin subprefix hijack [[RFC7115],[GCHSS]]: 186 The hijacker AS 666 sends a BGP announcement "168.122.0.0/24: AS 187 666, AS 111", falsely claiming that AS 666 is a neighbor of AS 111 188 and falsely claiming that AS 111 originates the IP prefix 189 168.122.0.0/24. In fact, the IP prefix 168.122.0.0/24 is not 190 originated by AS 111. 192 The hijacker's BGP announcement is valid according the RPKI, since 193 the ROA (168.122.0.0/16-24, AS 111) authorizes AS 111 to originate 194 BGP routes for 168.122.0.0/24. Becaue AS 111 does not actually 195 originate a route for 168.122.0.0/24, the hijacker's route is the 196 *only* route to the 168.122.0.0/24. Longest-prefix-match routing 197 ensures that the hijacker's route to the subprefix 168.122.0.0/24 is 198 always preferred over the legitimate route to 168.122.0.0/16 199 originated by AS 111. Thus, if the hijacker's route propagates 200 through the Internet, the hijacker will intercept traffic destined 201 for IP addresses in 168.122.0.0/24. 203 The forged origin *subprefix* hijack would have failed if the 204 "minimal ROA" described above was used instead of the "loose ROA". 205 If the "minimal ROA" had been used instead, the attacker would be 206 forced to launch a forged origin *prefix* hijack in order to attract 207 traffic, as follows: 209 The hijacker AS 666 sends a BGP announcement "168.122.0.0/16: AS 210 666, AS 111", falsely claiming that AS 666 is a neighbor of AS 211 111. 213 This forged-origin *prefix* hijack is significantly less damaging 214 than the forged-origin *subprefix* hijack. With a forged-origin 215 *prefix* hijack, AS 111 legitimately originates 168.122.0.0/16 in 216 BGP, so the hijacker AS 666 is not presenting the *only* route to 217 168.122.0.0/16. Moreover, the path originated by AS 666 is one hop 218 longer than the path originated by the legitimate origin AS 111. As 219 discussed in [LSG16], this means that the hijacker will attract less 220 traffic than he would have in the forged origin *subprefix* hijack, 221 where the hijacker presents the *only* route to the hijacked 222 subprefix. 224 In sum, a forged-origin subprefix hijack has the same impact as a 225 regular subprefix hijack. A forged-origin *subprefix* hijack is also 226 more damaging than than forged-origin *prefix* hijack. 228 Any ROA that is not minimal is vulnerable to forged-origin subprefix 229 hijack. 231 4. Measurements of Today's RPKI 233 Network measurements from June 1, 2017 show that 12% of the IP 234 prefixes authorized in ROAs have a maxLength longer than their prefix 235 length. The vast majority of these (84%) of these are vulnerable to 236 forged-origin subprefix hijacks. Even large providers are vulnerable 237 to these attacks. See [GSG17] for details. 239 These measurements suggest that operators commonly misconfigure the 240 maxLength attribute, and unwittingly open themselves up to forged- 241 origin subprefix hijacks. 243 5. Use Minimal ROAs without Maxlength 245 Operators SHOULD avoid using the maxLength attribute in their ROAs. 247 Operators SHOULD use "minimal ROAs" whenever possible. A minimal ROA 248 contains only those IP prefixes that are actually originated by an AS 249 in BGP, and no other IP prefixes. (See Section 3 for an example.) 251 This practice requires no changes to the RPKI specification and will 252 not increase the number of signed ROAs in the RPKI, because ROAs 253 already support lists of IP prefixes [RFC6482]. See also [GSG17] for 254 further discussion of why this practice will have minimal impact on 255 the performance of the RPKI ecosystem. 257 5.1. When a Minimal ROA Cannot Be Used? 259 Sometimes, it is not possible to use a "minimal ROA", because an 260 operator wants to issue a ROA that includes an IP prefix that is 261 sometimes (but not always) originated in BGP. 263 In this case, the ROA SHOULD include (1) the set of IP prefixes that 264 are always originated in BGP, and (2) the set IP prefixes that are 265 sometimes, but not always, originated in BGP. The ROA SHOULD NOT 266 include any IP prefixes that the operator knows will not be 267 originated in BGP. Whenever possible, the ROA SHOULD also avoid the 268 use of the maxlength attribute. 270 We now extend our running example to illustrate one situation where 271 where it is not possible to issue a minimal ROA. 273 Suppose AS 111 has a contract with a DDoS mitigation service provider 274 that holds AS 222. The DDoS mitigation service is contracted to 275 protect all IP addresses covered by 168.122.0.0/22. When a DDoS 276 attack is detected, AS 222 immediately originates 168.122.0.0/22, 277 thus attracting all the DDoS traffic to itself. The traffic is 278 scrubbed at AS 222 and then and sent back to AS 111 over a backhaul 279 data link. Notice that, during a DDoS attack, the DDoS mitigation 280 service provider AS 222 originates a /22 prefix that are longer than 281 than AS 111's /16 prefix, and so all the traffic that normally goes 282 to AS 111 goes to AS 222 instead. 284 First, suppose the RPKI only had the minimal ROA for AS 111, as 285 described in Section 3. But, if there is no ROA authorizing AS 222 286 to announce the /23 prefix, then the traffic-scrubbing scheme would 287 not work. That is, if AS 222 originates the /22 prefix in BGP during 288 a DDoS attack, the announcement would be invalid [RFC6811]. 290 Instead, the RPKI should have two ROAs: one for AS 111 and one for AS 291 222. 293 ROA:(168.122.0.0/16,168.122.225.0/24, AS 111) 295 ROA:(168.122.0.0/22, AS 222) 297 Neither ROA uses the maxLength attribute. But, the second ROA is not 298 "minimal" because it contains a /22 prefix that is not originated by 299 anyone in BGP during normal operations. The /22 prefix is only 300 originated by AS 222 as part of its DDoS mitigation service during a 301 DDoS attack. 303 Notice, however, that this scheme does not come without risks. 304 Namely, all of the IP addresses in 168.122.0.0/22 are vulnerable to a 305 forged-origin subprefix hijack during normal operations, when the /22 306 prefix is not originated. (The hijacker AS 666 would send the BGP 307 announcement `168.122.0.0/22: AS 666, AS 222'', falsely claiming that 308 AS 666 is a neighbor of AS 222 and falsely claiming that AS 222 309 originates 168.122.0.0/22.) 311 In some situations, the DDoS mitigation service at AS 222 might want 312 to limit the amount of DDoS traffic that it attracts and scrubs. 313 Suppose that a DDoS attack only targets IP addresses in 314 168.122.0.0/24. Then, the DDoS mitigation service at AS 222 only 315 wants to attract the traffic destinated for the /24 prefix that is 316 under attack, but not the entire /22 prefix. To allow for this, the 317 RPKI should have two ROAs: one for AS 111 and one for AS 222. 319 ROA:(168.122.0.0/16,168.122.225.0/24, AS 111) 321 ROA:(168.122.0.0/22-24, AS 222) 323 The second ROA uses the maxLength attribute because it is designed to 324 explicitly enable AS 222 to originate *any* /24 subprefix of 325 168.122.0.0/22. 327 As before, the second ROA is also not "minimal" because it contains 328 prefixes that are not originated by anyone in BGP during normal 329 operations. As before, all of the IP addresses in 168.122.0.0/22 are 330 vulnerable to a forged-origin subprefix hijack during normal 331 operations, when the /22 prefix is not originated. 333 The use of maxLength in this second ROA also comes with an additional 334 risk. Consider a DDoS attack that causes the DDoS mitigation service 335 at AS 222 to originates prefix 168.122.0.0/24. It follows that all 336 *other* /24 prefixes covered by the /22 prefix (i.e., 168.122.1.0/24, 337 168.122.2.0/24, 168.122.3.0/24) are all vulnerable to a forged-origin 338 subprefix attacks during the DDoS attack. 340 6. Change Log 342 Note to RFC Editor: if this document does not obsolete an existing 343 RFC, please remove this appendix before publication as an RFC. 345 00 - New document. 347 01 - Updated network measurements. Updated citation to [GSG17]. 348 Editorial changes to clarify difference between "minimal ROA" 349 recommendation and "avoid maxLength" recommendation. Updated 350 example in Section 5.1. 352 7. Contributors 354 This document would not be possible without the work of Omar Sagga 355 (Boston University). 357 8. References 359 8.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 367 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 368 DOI 10.17487/RFC4271, January 2006, 369 . 371 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 372 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 373 February 2012, . 375 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 376 Origin Authorizations (ROAs)", RFC 6482, 377 DOI 10.17487/RFC6482, February 2012, 378 . 380 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 381 Austein, "BGP Prefix Origin Validation", RFC 6811, 382 DOI 10.17487/RFC6811, January 2013, 383 . 385 8.2. Informative References 387 [GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 388 Shulman, "Are We There Yet? On RPKI's Deployment and 389 Security", in NDSS 2017, February 2017, 390 . 392 [GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "Maxlength 393 Considered Harmful to the RPKI", in ACM CoNEXT 2017, 394 December 2017, . 396 [I-D.ietf-sidr-bgpsec-protocol] 397 Lepinski, M. and K. Sriram, "BGPsec Protocol 398 Specification", draft-ietf-sidr-bgpsec-protocol-23 (work 399 in progress), April 2017. 401 [LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking 402 Security for Internet Routing", in Communications of the 403 ACM, October 2016, . 407 [RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and 408 Interpretations of Resource Public Key Infrastructure 409 (RPKI) Objects for Issuers and Relying Parties", RFC 6907, 410 DOI 10.17487/RFC6907, March 2013, 411 . 413 [RFC7115] Bush, R., "Origin Validation Operation Based on the 414 Resource Public Key Infrastructure (RPKI)", BCP 185, 415 RFC 7115, DOI 10.17487/RFC7115, January 2014, 416 . 418 Authors' Addresses 420 Yossi Gilad 421 Boston University 422 111 Cummington St, MCS135 423 Boston, MA 02215 424 USA 426 EMail: yossigi@bu.edu 427 Sharon Goldberg 428 Boston University 429 111 Cummington St, MCS135 430 Boston, MA 02215 431 USA 433 EMail: goldbe@cs.bu.edu 435 Kotikalapudi Sriram 436 NIST 437 100 Bureau Drive 438 Gaithersburg, MD 20899 439 USA 441 EMail: kotikalapudi.sriram@nist.gov 443 Job Snijders 444 NTT Communications 445 Theodorus Majofskistraat 100 446 Amsterdam 1065 SZ 447 The Netherlands 449 EMail: job@ntt.net