idnits 2.17.1 draft-ietf-sidrops-rpkimaxlen-08.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.) == There are 32 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (5 October 2021) is 931 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) == Unused Reference: 'NIST-800-189' is defined on line 542, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6480 Summary: 3 errors (**), 0 flaws (~~), 4 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 Hebrew University of Jerusalem 4 Intended status: Best Current Practice S. Goldberg 5 Expires: 8 April 2022 Boston University 6 K. Sriram 7 USA NIST 8 J. Snijders 9 Fastly 10 B. Maddison 11 Workonline Communications 12 5 October 2021 14 The Use of Maxlength in the RPKI 15 draft-ietf-sidrops-rpkimaxlen-08 17 Abstract 19 This document recommends ways to reduce forged-origin hijack attack 20 surface by prudently limiting the set of IP prefixes that are 21 included in a Route Origin Authorization (ROA). One recommendation 22 is to avoid using the maxLength attribute in ROAs except in some 23 specific cases. The recommendations complement and extend those in 24 RFC 7115. The document also discusses creation of ROAs for 25 facilitating the use of Distributed Denial of Service (DDoS) 26 mitigation services. Considerations related to ROAs and origin 27 validation in the context of destination-based Remote Triggered Black 28 Hole (RTBH) filtering are also highlighted. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 8 April 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Documentation Prefixes . . . . . . . . . . . . . . . . . 4 66 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Forged-Origin Subprefix Hijack . . . . . . . . . . . . . . . 4 68 4. Measurements of Today's RPKI . . . . . . . . . . . . . . . . 6 69 5. Recommendations about Minimal ROAs and maxLength . . . . . . 7 70 5.1. Facilitating Ad-hoc Routing Changes and DDoS 71 Mitigation . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2. Defensive de-aggregation in response to prefix hijacks . 10 73 6. Considerations for RTBH Filtering Scenarios . . . . . . . . . 10 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 The RPKI [RFC6480] uses Route Origin Authorizations (ROAs) to create 83 a cryptographically verifiable mapping from an IP prefix to a set of 84 autonomous systems (ASes) that are authorized to originate that 85 prefix. Each ROA contains a set of IP prefixes, and an AS number of 86 an AS authorized to originate all the IP prefixes in the set 87 [RFC6482]. The ROA is cryptographically signed by the party that 88 holds a certificate for the set of IP prefixes. 90 The ROA format also supports a maxLength attribute. According to 91 [RFC6482], "When present, the maxLength specifies the maximum length 92 of the IP address prefix that the AS is authorized to advertise." 93 Thus, rather than requiring the ROA to list each prefix the AS is 94 authorized to originate, the maxLength attribute provides a shorthand 95 that authorizes an AS to originate a set of IP prefixes. 97 However, measurements of current RPKI deployments have found that use 98 of the maxLength in ROAs tends to lead to security problems. 99 Specifically, measurements have shown that 84% of the prefixes 100 specified in ROAs that use the maxLength attribute, are vulnerable to 101 a forged-origin subprefix hijack [HARMFUL]. The forged-origin prefix 102 or subprefix hijack involves inserting the legitimate AS as specified 103 in the ROA as the origin AS in the AS_PATH, and can be launched 104 against any IP prefix/subprefix that has a ROA. Consider a prefix/ 105 subprefix that has a ROA but is unused, i.e., not announced in BGP by 106 a legitimate AS. A forged origin hijack involving such a prefix/ 107 subprefix can propagate widely throughout the Internet. On the other 108 hand, if the prefix/subprefix were announced by the legitimate AS, 109 then the propagation of the forged-origin hijack is somewhat limited 110 because of its increased AS_PATH length relative to the legitimate 111 announcement. Of course, forged-origin hijacks are harmful in both 112 cases but the extent of harm is greater for unannounced prefixes. 114 For this reason, this document recommends that, whenever possible, 115 operators SHOULD use "minimal ROAs" that authorize only those IP 116 prefixes that are actually originated in BGP, and no other prefixes. 117 Further, it recommends ways to reduce forged-origin attack surface by 118 prudently limiting the address space that is included in Route Origin 119 Authorizations (ROAs). One recommendation is to avoid using the 120 maxLength attribute in ROAs except in some specific cases. The 121 recommendations complement and extend those in [RFC7115]. The 122 document also discusses creation of ROAs for facilitating the use of 123 Distributed Denial of Service (DDoS) mitigation services. 124 Considerations related to ROAs and origin validation in the context 125 of destination-based Remote Triggered Black Hole (RTBH) filtering are 126 also highlighted. 128 One ideal place to implement the ROA related recommendations is in 129 the user interfaces for configuring ROAs. Thus, this document 130 further recommends that designers and/or providers of such user 131 interfaces SHOULD provide warnings to draw the user's attention to 132 the risks of using the maxLength attribute. 134 Best current practices described in this document require no changes 135 to the RPKI specification and will not increase the number of signed 136 ROAs in the RPKI, because ROAs already support lists of IP prefixes 137 [RFC6482]. 139 1.1. Requirements 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 1.2. Documentation Prefixes 147 The documentation prefixes recommended in [RFC5737] are insufficient 148 for use as example prefixes in this document. Therefore, this 149 document uses [RFC1918] address space for constructing example 150 prefixes. 152 2. Suggested Reading 154 It is assumed that the reader understands BGP [RFC4271], RPKI 155 [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], RPKI-based 156 Prefix Validation [RFC6811], and BGPsec [RFC8205]. 158 3. Forged-Origin Subprefix Hijack 160 A detailed description and discussion of forged-origin subprefix 161 hijacks are presented here, especially considering the case when the 162 subprefix is not announced in BGP. The forged-origin subprefix 163 hijack is relevant to a scenario in which: 165 (1) the RPKI [RFC6480] is deployed, and 167 (2) routers use RPKI origin validation to drop invalid routes 168 [RFC6811], but 170 (3) BGPsec [RFC8205] (or any similar method to validate the 171 truthfulness of the BGP AS_PATH attribute) is not deployed. 173 Note that this set of assumptions accurately describes a substantial, 174 and growing, number of large Internet networks at the time writing. 176 The forged-origin subprefix hijack [RFC7115] [GCHSS] is described 177 here using a running example. 179 Consider the IP prefix 192.168.0.0/16 which is allocated to an 180 organization that also operates AS 64496. In BGP, AS 64496 181 originates the IP prefix 192.168.0.0/16 as well as its subprefix 182 192.168.225.0/24. Therefore, the RPKI should contain a ROA 183 authorizing AS 64496 to originate these two IP prefixes. 185 Suppose, however, the organization issues and publishes a ROA 186 including a maxLength value of 24: 188 ROA:(192.168.0.0/16-24, AS 64496) 190 We refer to the above as a "loose ROA" since it authorizes AS 64496 191 to originate any subprefix of 192.168.0.0/16 up to and including 192 length /24, rather than only those prefixes that are intended to be 193 announced in BGP. 195 Because AS 64496 only originates two prefixes in BGP: 192.168.0.0/16 196 and 192.168.225.0/24, all other prefixes authorized by the "loose 197 ROA" (for instance, 192.168.0.0/24), are vulnerable to the following 198 forged-origin subprefix hijack [RFC7115] [GCHSS]: 200 The hijacker AS 64511 sends a BGP announcement "192.168.0.0/24: AS 201 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 202 AS 64496 and falsely claiming that AS 64496 originates the IP 203 prefix 192.168.0.0/24. In fact, the IP prefix 192.168.0.0/24 is 204 not originated by AS 64496. 206 The hijacker's BGP announcement is valid according to the RPKI, 207 since the ROA (192.168.0.0/16-24, AS 64496) authorizes AS 64496 to 208 originate BGP routes for 192.168.0.0/24. 210 Because AS 64496 does not actually originate a route for 211 192.168.0.0/24, the hijacker's route is the *only* route to the 212 192.168.0.0/24. Longest-prefix-match routing ensures that the 213 hijacker's route to the subprefix 192.168.0.0/24 is always 214 preferred over the legitimate route to 192.168.0.0/16 originated 215 by AS 64496. 217 Thus, the hijacker's route propagates through the Internet, the 218 traffic destined for IP addresses in 192.168.0.0/24 will be delivered 219 to the hijacker. 221 The forged-origin *subprefix* hijack would have failed if a "minimal 222 ROA" described below was used instead of the "loose ROA". In this 223 example, a "minimal ROA" would be: 225 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 227 This ROA is "minimal" because it includes only those IP prefixes that 228 AS 64496 originates in BGP, but no other IP prefixes [RFC6907]. 230 The "minimal ROA" renders AS 64511's BGP announcement invalid, 231 because: 233 (1) this ROA "covers" the attacker's announcement (since 234 192.168.0.0/24 is a subprefix of 192.168.0.0/16), and 235 (2) there is no ROA "matching" the attacker's announcement (there 236 is no ROA for AS 64511 and IP prefix 192.168.0.0/24) [RFC6811]. 238 If routers ignore invalid BGP announcements, the minimal ROA above 239 ensures that the subprefix hijack will fail. 241 Thus, if a "minimal ROA" had been used, the attacker would be forced 242 to launch a forged-origin *prefix* hijack in order to attract 243 traffic, as follows: 245 The hijacker AS 64511 sends a BGP announcement "192.168.0.0/16: AS 246 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 247 AS 64496. 249 This forged-origin *prefix* hijack is significantly less damaging 250 than the forged-origin *subprefix* hijack: 252 AS 64496 legitimately originates 192.168.0.0/16 in BGP, so the 253 hijacker AS 64511 is not presenting the *only* route to 254 192.168.0.0/16. 256 Moreover, the path originated by AS 64511 is one hop longer than 257 the path originated by the legitimate origin AS 64496. 259 As discussed in [LSG16], this means that the hijacker will attract 260 less traffic than he would have in the forged-origin *subprefix* 261 hijack, where the hijacker presents the *only* route to the hijacked 262 subprefix. 264 In summary, a forged-origin subprefix hijack has the same impact as a 265 regular subprefix hijack, despite the increased AS_PATH length of the 266 illegitimate route. A forged-origin *subprefix* hijack is also more 267 damaging than forged-origin *prefix* hijack. 269 4. Measurements of Today's RPKI 271 Network measurements have shown that 12% of the IP prefixes 272 authorized in ROAs have a maxLength longer than their prefix length. 273 Of these, the vast majority (84%) are non-minimal, as they include 274 subprefixes that are not announced in BGP by the legitimate AS, and 275 are thus vulnerable to forged origin subprefix hijacks. See [GSG17] 276 for details. 278 These measurements suggest that operators commonly misconfigure the 279 maxLength attribute, and unwittingly open themselves up to forged- 280 origin subprefix hijacks. That is, they are exposing a much larger 281 attack surface for forged-origin hijacks than necessary. 283 5. Recommendations about Minimal ROAs and maxLength 285 Operators SHOULD use "minimal ROAs" whenever possible. A minimal ROA 286 contains only those IP prefixes that are actually originated by an AS 287 in BGP, and no other IP prefixes. (See Section 3 for an example.) 289 In general, except in some special cases, operators SHOULD avoid 290 using the maxLength attribute in their ROAs, since its inclusion will 291 usually make the ROA non-minimal. 293 One such exception may be when all more specific prefixes permitted 294 by the maxLength are actually announced by the AS in the ROA. 295 Another exception is where: (a) the maxLength is substantially larger 296 compared to the specified prefix length in the ROA, and (b) a large 297 number of more specific prefixes in that range are announced by the 298 AS in the ROA. This case should occur rarely in practice (if at 299 all). Operator discretion is necessary in this case. 301 This practice requires no changes to the RPKI specification and need 302 not increase the number of signed ROAs in the RPKI, because ROAs 303 already support lists of IP prefixes [RFC6482]. See also [GSG17] for 304 further discussion of why this practice will have minimal impact on 305 the performance of the RPKI ecosystem. 307 5.1. Facilitating Ad-hoc Routing Changes and DDoS Mitigation 309 Operational requirements may require that a route for an IP prefix be 310 originated on an ad-hoc basis, with little or no prior warning. An 311 example of such a situation arises where an operator wishes to make 312 use of DDoS mitigation services that use BGP to redirect traffic via 313 a "scrubbing center". 315 In order to ensure that such ad-hoc routing changes are effective, 316 there should exist a ROA validating the new route. However a 317 difficulty arises due to the fact that newly created objects in the 318 RPKI are made visible to relying parties considerabley more slowly 319 than routing updates in BGP. 321 Ideally, it would not be necessary to pre-create the ROA which 322 validates the ad-hoc route, and instead create it "on-the-fly" as 323 required. However, this is practical only if the latency imposed by 324 the propagation of RPKI data is guaranteed to be within acceptable 325 limits in the circumstances. For time-critical interventions such as 326 responding to a DDoS attack, this is unlikely to be the case. 328 Thus, the ROA in question will usually need to be created well in 329 advance of the routing intervention, but such a ROA will be non- 330 minimal, since it includes an IP prefix that is sometimes (but not 331 always) originated in BGP. 333 In this case, the ROA SHOULD include: 335 (1) the set of IP prefixes that are always originated in BGP, and 337 (2) the set IP prefixes that are sometimes, but not always, 338 originated in BGP. 340 The ROA SHOULD NOT include any IP prefixes that the operator knows 341 will not be originated in BGP. Whenever possible, the ROA SHOULD 342 also avoid the use of the maxLength attribute unless doing so has no 343 impact on the set of included prefixes. 345 The running example is now extended to illustrate one situation where 346 it is not possible to issue a minimal ROA. 348 Consider the following scenario prior to deployment of RPKI. Suppose 349 AS 64496 announced 192.168.0.0/16 and has a contract with a 350 Distributed Denial of Service (DDoS) mitigation service provider that 351 holds AS 64500. Further, assume that the DDoS mitigation service 352 contract applies to all IP addresses covered by 192.168.0.0/22. When 353 a DDoS attack is detected and reported by AS 64496, AS 64500 354 immediately originates 192.168.0.0/22, thus attracting all the DDoS 355 traffic to itself. The traffic is scrubbed at AS 64500 and then sent 356 back to AS 64496 over a backhaul data link. Notice that, during a 357 DDoS attack, the DDoS mitigation service provider AS 64500 originates 358 a /22 prefix that is longer than AS 64496's /16 prefix, and so all 359 the traffic (destined to addresses in 192.168.0.0/22) that normally 360 goes to AS 64496 goes to AS 64500 instead. In some deployments, the 361 origination of the /22 route is performed by AS 64496 and announced 362 only to AS 64500, which then announces transit for that prefix. This 363 variation does not change the properties considered here. 365 First, suppose the RPKI only had the minimal ROA for AS 64496, as 366 described in Section 3. But if there is no ROA authorizing AS 64500 367 to announce the /22 prefix, then the DDoS mitigation (and traffic 368 scrubbing) scheme would not work. That is, if AS 64500 originates 369 the /22 prefix in BGP during DDoS attacks, the announcement would be 370 invalid [RFC6811]. 372 Therefore, the RPKI should have two ROAs: one for AS 64496 and one 373 for AS 64500. 375 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 376 ROA:(192.168.0.0/22, AS 64500) 378 Neither ROA uses the maxLength attribute. But the second ROA is not 379 "minimal" because it contains a /22 prefix that is not originated by 380 anyone in BGP during normal operations. The /22 prefix is only 381 originated by AS 64500 as part of its DDoS mitigation service during 382 a DDoS attack. 384 Notice, however, that this scheme does not come without risks. 385 Namely, all IP addresses in 192.168.0.0/22 are vulnerable to a 386 forged-origin subprefix hijack during normal operations, when the /22 387 prefix is not originated. (The hijacker AS 64511 would send the BGP 388 announcement "192.168.0.0/22: AS 64511, AS 64500", falsely claiming 389 that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS 390 64500 originates 192.168.0.0/22.) 392 In some situations, the DDoS mitigation service at AS 64500 might 393 want to limit the amount of DDoS traffic that it attracts and scrubs. 394 Suppose that a DDoS attack only targets IP addresses in 395 192.168.0.0/24. Then, the DDoS mitigation service at AS 64500 only 396 wants to attract the traffic designated for the /24 prefix that is 397 under attack, but not the entire /22 prefix. To allow for this, the 398 RPKI should have two ROAs: one for AS 64496 and one for AS 64500. 400 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 402 ROA:(192.168.0.0/22-24, AS 64500) 404 The second ROA uses the maxLength attribute because it is designed to 405 explicitly enable AS 64500 to originate *any* /24 subprefix of 406 192.168.0.0/22. 408 As before, the second ROA is not "minimal" because it contains 409 prefixes that are not originated by anyone in BGP during normal 410 operations. As before, all IP addresses in 192.168.0.0/22 are 411 vulnerable to a forged-origin subprefix hijack during normal 412 operations, when the /22 prefix is not originated. 414 The use of maxLength in this second ROA also comes with an additional 415 risk. While it permits the DDoS mitigation service at AS 64500 to 416 originate prefix 192.168.0.0/24 during a DDoS attack in that space, 417 it also makes the *other* /24 prefixes covered by the /22 prefix 418 (i.e., 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24) vulnerable to 419 a forged-origin subprefix attacks. 421 5.2. Defensive de-aggregation in response to prefix hijacks 423 In responding to certain classes of prefix hijack, in particular the 424 forged-origin subprefix hijack described above, it may be desirable 425 for the victim to perform "defensive de-aggregation". That is: to 426 begin originating more-specific prefixes in order to compete with the 427 hijack routes for selection as best path in networks that are not 428 performing RPKI-based route origin validation [RFC6811]. 430 In some topologies, where at least one AS on every path between the 431 victim and hijacker filters ROV invalid prefixes, it may be the case 432 that the existence of a minimal ROA issued by the victim prevents the 433 defensive more- specific prefixes being propagated to the networks 434 topologically close to the attacker, thus hampering the effectiveness 435 of this response. 437 Nevertheless, this document recommends that where possible, network 438 operators publish minimal ROAs even in the face of this risk. This 439 is because: 441 * Minimal ROAs offer the best possible protection against the 442 immediate impact of such an attack, rendering the need for such a 443 response less likely; 445 * Increasing ROV adoption by network operators will, over time, 446 decrease the size of the neighborhoods in which this risk exists; 447 and 449 * Other methods for reducing the size of such neighborhoods are 450 available to potential victims, such as establishing direct eBGP 451 adjacencies with networks from whom the defensive routes would 452 otherwise be hidden. 454 6. Considerations for RTBH Filtering Scenarios 456 Considerations related to ROAs and origin validation [RFC6811] for 457 the case of destination-based Remote Triggered Black Hole (RTBH) 458 filtering are addressed here. In RTBH filtering, highly specific 459 prefixes (greater than /24 in IPv4 and greater than /48 in IPv6; 460 possibly even /32 (IPv4) and /128 (IPv6)) are announced in BGP. 461 These announcements are tagged with a BLACKHOLE Community [RFC7999]. 462 It is obviously not desirable to use large maxlength or include any 463 such highly specific prefixes in the ROAs to accommodate destination- 464 based RTBH filtering, for the reasons set out above. 466 As a result, RPKI based route origin validation [RFC6811] is a poor 467 fit for the validation of RTBH routes. Specification of new 468 procedures to address this use case through the use of the RPKI is 469 outside the scope of this document. 471 Therefore: 473 * Operators SHOULD NOT create non-minimal ROAs (either by creating 474 additional ROAs, or through the use of maxLength) for the purpose 475 of advertising RTBH routes; and 477 * Operators providing a means for operators of neighboring 478 autonomous systems to advertise RTBH routes via BGP MUST NOT make 479 the creation of non-minimal ROAs a pre-requisite for its use. 481 7. Acknowledgments 483 The authors would like to thank the following people for their review 484 and contributions to this document: Omar Sagga (Boston University) 485 and Aris Lambrianidis (AMS-IX). Thanks are also due to Matthias 486 Waehlisch (Free University of Berlin) for comments and suggestions. 488 8. References 490 8.1. Normative References 492 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 493 J., and E. Lear, "Address Allocation for Private 494 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 495 February 1996, . 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 503 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 504 DOI 10.17487/RFC4271, January 2006, 505 . 507 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 508 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 509 February 2012, . 511 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 512 Origin Authorizations (ROAs)", RFC 6482, 513 DOI 10.17487/RFC6482, February 2012, 514 . 516 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 517 Austein, "BGP Prefix Origin Validation", RFC 6811, 518 DOI 10.17487/RFC6811, January 2013, 519 . 521 8.2. Informative References 523 [GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "Maxlength 524 Considered Harmful to the RPKI", in ACM CoNEXT 2017, 525 December 2017, . 527 [LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking 528 Security for Internet Routing", in Communications of the 529 ACM, October 2016, . 533 [GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 534 Shulman, "Are We There Yet? On RPKI's Deployment and 535 Security", in NDSS 2017, February 2017, 536 . 538 [HARMFUL] Gilad, Y., Sagga, O., and S. Goldberg, "MaxLength 539 Considered Harmful to the RPKI", 2017, 540 . 542 [NIST-800-189] 543 Sriram, K. and D. Montgomery, "Resilient Interdomain 544 Traffic Exchange: BGP Security and DDoS Mitigation", NIST 545 Special Publication, NIST SP 800-189, December 2019, 546 . 549 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 550 Reserved for Documentation", RFC 5737, 551 DOI 10.17487/RFC5737, January 2010, 552 . 554 [RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and 555 Interpretations of Resource Public Key Infrastructure 556 (RPKI) Objects for Issuers and Relying Parties", RFC 6907, 557 DOI 10.17487/RFC6907, March 2013, 558 . 560 [RFC7115] Bush, R., "Origin Validation Operation Based on the 561 Resource Public Key Infrastructure (RPKI)", BCP 185, 562 RFC 7115, DOI 10.17487/RFC7115, January 2014, 563 . 565 [RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. 566 Hankins, "BLACKHOLE Community", RFC 7999, 567 DOI 10.17487/RFC7999, October 2016, 568 . 570 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 571 Specification", RFC 8205, DOI 10.17487/RFC8205, September 572 2017, . 574 Authors' Addresses 576 Yossi Gilad 577 Hebrew University of Jerusalem 578 Rothburg Family Buildings, Edmond J. Safra Campus 579 Jerusalem 9190416 580 Israel 582 Email: yossigi@cs.huji.ac.il 584 Sharon Goldberg 585 Boston University 586 111 Cummington St, MCS135 587 Boston, MA 02215 588 United States of America 590 Email: goldbe@cs.bu.edu 592 Kotikalapudi Sriram 593 USA National Institute of Standards and Technology 594 100 Bureau Drive 595 Gaithersburg, MD 20899 596 United States of America 598 Email: kotikalapudi.sriram@nist.gov 600 Job Snijders 601 Fastly 602 Amsterdam 603 Netherlands 604 Email: job@fastly.com 606 Ben Maddison 607 Workonline Communications 608 114 West St 609 Johannesburg 610 2196 611 South Africa 613 Email: benm@workonline.africa