idnits 2.17.1 draft-ietf-sidrops-rpkimaxlen-10.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 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 (3 May 2022) is 722 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) Y. Gilad 3 Internet-Draft Hebrew University of Jerusalem 4 Intended status: Best Current Practice S. Goldberg 5 Expires: 4 November 2022 Boston University 6 K. Sriram 7 USA NIST 8 J. Snijders 9 Fastly 10 B. Maddison 11 Workonline Communications 12 3 May 2022 14 The Use of maxLength in the RPKI 15 draft-ietf-sidrops-rpkimaxlen-10 17 Abstract 19 This document recommends ways to reduce the forged-origin hijack 20 attack 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 the 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 4 November 2022. 47 Copyright Notice 49 Copyright (c) 2022 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 Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised 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 the 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 . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 10.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The RPKI [RFC6480] uses Route Origin Authorizations (ROAs) to create 85 a cryptographically verifiable mapping from an IP prefix to a set of 86 autonomous systems (ASes) that are authorized to originate that 87 prefix. Each ROA contains a set of IP prefixes, and an AS number of 88 an AS authorized to originate all the IP prefixes in the set 89 [RFC6482]. The ROA is cryptographically signed by the party that 90 holds a certificate for the set of IP prefixes. 92 The ROA format also supports a maxLength attribute. According to 93 [RFC6482], "When present, the maxLength specifies the maximum length 94 of the IP address prefix that the AS is authorized to advertise." 95 Thus, rather than requiring the ROA to list each prefix that the AS 96 is authorized to originate, the maxLength attribute provides a 97 shorthand that authorizes an AS to originate a set of IP prefixes. 99 However, measurements of RPKI deployments have found that the use of 100 the maxLength in ROAs tends to lead to security problems. In 101 particular, measurements taken in June 2017 showed that 84% of the 102 prefixes specified in ROAs that use the maxLength attribute, were 103 vulnerable to a forged-origin subprefix hijack [HARMFUL]. The 104 forged-origin prefix or subprefix hijack involves inserting the 105 legitimate AS as specified in the ROA as the origin AS in the 106 AS_PATH, and can be launched against any IP prefix/subprefix that has 107 a ROA. Consider a prefix/subprefix that has a ROA but is unused, 108 i.e., not announced in BGP by a legitimate AS. A forged origin 109 hijack involving such a prefix/subprefix can propagate widely 110 throughout the Internet. On the other hand, if the prefix/subprefix 111 were announced by the legitimate AS, then the propagation of the 112 forged-origin hijack is somewhat limited because of its increased 113 AS_PATH length relative to the legitimate announcement. Of course, 114 forged-origin hijacks are harmful in both cases but the extent of 115 harm is greater for unannounced prefixes. 117 For this reason, this document recommends that, whenever possible, 118 operators SHOULD use "minimal ROAs" that authorize only those IP 119 prefixes that are actually originated in BGP, and no other prefixes. 120 Further, it recommends ways to reduce the forged-origin attack 121 surface by prudently limiting the address space that is included in 122 Route Origin Authorizations (ROAs). One recommendation is to avoid 123 using the maxLength attribute in ROAs except in some specific cases. 124 The recommendations complement and extend those in [RFC7115]. The 125 document also discusses the creation of ROAs for facilitating the use 126 of Distributed Denial of Service (DDoS) mitigation services. 127 Considerations related to ROAs and origin validation in the context 128 of destination-based Remote Triggered Black Hole (RTBH) filtering are 129 also highlighted. 131 One ideal place to implement the ROA related recommendations is in 132 the user interfaces for configuring ROAs. Thus, this document 133 further recommends that designers and/or providers of such user 134 interfaces SHOULD provide warnings to draw the user's attention to 135 the risks of using the maxLength attribute. 137 Best current practices described in this document require no changes 138 to the RPKI specification and will not increase the number of signed 139 ROAs in the RPKI, because ROAs already support lists of IP prefixes 140 [RFC6482]. 142 1.1. Requirements 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 1.2. Documentation Prefixes 150 The documentation prefixes recommended in [RFC5737] are insufficient 151 for use as example prefixes in this document. Therefore, this 152 document uses [RFC1918] address space for constructing example 153 prefixes. 155 2. Suggested Reading 157 It is assumed that the reader understands BGP [RFC4271], RPKI 158 [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], RPKI-based 159 Prefix Validation [RFC6811], and BGPsec [RFC8205]. 161 3. Forged-Origin Subprefix Hijack 163 A detailed description and discussion of forged-origin subprefix 164 hijacks are presented here, especially considering the case when the 165 subprefix is not announced in BGP. The forged-origin subprefix 166 hijack is relevant to a scenario in which: 168 (1) the RPKI [RFC6480] is deployed, and 170 (2) routers use RPKI origin validation to drop invalid routes 171 [RFC6811], but 173 (3) BGPsec [RFC8205] (or any similar method to validate the 174 truthfulness of the BGP AS_PATH attribute) is not deployed. 176 Note that this set of assumptions accurately describes a substantial 177 and growing number of large Internet networks at the time of writing. 179 The forged-origin subprefix hijack [RFC7115] [GCHSS] is described 180 here using a running example. 182 Consider the IP prefix 192.168.0.0/16 which is allocated to an 183 organization that also operates AS 64496. In BGP, AS 64496 184 originates the IP prefix 192.168.0.0/16 as well as its subprefix 185 192.168.225.0/24. Therefore, the RPKI should contain a ROA 186 authorizing AS 64496 to originate these two IP prefixes. 188 Suppose, however, the organization issues and publishes a ROA 189 including a maxLength value of 24: 191 ROA:(192.168.0.0/16-24, AS 64496) 193 We refer to the above as a "loose ROA" since it authorizes AS 64496 194 to originate any subprefix of 192.168.0.0/16 up to and including 195 length /24, rather than only those prefixes that are intended to be 196 announced in BGP. 198 Because AS 64496 only originates two prefixes in BGP: 192.168.0.0/16 199 and 192.168.225.0/24, all other prefixes authorized by the "loose 200 ROA" (for instance, 192.168.0.0/24), are vulnerable to the following 201 forged-origin subprefix hijack [RFC7115] [GCHSS]: 203 The hijacker AS 64511 sends a BGP announcement "192.168.0.0/24: AS 204 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 205 AS 64496 and falsely claiming that AS 64496 originates the IP 206 prefix 192.168.0.0/24. In fact, the IP prefix 192.168.0.0/24 is 207 not originated by AS 64496. 209 The hijacker's BGP announcement is valid according to the RPKI 210 since the ROA (192.168.0.0/16-24, AS 64496) authorizes AS 64496 to 211 originate BGP routes for 192.168.0.0/24. 213 Because AS 64496 does not actually originate a route for 214 192.168.0.0/24, the hijacker's route is the *only* route to the 215 192.168.0.0/24. The longest-prefix-match routing ensures that the 216 hijacker's route to the subprefix 192.168.0.0/24 is always 217 preferred over the legitimate route to 192.168.0.0/16 originated 218 by AS 64496. 220 Thus, the hijacker's route propagates through the Internet, the 221 traffic destined for IP addresses in 192.168.0.0/24 will be delivered 222 to the hijacker. 224 The forged-origin *subprefix* hijack would have failed if a "minimal 225 ROA" described below was used instead of the "loose ROA". In this 226 example, a "minimal ROA" would be: 228 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 230 This ROA is "minimal" because it includes only those IP prefixes that 231 AS 64496 originates in BGP, but no other IP prefixes [RFC6907]. 233 The "minimal ROA" renders AS 64511's BGP announcement invalid, 234 because: 236 (1) this ROA "covers" the attacker's announcement (since 237 192.168.0.0/24 is a subprefix of 192.168.0.0/16), and 238 (2) there is no ROA "matching" the attacker's announcement (there 239 is no ROA for AS 64511 and IP prefix 192.168.0.0/24) [RFC6811]. 241 If routers ignore invalid BGP announcements, the minimal ROA above 242 ensures that the subprefix hijack will fail. 244 Thus, if a "minimal ROA" had been used, the attacker would be forced 245 to launch a forged-origin *prefix* hijack in order to attract 246 traffic, as follows: 248 The hijacker AS 64511 sends a BGP announcement "192.168.0.0/16: AS 249 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 250 AS 64496. 252 This forged-origin *prefix* hijack is significantly less damaging 253 than the forged-origin *subprefix* hijack: 255 AS 64496 legitimately originates 192.168.0.0/16 in BGP, so the 256 hijacker AS 64511 is not presenting the *only* route to 257 192.168.0.0/16. 259 Moreover, the path originated by AS 64511 is one hop longer than 260 the path originated by the legitimate origin AS 64496. 262 As discussed in [LSG16], this means that the hijacker will attract 263 less traffic than he would have in the forged-origin *subprefix* 264 hijack, where the hijacker presents the *only* route to the hijacked 265 subprefix. 267 In summary, a forged-origin subprefix hijack has the same impact as a 268 regular subprefix hijack, despite the increased AS_PATH length of the 269 illegitimate route. A forged-origin *subprefix* hijack is also more 270 damaging than the forged-origin *prefix* hijack. 272 4. Measurements of the RPKI 274 Network measurements taken in June 2017 showed that 12% of the IP 275 prefixes authorized in ROAs have a maxLength longer than their prefix 276 length. Of these, the vast majority (84%) were non-minimal, as they 277 included subprefixes that are not announced in BGP by the legitimate 278 AS, and were thus vulnerable to forged-origin subprefix hijacks. See 279 [GSG17] for details. 281 These measurements suggest that operators commonly misconfigure the 282 maxLength attribute, and unwittingly open themselves up to forged- 283 origin subprefix hijacks. That is, they are exposing a much larger 284 attack surface for forged-origin hijacks than necessary. 286 5. Recommendations about Minimal ROAs and maxLength 288 Operators SHOULD use "minimal ROAs" whenever possible. A minimal ROA 289 contains only those IP prefixes that are actually originated by an AS 290 in BGP and no other IP prefixes. (See Section 3 for an example.) 292 In general, except in some special cases, operators SHOULD avoid 293 using the maxLength attribute in their ROAs, since its inclusion will 294 usually make the ROA non-minimal. 296 One such exception maybe when all more specific prefixes permitted by 297 the maxLength are actually announced by the AS in the ROA. Another 298 exception is where: (a) the maxLength is substantially larger 299 compared to the specified prefix length in the ROA, and (b) a large 300 number of more specific prefixes in that range are announced by the 301 AS in the ROA. This case should occur rarely in practice (if at 302 all). Operator discretion is necessary in this case. 304 This practice requires no changes to the RPKI specification and need 305 not increase the number of signed ROAs in the RPKI, because ROAs 306 already support lists of IP prefixes [RFC6482]. See also [GSG17] for 307 further discussion of why this practice will have minimal impact on 308 the performance of the RPKI ecosystem. 310 Operators that have existing ROAs published in the RPKI system SHOULD 311 perform a review of such objects, especially where they make use of 312 the maxLength attribute, to ensure that the set of included prefixes 313 is "minimal" with respect to the current BGP origination and routing 314 policies, and replace the published ROAs as necessary. Such an 315 exercise SHOULD be repeated whenever the operator makes changes to 316 either policy. 318 5.1. Facilitating Ad-hoc Routing Changes and DDoS Mitigation 320 Operational requirements may require that a route for an IP prefix be 321 originated on an ad-hoc basis, with little or no prior warning. An 322 example of such a situation arises when an operator wishes to make 323 use of DDoS mitigation services that use BGP to redirect traffic via 324 a "scrubbing center". 326 In order to ensure that such ad-hoc routing changes are effective, 327 there should exist a ROA validating the new route. However a 328 difficulty arises due to the fact that newly created objects in the 329 RPKI are made visible to relying parties considerably more slowly 330 than routing updates in BGP. 332 Ideally, it would not be necessary to pre-create the ROA which 333 validates the ad-hoc route; instead create it "on-the-fly" as 334 required. However, this is practical only if the latency imposed by 335 the propagation of RPKI data is guaranteed to be within acceptable 336 limits in the circumstances. For time-critical interventions such as 337 responding to a DDoS attack, this is unlikely to be the case. 339 Thus, the ROA in question will usually need to be created well in 340 advance of the routing intervention, but such a ROA will be non- 341 minimal, since it includes an IP prefix that is sometimes (but not 342 always) originated in BGP. 344 In this case, the ROA SHOULD include only: 346 (1) the set of IP prefixes that are always originated in BGP, and 348 (2) the set of IP prefixes that are sometimes, but not always, 349 originated in BGP. 351 The ROA SHOULD NOT include any IP prefixes that the operator knows 352 will not be originated in BGP. In general, the ROA SHOULD NOT make 353 use of the maxLength attribute unless doing so has no impact on the 354 set of included prefixes. 356 The running example is now extended to illustrate one situation where 357 it is not possible to issue a minimal ROA. 359 Consider the following scenario prior to the deployment of RPKI. 360 Suppose AS 64496 announced 192.168.0.0/16 and has a contract with a 361 Distributed Denial of Service (DDoS) mitigation service provider that 362 holds AS 64500. Further, assume that the DDoS mitigation service 363 contract applies to all IP addresses covered by 192.168.0.0/22. When 364 a DDoS attack is detected and reported by AS 64496, AS 64500 365 immediately originates 192.168.0.0/22, thus attracting all the DDoS 366 traffic to itself. The traffic is scrubbed at AS 64500 and then sent 367 back to AS 64496 over a backhaul data link. Notice that, during a 368 DDoS attack, the DDoS mitigation service provider AS 64500 originates 369 a /22 prefix that is longer than AS 64496's /16 prefix, and so all 370 the traffic (destined to addresses in 192.168.0.0/22) that normally 371 goes to AS 64496 goes to AS 64500 instead. In some deployments, the 372 origination of the /22 route is performed by AS 64496 and announced 373 only to AS 64500, which then announces transit for that prefix. This 374 variation does not change the properties considered here. 376 First, suppose the RPKI only had the minimal ROA for AS 64496, as 377 described in Section 3. But if there is no ROA authorizing AS 64500 378 to announce the /22 prefix, then the DDoS mitigation (and traffic 379 scrubbing) scheme would not work. That is if AS 64500 originates the 380 /22 prefix in BGP during DDoS attacks, the announcement would be 381 invalid [RFC6811]. 383 Therefore, the RPKI should have two ROAs: one for AS 64496 and one 384 for AS 64500. 386 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 388 ROA:(192.168.0.0/22, AS 64500) 390 Neither ROA uses the maxLength attribute. But the second ROA is not 391 "minimal" because it contains a /22 prefix that is not originated by 392 anyone in BGP during normal operations. The /22 prefix is only 393 originated by AS 64500 as part of its DDoS mitigation service during 394 a DDoS attack. 396 Notice, however, that this scheme does not come without risks. 397 Namely, all IP addresses in 192.168.0.0/22 are vulnerable to a 398 forged-origin subprefix hijack during normal operations, when the /22 399 prefix is not originated. (The hijacker AS 64511 would send the BGP 400 announcement "192.168.0.0/22: AS 64511, AS 64500", falsely claiming 401 that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS 402 64500 originates 192.168.0.0/22.) 404 In some situations, the DDoS mitigation service at AS 64500 might 405 want to limit the amount of DDoS traffic that it attracts and scrubs. 406 Suppose that a DDoS attack only targets IP addresses in 407 192.168.0.0/24. Then, the DDoS mitigation service at AS 64500 only 408 wants to attract the traffic designated for the /24 prefix that is 409 under attack, but not the entire /22 prefix. To allow for this, the 410 RPKI should have two ROAs: one for AS 64496 and one for AS 64500. 412 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 414 ROA:(192.168.0.0/22-24, AS 64500) 416 The second ROA uses the maxLength attribute because it is designed to 417 explicitly enable AS 64500 to originate *any* /24 subprefix of 418 192.168.0.0/22. 420 As before, the second ROA is not "minimal" because it contains 421 prefixes that are not originated by anyone in BGP during normal 422 operations. As before, all IP addresses in 192.168.0.0/22 are 423 vulnerable to a forged-origin subprefix hijack during normal 424 operations, when the /22 prefix is not originated. 426 The use of maxLength in this second ROA also comes with additional 427 risk. While it permits the DDoS mitigation service at AS 64500 to 428 originate prefix 192.168.0.0/24 during a DDoS attack in that space, 429 it also makes the *other* /24 prefixes covered by the /22 prefix 430 (i.e., 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24) vulnerable to 431 a forged-origin subprefix attacks. 433 5.2. Defensive de-aggregation in response to prefix hijacks 435 In responding to certain classes of prefix hijack, in particular, the 436 forged-origin subprefix hijack described above, it may be desirable 437 for the victim to perform "defensive de-aggregation". I.e., begin 438 originating more-specific prefixes in order to compete with the 439 hijacked route for selection as the best path in networks that are 440 not performing RPKI-based route origin validation [RFC6811]. 442 In some topologies, where at least one AS on every path between the 443 victim and hijacker filters ROV invalid prefixes, it may be the case 444 that the existence of a minimal ROA issued by the victim prevents the 445 defensive more-specific prefixes being propagated to the networks 446 topologically close to the attacker, thus hampering the effectiveness 447 of this response. 449 Nevertheless, this document recommends that where possible, network 450 operators publish minimal ROAs even in the face of this risk. This 451 is because: 453 * Minimal ROAs offer the best possible protection against the 454 immediate impact of such an attack, rendering the need for such a 455 response less likely; 457 * Increasing ROV adoption by network operators will, over time, 458 decrease the size of the neighborhoods in which this risk exists; 459 and 461 * Other methods for reducing the size of such neighborhoods are 462 available to potential victims, such as establishing direct eBGP 463 adjacencies with networks from whom the defensive routes would 464 otherwise be hidden. 466 6. Considerations for RTBH Filtering Scenarios 468 Considerations related to ROAs and origin validation [RFC6811] for 469 the case of destination-based Remote Triggered Black Hole (RTBH) 470 filtering are addressed here. In RTBH filtering, highly specific 471 prefixes (greater than /24 in IPv4 and greater than /48 in IPv6; 472 possibly even /32 (IPv4) and /128 (IPv6)) are announced in BGP. 473 These announcements are tagged with a BLACKHOLE Community [RFC7999]. 474 It is obviously not desirable to use a large maxLength or include any 475 such highly specific prefixes in the ROAs to accommodate destination- 476 based RTBH filtering, for the reasons set out above. 478 As a result, RPKI-based route origin validation [RFC6811] is a poor 479 fit for the validation of RTBH routes. Specification of new 480 procedures to address this use case through the use of the RPKI is 481 outside the scope of this document. 483 Therefore: 485 * Operators SHOULD NOT create non-minimal ROAs (either by creating 486 additional ROAs, or through the use of maxLength) for the purpose 487 of advertising RTBH routes; and 489 * Operators providing a means for operators of neighboring 490 autonomous systems to advertise RTBH routes via BGP MUST NOT make 491 the creation of non-minimal ROAs a pre-requisite for its use. 493 7. IANA Considerations 495 This document includes no request to IANA. 497 8. Security Considerations 499 This document makes recommendations regarding the use of RPKI-based 500 origin validation as defined in [RFC6811], and as such introduces no 501 additional security considerations beyond those set out therein. 503 The recommendations set out in this document, in particular, those in 504 Section 5, involve trade-offs between operational agility and 505 security. Operators are encouraged to carefully review the issues 506 highlighted in light of their specific operational requirements. 507 Failure to do so could, in the worst case, result in a self-inflicted 508 denial of service. 510 9. Acknowledgments 512 The authors would like to thank the following people for their review 513 and contributions to this document: Omar Sagga and Aris Lambrianidis. 514 Thanks are also due to Matthias Waehlisch, Ties de Kock, and Amreesh 515 Phokeer for comments and suggestions. 517 10. References 519 10.1. Normative References 521 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 522 J., and E. Lear, "Address Allocation for Private 523 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 524 February 1996, . 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, 528 DOI 10.17487/RFC2119, March 1997, 529 . 531 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 532 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 533 DOI 10.17487/RFC4271, January 2006, 534 . 536 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 537 Origin Authorizations (ROAs)", RFC 6482, 538 DOI 10.17487/RFC6482, February 2012, 539 . 541 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 542 Austein, "BGP Prefix Origin Validation", RFC 6811, 543 DOI 10.17487/RFC6811, January 2013, 544 . 546 10.2. Informative References 548 [GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 549 Shulman, "Are We There Yet? On RPKI's Deployment and 550 Security", in NDSS 2017, February 2017, 551 . 553 [GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "Maxlength 554 Considered Harmful to the RPKI", in ACM CoNEXT 2017, 555 December 2017, . 557 [HARMFUL] Gilad, Y., Sagga, O., and S. Goldberg, "MaxLength 558 Considered Harmful to the RPKI", 2017, 559 . 561 [LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking 562 Security for Internet Routing", in Communications of the 563 ACM, October 2016, . 567 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 568 Reserved for Documentation", RFC 5737, 569 DOI 10.17487/RFC5737, January 2010, 570 . 572 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 573 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 574 February 2012, . 576 [RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and 577 Interpretations of Resource Public Key Infrastructure 578 (RPKI) Objects for Issuers and Relying Parties", RFC 6907, 579 DOI 10.17487/RFC6907, March 2013, 580 . 582 [RFC7115] Bush, R., "Origin Validation Operation Based on the 583 Resource Public Key Infrastructure (RPKI)", BCP 185, 584 RFC 7115, DOI 10.17487/RFC7115, January 2014, 585 . 587 [RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. 588 Hankins, "BLACKHOLE Community", RFC 7999, 589 DOI 10.17487/RFC7999, October 2016, 590 . 592 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 593 Specification", RFC 8205, DOI 10.17487/RFC8205, September 594 2017, . 596 Authors' Addresses 598 Yossi Gilad 599 Hebrew University of Jerusalem 600 Rothburg Family Buildings, Edmond J. Safra Campus 601 Jerusalem 9190416 602 Israel 603 Email: yossigi@cs.huji.ac.il 604 Sharon Goldberg 605 Boston University 606 111 Cummington St, MCS135 607 Boston, MA 02215 608 United States of America 609 Email: goldbe@cs.bu.edu 611 Kotikalapudi Sriram 612 USA National Institute of Standards and Technology 613 100 Bureau Drive 614 Gaithersburg, MD 20899 615 United States of America 616 Email: kotikalapudi.sriram@nist.gov 618 Job Snijders 619 Fastly 620 Amsterdam 621 Netherlands 622 Email: job@fastly.com 624 Ben Maddison 625 Workonline Communications 626 114 West St 627 Johannesburg 628 2196 629 South Africa 630 Email: benm@workonline.africa