idnits 2.17.1 draft-ietf-idr-bgp-flowspec-oid-15.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 abstract seems to contain references ([RFC8955]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC8955, but the abstract doesn't seem to directly say this. It does mention RFC8955 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 3, 2021) is 1057 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) == Outdated reference: A later version (-12) exists of draft-ietf-idr-deprecate-as-set-confed-set-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Uttaro 3 Internet-Draft AT&T 4 Updates: 8955 (if approved) J. Alcaide 5 Intended status: Standards Track C. Filsfils 6 Expires: December 5, 2021 D. Smith 7 Cisco 8 P. Mohapatra 9 Sproute Networks 10 June 3, 2021 12 Revised Validation Procedure for BGP Flow Specifications 13 draft-ietf-idr-bgp-flowspec-oid-15 15 Abstract 17 This document describes a modification to the validation procedure 18 defined for the dissemination of BGP Flow Specifications. The 19 dissemination of BGP Flow Specifications as specified in [RFC8955] 20 requires that the originator of the Flow Specification matches the 21 originator of the best-match unicast route for the destination prefix 22 embedded in the Flow Specification. For an iBGP received route, the 23 originator is typically a border router within the same autonomous 24 system. The objective is to allow only BGP speakers within the data 25 forwarding path to originate BGP Flow Specifications. Sometimes it 26 is desirable to originate the BGP Flow Specification from any place 27 within the autonomous system itself, for example, from a centralized 28 BGP route controller. However, the RFC 8955 validation procedure 29 will fail in this scenario. The modification proposed herein relaxes 30 the validation rule to enable Flow Specifications to be originated 31 within the same autonomous system as the BGP speaker performing the 32 validation. Additionally, this document revises the AS_PATH 33 validation rules so Flow Specifications received from an eBGP peer 34 can be validated when such peer is a BGP route server. 36 This document updates the validation procedure in [RFC8955]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 5, 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 5. Revised Validation Procedure . . . . . . . . . . . . . . . . 7 77 5.1. Revision of Route Feasibility . . . . . . . . . . . . . . 7 78 5.2. Revision of AS_PATH Validation . . . . . . . . . . . . . 8 79 6. Topology Considerations . . . . . . . . . . . . . . . . . . . 10 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in BCP 93 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 2. Terminology 98 Local Domain: the local AS or the local confederation of ASes 99 [RFC5065]. 101 eBGP: BGP peering to a router not within the Local Domain. 103 iBGP: BGP peering not eBGP as defined above (i.e. both classic iBGP 104 and any form of eBGP peering with a router within the same 105 confederation). 107 3. Introduction 109 [RFC8955] defines a BGP NLRI [RFC4760] that can be used to distribute 110 traffic Flow Specifications amongst BGP speakers in support of 111 traffic filtering. The primary intention of [RFC8955] is to enable 112 downstream autonomous systems to signal traffic filtering policies to 113 upstream autonomous systems. In this way, traffic is filtered closer 114 to the source and the upstream autonomous system(s) avoid carrying 115 the traffic to the downstream autonomous system only to be discarded. 116 [RFC8955] also enables more granular traffic filtering based upon 117 upper layer protocol information (e.g., protocol or port numbers) as 118 opposed to coarse IP destination prefix-based filtering. Flow 119 Specification NLRIs received from a BGP peer are subject to validity 120 checks before being considered feasible and subsequently installed 121 within the respective Adj-RIB-In. 123 The validation procedure defined within [RFC8955] requires that the 124 originator of the Flow Specification NLRI matches the originator of 125 the best-match unicast route for the destination prefix embedded in 126 the Flow Specification. The aim is to make sure that only speakers 127 on the forwarding path can originate the Flow Specification. Let's 128 consider the particular case where the Flow Specification is 129 originated in any location within the same Local Domain as the 130 speaker performing the validation (for example by a centralized BGP 131 route controller), and the best-match unicast route is originated in 132 another Local Domain. In order for the validation to succeed for a 133 Flow Specification received from an iBGP peer, it would be necessary 134 to disseminate such Flow Specification NLRI directly from the 135 specific border router (within the Local Domain) that is advertising 136 the corresponding best-match unicast route to the Local Domain. 137 Those border routers would be acting as de facto route controllers. 138 This approach would be, however, operationally cumbersome in a Local 139 Domain with numerous border routers having complex BGP policies. 141 Figure 1 illustrates this principle. R1 (the upstream router) and RR 142 (a route reflector) need to validate the Flow Specification whose 143 embedded destination prefix has a best-match unicast route (dest- 144 route) originated by ASBR2. ASBR2 could originate the Flow 145 Specification, and it would be validated when received by RR and R1 146 (from their point of view, the originator of both the FLow 147 Specification and the best-match unicast route will be ASBR1). 148 Sometimes the Flow Specification needs to be originated within AS1. 149 ASBR1 could originate it, and the Flow Specification would still be 150 validated. In both cases, the Flow Specification is originated by a 151 router in the same forwarding path as the dest-route. For the case 152 where AS1 has thousands of ASBRs, it becomes impractical to originate 153 different Flow Specification rules on each ASBR in AS1 based on which 154 ASBR each dest-route is learned from. To make the situation more 155 tenable, the objective is to advertise all the Flow Specifications 156 from the same route-controller. 158 R1(AS1) --- RR(AS1) --- ASBR1(AS1) --- ASBR2(AS2) 159 | 160 route-controller(AS1) 162 Figure 1 164 This document describes a modification to the [RFC8955] validation 165 procedure, allowing Flow Specification NLRIs to be originated from a 166 centralized BGP route controller located within the Local Domain and 167 not necessarily in the data forwarding path. While the proposed 168 modification cannot be used for inter-domain coordination of traffic 169 filtering, it greatly simplifies distribution of intra-domain traffic 170 filtering policies within a Local Domain which has numerous border 171 routers having complex BGP policies. By relaxing the validation 172 procedure for iBGP, the proposed modification allows Flow 173 Specifications to be distributed in a standard and scalable manner 174 throughout the Local Domain. 176 Throughout this document, some references are made to 177 AS_CONFED_SEQUENCE segments; see Sections 4.1 and 5. If 178 AS_CONFED_SET segments are also present in the AS_PATH, the same 179 considerations apply to them. Note, however, that the use of 180 AS_CONFED_SET segments is not recommended [RFC6472]. Refer to 181 [I-D.ietf-idr-deprecate-as-set-confed-set] as well. 183 4. Motivation 185 Step (b) of the validation procedure in Section 6 of [RFC8955] is 186 defined with the underlying assumption that the Flow Specification 187 NLRI traverses the same path, in the inter-domain and intra-domain 188 route distribution graph, as that of the longest-match unicast route 189 for the destination prefix embedded in the Flow Specification. 191 In the case of inter-domain traffic filtering, the Flow Specification 192 originator at the egress border routers of an AS (e.g. RTR-D and 193 RTR-E of AS1 in Figure 2) matches the eBGP neighbor that advertised 194 the longest match destination prefix (see RTR-F and RTR-G 195 respectively in Figure 2). 197 Similarly, at the upstream routers of an AS (see RTR-A and RTR-B of 198 AS1 in Figure 2), the Flow Specification originator matches the 199 egress iBGP border routers that had advertised the unicast route for 200 the best-match destination prefix (see RTR-D and RTR-E respectively 201 in Figure 2). This is true even when upstream routers select paths 202 from different egress border routers as best route based upon IGP 203 distance. For example, in Figure 2: 205 RTR-A chooses RTR-D as the best route 207 RTR-B chooses RTR-E as the best route 208 / - - - - - - - - - - - - - - 209 | AS1 | 210 +-------+ +-------+ 211 | | | | | | 212 | RTR-A | | RTR-B | 213 | | | | | | 214 +-------+ +-------+ 215 | \ / | 216 iBGP \ / iBGP 217 | \ / | 218 +-------+ 219 | | | | 220 | RTR-C | 221 | | RC | | 222 +-------+ 223 | / \ | 224 / \ 225 | iBGP / \ iBGP | 226 +-------+ +-------+ 227 | | RTR-D | | RTR-E | | 228 | | | | 229 | | | | | | 230 +-------+ +-------+ 231 | | | | 232 - - -|- - - - - - - - -|- - -/ 233 | eBGP eBGP | 234 - - -|- - - - - - - - -|- - -/ 235 | | | | 236 +-------+ +-------+ 237 | | | | | | 238 | RTR-F | | RTR-G | 239 | | | | | | 240 +-------+ +-------+ 241 | AS2 | 242 / - - - - - - - - - - - - - - 244 Figure 2 246 It is highly desirable that mechanisms exist to protect each AS 247 independently from network security attacks using the BGP Flow 248 Specification NLRI for intra-AS purposes only. Network operators 249 often deploy a dedicated Security Operations Center (SOC) within 250 their AS to monitor and detect such security attacks. To mitigate 251 attacks within an AS, operators require the ability to originate 252 intra-AS Flow Specification NLRIs from a central BGP route controller 253 that is not within the data forwarding plane. In this way, operators 254 can direct border routers within their AS with specific attack 255 mitigation actions (drop the traffic, forward to a pipe-cleaning 256 location, etc.). 258 In addition, an operator may extend the requirements above for a 259 group of ASes via policy. This is described below in Section (b.2.3) 260 of the validation procedure. 262 A central BGP route controller that originates a Flow Specification 263 NLRI should be able to avoid the complexity of having to determine 264 the egress border router whose path was chosen as the best for each 265 of its neighbors. When a central BGP route controller originates a 266 Flow Specification NLRI, the rest of the speakers within the AS will 267 see the BGP route controller as the originator of the Flow 268 Specification in terms of the validation procedure rules. Thus, it 269 is necessary to modify step (b) of the [RFC8955] validation procedure 270 such that an iBGP peer that is not within the data forwarding plane 271 may originate Flow Specification NLRIs. 273 5. Revised Validation Procedure 275 5.1. Revision of Route Feasibility 277 Step (b) of the validation procedure specified in Section 6 of 278 [RFC8955] is redefined as follows: 280 b) One of the following conditions MUST hold true: 282 1. The originator of the Flow Specification matches the 283 originator of the best-match unicast route for the destination 284 prefix embedded in the Flow Specification (this is the unicast 285 route with the longest possible prefix length covering the 286 destination prefix embedded in the Flow Specification). 288 2. The AS_PATH attribute of the Flow Specification is empty or 289 contains only an AS_CONFED_SEQUENCE segment [RFC5065]. 291 1. This condition SHOULD be enabled by default. 293 2. This condition MAY be disabled by explicit configuration 294 on a BGP speaker. 296 3. As an extension to this rule, a given non-empty AS_PATH 297 (besides AS_CONFED_SEQUENCE segments) MAY be permitted by 298 policy. 300 Explanation: 302 Receiving either an empty AS_PATH or one with only an 303 AS_CONFED_SEQUENCE segment indicates that the Flow Specification 304 was originated inside the Local Domain. 306 With the above modification to the [RFC8955] validation procedure, 307 a BGP peer within the Local Domain that is not within the data 308 forwarding path can originate a Flow Specification. 310 Disabling the new condition above (b.2.2) could be a good practice 311 if the operator knew with certainty that a Flow Specification 312 would not be originated inside the Local Domain. An additional 313 case would be if it was known for a fact that only the right 314 egress border routers (i.e. those that were also egress border 315 routers for the best routes) were originating a Flow Specification 316 NLRI. 318 Also, policy may be useful to permit a specific set of non-empty 319 AS_PATHs (b.2.3). For example, it could validate a Flow 320 Specification whose AS_PATH contained only an AS_SEQUENCE segment 321 with ASes that were all known to belong to the same administrative 322 domain. 324 5.2. Revision of AS_PATH Validation 326 Section 6 of [RFC8955] states: 328 BGP implementations MUST also enforce that the AS_PATH attribute 329 of a route received via the External Border Gateway Protocol 330 (eBGP) contains the neighboring AS in the left-most position of 331 the AS_PATH attribute. While this rule is optional in the BGP 332 specification, it becomes necessary to enforce it here for 333 security reasons. 335 This rule prevents the exchange of BGP Flow Specification NLRIs at 336 Internet exchanges with BGP route servers, which by design don't 337 insert their own AS number into the AS_PATH (Section 2.2.2.1 of 338 [RFC7947]). Therefore, this document also redefines the [RFC8955] 339 AS_PATH validation procedure referenced above as follows: 341 BGP Flow Specification implementations MUST enforce that the AS in 342 the left-most position of the AS_PATH attribute of a Flow 343 Specification route received via the External Border Gateway 344 Protocol (eBGP) matches the AS in the left-most position of the 345 AS_PATH attribute of the best-match unicast route for the 346 destination prefix embedded in the Flow Specification NLRI. 348 Explanation: 350 For clarity, the AS in the left-most position of the AS_PATH means 351 the AS that was last added to an AS_SEQUENCE. 353 This proposed modification enables the exchange of BGP Flow 354 Specification NLRIs at Internet exchanges with BGP route servers 355 while at the same time, for security reasons, prevents an eBGP 356 peer from advertising an inter-domain Flow Specification for a 357 destination prefix that it does not provide reachability 358 information for. 360 Comparing only the left-most AS in the AS-PATH for eBGP learned 361 Flow Specification NLRIs is roughly equivalent to checking the 362 neighboring AS. If the peer is a route server, security is 363 necessarily weakened for the Flow Specification NLRI, as it is for 364 any unicast route advertised from a route server. An example is 365 discussed in the Security Considerations Section. 367 Redefinition of this AS_PATH validation rule for a Flow 368 Specification does not mean that the original rule in [RFC8955] 369 cannot be enforced as well. Its enforcement remains optional per 370 Section 6.3 of [RFC4271]. That is, a BGP speaker can enforce the 371 first AS in the AS_PATH to be the same as the neighbor AS for a 372 route belonging to any Address Family (including Flow 373 Specification Address Family). If the BGP speaker peer is not a 374 route server, when enforcing this optional rule, the security 375 characteristics are exactly equivalent to those specified in 376 [RFC8955]. 378 Alternatively, enforcing this optional rule for unicast routes 379 (even if not enforced on Flow Specification NLRIs) achieves 380 exactly the same security characteristics. The reason is that, 381 after all validations, the neighboring AS will be the same as the 382 left-most AS in the AS-PATH for the unicast route, and the left- 383 most AS in the AS_PATH for the unicast route will be the same as 384 the left-most AS in the AS_PATH for the Flow Specification NLRI. 385 Therefore, the neighboring AS will be the same as the left-most AS 386 in the AS_PATH for the Flow Specification NLRI (as the original 387 AS_PATH validation rule in [RFC8955] states). 389 Note, however, that not checking the full AS_PATH allows any rogue 390 or misconfigured AS the ability to originate undesired Flow 391 Specifications. This is a BGP security threat, already present on 392 [RFC8955], but out of the scope of this document. 394 Using the new rule to validate a Flow Specification route received 395 from a peer belonging to the same Local Domain is out of the scope 396 of this document. Note that although it's possible, its utility 397 is dubious. Although it is conceivable that a router in the same 398 Local Domain could send a rogue update, only eBGP risk is 399 considered within this document (in the same spirit as the 400 aforementioned AS_PATH validation in [RFC4271]). 402 6. Topology Considerations 404 [RFC8955] indicates that the originator may refer to the originator 405 path attribute (ORIGINATOR_ID) or (if the attribute is not present) 406 the transport address of the peer from which the BGP speaker received 407 the update. If the latter applies, a network should be designed so 408 it has a congruent topology amongst unicast routes and Flow 409 Specification routes. By congruent topology, it is understood that 410 the two routes (i.e. the Flow Specification route and its best-match 411 unicast route) are learned from the same peer across the AS. That 412 would likely not be true, for instance, if some peers only negotiated 413 one Address Family or if each Address Family peering had a different 414 set of policies. Failing to have a congruent topology would result 415 in step (b.1) of the validation procedure to fail. 417 With the additional second condition (b.2) in the validation 418 procedure, non-congruent topologies are supported within the Local 419 Domain if the Flow Specification is originated within the Local 420 Domain. 422 Explanation: 424 Consider the following scenarios of a non-congruent topology 425 without the second condition (b.2) being added to the validation 426 procedure: 428 1. Consider a topology with two BGP speakers with two iBGP 429 peering sessions between them, one for unicast and one for 430 Flow Specification. This is a non-congruent topology. Let's 431 assume that the ORIGINATOR_ID attribute was not received (e.g. 432 a route reflector receiving routes from its clients). In this 433 case, the Flow Specification validation procedure will fail 434 because of the first condition (b.1). 436 2. Consider a confederation of ASes with local AS X and local AS 437 Y (both belonging to the same Local Domain), and a given BGP 438 speaker X1 inside local AS X. The ORIGINATOR_ID attribute is 439 not advertised when propagating routes across local ASes. 440 Let's assume the Flow Specification route is received from 441 peer Y1 and the best-match unicast route is received from peer 442 Y2. Both peers belong to local AS Y. The Flow Specification 443 validation procedure will also fail because of the first 444 condition (b.1). 446 Consider now that the second conditon (b.2) is added to the 447 validation procedure. In the scenarios above, if Flow 448 Specifications are originated in the same Local Domain, the 449 AS_PATH will be empty or contain only an AS_CONFED_SEQUENCE 450 segment. Condition (b.2) will evaluate to true. Therefore, using 451 the second condition (b.2), as defined by this document, 452 guarantees that the overall validation procedure will pass. Thus, 453 non-congruent topologies are supported if the Flow Specification 454 is originated in the same Local Domain. 456 Flow Specifications originated in a different Local Domain sill 457 need a congruent topology. The reason is that in a non-congruent 458 topology the second condition (b.2) evaluates to false and only 459 the first condition (b.1) is evaluated. 461 7. IANA Considerations 463 This document includes no request to IANA. 465 8. Security Considerations 467 This document updates the route feasibility validation procedures for 468 Flow Specifications learned from iBGP peers and through route 469 servers. This change is in line with the procedures described in 470 [RFC8955] and, thus, security characteristics remain essentially 471 equivalent to the existing security properties of BGP unicast 472 routing, except as detailed below. 474 The security considerations discussed in [RFC8955] apply to this 475 specification as well. 477 This document makes the original AS_PATH validation rule (Section 6.3 478 of [RFC4271]) again OPTIONAL (Section 5.2) for Flow Specification 479 Address Family (the rule is no longer mandatory as had been specified 480 by [RFC8955]). If that original rule is not enforced for Flow 481 Specification it may introduce some new security risks. A speaker in 482 AS X peering with a route server could advertise a rogue Flow 483 Specification route whose first AS in AS_PATH was Y. Assume Y is the 484 first AS in the AS_PATH of the best-match unicast route. When the 485 route server advertises the Flow Specification to a speaker in AS Z, 486 it will be validated by that speaker. This risk is impossible to 487 prevent if the Flow Specification route is received from a route 488 server peer. If configuration (or other means beyond the scope of 489 this document) indicates that the peer is not a route server, that 490 optional rule SHOULD be enforced, for unicast and/or for Flow 491 Specification routes (as discussed in the AS_PATH Validation Section, 492 just enforcing it in one of those Addres Families is enough). If the 493 indication is that the peer is not a route server or there is no 494 conclusive indication, that optional rule SHOULD NOT be enforced. 496 A route server itself may be in a good position to enforce the 497 AS_PATH validation rule described in the previous paragraph. If it 498 is known that a route server is not peering with any other route 499 server, it can enforce the AS_PATH validation rule across all its 500 peers. 502 BGP updates learned from iBGP peers are considered trusted, so the 503 Traffic Flow Specifications contained in BGP updates are also 504 considered trusted. Therefore, it is not required to validate that 505 the originator of an intra-domain Traffic Flow Specification matches 506 the originator of the best-match unicast route for the destination 507 prefix embedded in that Flow Specification. Note that this 508 trustworthiness consideration is not absolute and the new possibility 509 that an iBGP speaker could send a rogue Flow Specification is 510 introduced. 512 The changes in Section 5.1 don't affect the validation procedures for 513 eBGP-learned routes. 515 It's worth mentioning that allowing (or making operationally 516 feasible) to originate Flow Specifications within the Local Domain 517 makes the network overall more secure. Flow Specifications can be 518 originated more readily during attacks and improve the stability and 519 security of the network. 521 9. Acknowledgements 523 The authors would like to thank Han Nguyen for his direction on this 524 work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen, 525 Shyam Sethuram, Susan Hares, Alvaro Retana and John Scudder for their 526 review comments. 528 10. References 530 10.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 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 538 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 539 DOI 10.17487/RFC4271, January 2006, 540 . 542 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 543 "Multiprotocol Extensions for BGP-4", RFC 4760, 544 DOI 10.17487/RFC4760, January 2007, 545 . 547 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 548 System Confederations for BGP", RFC 5065, 549 DOI 10.17487/RFC5065, August 2007, 550 . 552 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 553 "Internet Exchange BGP Route Server", RFC 7947, 554 DOI 10.17487/RFC7947, September 2016, 555 . 557 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 558 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 559 May 2017, . 561 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 562 Bacher, "Dissemination of Flow Specification Rules", 563 RFC 8955, DOI 10.17487/RFC8955, December 2020, 564 . 566 10.2. Informative References 568 [I-D.ietf-idr-deprecate-as-set-confed-set] 569 Kumari, W., Sriram, K., Hannachi, L., and J. Haas, 570 "Deprecation of AS_SET and AS_CONFED_SET in BGP", draft- 571 ietf-idr-deprecate-as-set-confed-set-05 (work in 572 progress), March 2021. 574 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 575 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 576 DOI 10.17487/RFC6472, December 2011, 577 . 579 Authors' Addresses 581 James Uttaro 582 AT&T 583 200 S. Laurel Ave 584 Middletown, NJ 07748 585 USA 587 Email: ju1738@att.com 588 Juan Alcaide 589 Cisco 590 7100 Kit Creek Road 591 Research Triangle Park, NC 27709 592 USA 594 Email: jalcaide@cisco.com 596 Clarence Filsfils 597 Cisco 599 Email: cf@cisco.com 601 David Smith 602 Cisco 603 111 Wood Ave South 604 Iselin, NJ 08830 605 USA 607 Email: djsmith@cisco.com 609 Pradosh Mohapatra 610 Sproute Networks 612 Email: mpradosh@yahoo.com