idnits 2.17.1 draft-ietf-grow-route-leak-detection-mitigation-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 October 2021) is 908 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 (-24) exists of draft-ietf-idr-bgp-open-policy-17 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR and SIDR K. Sriram, Ed. 3 Internet-Draft USA NIST 4 Intended status: Standards Track A. Azimov, Ed. 5 Expires: 27 April 2022 Yandex 6 24 October 2021 8 Methods for Detection and Mitigation of BGP Route Leaks 9 draft-ietf-grow-route-leak-detection-mitigation-06 11 Abstract 13 Problem definition for route leaks and enumeration of types of route 14 leaks are provided in RFC 7908. This document describes a new well- 15 known Large Community that provides a way for route-leak prevention, 16 detection, and mitigation. The configuration process for this 17 Community can be automated with the methodology for setting BGP roles 18 that is described in ietf-idr-bgp-open-policy draft. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 27 April 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3 56 3. Community vs Attribute . . . . . . . . . . . . . . . . . . . 4 57 4. Down Only Community . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Route-Leak Mitigation . . . . . . . . . . . . . . . . . . 5 59 4.2. Only Marking . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Implementation Considerations . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 8.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 RFC 7908 [RFC7908] provides a definition of the route-leak problem 73 and enumerates several types of route leaks. For this document, the 74 definition that is applied is that a route leak occurs when a route 75 received from a transit provider or a lateral peer is forwarded 76 (against commonly used policy) to another transit provider or a 77 lateral peer. The commonly used policy is that a route received from 78 a transit provider or a lateral peer MAY be forwarded only to 79 customers. 81 This document describes a solution for prevention, detection and 82 mitigation of route leaks which is based on conveying route-leak 83 detection information in a transitive well-known BGP Large Community 84 [RFC8092]. The configuration process for the Large Community MUST be 85 defined according to peering relations between ISPs. This process 86 can be automated with the methodology for setting BGP roles that is 87 described in [I-D.ietf-idr-bgp-open-policy]. 89 The techniques described in this document can be incrementally 90 deployed. If a pair of ISPs and/or Internet Exchanges (IXes) deploy 91 the proposed techniques, then they would detect and mitigate any 92 route leaks that occur in an AS path between them even when other 93 ASes in the path are not upgraded. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Peering Relationships 105 As described in [I-D.ietf-idr-bgp-open-policy] there are several 106 common peering relations between eBGP neighbors: 108 * Provider - sender is a transit provider of the neighbor; 110 * Customer - sender is a customer of the neighbor; 112 * Route Server (RS) - sender is route server at an internet exchange 113 (IX) 115 * RS-client - sender is client of an RS at an IX 117 * Peer - sender and neighbor are lateral (non-transit) peers; 119 If a route is received from a provider, peer, or RS-client, it MUST 120 follow the 'down only' rule, i.e., it MAY be advertised only to 121 customers. If a route is sent to a customer, peer, or RS-client, it 122 also MUST follow the 'down only' rule at each subsequent AS in the AS 123 path. 125 A standardized transitive route-leak detection signal is needed that 126 will prevent Autonomous Systems (ASes) from leaking and also inform a 127 remote ISP (or AS) in the AS path that a received route violates the 128 'down only' policy. This signal would facilitate a way to stop the 129 propagation of leaked prefixes. 131 To improve reliability and cover for non-participating preceding 132 neighbor, the signal should be set on both receiver and sender sides. 134 3. Community vs Attribute 136 This section presents a brief discussion of the advantages and 137 disadvantages of communities and BGP path attributes for the purpose 138 of route-leak detection. 140 A transitive path attribute is a native way to implement the route- 141 leak detection signal. Based on the way BGP protocol works, the use 142 of a transitive attribute makes it more certain that the route-leak 143 detection signal would pass unaltered through non-participating 144 (i.e., not upgraded) BGP routers. The main disadvantage of this 145 approach is that the deployment of a new BGP attribute requires a 146 software upgrade in the router OS which may delay wide adoption for 147 years. 149 On the other hand, BGP Communities do not require a router OS update. 150 The potential disadvantage of using a Community for the route-leak 151 detection signal is that it is more likely to be dropped somewhere 152 along the way in the AS path. Currently, the use of BGP Communities 153 is somewhat overloaded. BGP Communities are already used for 154 numerous applications: different types of route marking, route policy 155 control, blackholing, etc. It is observed that some ASes seem to 156 purposefully or accidentally remove BGP Communities on receipt, 157 sometimes well-known ones. Perhaps this issue may be mitigated with 158 strong policy guidance related to the handling of Communities. 160 Large Communities have much higher capacity, and therefore they are 161 likely to be less overloaded. Hence, Large Community is proposed to 162 be used for route-leak detection. This document suggests reserving 163 class for the purpose of transitive well-known Large 164 Communities that MUST NOT be stripped on ingress or egress. 166 While it is not a part of this document, the route-leak detection 167 signal described here can also be carried in a transitive BGP Path 168 Attribute, and similar prevention and mitigation techniques as 169 described here would apply (see [I-D.ietf-idr-bgp-open-policy]). 171 Due to frequently occurring regional and global disruptions in 172 Internet connectivity, it is critical to move forward with a solution 173 that is viable in the near term. That solution would be route-leak 174 detection using a well-known Large Community. 176 4. Down Only Community 178 This section specifies the semantics of route-leak detection 179 Community and its usage. This Community is given the specific name 180 Down Only (DO) Community. The DO Community is carried in a BGP Large 181 Community with a format as shown in Figure 1. 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | TBD1 (class for transitive well-known Large Communities) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | TBD2 (subclass for DO) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | ASN | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: Format of the DO Community using a BGP Large Community. 195 The authors studied different options for route-leak mitigation. The 196 main options considered are (1) drop detected route leaks and (2) 197 deprioritize detected route leaks. It can be demonstrated that the 198 loose mode that uses deprioritization is not safe. Traffic 199 Engineering (TE) techniques which limit prefix visibility are quite 200 common. It may happen that a more specific TE prefix is sent only to 201 downstream ASes or to IX(es)/selected peers, and a control Community 202 is used to restrict its propagation. If such a more specific prefix 203 is leaked, deprioritization will not stop such a route leak from 204 propagating. In addition, propagation of leaked prefixes based on 205 deprioritization may result in priority loops leading to BGP wedgies 206 [RFC4264] or even persistent route oscillations. 208 So, the only truly safe way to implement route-leak mitigation is to 209 drop detected route leaks. The ingress and egress policies 210 corresponding to 'drop detected route leaks' is described in 211 Section 4.1. This policy SHOULD be used as a default behavior. 213 Nevertheless, early adopters might want to deploy only the signaling 214 and perhaps use it only for diagnostics before applying any route- 215 leak mitigation policy. They are also encouraged to use slightly 216 limited marking, which is described in Section 4.2. 218 4.1. Route-Leak Mitigation 220 This section describes the eBGP ingress and egress policies that MUST 221 be used to perform route-leak prevention, detection and mitigation 222 using the DO Community. It should be noted that a route may carry 223 more than one DO Communities. Hence, in the rest of this document, 224 "a route with DO Community" means "a route with one or more DO 225 Communities". 227 The ingress policy MUST use the following procedure: 229 1. If a route with DO Community is received from a Customer or RS- 230 client, then it is a route leak and MUST be dropped. The 231 procedure halts. 233 2. If a route with DO Community is received from a Peer (non- 234 transit) and at least one DO value is not equal to the sending 235 neighbor's ASN, then it is a route leak and MUST be dropped. The 236 procedure halts. 238 3. If a route is received from a Provider, Peer, or RS, then a DO 239 Community MUST be added with a value equal to the sending 240 neighbor's ASN. 242 The egress policy MUST use the following procedure: 244 1. A route with DO Community (i.e., DO Community was present or 245 added at ingress) MUST NOT be sent to a Provider, Peer, or RS. 247 2. If a route is sent to a Customer or Peer, then a DO Community 248 MUST be added with value equal to the ASN of the sender. 250 The above procedures comprehensively provide route-leak prevention, 251 detection and mitigation. Policy consisting of these procedures 252 SHOULD be used as a default behavior. 254 4.2. Only Marking 256 This section describes eBGP ingress and egress marking policies that 257 MUST be used if an AS is not performing route-leak mitigation (i.e., 258 not dropping detected route leaks) as described in Section 4.1, but 259 wants to use the DO Community only for marking. The slightly limited 260 DO marking (compared to that in Section 4.1) described below 261 guarantees that this DO marking will not limit the leak detection 262 opportunities for subsequent ASes in the AS path. 264 The ingress policy MUST use the following procedure: 266 1. If a route with DO Community is received from a Customer or RS- 267 client, then it is a route leak. The procedure halts. 269 2. If a route with DO Community is received from a Peer (non- 270 transit) and at least one DO value is not equal to the sending 271 neighbor's ASN, then it is a route leak. The procedure halts. 273 3. If a route is received from a Provider, Peer, or RS, then a DO 274 Community MUST be added with value equal to the sending 275 neighbor's ASN. 277 The egress policy MUST use the following procedure: 279 1. If a route is sent to a Customer or RS-client, then a DO 280 Community MUST be added with value equal to the ASN of the 281 sender. 283 2. If a route without DO Community is sent to a Peer, then a DO 284 Community MUST be added with value equal to the ASN of the 285 sender. Conversely, if a route with DO Community (i.e., DO 286 Community was present or added at ingress) is sent to a Peer, 287 then an additional DO Community MUST NOT be added.) 289 These above procedures specify setting the DO signals in a way that 290 can be used to evaluate the potential impact of route-leak mitigation 291 policy before deploying strict dropping of detected route leaks. 293 5. Implementation Considerations 295 It was observed that the majority of BGP implementations do not 296 support negative match for communities like a:b:!c. Further, it is 297 observed that a route received from a compliant Peer (non-transit) 298 adhering to procedures from either Section 4.1 or Section 4.2 will 299 always have a single DO Community with value equal to the peer's ASN. 300 Hence, it is suggested to replace the second rule from the ingress 301 policies (in Section 4.1 and Section 4.2) with the following: 303 In Section 4.1: If a route with DO Community is received from a 304 Peer and a DO value is equal to the sending neighbor's ASN, then 305 it is a valid route, otherwise it is a route leak and MUST be 306 dropped. The procedure halts. 308 In Section 4.2: If a route with DO Community is received from a 309 Peer and a DO value is equal to the sending neighbor's ASN, then 310 it is a valid route, otherwise it is a route leak. The procedure 311 halts. 313 This rule is based on a weaker assumption that a peer that is doing 314 marking is also doing filtering (i.e., dropping detected leaks). 315 That is why networks that do not follow the route-leak mitigation 316 policy in Section 4.1 MUST carefully follow marking rules described 317 in Section 4.2. 319 6. IANA Considerations 321 IANA is requested to reserve a Global Administrator ID for 322 transitive well-known Large Community registry. IANA is also 323 requested to register a subclass for DO Community in this 324 registry. 326 7. Security Considerations 328 In specific circumstances in a state of partial adoption, route-leak 329 mitigation mechanism can result in Denial of Service (DoS) for the 330 victim prefix. Such a scenario may happen only for a prefix that has 331 a single path from the originator to a Tier-1 ISP and only when the 332 prefix is not covered with a less specific prefix with multiple paths 333 to the Tier-1 ISP. If, in such unreliable topology, a route leak is 334 injected somewhere inside this single path, then it may be dropped by 335 upper tier providers in the path, thus limiting prefix visibility. 336 While such anomaly is unlikely to happen, such an issue should be 337 easy to debug, since it directly affects the sequence of originator's 338 providers. 340 With the use of BGP Community, there is often a concern that the 341 Community propagates beyond its intended perimeter and causes harm 342 [streibelt]. However, that concern does not apply to the DO 343 Community because it is a transitive Community that must propagate as 344 far as the update goes. 346 8. References 348 8.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, 353 . 355 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 356 I., and N. Hilliard, "BGP Large Communities Attribute", 357 RFC 8092, DOI 10.17487/RFC8092, February 2017, 358 . 360 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 361 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 362 May 2017, . 364 8.2. Informative References 366 [I-D.ietf-idr-bgp-open-policy] 367 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 368 Sriram, "Route Leak Prevention and Detection using Roles 369 in UPDATE and OPEN Messages", Work in Progress, Internet- 370 Draft, draft-ietf-idr-bgp-open-policy-17, 13 October 2021, 371 . 374 [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, 375 DOI 10.17487/RFC4264, November 2005, 376 . 378 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 379 and B. Dickson, "Problem Definition and Classification of 380 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 381 2016, . 383 [streibelt] 384 Streibelt et al., F., "BGP Communities: Even more Worms in 385 the Routing Can", ACM IMC, October 2018, 386 . 388 Acknowledgements 390 The authors wish to thank John Scudder, Susan Hares, Ruediger Volk, 391 Jeffrey Haas, Mat Ford, Greg Skinner for their review and comments. 393 Contributors 395 The following people made significant contributions to this document 396 and should be considered co-authors: 398 Brian Dickson 399 Independent 400 Email: brian.peter.dickson@gmail.com 402 Doug Montgomery 403 USA National Institute of Standards and Technology 404 Email: dougm@nist.gov 406 Keyur Patel 407 Arrcus 408 Email: keyur@arrcus.com 410 Andrei Robachevsky 411 Internet Society 412 Email: robachevsky@isoc.org 414 Eugene Bogomazov 415 Qrator Labs 416 Email: eb@qrator.net 418 Randy Bush 419 Internet Initiative Japan 420 Email: randy@psg.com 422 Authors' Addresses 424 Kotikalapudi Sriram (editor) 425 USA National Institute of Standards and Technology 426 100 Bureau Drive 427 Gaithersburg, MD 20899 428 United States of America 430 Email: ksriram@nist.gov 432 Alexander Azimov (editor) 433 Yandex 434 Ulitsa Lva Tolstogo 16 435 Moscow 437 Email: a.e.azimov@gmail.com