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