idnits 2.17.00 (12 Aug 2021) /tmp/idnits9950/draft-ietf-sidrops-aspa-verification-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 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 6 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 (25 August 2021) is 262 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 398, but not defined -- Looks like a reference, but probably isn't: '0' on line 448 == Outdated reference: A later version (-07) exists of draft-ietf-grow-route-leak-detection-mitigation-00 == Outdated reference: draft-ietf-idr-bgp-open-policy has been published as RFC 9234 == Outdated reference: A later version (-07) 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: 26 February 2022 Qrator Labs 6 R. Bush 7 Internet Initiative Japan & Arrcus 8 K. Patel 9 Arrcus, Inc. 10 J. Snijders 11 Fastly 12 25 August 2021 14 Verification of AS_PATH Using the Resource Certificate Public Key 15 Infrastructure and Autonomous System Provider Authorization 16 draft-ietf-sidrops-aspa-verification-08 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 26 February 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3 68 3. Autonomous System Provider Authorization . . . . . . . . . . 4 69 4. Customer-Provider Verification Procedure . . . . . . . . . . 4 70 5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 5 71 5.1. Upstream Paths . . . . . . . . . . . . . . . . . . . . . 5 72 5.2. Downstream Paths . . . . . . . . . . . . . . . . . . . . 7 73 5.3. Paths from Route Server . . . . . . . . . . . . . . . . . 9 74 5.4. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 11 76 7. Mutual Transit (Complex Relations) . . . . . . . . . . . . . 11 77 8. Comparison to Peerlock . . . . . . . . . . . . . . . . . . . 11 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 11.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 The Border Gateway Protocol (BGP) was designed without mechanisms to 88 validate BGP attributes. Two consequences are BGP Hijacks and BGP 89 Route Leaks [RFC7908]. BGP extensions are able to partially solve 90 these problems. For example, ROA-based Origin Validation [RFC6483] 91 can be used to detect and filter accidental mis-originations, and 92 [I-D.ietf-idr-bgp-open-policy] or 93 [I-D.ietf-grow-route-leak-detection-mitigation] can be used to detect 94 accidental route leaks. While these upgrades to BGP are quite 95 useful, they still rely on transitive BGP attributes, i.e. AS_PATH, 96 that can be manipulated by attackers. 98 BGPSec [RFC8205] was designed to solve the problem of AS_PATH 99 validation. Unfortunately, strict cryptographic validation brought 100 expensive computational overhead for BGP routers. BGPSec also proved 101 vulnerable to downgrade attacks that nullify the benefits of AS_PATH 102 signing. As a result, to abuse the AS_PATH or any other signed 103 transit attribute, an attacker merely needs to downgrade to 'old' 104 BGP-4. 106 An alternative approach was introduced with soBGP 107 [I-D.white-sobgp-architecture]. Instead of strong cryptographic 108 AS_PATH validation, it created an AS_PATH security function based on 109 a shared database of AS adjacencies. While such an approach has 110 reasonable computational cost, the two side adjacencies don't provide 111 a way to automate anomaly detection without high adoption rate - an 112 attacker can easily create a one-way adjacency. SO-BGP transported 113 data about adjacencies in new additional BGP messages, which was 114 recursively complex thus significantly increasing adoption complexity 115 and risk. In addition, the general goal to verify all AS_PATHs was 116 not achievable given the indirect adjacencies at internet exchange 117 points. 119 Instead of checking AS_PATH correctness, this document focuses on 120 solving real-world operational problems - automatic detection of 121 malicious hijacks and route leaks. To achieve this new AS_PATH 122 verification procedures are defined to automatically detect invalid 123 (malformed) AS_PATHs in announcements that are received from 124 customers, peers, providers, RS and RS-clients. This procedures uses 125 a shared signed database of customer-to-provider relationships using 126 a new RPKI object - Autonomous System Provider Authorization (ASPA). 127 This technique provides benefits for participants even during early 128 and incremental adoption. 130 2. Anomaly Propagation 132 Both route leaks and hijacks have similar effects on ISP operations - 133 they redirect traffic, resulting in increased latency, packet loss, 134 or possible MiTM attacks. But the level of risk depends 135 significantly on the propagation of the anomalies. For example, a 136 hijack that is propagated only to customers may concentrate traffic 137 in a particular ISP's customer cone; while if the anomaly is 138 propagated through peers, upstreams, or reaches Tier-1 networks, thus 139 distributing globally, traffic may be redirected at the level of 140 entire countries and/or global providers. 142 The ability to constrain propagation of BGP anomalies to upstreams 143 and peers, without requiring support from the source of the anomaly 144 (which is critical if source has malicious intent), should 145 significantly improve the security of inter-domain routing and solve 146 the majority of problems. 148 3. Autonomous System Provider Authorization 150 As described in [RFC6480], the RPKI is based on a hierarchy of 151 resource certificates that are aligned to the Internet Number 152 Resource allocation structure. Resource certificates are X.509 153 certificates that conform to the PKIX profile [RFC5280], and to the 154 extensions for IP addresses and AS identifiers [RFC3779]. A resource 155 certificate is a binding by an issuer of IP address blocks and 156 Autonomous System (AS) numbers to the subject of a certificate, 157 identified by the unique association of the subject's private key 158 with the public key contained in the resource certificate. The RPKI 159 is structured so that each current resource certificate matches a 160 current resource allocation or assignment. 162 ASPA is digitally signed object that bind, for a selected AFI, a Set 163 of Provider AS numbers to a Customer AS number (in terms of BGP 164 announcements not business), and are signed by the holder of the 165 Customer AS. An ASPA attests that a Customer AS holder (CAS) has 166 authorized Set of Provider ASes (SPAS) to propagate the Customer's 167 IPv4/IPv6 announcements onward, e.g. to the Provider's upstream 168 providers or peers. The ASPA record profile is described in 169 [I-D.ietf-sidrops-aspa-profile]. For a selected Customer AS SHOULD 170 exist only single ASPA object at any time. In this document we will 171 use ASPA(AS1, AFI, [AS2, ...]) as notation to represent ASPA object 172 for AS1 in the selected AFI. 174 4. Customer-Provider Verification Procedure 176 This section describes an abstract procedure that checks that a pair 177 of ASNs (AS1, AS2) is included in the set of signed ASPAs. The 178 semantics of its use is defined in next section. The procedure takes 179 (AS1, AS2, AFI) as input parameters and returns one of three results: 180 "Valid", "Invalid" and "Unknown". 182 A relying party (RP) must have access to a local cache of the 183 complete set of cryptographically valid ASPAs when performing 184 customer-provider verification procedure. 186 1. Retrieve all cryptographically valid ASPAs in a selected AFI with 187 a customer value of AS1. The union of SPAS forms the set of 188 "Candidate Providers." 190 2. If the set of Candidate Providers is empty, then the procedure 191 exits with an outcome of "Unknown." 193 3. If AS2 is included in the Candidate Providers, then the procedure 194 exits with an outcome of "Valid." 196 4. Otherwise, the procedure exits with an outcome of "Invalid." 198 Since an AS1 may have different set of providers in different AFI, it 199 should also have different SPAS in corresponding ASPAs. In this 200 case, the output of this procedure with input (AS1, AS2, AFI) may 201 have different output for different AFI values. 203 5. AS_PATH Verification 205 The AS_PATH attribute identifies the autonomous systems through which 206 an UPDATE message has passed. AS_PATH may contain two types of 207 components: AS_SEQUENCEs and AS_SETs, as defined in [RFC4271]. 209 We will use index of AS_PATH segments, where Seg(0) stands for the 210 segment of originating AS. We will use Seg(I).value and Seg(I).type 211 to represent Ith segment value and type respectively. 213 The below procedures are applicable only for 32-bit AS number 214 compatible BGP speakers. 216 5.1. Upstream Paths 218 When a route is received from a customer, a literal peer, or by a RS 219 at an IX, each consecutive AS_SEQUENCE pair MUST be equal (prepend 220 policy) or belong to customer-provider or mutual transit relationship 221 (Section 7). If there are other types of relationships, it means 222 that the route was leaked or the AS_PATH attribute was malformed. 223 The goal of the procedure described below is to check the correctness 224 of this statement. 226 The following Python function and algorithm describes the procedure 227 that MUST be applied on routes with AFI received from a customer, 228 peer or RS-client: 230 def check_upflow_path(aspath, neighbor_as, afi): 231 if len(aspath) == 0: 232 return Invalid 234 if aspath[-1].type == AS_SEQUENCE and aspath[-1].value != neighbor_as: 235 return Invalid 237 semi_state = Valid 239 as1 = 0 240 for segment in aspath: 241 if segment.type != AS_SEQUENCE: 242 as1 = 0 243 semi_state = Unverifiable 244 elif segment.type == AS_SEQUENCE: 245 if not as1: 246 as1 = segment.value 247 elif as1 == segment.value: 248 continue 249 else: 250 pair_check = verify_pair(as1, segment.value, afi) 251 if pair_check == Invalid: 252 return Invalid 253 elif pair_check == Unknown and semi_state == Valid: 254 semi_state = pair_check 255 as1 = segment.value 256 return semi_state 258 1. If the AS_PATH has zero length then procedure halts with the 259 outcome "Invalid"; 261 2. If the last segment in the AS_PATH has type AS_SEQUENCE and its 262 value isn't equal to receiver's neighbor AS then procedure halts 263 with the outcome "Invalid"; 265 3. If there exists I such that Seg(I-1).type and Seg(I).type equal 266 to AS_SEQUENCE, Seg(I-1).value != Seg(I).value and customer- 267 provider verification procedure (Section 4) with parameters 268 (Seg(I-1).value, Seg(I).value, AFI) returns "Invalid" then the 269 procedure also halts with the outcome "Invalid"; 271 4. If the AS_PATH has at least one AS_SET segment then procedure 272 halts with the outcome "Unverifiable"; 274 5. If there exists I such that Seg(I-1).type and Seg(I).type equal 275 to AS_SEQUENCE, Seg(I-1).value != Seg(I).value and customer- 276 provider verification procedure (Section 4) with parameters 277 (Seg(I-1).value, Seg(I).value, AFI) returns "Unknown" then the 278 procedure also halts with the outcome "Unknown"; 280 6. Otherwise, the procedure halts with an outcome of "Valid". 282 5.2. Downstream Paths 284 When route is received from provider it may have both Upstream and 285 Downstream fragments, where a Downstream follows an Upstream 286 fragment. If the path differs from this rule, e.g. the Downstream 287 fragment is followed by Upstream fragment it means that the route was 288 leaked or the AS_PATH attribute was malformed. The first unequal 289 pair of AS_SEQUENCE segments that has an "Invalid" outcome of the 290 customer-provider verification procedure indicates the end of the 291 Upstream fragment. All subsequent reverse pairs of AS_SEQUENCE 292 segments MUST be equal (prepend policy) or belong to a customer- 293 provider or mutual transit relationship Section 7, thus can be also 294 verified using ASPA objects. 296 The following Python function and algorithm describe the procedure 297 that MUST be applied on routes with AFI received from a provider: 299 def check_downflow_path(aspath, neighbor_as, afi): 300 if len(aspath) == 0: 301 return Invalid 303 if aspath[-1].type == AS_SEQUENCE and aspath[-1].value != neighbor_as: 304 return Invalid 305 else: 306 semi_state = Valid 308 as1 = 0 309 upflow_fragment = True 310 for segment in aspath: 311 if segment.type != AS_SEQUENCE: 312 as1 = 0 313 semi_state = Unverifiable 314 elif segment.type == AS_SEQUENCE: 315 if not as1: 316 as1 = segment.value 317 elif as1 == segment.value: 318 continue 319 else: 320 if upflow_fragment: 321 pair_check = verify_pair(as1, segment.value, afi) 322 if pair_check == Invalid: 323 upflow_fragment = False 324 elif pair_check == Unknown and semi_state == Valid: 325 semi_state = Unknown 326 else: 327 pair_check = verify_pair(segment.value, as1, afi) 328 if pair_check == Invalid: 329 return Invalid 330 elif pair_check == Unknown and semi_state == Valid: 331 semi_state = pair_check 332 as1 = segment.value 334 return semi_state 336 1. If the AS_PATH has zero length then procedure halts with the 337 outcome "Invalid"; 339 2. If a route is received from a provider and the last segment in 340 the AS_PATH has type AS_SEQUENCE and its value isn't equal to 341 receiver's neighbor AS, then the procedure halts with the outcome 342 "Invalid"; 344 3. Let's define I_MIN as the minimal index for which Seg(I-1).type 345 and Seg(I).type equal to AS_SEQUENCE, its values aren't equal and 346 the verification procedure for (Seg(I-1).value, Seg(I).value, 347 AFI) returns "Invalid". If I_MIN doesn't exist put the length of 348 AS_PATH in I_MIN variable and jump to 5. 350 4. If there exists J > I_MIN such that both Seg(J-1).type, 351 Seg(J).type equal to AS_SEQUENCE, Seg(J-1).value != Seg(J).value 352 and the customer-provider verification procedure (Section 4) 353 returns "Invalid" for (Seg(J).value, Seg(J-1).value, AFI), then 354 the procedure halts with the outcome "Invalid"; 356 5. If the AS_PATH has at least one AS_SET segment then procedure 357 halts with the outcome "Unverifiable"; 359 6. If there exists J > I_MIN such that both Seg(J-1).type, 360 Seg(J).type equal to AS_SEQUENCE, Seg(J-1).value != Seg(J).value 361 and the customer-provider verification procedure (Section 4) 362 returns "Unknown" for (Seg(J).value, Seg(J-1).value, AFI), then 363 the procedure halts with the outcome "Unknown"; 365 7. If there exists I_MIN > J 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-1).value, Seg(J).value, AFI), then 369 the procedure halts with the outcome "Unknown"; 371 8. Otherwise, the procedure halts with an outcome of "Valid". 373 5.3. Paths from Route Server 375 A route received from a RS at IX has much in common with route 376 received from a provider. A valid route from RS contains Upflow 377 fragment and MAY contain Downflow fragment that contains IX AS. The 378 ambiguity is created by transparent IXes that by default don't add 379 their AS in the AS_PATH. In this case, a route will have only Upflow 380 segment, though even 'transparent' IXes may support control 381 communities that give a way to explicitly add IX AS in the path. 383 Routes from RS MAY be processed the same way as routes from 384 Providers, but in the case of full IX 'transparency', it will limit 385 the opportunity of IX members to detect and filter route leaks. This 386 document suggests using the presence of IX AS as a token to 387 distinguish if Upflow or Downflow path verification procedure should 388 be applied. 390 The following Python function and algorithm describe the procedure 391 that SHOULD be applied on routes with AFI received from a RS: 393 def check_ix_path(aspath, neighbor_as, afi): 394 if len(aspath) == 0: 395 return Invalid 397 if aspath[-1].value != neighbor_as: 398 return check_upflow_path(aspath, aspath[-1].value, afi) 399 else: 400 return check_downflow_path(aspath, neighbor_as, afi) 402 1. If the AS_PATH has zero length then procedure halts with the 403 outcome "Invalid"; 405 2. If a route is received from a RS and the last segment in the 406 AS_PATH isn't equal to receiver's neighbor AS, the result equals 407 to the outcome of upflow verification procedure applied to 408 AS_PATH with neighbor_as replaced with the value of the last 409 AS_PATH segment Section 5.1; 411 3. If a route is received from a RS and the last segment in the 412 AS_PATH is equal to receiver's neighbor AS, the result equals to 413 the outcome of downflow verification procedure applied to AS_PATH 414 Section 5.2; 416 5.4. Mitigation 418 If the output of the AS_PATH verification procedure is "Invalid" the 419 route MUST be rejected. 421 If the output of the AS_PATH verification procedure is 'Unverifiable' 422 it means that AS_PATH can't be fully checked. Such routes should be 423 treated with caution and SHOULD be processed the same way as 424 "Invalid" routes. This policy goes with full correspondence to 425 [I-D.kumari-deprecate-as-set-confed-set]. 427 The above AS_PATH verification procedure is able to check routes 428 received from customer, peers, providers, RS, and RS-clients. The 429 ASPA mechanism combined with BGP Roles [I-D.ietf-idr-bgp-open-policy] 430 and ROA-based Origin Validation [RFC6483] can provide a fully 431 automated solution to detect and filter hijacks and route leaks, 432 including malicious ones. 434 6. Disavowal of Provider Authorizaion 436 An ASPA is a positive attestation that an AS holder has authorized 437 its providers to redistribute received routes to the provider's 438 providers and peers. This does not preclude the provider ASes from 439 redistribution to its other customers. By creating an ASPA with 440 providers set of [0], the customer indicates that no provider should 441 further announce its routes. Specifically, AS 0 is reserved to 442 identify provider-free networks, Internet exchange meshes, etc. 444 An ASPA(AS, AFI, [0]) is a statement by the customer AS that its 445 routes should not be received by any relying party AS from any of its 446 customers or peers. 448 By convention, an ASPA(AS, AFI, [0]) should be the only ASPA issued 449 by a given AS holder in the selected AFI; although this is not a 450 strict requirement. An AS 0 may coexist with other provider ASes in 451 the same ASPA (or other ASPA records in the same AFI); though in such 452 cases, the presence or absence of the provider AS 0 in ASPA does not 453 alter the AS_PATH verification procedure. 455 7. Mutual Transit (Complex Relations) 457 There are peering relationships which can not be described as 458 strictly simple peer-peer or customer-provider; e.g. when both 459 parties are intentionally sending prefixes received from each other 460 to their peers and/or upstreams. 462 In this case, two corresponding records ASPA(AS1, AFI, [AS2, ...]), 463 ASPA(AS2, AFI, [AS1, ...]) must be created by AS1 and AS2 464 respectively. 466 8. Comparison to Peerlock 468 ASPA has much in common with [Peerlock]. Peerlock is a BGP 469 Flexsealing [Flexsealing] protection mechanism commonly deployed by 470 global-scale Internet carriers to protect other large-scale carriers. 472 Peerlock, unfortunately, depends on a laborious manual process in 473 which operators coordinate the distribution of unstructured Provider 474 Authorizations through out-of-band means in a many-to-many fashion. 475 On the other hand, ASPA's use of PKIX [RFC5280] allows for automated, 476 scalable, and ubiquitous deployment, making the protection mechanism 477 available to a wider range of Internet Number Resource holders. 479 ASPA mechanics implemented in code instead of Peerlock AS_PATH 480 regular expressions also provides a way to detect anomalies coming 481 from transit providers and internet exchange route servers. 483 ASPA is intended to be a complete solution and replacement for 484 existing Peerlock deployments. 486 9. Security Considerations 488 The proposed mechanism is compatible only with BGP implementations 489 that can process 32-bit ASNs in the AS_PATH. This limitation should 490 not have a real effect on operations - such legacy BGP routers are 491 rare and it's highly unlikely that they support integration with the 492 RPKI. 494 ASPA issuers should be aware of the verification implication in 495 issuing an ASPA - an ASPA implicitly invalidates all routes passed to 496 upstream providers other than the provider ASs listed in the ASPA 497 record. It is the Customer AS's duty to maintain a correct set of 498 providers in ASPA record(s). 500 While it's not restricted, but it's highly recommended maintaining 501 for selected Customer AS a single ASPA object that covers all its 502 providers. Such policy should prevent race conditions during ASPA 503 updates that might affect prefix propagation. The software that 504 provides hosting for ASPA records SHOULD support enforcement of this 505 rule. In the case of the transition process between different CA 506 registries, the ASPA records SHOULD be kept identical in all 507 registries. 509 While the ASPA is able to detect both mistakes and malicious activity 510 for routes received from customers, RS-clients, or peers, it provides 511 only detection of mistakes for routes that are received from upstream 512 providers and RS(s). 514 Since an upstream provider becomes a trusted point, it will be able 515 to send hijacked prefixes of its customers or send hijacked prefixes 516 with malformed AS_PATHs back. While it may happen in theory, it's 517 doesn't seem to be a real scenario: normally customer and provider 518 have a signed agreement and such policy violation should have legal 519 consequences or customer can just drop relation with such a provider 520 and remove the corresponding ASPA record. 522 10. Acknowledgments 524 The authors wish to thank authors of [RFC6483] since its text was 525 used as an example while writing this document. The also authors 526 wish to thank Iljitsch van Beijnum for giving a hint about Downstream 527 paths. 529 11. References 530 11.1. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, 534 DOI 10.17487/RFC2119, March 1997, 535 . 537 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 538 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 539 May 2017, . 541 11.2. Informative References 543 [Flexsealing] 544 McDaniel, T., Smith, J., and M. Schuchard, "Flexsealing 545 BGP Against Route Leaks: Peerlock Active Measurement and 546 Analysis", November 2020, 547 . 549 [I-D.ietf-grow-route-leak-detection-mitigation] 550 Sriram, K. and A. Azimov, "Methods for Detection and 551 Mitigation of BGP Route Leaks", Work in Progress, 552 Internet-Draft, draft-ietf-grow-route-leak-detection- 553 mitigation-00, 19 April 2019, . 557 [I-D.ietf-idr-bgp-open-policy] 558 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 559 Sriram, "Route Leak Prevention using Roles in Update and 560 Open messages", Work in Progress, Internet-Draft, draft- 561 ietf-idr-bgp-open-policy-05, 15 February 2019, 562 . 565 [I-D.ietf-sidrops-aspa-profile] 566 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 567 and R. Housley, "A Profile for Autonomous System Provider 568 Authorization", Work in Progress, Internet-Draft, draft- 569 ietf-sidrops-aspa-profile-00, 17 May 2019, 570 . 573 [I-D.kumari-deprecate-as-set-confed-set] 574 Kumari, W. and K. Sriram, "Deprecation of AS_SET and 575 AS_CONFED_SET in BGP", Work in Progress, Internet-Draft, 576 draft-kumari-deprecate-as-set-confed-set-12, 2 July 2018, 577 . 580 [I-D.white-sobgp-architecture] 581 White, R., "Architecture and Deployment Considerations for 582 Secure Origin BGP (soBGP)", Work in Progress, Internet- 583 Draft, draft-white-sobgp-architecture-02, 16 June 2006, 584 . 587 [Peerlock] Snijders, J., "Peerlock", June 2016, 588 . 591 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 592 Addresses and AS Identifiers", RFC 3779, 593 DOI 10.17487/RFC3779, June 2004, 594 . 596 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 597 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 598 DOI 10.17487/RFC4271, January 2006, 599 . 601 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 602 Housley, R., and W. Polk, "Internet X.509 Public Key 603 Infrastructure Certificate and Certificate Revocation List 604 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 605 . 607 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 608 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 609 February 2012, . 611 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 612 Origination Using the Resource Certificate Public Key 613 Infrastructure (PKI) and Route Origin Authorizations 614 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 615 . 617 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 618 and B. Dickson, "Problem Definition and Classification of 619 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 620 2016, . 622 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 623 Specification", RFC 8205, DOI 10.17487/RFC8205, September 624 2017, . 626 Authors' Addresses 628 Alexander Azimov 629 Yandex 631 Email: a.e.azimov@gmail.com 633 Eugene Bogomazov 634 Qrator Labs 636 Email: eb@qrator.net 638 Randy Bush 639 Internet Initiative Japan & Arrcus 641 Email: randy@psg.com 643 Keyur Patel 644 Arrcus, Inc. 646 Email: keyur@arrcus.com 648 Job Snijders 649 Fastly 650 Amsterdam 652 Email: job@fastly.com