idnits 2.17.1 draft-ietf-sidrops-aspa-verification-06.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 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 6 instances of too long lines in the document, the longest one being 22 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '-1' is mentioned on line 309, but not defined -- Looks like a reference, but probably isn't: '0' on line 411 == Outdated reference: A later version (-10) exists of draft-ietf-grow-route-leak-detection-mitigation-00 == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-05 == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-profile-00 == Outdated reference: A later version (-14) exists of draft-kumari-deprecate-as-set-confed-set-12 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Azimov 3 Internet-Draft Yandex 4 Intended status: Standards Track E. Bogomazov 5 Expires: May 6, 2021 Qrator Labs 6 R. Bush 7 Internet Initiative Japan & Arrcus 8 K. Patel 9 Arrcus, Inc. 10 J. Snijders 11 NTT 12 November 2, 2020 14 Verification of AS_PATH Using the Resource Certificate Public Key 15 Infrastructure and Autonomous System Provider Authorization 16 draft-ietf-sidrops-aspa-verification-06 18 Abstract 20 This document defines the semantics of an Autonomous System Provider 21 Authorization object in the Resource Public Key Infrastructure to 22 verify the AS_PATH attribute of routes advertised in the Border 23 Gateway Protocol. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 6, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3 69 3. Autonomous System Provider Authorization . . . . . . . . . . 4 70 4. Customer-Provider Verification Procedure . . . . . . . . . . 4 71 5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 5 72 5.1. Upstream Paths . . . . . . . . . . . . . . . . . . . . . 5 73 5.2. Downstream Paths . . . . . . . . . . . . . . . . . . . . 7 74 5.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 10 76 7. Mutual Transit (Complex Relations) . . . . . . . . . . . . . 10 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 10.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The Border Gateway Protocol (BGP) was designed without mechanisms to 87 validate BGP attributes. Two consequences are BGP Hijacks and BGP 88 Route Leaks [RFC7908]. BGP extensions are able to partially solve 89 these problems. For example, ROA-based Origin Validation [RFC6483] 90 can be used to detect and filter accidental mis-originations, and 91 [I-D.ietf-grow-route-leak-detection-mitigation] can be used to detect 92 accidental route leaks. While these upgrades to BGP are quite 93 useful, they still rely on transitive BGP attributes, i.e. AS_PATH, 94 that can be manipulated by attackers. 96 BGPSec [RFC8205] was designed to solve the problem of AS_PATH 97 validation. Unfortunately, strict cryptographic validation brought 98 expensive computational overhead for BGP routers. BGPSec also proved 99 vulnerable to downgrade attacks that nullify the benefits of AS_PATH 100 signing. As a result, to abuse the AS_PATH or any other signed 101 transit attribute, an attacker merely needs to downgrade to 'old' 102 BGP-4. 104 An alternative approach was introduced with soBGP 105 [I-D.white-sobgp-architecture]. Instead of strong cryptographic 106 AS_PATH validation, it created an AS_PATH security function based on 107 a shared database of AS adjacencies. While such an approach has 108 reasonable computational cost, the two side adjacencies don't provide 109 a way to automate anomaly detection without high adoption rate - an 110 attacker can easily create a one-way adjacency. SO-BGP transported 111 data about adjacencies in new additional BGP messages, which was 112 recursively complex thus significantly increasing adoption complexity 113 and risk. In addition, the general goal to verify all AS_PATHs was 114 not achievable given the indirect adjacencies at internet exchange 115 points. 117 Instead of checking AS_PATH correctness, this document focuses on 118 solving real-world operational problems - automatic detection of 119 malicious hijacks and route leaks. To achieve this a new AS_PATH 120 verification procedure is defined which is able to automatically 121 detect invalid (malformed) AS_PATHs in announcements that are 122 received from customers and peers. This procedure uses a shared 123 signed database of customer-to-provider relationships using a new 124 RPKI object - Autonomous System Provider Authorization (ASPA). This 125 technique provides benefits for participants even during early and 126 incremental adoption. 128 2. Anomaly Propagation 130 Both route leaks and hijacks have similar effects on ISP operations - 131 they redirect traffic, resulting in increased latency, packet loss, 132 or possible MiTM attacks. But the level of risk depends 133 significantly on the propagation of the anomalies. For example, a 134 hijack that is propagated only to customers may concentrate traffic 135 in a particular ISP's customer cone; while if the anomaly is 136 propagated through peers, upstreams, or reaches Tier-1 networks, thus 137 distributing globally, traffic may be redirected at the level of 138 entire countries and/or global providers. 140 The ability to constrain propagation of BGP anomalies to upstreams 141 and peers, without requiring support from the source of the anomaly 142 (which is critical if source has malicious intent), should 143 significantly improve the security of inter-domain routing and solve 144 the majority of problems. 146 3. Autonomous System Provider Authorization 148 As described in [RFC6480], the RPKI is based on a hierarchy of 149 resource certificates that are aligned to the Internet Number 150 Resource allocation structure. Resource certificates are X.509 151 certificates that conform to the PKIX profile [RFC5280], and to the 152 extensions for IP addresses and AS identifiers [RFC3779]. A resource 153 certificate is a binding by an issuer of IP address blocks and 154 Autonomous System (AS) numbers to the subject of a certificate, 155 identified by the unique association of the subject's private key 156 with the public key contained in the resource certificate. The RPKI 157 is structured so that each current resource certificate matches a 158 current resource allocation or assignment. 160 ASPA is digitally signed object that bind, for a selected AFI, a Set 161 of Provider AS numbers to a Customer AS number (in terms of BGP 162 announcements not business), and are signed by the holder of the 163 Customer AS. An ASPA attests that a Customer AS holder (CAS) has 164 authorized Set of Provider ASes (SPAS) to propagate the Customer's 165 IPv4/IPv6 announcements onward, e.g. to the Provider's upstream 166 providers or peers. The ASPA record profile is described in 167 [I-D.ietf-sidrops-aspa-profile]. For a selected Customer AS SHOULD 168 exist only single ASPA object. In this document we will use 169 ASPA(AS1, AFI, [AS2, ...]) as notation to represent ASPA object for 170 AS1 in the selected AFI. 172 4. Customer-Provider Verification Procedure 174 This section describes an abstract procedure that checks that a pair 175 of ASNs (AS1, AS2) is included in the set of signed ASPAs. The 176 semantics of its use is defined in next section. The procedure takes 177 (AS1, AS2, AFI) as input parameters and returns one of three results: 178 "Valid", "Invalid" and "Unknown". 180 A relying party (RP) must have access to a local cache of the 181 complete set of cryptographically valid ASPAs when performing 182 customer-provider verification procedure. 184 1. Retrieve all cryptographically valid ASPAs in a selected AFI with 185 a customer value of AS1. The union of SPAS forms the set of 186 "Candidate Providers." 188 2. If the set of Candidate Providers is empty, then the procedure 189 exits with an outcome of "Unknown." 191 3. If AS2 is included in the Candidate Providers, then the procedure 192 exits with an outcome of "Valid." 194 4. Otherwise, the procedure exits with an outcome of "Invalid." 196 Since an AS1 may have different set of providers in different AFI, it 197 should also have different PCAS in corresponding ASPAs. In this 198 case, the output of this procedure with input (AS1, AS2, AFI) may 199 have different output for different AFI values. 201 5. AS_PATH Verification 203 The AS_PATH attribute identifies the autonomous systems through which 204 an UPDATE message has passed. AS_PATH may contain two types of 205 components: AS_SEQUENCEs and AS_SETs, as defined in [RFC4271]. 207 We will use index of AS_PATH segments, where Seg(0) stands for the 208 segment of originating AS. We will use Seg(I).value and Seg(I).type 209 to represent Ith segment value and type respectively. 211 The below procedures are applicable only for 32-bit AS number 212 compatible BGP speakers. 214 5.1. Upstream Paths 216 When a route is received from a customer, a literal peer, or by a RS 217 at an IX, each consecutive AS_SEQUENCE pair MUST be equal (prepend 218 policy) or belong to customer-provider or mutual transit relationship 219 (Section 7). If there are other types of relationships, it means 220 that the route was leaked or the AS_PATH attribute was malformed. 221 The goal of the procedure described below is to check the correctness 222 of this statement. 224 The following Python function and algorithm describes the procedure 225 that MUST be applied on routes with AFI received from a customer, 226 peer or RS-client: 228 def check_upflow_path(self, aspath, neighbor_as, afi): 229 if len(aspath) == 0: 230 return Invalid 232 if aspath[-1].type == AS_SEQUENCE and aspath[-1].value != neighbor_as: 233 return Invalid 235 semi_state = Valid 237 as1 = 0 238 for segment in aspath: 239 if segment.type != AS_SEQUENCE: 240 as1 = 0 241 semi_state = Unverifiable 242 elif segment.type == AS_SEQUENCE: 243 if not as1: 244 as1 = segment.value 245 elif as1 == segment.value: 246 continue 247 else: 248 pair_check = verify_pair(as1, segment.value, afi) 249 if pair_check == Invalid: 250 return Invalid 251 elif pair_check == Unknown and semi_state == Valid: 252 semi_state = pair_check 253 as1 = segment.value 254 return semi_state 256 1. If the the AS_PATH has zero length then procedure halts with the 257 outcome "Invalid"; 259 2. If the first segment in the AS_PATH has type AS_SEQUENCE and its 260 value isn't equal to receiver's neighbor AS then procedure halts 261 with the outcome "Invalid"; 263 3. If there exists I such that Seg(I-1).type and Seg(I).type equal 264 to AS_SEQUENCE, Seg(I-1).value != Seg(I).value and customer- 265 provider verification procedure (Section 4) with parameters 266 (Seg(I-1).value, Seg(I).value, AFI) returns "Invalid" then the 267 procedure also halts with the outcome "Invalid"; 269 4. If the AS_PATH has at least one AS_SET segment then procedure 270 halts with the outcome "Unverifiable"; 272 5. If there exists I such that Seg(I-1).type and Seg(I).type equal 273 to AS_SEQUENCE, Seg(I-1).value != Seg(I).value and customer- 274 provider verification procedure (Section 4) with parameters 275 (Seg(I-1).value, Seg(I).value, AFI) returns "Unknown" then the 276 procedure also halts with the outcome "Unknown"; 278 6. Otherwise, the procedure halts with an outcome of "Valid". 280 5.2. Downstream Paths 282 When route is received from provider or RS it may have both Upstream 283 and Downstream fragments, where a Downstream follows an Upstream 284 fragment. If the path differs from this rule, e.g. the Downstream 285 fragment is followed by Upstream fragment it means that the route was 286 leaked or the AS_PATH attribute was malformed. The first unequal 287 pair of AS_SEQUENCE segments that has an "Invalid" outcome of the 288 customer-provider verification procedure indicates the end of the 289 Upstream fragment. All subsequent reverse pairs of AS_SEQUENCE 290 segments MUST be equal (prepend policy) or belong to a customer- 291 provider or mutual transit relationship Section 7, thus can be also 292 verified using ASPA objects. 294 Additional caution should be exercised when processing prefixes that 295 are received from transparent IXes, as they don't add their AS in the 296 AS_PATH. At the same time, we can't rely on IX 'transparency' in 297 general since there are IXes that do add their AS and there are 298 control communities that give a way to explicitly add IX AS in the 299 path. 301 The following Python function and procedure describe the procedure 302 that MUST be applied on routes with AFI received from a provider or a 303 RS: 305 def check_downflow_path(self, aspath, neighbor_as, afi, from_ix): 306 if len(aspath) == 0: 307 return Invalid 309 if aspath[-1].type == AS_SEQUENCE and not from_ix and aspath[-1].value != neighbor_as: 310 return Invalid 311 else: 312 semi_state = Valid 314 as1 = 0 315 upflow_fragment = True 316 for segment in aspath: 317 if segment.type != AS_SEQUENCE: 318 as1 = 0 319 semi_state = Unverifiable 320 elif segment.type == AS_SEQUENCE: 321 if not as1: 322 as1 = segment.value 323 elif as1 == segment.value: 324 continue 325 else: 326 if upflow_fragment: 327 pair_check = verify_pair(as1, segment.value, afi) 328 if pair_check == Invalid: 329 upflow_fragment = False 330 elif pair_check == Unknown and semi_state == Valid: 331 semi_state = Unknown 332 else: 333 pair_check = verify_pair(segment.value, as1, afi) 334 if pair_check == Invalid: 335 return Invalid 336 elif pair_check == Unknown and semi_state == Valid: 337 semi_state = pair_check 338 as1 = segment.value 340 return semi_state 342 1. If the the AS_PATH has zero length then procedure halts with the 343 outcome "Invalid"; 345 2. If a route is received from a provider and the first segment in 346 the AS_PATH has type AS_SEQUENCE and its value isn't equal to 347 receiver's neighbor AS, then the procedure halts with the outcome 348 "Invalid"; 350 3. Let's define I_MIN as the minimal index for which Seg(I-1).type 351 and Seg(I).type equal to AS_SEQUENCE, its values aren't equal and 352 the verification procedure for (Seg(I-1).value, Seg(I).value, 353 AFI) returns "Invalid". If I_MIN doesn't exist put the length of 354 AS_PATH in I_MIN variable and jump to 5. 356 4. If there exists J > I_MIN such that both Seg(J-1).type, 357 Seg(J).type equal to AS_SEQUENCE, Seg(J-1).value != Seg(J).value 358 and the customer-provider verification procedure (Section 4) 359 returns "Invalid" for (Seg(J).value, Seg(J-1).value, AFI), then 360 the procedure halts with the outcome "Invalid"; 362 5. If the AS_PATH has at least one AS_SET segment then procedure 363 halts with the outcome "Unverifiable"; 365 6. If there exists J > I_MIN such that both Seg(J-1).type, 366 Seg(J).type equal to AS_SEQUENCE, Seg(J-1).value != Seg(J).value 367 and the customer-provider verification procedure (Section 4) 368 returns "Unknown" for (Seg(J).value, Seg(J-1).value, AFI), then 369 the procedure halts with the outcome "Unknown"; 371 7. If there exists I_MIN > J such that both Seg(J-1).type, 372 Seg(J).type equal to AS_SEQUENCE, Seg(J-1).value != Seg(J).value 373 and the customer-provider verification procedure (Section 4) 374 returns "Unknown" for (Seg(J-1).value, Seg(J).value, AFI), then 375 the procedure halts with the outcome "Unknown"; 377 8. Otherwise, the procedure halts with an outcome of "Valid". 379 5.3. Mitigation 381 If the output of the AS_PATH verification procedure is "Invalid" the 382 route MUST be rejected. 384 If the output of the AS_PATH verification procedure is 'Unverifiable' 385 it means that AS_PATH can't be fully checked. Such routes should be 386 treated with caution and SHOULD be processed the same way as 387 "Invalid" routes. This policy goes with full correspondence to 388 [I-D.kumari-deprecate-as-set-confed-set]. 390 The above AS_PATH verification procedure is able to check routes 391 received from customer, peers, providers, RS, and RS-clients. The 392 ASPA mechanism combined with BGP Roles [I-D.ietf-idr-bgp-open-policy] 393 and ROA-based Origin Validation [RFC6483] can provide a fully 394 automated solution to detect and filter hijacks and route leaks, 395 including malicious ones. 397 6. Disavowal of Provider Authorizaion 399 An ASPA is a positive attestation that an AS holder has authorized 400 its providers to redistribute received routes to the provider's 401 providers and peers. This does not preclude the provider ASes from 402 redistribution to its other customers. By creating an ASPA with 403 providers set of [0], the customer indicates that no provider should 404 further announce its routes. Specifically, AS 0 is reserved to 405 identify provider-free networks, Internet exchange meshes, etc. 407 An ASPA(AS, AFI, [0]) is a statement by the customer AS that its 408 routes should not be received by any relying party AS from any of its 409 customers or peers. 411 By convention, an ASPA(AS, AFI, [0]) should be the only ASPA issued 412 by a given AS holder in the selected AFI; although this is not a 413 strict requirement. An AS 0 may coexist with other provider ASes in 414 the same ASPA (or other ASPA records in the same AFI); though in such 415 cases, the presence or absence of the provider AS 0 in ASPA does not 416 alter the AS_PATH verification procedure. 418 7. Mutual Transit (Complex Relations) 420 There are peering relationships which can not be described as 421 strictly simple peer-peer or customer-provider; e.g. when both 422 parties are intentionally sending prefixes received from each other 423 to their peers and/or upstreams. 425 In this case, two corresponding records ASPA(AS1, AFI, [AS2, ...]), 426 ASPA(AS2, AFI, [AS1, ...]) must be created by AS1 and AS2 427 respectively. 429 8. Security Considerations 431 The proposed mechanism is compatible only with BGP implementations 432 that can process 32-bit ASNs in the ASPATH. This limitation should 433 not have a real effect on operations - such legacy BGP routers are 434 rare and it's highly unlikely that they support integration with the 435 RPKI. 437 ASPA issuers should be aware of the verification implication in 438 issuing an ASPA - an ASPA implicitly invalidates all routes passed to 439 upstream providers other than the provider ASs listed in the ASPA 440 record. It is the Customer AS's duty to maintain a correct set of 441 providers in ASPA record(s). 443 While it's not restricted, but it's highly recommended maintaining 444 for selected Customer AS a single ASPA object that covers all its 445 providers. Such policy should prevent race conditions during ASPA 446 updates that might affect prefix propagation. The software that 447 provides hosting for ASPA records SHOULD support enforcement of this 448 rule. In the case of the transition process between different CA 449 registries, the ASPA records SHOULD be kept identical in all 450 registries. 452 While the ASPA is able to detect both mistakes and malicious activity 453 for routes received from customers, RS-clients, or peers, it provides 454 only detection of mistakes for routes that are received from upstream 455 providers and RS(s). 457 Since an upstream provider becomes a trusted point, it will be able 458 to send hijacked prefixes of its customers or send hijacked prefixes 459 with malformed AS_PATHs back. While it may happen in theory, it's 460 doesn't seem to be a real scenario: normally customer and provider 461 have a signed agreement and such policy violation should have legal 462 consequences or customer can just drop relation with such a provider 463 and remove the corresponding ASPA record. 465 9. Acknowledgments 467 The authors wish to thank authors of [RFC6483] since its text was 468 used as an example while writing this document. The also authors 469 wish to thank Iljitsch van Beijnum for giving a hint about Downstream 470 paths. 472 10. References 474 10.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 482 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 483 May 2017, . 485 10.2. Informative References 487 [I-D.ietf-grow-route-leak-detection-mitigation] 488 Sriram, K. and A. Azimov, "Methods for Detection and 489 Mitigation of BGP Route Leaks", draft-ietf-grow-route- 490 leak-detection-mitigation-00 (work in progress), April 491 2019. 493 [I-D.ietf-idr-bgp-open-policy] 494 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 495 Sriram, "Route Leak Prevention using Roles in Update and 496 Open messages", draft-ietf-idr-bgp-open-policy-05 (work in 497 progress), February 2019. 499 [I-D.ietf-sidrops-aspa-profile] 500 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 501 and R. Housley, "A Profile for Autonomous System Provider 502 Authorization", draft-ietf-sidrops-aspa-profile-00 (work 503 in progress), May 2019. 505 [I-D.kumari-deprecate-as-set-confed-set] 506 Kumari, W. and K. Sriram, "Deprecation of AS_SET and 507 AS_CONFED_SET in BGP", draft-kumari-deprecate-as-set- 508 confed-set-12 (work in progress), July 2018. 510 [I-D.white-sobgp-architecture] 511 White, R., "Architecture and Deployment Considerations for 512 Secure Origin BGP (soBGP)", draft-white-sobgp- 513 architecture-02 (work in progress), June 2006. 515 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 516 Addresses and AS Identifiers", RFC 3779, 517 DOI 10.17487/RFC3779, June 2004, 518 . 520 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 521 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 522 DOI 10.17487/RFC4271, January 2006, 523 . 525 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 526 Housley, R., and W. Polk, "Internet X.509 Public Key 527 Infrastructure Certificate and Certificate Revocation List 528 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 529 . 531 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 532 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 533 February 2012, . 535 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 536 Origination Using the Resource Certificate Public Key 537 Infrastructure (PKI) and Route Origin Authorizations 538 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 539 . 541 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 542 and B. Dickson, "Problem Definition and Classification of 543 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 544 2016, . 546 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 547 Specification", RFC 8205, DOI 10.17487/RFC8205, September 548 2017, . 550 Authors' Addresses 552 Alexander Azimov 553 Yandex 555 Email: a.e.azimov@gmail.com 557 Eugene Bogomazov 558 Qrator Labs 560 Email: eb@qrator.net 562 Randy Bush 563 Internet Initiative Japan & Arrcus 565 Email: randy@psg.com 567 Keyur Patel 568 Arrcus, Inc. 570 Email: keyur@arrcus.com 572 Job Snijders 573 NTT Communications 574 Theodorus Majofskistraat 100 575 Amsterdam 1065 SZ 576 The Netherlands 578 Email: job@ntt.net