idnits 2.17.1 draft-ietf-idr-bgp-flowspec-oid-14.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: This document makes the original AS_PATH validation rule ([RFC4271] section 6.3) again optional (section 4.2) for Flow Specification Address Family (the rule is no longer mandatory as it was specified by [RFC8955]). If that original rule is not enforced for Flow Specification it may introduce some new security risks. A peer (or a client of a route server peer) in AS X could advertise a rogue Flow Specification route whose first AS in AS_PATH was Y (assume Y is the first AS in the AS_PATH of the best-match unicast route). This risk is impossible to prevent if the Flow Specification route is received from a route server peer. If that peer is known for a fact not to be a route server, that optional rule SHOULD be enforced for Flow Specification routes. Note that identifying those peers that are route servers may suppose an operational challenge. If the condition of the peer is unknown, the rule SHOULD not be enforced. -- The document date (May 13, 2021) is 1077 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 (~~), 3 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: November 14, 2021 D. Smith 7 Cisco 8 P. Mohapatra 9 Sproute Networks 10 May 13, 2021 12 Revised Validation Procedure for BGP Flow Specifications 13 draft-ietf-idr-bgp-flowspec-oid-14 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 requires that the originator 20 of the Flow Specification matches the originator of the best-match 21 unicast route for the destination prefix embedded in the Flow 22 Specification. For an iBGP received route, the originator is 23 typically a border router within the same autonomous system. The 24 objective is to allow only BGP speakers within the data forwarding 25 path to originate BGP Flow Specifications. Sometimes it is desirable 26 to originate the BGP Flow Specification from any place within the 27 autonomous system itself, for example, from a centralized BGP route 28 controller. However, the validation procedure will fail in this 29 scenario. The modification proposed herein relaxes the validation 30 rule to enable Flow Specifications to be originated within the same 31 autonomous system as the BGP speaker performing the validation. 32 Additionally, this document revises the AS_PATH validation rules so 33 Flow Specifications received from an eBGP peer can be validated when 34 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 November 14, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Revised Validation Procedure . . . . . . . . . . . . . . . . 6 76 4.1. Revision of Route Feasibility . . . . . . . . . . . . . . 6 77 4.2. Revision of AS_PATH Validation . . . . . . . . . . . . . 7 78 5. Topology Considerations . . . . . . . . . . . . . . . . . . . 9 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 9.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 2. Introduction 97 [RFC8955] defines a BGP NLRI [RFC4271] that can be used to distribute 98 traffic Flow Specifications amongst BGP speakers in support of 99 traffic filtering. The primary intention of [RFC8955] is to enable 100 downstream autonomous systems to signal traffic filtering policies to 101 upstream autonomous systems. In this way, traffic is filtered closer 102 to the source and the upstream autonomous system(s) avoid carrying 103 the traffic to the downstream autonomous system only to be discarded. 104 [RFC8955] also enables more granular traffic filtering based upon 105 upper layer protocol information (e.g., protocol port numbers) as 106 opposed to coarse IP destination prefix-based filtering. Flow 107 specification NLRIs received from a BGP peer are subject to validity 108 checks before being considered feasible and subsequently installed 109 within the respective Adj-RIB-In. 111 The validation procedure defined within [RFC8955] requires that the 112 originator of the Flow Specification NLRI matches the originator of 113 the best-match unicast route for the destination prefix embedded in 114 the Flow Specification. The aim is making sure that only speakers on 115 the forwarding path can originate the Flow Specification. Let's 116 consider the particular case where the Flow Specification is 117 originated in any location within the same autonomous system than the 118 speaker performing the validation (for example by a centralized BGP 119 route controller), and the best-match unicast route is originated in 120 another autonomous system. In order for the validation to succeed 121 for a Flow Specification received from an iBGP peer, it could be 122 possible to disseminate such Flow Specification NLRIs directly from 123 the specific border router (within the local autonomous system) that 124 is advertising the corresponding best-match unicast route to the 125 local autonomous system. Those border routers would be acting as de 126 facto router controllers. This approach would be, however, 127 operationally cumbersome in an autonomous system with a large number 128 of border routers having complex BGP policies. 130 Figure 1 illustrates this principle. R1 (the upstream router) and RR 131 need to validate the Flow Specification whose embedded destination 132 prefix has a best-match unicast route (dest-route) originated by 133 ASBR2. ASBR2 could originate the Flow Specification, and it would be 134 validated when received by RR and R1. Sometimes the Flow 135 Specification needs to be originated inside AS1. ASBR1 could 136 originate it, and the Flow Specification would still be validated. 137 In both cases, the Flow Specification is originated by a router in 138 the same forwarding path as the dest-route. For the case where AS1 139 has thousands of ASBRs, it becomes impractical to originate different 140 Flow Specification rules on each ASBR in AS1 based on which ASBR each 141 dest-route is learned from. The objective is to advertise all the 142 Flow Specifications from the same route-controller. 144 R1(AS1) --- RR(AS1) --- ASBR1(AS1) --- ASBR2(AS2) 145 | 146 route-controller(AS1) 148 Figure 1 150 This document describes a modification to the [RFC8955] validation 151 procedure, allowing Flow Specification NLRIs to be originated from a 152 centralized BGP route controller located within the local autonomous 153 system and not necessarily in the data forwarding path. While the 154 proposed modification cannot be used for inter-domain coordination of 155 traffic filtering, it greatly simplifies distribution of intra-domain 156 traffic filtering policies within an autonomous system which has a 157 large number of border routers having complex BGP policies. By 158 relaxing the validation procedure for iBGP, the proposed modification 159 allows Flow Specifications to be distributed in a standard and 160 scalable manner throughout an autonomous system. 162 Throughout this document, some references are made to 163 AS_CONFED_SEQUENCE segments; see Sections 4.1 and 5. If 164 AS_CONFED_SET segments are also present in the AS_PATH, the same 165 considerations apply to them. Note, however, that the use of 166 AS_CONFED_SET segments is not recommended [RFC6472]. Refer to 167 [I-D.ietf-idr-deprecate-as-set-confed-set] as well. 169 3. Motivation 171 Step (b) of the validation procedure in [RFC8955], section 6 is 172 defined with the underlying assumption that the Flow Specification 173 NLRI traverses the same path, in the inter-domain and intra-domain 174 route distribution graph, as that of the longest-match unicast route 175 for the destination prefix embedded in the Flow Specification. 177 In the case of inter-domain traffic filtering, the Flow Specification 178 originator at the egress border routers of an AS (e.g. RTR-D and 179 RTR-E of AS1 in Figure 2) matches the eBGP neighbor that advertised 180 the longest match destination prefix (see RTR-F and RTR-G 181 respectively in Figure 2). 183 Similarly, at the upstream routers of an AS (see RTR-A and RTR-B of 184 AS1 in Figure 2), the Flow Specification originator matches the 185 egress iBGP border routers that had advertised the unicast route for 186 the best-match destination prefix (see RTR-D and RTR-E respectively 187 in Figure 2). This is true even when upstream routers select paths 188 from different egress border routers as best route based upon IGP 189 distance. For example, in Figure 2: 191 RTR-A chooses RTR-D as the best route 192 RTR-B chooses RTR-E as the best route 194 / - - - - - - - - - - - - - - 195 | AS1 | 196 +-------+ +-------+ 197 | | | | | | 198 | RTR-A | | RTR-B | 199 | | | | | | 200 +-------+ +-------+ 201 | \ / | 202 iBGP \ / iBGP 203 | \ / | 204 +-------+ 205 | | | | 206 | RTR-C | 207 | | RC | | 208 +-------+ 209 | / \ | 210 / \ 211 | iBGP / \ iBGP | 212 +-------+ +-------+ 213 | | RTR-D | | RTR-E | | 214 | | | | 215 | | | | | | 216 +-------+ +-------+ 217 | | | | 218 - - -|- - - - - - - - -|- - -/ 219 | eBGP eBGP | 220 - - -|- - - - - - - - -|- - -/ 221 | | | | 222 +-------+ +-------+ 223 | | | | | | 224 | RTR-F | | RTR-G | 225 | | | | | | 226 +-------+ +-------+ 227 | AS2 | 228 / - - - - - - - - - - - - - - 230 Figure 2 232 It is highly desirable that mechanisms exist to protect each AS 233 independently from network security attacks using the BGP Flow 234 Specification NLRI for intra-AS purposes only. Network operators 235 often deploy a dedicated Security Operations Center (SOC) within 236 their AS to monitor and detect such security attacks. To mitigate 237 attacks within an AS, operators require the ability to originate 238 intra-AS Flow Specification NLRIs from a central BGP route controller 239 that is not within the data forwarding plane. In this way, operators 240 can direct border routers within their AS with specific attack 241 mitigation actions (drop the traffic, forward to a clean-pipe center, 242 etc.). 244 In addition, an operator may extend the requirements above for a 245 group of ASes via policy. This is described in section (b.2.3) of 246 the validation procedure. 248 A central BGP route controller that originates a Flow Specification 249 NLRI should be able to avoid the complexity of having to determine 250 the egress border router whose path was chosen as the best for each 251 of its neighbors. When a central BGP route controller originates a 252 Flow Specification NLRI, the rest of the speakers within the AS will 253 see the BGP controller as the originator of the Flow Specification in 254 terms of the validation procedure rules. Thus, it is necessary to 255 modify step (b) of the [RFC8955] validation procedure such that an 256 iBGP peer that is not within the data forwarding plane may originate 257 Flow Specification NLRIs. 259 4. Revised Validation Procedure 261 4.1. Revision of Route Feasibility 263 Step (b) of the validation procedure specified in [RFC8955], section 264 6 is redefined as follows: 266 b) One of the following conditions MUST hold true: 268 1. The originator of the Flow Specification matches the 269 originator of the best-match unicast route for the destination 270 prefix embedded in the Flow Specification (this is the unicast 271 route with the longest possible prefix length covering the 272 destination prefix embedded in the Flow Specification). 274 2. The AS_PATH attribute of the Flow Specification is empty or 275 contains only an AS_CONFED_SEQUENCE segment [RFC5065]. 277 1. This condition SHOULD be enabled by default (it may be 278 disabled by explicit configuration as described on the 279 next list item (b.2.2)). 281 2. This condition MAY be disabled by explicit configuration 282 on a BGP speaker. 284 3. As an extension to this rule, a given non-empty AS_PATH 285 (besides AS_CONFED_SEQUENCE segments) MAY be validated by 286 policy. 288 Explanation: 290 In this context, a local domain includes the local AS or the local 291 confederation [RFC5065]. Receiving either an empty AS_PATH or one 292 with only an AS_CONFED_SEQUENCE segment indicates that the Flow 293 Specification was originated inside the local domain. 295 With the above modification to the [RFC8955] validation procedure, 296 a BGP peer within the local domain that is not within the data 297 forwarding path can originate a Flow Specification. 299 Disabling the new condition above (b.2.2) could be a good practice 300 if the operator knew with certainty that a Flow Specification 301 would not be originated inside the local domain. An additional 302 case would be if it was known for a fact that only the right 303 egress border routers (i.e. those that were also egress border 304 routers for the best routes) were originating a Flow Specification 305 NLRI. 307 Also, policy may be useful to validate a specific set of non-empty 308 AS_PATHs (b.2.3). For example, it could validate a Flow 309 Specification whose AS_PATH contained only an AS_SEQUENCE segment 310 with ASes that were all known to belong to the same administrative 311 domain. 313 4.2. Revision of AS_PATH Validation 315 [RFC8955] states: 317 BGP implementations MUST also enforce that the AS_PATH attribute 318 of a route received via the External Border Gateway Protocol 319 (eBGP) contains the neighboring AS in the left-most position of 320 the AS_PATH attribute. While this rule is optional in the BGP 321 specification, it becomes necessary to enforce it here for 322 security reasons. 324 This rule prevents the exchange of BGP Flow Specification NLRIs at 325 Internet exchanges with BGP route servers [RFC7947]. Therefore, this 326 document also redefines the [RFC8955] AS_PATH validation procedure 327 referenced above as follows: 329 BGP Flow Specification implementations MUST enforce that the AS in 330 the left-most position of the AS_PATH attribute of a Flow 331 Specification route received via the External Border Gateway 332 Protocol (eBGP) matches the AS in the left-most position of the 333 AS_PATH attribute of the best-match unicast route for the 334 destination prefix embedded in the Flow Specification NLRI. 336 Explanation: 338 For clarity, the AS in the left-most position of the AS_PATH means 339 the AS that was last added to the AS_SEQUENCE. 341 This proposed modification enables the exchange of BGP Flow 342 Specification NLRIs at Internet exchanges with BGP route servers 343 while at the same time, for security reasons, prevents an eBGP 344 peer from advertising an inter-domain Flow Specification for a 345 destination prefix that it does not provide reachability 346 information for. 348 Comparing only the last ASes added is sufficient for eBGP learned 349 Flow Specification NLRIs. Requiring a full AS_PATH match would 350 limit origination of inter-domain Flow Specifications to the 351 origin AS of the best-match unicast route for the destination 352 prefix embedded in the Flow Specification only. As such, a full 353 AS_PATH validity check may prevent transit ASes from originating 354 inter-domain Flow Specifications, which is not desirable. 356 Note, however, that not checking the full AS_PATH allows any rogue 357 or misconfigured AS the ability to originate undesired Flow 358 Specifications. This is a security BGP threat, but out of the 359 scope of this document. 361 Redefinition of this AS_PATH validation rule for a Flow 362 Specification does not mean that the original rule in [RFC8955] 363 cannot be enforced as well. Its enforcement remains optional per 364 [RFC4271] section 6.3. That is, a BGP speaker can enforce the 365 first AS in the AS_PATH to be the same as the neighbor AS for any 366 address-family route (including a Flow Specification address- 367 family route). 369 Using the new rule to validate a Flow Specification route received 370 from an External Border Gateway Protocol (eBGP) peer belonging to 371 the same local domain (in the case of a confederation) is out of 372 the scope of this document. Note that although it's possible, its 373 utility is dubious. Although it is conceivable that a router in 374 the same local domain (both iBGP and eBGP within the same local 375 domain) could send a rogue update, only eBGP (outside the local 376 domain) risk is considered within this document (in the same 377 spirit of the mentioned beforehand AS_PATH validation in 378 [RFC4271]). 380 5. Topology Considerations 382 [RFC8955] indicates that the originator may refer to the originator 383 path attribute (ORIGINATOR_ID) or (if the attribute is not present) 384 the transport address of the peer from which the BGP speaker received 385 the update. If the latter applies, a network should be designed so 386 it has a congruent topology amongst unicast routes and Flow 387 Specification routes. By congruent topology, it is understood that 388 the two routes (i.e. the Flow Specification route and its best-match 389 unicast route) are learned from the same peer across the AS. That 390 would likely not be true, for instance, if some peers only negotiated 391 one type of address-family or if each address-family had a different 392 set of policies. 394 With the additional second condition (b.2) in the validation 395 procedure, non-congruent topologies are supported within the local 396 domain if the Flow Specification is originated within the local 397 domain. 399 Explanation: 401 Consider the following scenarios of a non-congruent topology 402 without the second condition (b.2) being added to the validation 403 procedure: 405 1. Consider a topology with two BGP speakers with two iBGP 406 peering sessions between them, one for unicast and one for 407 Flow Specification. This is a non-congruent topology. Let's 408 assume that the ORIGINATOR_ID attribute was not received (e.g. 409 a route reflector receiving routes from its clients). In this 410 case, the Flow Specification validation procedure will fail 411 because of the first condition (b.1). 413 2. Consider a confederation of ASes with local AS X and local AS 414 Y (both belonging to the same local domain), and a given BGP 415 speaker X1 inside local AS X. The ORIGINATOR_ID attribute is 416 not advertised when propagating routes across local ASes. 417 Let's assume the Flow Specification route is received from 418 peer Y1 and the best-match unicast route is received from peer 419 Y2. Both peers belong to local AS Y. The Flow Specification 420 validation procedure will also fail because of the first 421 condition (b.1). 423 In the scenarios above, if Flow Specifications are originated in 424 the same local domain, the AS_PATH will be empty or contain only 425 an AS_CONFED_SEQUENCE segment. Condition (b.2) will evaluate to 426 true. Therefore, using the second condition (b.2), as defined by 427 this document, guarantees that the overall validation procedure 428 will pass. Thus, non-congruent topologies are supported if the 429 Flow Specification is originated in the same local domain. 431 Flow Specifications originated in a different local domain sill 432 need a congruent topology. The reason is that the second 433 condition (b.2) evaluates to false and only the first condition 434 (b.1) is evaluated. 436 6. IANA Considerations 438 This memo includes no request to IANA. 440 7. Security Considerations 442 This document updates the route feasibility validation procedures for 443 Flow Specifications learned from iBGP peers and through route 444 servers. This change is in line with the procedures described in 445 [RFC8955] and, thus, the security characteristics equivalent to the 446 existing security properties of BGP unicast routing are maintained. 448 The security considerations discussed in [RFC8955] apply to this 449 specification as well. 451 This document makes the original AS_PATH validation rule ([RFC4271] 452 section 6.3) again optional (section 4.2) for Flow Specification 453 Address Family (the rule is no longer mandatory as it was specified 454 by [RFC8955]). If that original rule is not enforced for Flow 455 Specification it may introduce some new security risks. A peer (or a 456 client of a route server peer) in AS X could advertise a rogue Flow 457 Specification route whose first AS in AS_PATH was Y (assume Y is the 458 first AS in the AS_PATH of the best-match unicast route). This risk 459 is impossible to prevent if the Flow Specification route is received 460 from a route server peer. If that peer is known for a fact not to be 461 a route server, that optional rule SHOULD be enforced for Flow 462 Specification routes. Note that identifying those peers that are 463 route servers may suppose an operational challenge. If the condition 464 of the peer is unknown, the rule SHOULD not be enforced. 466 A route server itself may be in a good position to enforce the 467 AS_PATH validation rule described in the previous paragraph. If a 468 route server knowns it's not peering with any other route server, it 469 can enforce the AS_PATH validation rule across all its peers. If, in 470 addition to that, the route server is trusted, the security threat 471 described above disappears. 473 BGP updates learned from iBGP peers are considered trusted, so the 474 Traffic Flow Specifications contained in BGP updates are also 475 considered trusted. Therefore, it is not required to validate that 476 the originator of an intra-domain Traffic Flow Specification matches 477 the originator of the best-match unicast route for the destination 478 prefix embedded in that Flow Specification. Note that this 479 trustworthy consideration is not absolute and the new possibility 480 than an iBGP speaker could send a rogue Flow Specification is 481 introduced. 483 The changes in Section 4.1 don't affect the validation procedures for 484 eBGP-learned routes. 486 8. Acknowledgements 488 The authors would like to thank Han Nguyen for his direction on this 489 work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen 490 and Shyam Sethuram for their review comments. Shyam Sethuram for 491 their review comments. 493 9. References 495 9.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 503 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 504 DOI 10.17487/RFC4271, January 2006, 505 . 507 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 508 System Confederations for BGP", RFC 5065, 509 DOI 10.17487/RFC5065, August 2007, 510 . 512 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 513 "Internet Exchange BGP Route Server", RFC 7947, 514 DOI 10.17487/RFC7947, September 2016, 515 . 517 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 518 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 519 May 2017, . 521 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 522 Bacher, "Dissemination of Flow Specification Rules", 523 RFC 8955, DOI 10.17487/RFC8955, December 2020, 524 . 526 9.2. Informative References 528 [I-D.ietf-idr-deprecate-as-set-confed-set] 529 Kumari, W., Sriram, K., Hannachi, L., and J. Haas, 530 "Deprecation of AS_SET and AS_CONFED_SET in BGP", draft- 531 ietf-idr-deprecate-as-set-confed-set-05 (work in 532 progress), March 2021. 534 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 535 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 536 DOI 10.17487/RFC6472, December 2011, 537 . 539 Authors' Addresses 541 James Uttaro 542 AT&T 543 200 S. Laurel Ave 544 Middletown, NJ 07748 545 USA 547 Email: ju1738@att.com 549 Juan Alcaide 550 Cisco 551 7100 Kit Creek Road 552 Research Triangle Park, NC 27709 553 USA 555 Email: jalcaide@cisco.com 557 Clarence Filsfils 558 Cisco 560 Email: cf@cisco.com 561 David Smith 562 Cisco 563 111 Wood Ave South 564 Iselin, NJ 08830 565 USA 567 Email: djsmith@cisco.com 569 Pradosh Mohapatra 570 Sproute Networks 572 Email: mpradosh@yahoo.com