idnits 2.17.1 draft-ietf-sidrops-rpkimaxlen-04.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 38 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 (May 9, 2020) is 1446 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) == Missing Reference: 'RFC5737' is mentioned on line 144, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6480 Summary: 3 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 Hebrew University of Jerusalem 4 Intended status: Best Current Practice S. Goldberg 5 Expires: November 10, 2020 Boston University 6 K. Sriram 7 USA NIST 8 J. Snijders 9 NTT 10 B. Maddison 11 Workonline Communications 12 May 9, 2020 14 The Use of Maxlength in the RPKI 15 draft-ietf-sidrops-rpkimaxlen-04 17 Abstract 19 This document recommends ways to reduce forged-origin attack surface 20 by prudently limiting the address space that is included in Route 21 Origin Authorizations (ROAs). One recommendation is to avoid using 22 the maxLength attribute in ROAs except in some specific cases. The 23 recommendations complement and extend those in RFC 7115. The 24 document also discusses creation of ROAs for facilitating Distributed 25 Denial of Service (DDoS) mitigation services. Considerations related 26 to ROAs and origin validation for the case of destination-based 27 Remote Triggered Black Hole (RTBH) filtering are also highlighted. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 10, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . 6 70 5.1. Creation of ROAs Facilitating DDoS Mitigation Service . . 7 71 6. ROAs and Origin Validation for RTBH Filtering Scenario . . . 9 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 The RPKI [RFC6480] uses Route Origin Authorizations (ROAs) to create 81 a cryptographically verifiable mapping from an IP prefix to a set of 82 autonomous systems (ASes) that are authorized to originate this 83 prefix. Each ROA contains a set of IP prefixes, and an AS number of 84 an AS authorized to originate all the IP prefixes in the set 85 [RFC6482]. The ROA is cryptographically signed by the party that 86 holds a certificate for the set of IP prefixes. 88 The ROA format also supports a maxLength attribute. According to 89 [RFC6482], "When present, the maxLength specifies the maximum length 90 of the IP address prefix that the AS is authorized to advertise." 91 Thus, rather than requiring the ROA to list each prefix the AS is 92 authorized to originate, the maxLength attribute provides a shorthand 93 that authorizes an AS to originate a set of IP prefixes. 95 However, measurements of current RPKI deployments have found that use 96 of the maxLength in ROAs tends to lead to security problems. 97 Specifically, measurements have shown that 84% of the prefixes 98 specified in ROAs that use the maxLength attribute, are vulnerable to 99 a forged-origin subprefix hijack [HARMFUL]. The forged-origin prefix 100 or subprefix hijack involves inserting the legitimate AS (as 101 specified in the ROA) as the origin AS, and can be launched against 102 any IP prefix/subprefix that has a ROA. Consider a prefix/subprefix 103 that has a ROA but is unused, i.e., not announced in BGP by a 104 legitimate AS. A forged-origin hijack involving such a prefix/ 105 subprefix can propagate widely throughout the Internet. On the other 106 hand, if the prefix/subprefix were announced by the legitimate AS, 107 then the propagation of the forged-origin hijack is somewhat limited 108 because of its increased path length relative to the legitimate 109 announcement. Of course, forged-origin hijacks are harmful in both 110 cases but the extent of harm is greater for unannounced prefixes. 112 For this reason, this document recommends that, whenever possible, 113 operators SHOULD use "minimal ROAs" that include only those IP 114 prefixes that are actually originated in BGP, and no other prefixes. 115 Further, it recommends ways to reduce forged-origin attack surface by 116 prudently limiting the address space that is included in Route Origin 117 Authorizations (ROAs). One recommendation is to avoid using the 118 maxLength attribute in ROAs except in some specific cases. The 119 recommendations complement and extend those in [RFC7115]. The 120 document also discusses creation of ROAs for facilitating Distributed 121 Denial of Service (DDoS) mitigation services. Considerations related 122 to ROAs and origin validation for the case of destination-based 123 Remote Triggered Black Hole (RTBH) filtering are also highlighted. 125 One ideal place to implement the ROA related recommendations is in 126 the user interfaces for configuring ROAs. Thus, this document 127 further recommends that designers and/or providers of such user 128 interfaces SHOULD provide warnings to draw the user's attention to 129 the risks of using the maxLength attribute. 131 Best current practices described in this document require no changes 132 to the RPKI specification and will not increase the number of signed 133 ROAs in the RPKI, because ROAs already support lists of IP prefixes 134 [RFC6482]. 136 1.1. Requirements 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 1.2. Documentation Prefixes 144 The documentation prefixes recommended in [RFC5737] are insufficient 145 for use as example prefixes in this document. Therefore, this 146 document uses [RFC1918] address space for constructing example 147 prefixes. 149 2. Suggested Reading 151 It is assumed that the reader understands BGP [RFC4271], RPKI 152 [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], RPKI-based 153 Prefix Validation [RFC6811], and BGPsec [RFC8205]. 155 3. Forged-Origin Subprefix Hijack 157 A detailed description and discussion of forged-origin subprefix 158 hijack are presented here, especially considering the case when the 159 subprefix is not announced in BGP. The forged-origin subprefix 160 hijack is relevant to a scenario in which (1) the RPKI [RFC6480] is 161 deployed, and (2) routers use RPKI origin validation to drop invalid 162 routes [RFC6811], but (3) BGPsec [RFC8205] (or any similar method to 163 validate the truthfulness of the BGP AS_PATH attribute) is not 164 deployed. 166 The forged-origin subprefix hijack [RFC7115] [GCHSS] is described 167 here using a running example. 169 Consider the IP prefix 192.168.0.0/16 which is allocated to an 170 organization that also operates AS 64496. In BGP, AS 64496 171 originates the IP prefix 192.168.0.0/16 as well as its subprefix 172 192.168.225.0/24. Therefore, the RPKI should contain a ROA 173 authorizing AS 64496 to originate these two IP prefixes. That is, 174 the ROA should be 176 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 178 This ROA is "minimal" because it includes only those IP prefixes that 179 AS 64496 originates in BGP, but no other IP prefixes [RFC6907]. 181 Now suppose an attacking AS 64511 originates a BGP announcement for a 182 subprefix 192.168.0.0/24. This is a standard "subprefix hijack". 184 In the absence of the minimal ROA above, AS 64511 could intercept 185 traffic for the addresses in 192.168.0.0/24. This is because routers 186 perform a longest-prefix match when deciding where to forward IP 187 packets, and 192.168.0.0/24 originated by AS 64511 is a longer prefix 188 than 192.168.0.0/16 originated by AS 64496. 190 However, the minimal ROA renders AS 64511's BGP announcement invalid, 191 because (1) this ROA "covers" the attacker's announcement (since 192 192.168.0.0/24 is a subprefix of 192.168.0.0/16), and (2) there is no 193 ROA "matching" the attacker's announcement (there is no ROA for AS 194 64511 and IP prefix 192.168.0.0/24) [RFC6811]. If routers ignore 195 invalid BGP announcements, the minimal ROA above ensures that the 196 subprefix hijack will fail. 198 Now suppose that the "minimal ROA" was replaced with a "loose ROA" 199 that used maxLength as a shorthand for set of IP prefixes that AS 200 64496 is authorized to originate. The "loose ROA" would be: 202 ROA:(192.168.0.0/16-24, AS 64496) 204 This "loose ROA" authorizes AS 64496 to originate any subprefix of 205 192.168.0.0/16, up to length /24. That is, AS 64496 could originate 206 192.168.225.0/24 as well as all of 192.168.0.0/17, 192.168.128.0/17, 207 ..., 192.168.255.0/24 but not 192.168.0.0/25. 209 However, AS 64496 only originates two prefixes in BGP: 192.168.0.0/16 210 and 192.168.255.0/24. This means that all other prefixes authorized 211 by the "loose ROA" (for instance, 192.168.0.0/24), are vulnerable to 212 the following forged-origin subprefix hijack [RFC7115] [GCHSS]: 214 The hijacker AS 64511 sends a BGP announcement "192.168.0.0/24: AS 215 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 216 AS 64496 and falsely claiming that AS 64496 originates the IP 217 prefix 192.168.0.0/24. In fact, the IP prefix 192.168.0.0/24 is 218 not originated by AS 64496. 220 The hijacker's BGP announcement is valid according to the RPKI, since 221 the ROA (192.168.0.0/16-24, AS 64496) authorizes AS 64496 to 222 originate BGP routes for 192.168.0.0/24. Because AS 64496 does not 223 actually originate a route for 192.168.0.0/24, the hijacker's route 224 is the *only* route to the 192.168.0.0/24. Longest-prefix-match 225 routing ensures that the hijacker's route to the subprefix 226 192.168.0.0/24 is always preferred over the legitimate route to 227 192.168.0.0/16 originated by AS 64496. Thus, the hijacker's route 228 propagates through the Internet, the traffic destined for IP 229 addresses in 192.168.0.0/24 will be delivered to the hijacker. 231 The forged-origin *subprefix* hijack would have failed if the 232 "minimal ROA" described above was used instead of the "loose ROA". 233 If the "minimal ROA" had been used instead, the attacker would be 234 forced to launch a forged-origin *prefix* hijack in order to attract 235 traffic, as follows: 237 The hijacker AS 64511 sends a BGP announcement "192.168.0.0/16: AS 238 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 239 AS 64496. 241 This forged-origin *prefix* hijack is significantly less damaging 242 than the forged-origin *subprefix* hijack. AS 64496 legitimately 243 originates 192.168.0.0/16 in BGP, so the hijacker AS 64511 is not 244 presenting the *only* route to 192.168.0.0/16. Moreover, the path 245 originated by AS 64511 is one hop longer than the path originated by 246 the legitimate origin AS 64496. As discussed in [LSG16], this means 247 that the hijacker will attract less traffic than he would have in the 248 forged-origin *subprefix* hijack, where the hijacker presents the 249 *only* route to the hijacked subprefix. 251 In summary, a forged-origin subprefix hijack has the same impact as a 252 regular subprefix hijack. A forged-origin *subprefix* hijack is also 253 more damaging than forged-origin *prefix* hijack. 255 4. Measurements of Today's RPKI 257 Network measurements have shown that 12% of the IP prefixes 258 authorized in ROAs have a maxLength longer than their prefix length. 259 The vast majority of these (84%) are vulnerable to forged-origin 260 subprefix hijacks. These subprefixes are not announced in BGP by the 261 legitimate AS. Even large providers are vulnerable to these attacks. 262 See [GSG17] for details. 264 These measurements suggest that operators commonly misconfigure the 265 maxLength attribute, and unwittingly open themselves up to forged- 266 origin subprefix hijacks. That is, they are exposing a much larger 267 attack surface for forged-origin hijacks than necessary. 269 5. Recommendations about Minimal ROAs and Maxlength 271 Operators SHOULD avoid using the maxLength attribute in their ROAs 272 except in some special cases. One such exception may be when all 273 more specific prefixes permitted by the maxLength are actually 274 announced by the AS in the ROA. Another exception for use of 275 maxLength is when (a) the maxLength is substantially larger compared 276 to the specified prefix length in the ROA, and (b) a large number of 277 more specific prefixes in that range is announced by the AS in the 278 ROA. This case should occur rarely in practice (if at all). 279 Operator discretion is necessary in this case. 281 Operators SHOULD use "minimal ROAs" whenever possible. A minimal ROA 282 contains only those IP prefixes that are actually originated by an AS 283 in BGP, and no other IP prefixes. (See Section 3 for an example.) 284 This practice requires no changes to the RPKI specification and will 285 not increase the number of signed ROAs in the RPKI, because ROAs 286 already support lists of IP prefixes [RFC6482]. See also [GSG17] for 287 further discussion of why this practice will have minimal impact on 288 the performance of the RPKI ecosystem. 290 5.1. Creation of ROAs Facilitating DDoS Mitigation Service 292 Sometimes, it is not possible to use a "minimal ROA", because an 293 operator wants to issue a ROA that includes an IP prefix that is 294 sometimes (but not always) originated in BGP. 296 In this case, the ROA SHOULD include (1) the set of IP prefixes that 297 are always originated in BGP, and (2) the set IP prefixes that are 298 sometimes, but not always, originated in BGP. The ROA SHOULD NOT 299 include any IP prefixes that the operator knows will not be 300 originated in BGP. Whenever possible, the ROA SHOULD also avoid the 301 use of the maxLength attribute. 303 The running example is now extended to illustrate one situation where 304 it is not possible to issue a minimal ROA. 306 Consider the following scenario prior to deployment of RPKI. Suppose 307 AS 64496 announced 192.168.0.0/16 and has a contract with a 308 Distributed Denial of Service (DDoS) mitigation service provider that 309 holds AS 64500. Further, assume that the DDoS mitigation service 310 contract applies to all IP addresses covered by 192.168.0.0/22. When 311 a DDoS attack is detected and reported by AS 64496, AS 64500 312 immediately originates 192.168.0.0/22, thus attracting all the DDoS 313 traffic to itself. The traffic is scrubbed at AS 64500 and then sent 314 back to AS 64496 over a backhaul data link. Notice that, during a 315 DDoS attack, the DDoS mitigation service provider AS 64500 originates 316 a /22 prefix that is longer than AS 64496's /16 prefix, and so all 317 the traffic (destined to addresses in 192.168.0.0/22) that normally 318 goes to AS 64496 goes to AS 64500 instead. 320 First, suppose the RPKI only had the minimal ROA for AS 64496, as 321 described in Section 3. But if there is no ROA authorizing AS 64500 322 to announce the /22 prefix, then the DDoS mitigation (and traffic 323 scrubbing) scheme would not work. That is, if AS 64500 originates 324 the /22 prefix in BGP during DDoS attacks, the announcement would be 325 invalid [RFC6811]. 327 Therefore, the RPKI should have two ROAs: one for AS 64496 and one 328 for AS 64500. 330 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 331 ROA:(192.168.0.0/22, AS 64500) 333 Neither ROA uses the maxLength attribute. But the second ROA is not 334 "minimal" because it contains a /22 prefix that is not originated by 335 anyone in BGP during normal operations. The /22 prefix is only 336 originated by AS 64500 as part of its DDoS mitigation service during 337 a DDoS attack. 339 Notice, however, that this scheme does not come without risks. 340 Namely, all IP addresses in 192.168.0.0/22 are vulnerable to a 341 forged-origin subprefix hijack during normal operations, when the /22 342 prefix is not originated. (The hijacker AS 64511 would send the BGP 343 announcement "192.168.0.0/22: AS 64511, AS 64500", falsely claiming 344 that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS 345 64500 originates 192.168.0.0/22.) 347 In some situations, the DDoS mitigation service at AS 64500 might 348 want to limit the amount of DDoS traffic that it attracts and scrubs. 349 Suppose that a DDoS attack only targets IP addresses in 350 192.168.0.0/24. Then, the DDoS mitigation service at AS 64500 only 351 wants to attract the traffic designated for the /24 prefix that is 352 under attack, but not the entire /22 prefix. To allow for this, the 353 RPKI should have two ROAs: one for AS 64496 and one for AS 64500. 355 ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 357 ROA:(192.168.0.0/22-24, AS 64500) 359 The second ROA uses the maxLength attribute because it is designed to 360 explicitly enable AS 64500 to originate *any* /24 subprefix of 361 192.168.0.0/22. 363 As before, the second ROA is not "minimal" because it contains 364 prefixes that are not originated by anyone in BGP during normal 365 operations. As before, all IP addresses in 192.168.0.0/22 are 366 vulnerable to a forged-origin subprefix hijack during normal 367 operations, when the /22 prefix is not originated. 369 The use of maxLength in this second ROA also comes with an additional 370 risk. While it permits the DDoS mitigation service at AS 64500 to 371 originate prefix 192.168.0.0/24 during a DDoS attack in that space, 372 it also makes the *other* /24 prefixes covered by the /22 prefix 373 (i.e., 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24) vulnerable to 374 a forged-origin subprefix attacks. 376 There is another entirely different way of managing ROAs for DDoS 377 mitigation service. In this scheme, ROAs are not pre-created for the 378 DDoS mitigation service but are created on the fly when the DDoS 379 mitigation service request is made. Further, the BGP announcements 380 for actuating the DDoS mitigation service will not be made until the 381 ROAs propagate fully through the RPKI system. Hence, there would be 382 a latency involved in DDoS mitigation service going into effect. 383 This method would be effective only if the latency is guaranteed to 384 be within some acceptable limit. This calls for mechanisms to be in 385 place for RPKI data propagation to occur very fast. Thus, this 386 scheme of managing ROAs for DDoS mitigation service helps with 387 eliminating the attack surface for prefixes requiring this service. 388 However, the viability of this scheme depends on future work related 389 to achieving fast ROA propagation in the global RPKI system. 391 6. ROAs and Origin Validation for RTBH Filtering Scenario 393 Considerations related to ROAs and origin validation [RFC6811] for 394 the case of destination-based Remote Triggered Black Hole (RTBH) 395 filtering are addressed here. In RTBH filtering, highly specific 396 prefixes (greater than /24 in IPv4 and greater than /48 in IPv6; 397 possibly even /32 (IPv4) and /128 (IPv6)) are announced in BGP. 398 These announcements are tagged with a BLACKHOLE Community [RFC7999]. 399 It is obviously not desirable to use large maxlength or include any 400 such highly specific prefixes in the ROAs to accommodate destination- 401 based RTBH filtering. Therefore, operators SHOULD accommodate this 402 scenario by accepting BGP announcements tagged with BLACKHOLE 403 Community only if the following conditions are met: (1) the 404 announcement is received on a BGP session on which there is agreement 405 to accept BLACKHOLE Community, and (2) the origin AS number in the 406 announcement matches the neighbor (customer) AS number associated 407 with the BGP session, and (3) the prefix in the announcement is 408 subsumed by a less-specific prefix that the neighbor (customer) AS is 409 authorized to announce per RPKI/ROA. Additional details can be found 410 in Section 5.5 in [NIST-800-189]. 412 7. Acknowledgments 414 The authors would like to thank the following people for their review 415 and contributions to this document: Omar Sagga (Boston University) 416 and Aris Lambrianidis (AMS-IX). Thanks are also due to Matthias 417 Waehlisch (Free University of Berlin) for comments and suggestions. 419 8. References 421 8.1. Normative References 423 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 424 and E. Lear, "Address Allocation for Private Internets", 425 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 426 . 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 434 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 435 DOI 10.17487/RFC4271, January 2006, 436 . 438 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 439 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 440 February 2012, . 442 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 443 Origin Authorizations (ROAs)", RFC 6482, 444 DOI 10.17487/RFC6482, February 2012, 445 . 447 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 448 Austein, "BGP Prefix Origin Validation", RFC 6811, 449 DOI 10.17487/RFC6811, January 2013, 450 . 452 8.2. Informative References 454 [GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 455 Shulman, "Are We There Yet? On RPKI's Deployment and 456 Security", in NDSS 2017, February 2017, 457 . 459 [GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "Maxlength 460 Considered Harmful to the RPKI", in ACM CoNEXT 2017, 461 December 2017, . 463 [HARMFUL] Gilad, Y., Sagga, O., and S. Goldberg, "MaxLength 464 Considered Harmful to the RPKI", 2017, 465 . 467 [LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking 468 Security for Internet Routing", in Communications of the 469 ACM, October 2016, . 473 [NIST-800-189] 474 Sriram, K. and D. Montgomery, "Resilient Interdomain 475 Traffic Exchange: BGP Security and DDoS Mitigation", NIST 476 Special Publication, NIST SP 800-189, December 2019, 477 . 480 [RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and 481 Interpretations of Resource Public Key Infrastructure 482 (RPKI) Objects for Issuers and Relying Parties", RFC 6907, 483 DOI 10.17487/RFC6907, March 2013, 484 . 486 [RFC7115] Bush, R., "Origin Validation Operation Based on the 487 Resource Public Key Infrastructure (RPKI)", BCP 185, 488 RFC 7115, DOI 10.17487/RFC7115, January 2014, 489 . 491 [RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. 492 Hankins, "BLACKHOLE Community", RFC 7999, 493 DOI 10.17487/RFC7999, October 2016, 494 . 496 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 497 Specification", RFC 8205, DOI 10.17487/RFC8205, September 498 2017, . 500 Authors' Addresses 502 Yossi Gilad 503 Hebrew University of Jerusalem 504 Rothburg Family Buildings, Edmond J. Safra Campus 505 Jerusalem 9190416 506 Israel 508 EMail: yossigi@cs.huji.ac.il 510 Sharon Goldberg 511 Boston University 512 111 Cummington St, MCS135 513 Boston, MA 02215 514 USA 516 EMail: goldbe@cs.bu.edu 517 Kotikalapudi Sriram 518 USA National Institute of Standards and Technology 519 100 Bureau Drive 520 Gaithersburg, MD 20899 521 USA 523 EMail: kotikalapudi.sriram@nist.gov 525 Job Snijders 526 NTT Communications 527 Theodorus Majofskistraat 100 528 Amsterdam 1065 SZ 529 The Netherlands 531 EMail: job@ntt.net 533 Ben Maddison 534 Workonline Communications 535 30 Waterkant St 536 Cape Town 8001 537 South Africa 539 EMail: benm@workonline.co.za