idnits 2.17.1 draft-ietf-grow-as-path-prepending-03.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 8, 2021) is 1166 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 395 -- Looks like a reference, but probably isn't: '2' on line 397 -- Looks like a reference, but probably isn't: '3' on line 400 ** Downref: Normative reference to an Informational RFC: RFC 5398 ** Downref: Normative reference to an Informational RFC: RFC 5737 ** Downref: Normative reference to an Informational RFC: RFC 8195 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. McBride 3 Internet-Draft Futurewei 4 Intended status: Best Current Practice D. Madory 5 Expires: August 12, 2021 Kentik 6 J. Tantsura 7 Apstra 8 R. Raszuk 9 Bloomberg LP 10 H. Li 11 HPE 12 J. Heitz 13 Cisco 14 February 8, 2021 16 AS Path Prepending 17 draft-ietf-grow-as-path-prepending-03 19 Abstract 21 AS Path Prepending provides a tool to manipulate the BGP AS_Path 22 attribute through prepending multiple entries of an AS. AS Path 23 Prepending is used to deprioritize a route or alternate path. By 24 prepending the local ASN multiple times, ASs can make advertised AS 25 paths appear artificially longer. Excessive AS Path Prepending has 26 caused routing issues in the internet. This document provides 27 guidance,to the internet community, with how best to utilize AS Path 28 Prepending in order to avoid negatively affecting the internet. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 12, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Excessive Prepending . . . . . . . . . . . . . . . . . . 4 69 3.2. Prepending during a routing leak . . . . . . . . . . . . 5 70 3.3. Prepending to All . . . . . . . . . . . . . . . . . . . . 5 71 3.4. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.5. Errant announcement . . . . . . . . . . . . . . . . . . . 6 73 4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 7 74 5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH 86 attribute which enumerates ASs a route update has traversed. If the 87 UPDATE message is propagated over an external link, then the local AS 88 number is prepended to the AS_PATH attribute, and the NEXT_HOP 89 attribute is updated with an IP address of the router that should be 90 used as a next hop to the network. If the UPDATE message is 91 propagated over an internal link, then the AS_PATH attribute and the 92 NEXT_HOP attribute are passed unmodified. 94 A common practice among operators is to prepend multiple entries of 95 an AS (known as AS Path Prepending) in order to deprioritize a route 96 or a path. This has worked well in practice but the practice is 97 increasing, with both IPv4 and IPv6, and there are inherit risks to 98 the global internet especially with excessive AS Path Prepending. 99 Prepending is frequently employed in an excessive manner such that it 100 renders routes vulnerable to disruption or misdirection. AS Path 101 Prepending is discussed in Use of BGP Large Communities [RFC8195] and 102 this document provides additional, and specific, guidance to 103 operators on how to be a good internet citizen with the proper use of 104 AS Path Prepending. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Use Cases 114 There are various reasons that AS Path Prepending is in use today 115 including: 117 o Preferring one ISP over another ISP on the same ASBR or across 118 different ASBRs 120 o Preferring one ASBR over another ASBR in the same site 122 o Utilize one path exclusively and another path solely as a backup 124 o Signal to indicate that one path may have a different amount of 125 capacity than another where the lower capacity link still takes 126 traffic 128 o An ISP doesn't accept traffic engineering using BGP communities. 129 Prepending is the only option. 131 The following illustration, from Geoff Hustons Path Prepending in BGP 132 [1], shows how AS Prepending is typically used: 134 +---+ +---+ 135 +---| D |----| F | 136 | +---+ +---+ 137 +---+ +---+ | 138 | A |---| B | | 139 +---+ +---+ | 140 | +---+ +---+ 141 +---| C |----| E | 142 +---+ +---+ 144 B will normally prefer the path via C to send traffic to E, as this 145 represents the shorter AS path for B. If E were to prepend a further 146 two instances of its own AS number when advertising its routes to C, 147 then B will now see a different situation, where the AS Path via D 148 represents the shorter path. Through the use of selective prepending 149 E is able to alter the routing decision of B, even though B is not an 150 adjacent neighbour of E. The result is that traffic from A and B 151 will be passed via D and F to reach E, rather than via C. In this 152 way prepending implements action at a distance where the routing 153 decisions made by non-adjacent ASs can be influenced by selective AS 154 Path prepending. 156 3. Problems 158 Since it is so commonly used, what is the problem with the excessive 159 use of AS Path Prepending? Here are a few examples: 161 3.1. Excessive Prepending 163 The risk of excessive use of AS Path Prepending can be illustrated 164 with real-world examples that have been anonymized using documention 165 prefixes [RFC5737] and ASs [RFC5398] . Consider the prefix 166 198.51.100.0/24 which is normally announced with an inordinate amount 167 of prepending. A recent analysis revealed that 198.51.100.0/24 is 168 announced to the world along the following AS path: 170 64496 64511 64511 64511 64511 64511 64511 64511 64511 64511 64511 171 64511 64511 64511 64511 64511 64511 64511 64511 64511 64511 64511 172 64511 64511 174 In this example, the origin AS64511 appears 23 consecutive times 175 before being passed on to a single upstream (AS64496), which passes 176 it on to the global internet, prepended-to-all. An attacker, wanting 177 to intercept or manipulate traffic to this prefix, could enlist a 178 datacenter to allow announcements of the same prefix with a 179 fabricated AS path such as 999999 64496 64511. Here the fictional 180 AS999999 represents the shady datacenter. This malicious route would 181 be preferred due to the shortened AS path length and might go 182 unnoticed by the true origin, even if route-monitoring had been 183 implemented. Standard BGP route monitoring checks a route's origin 184 and upstream and both would be intact in this scenario. The length 185 of the prepending gives the attacker room to craft an AS path that 186 would appear plausible to the casual observer, comply with origin 187 validation mechanisms, and not be detected by off-the-shelf route 188 monitoring. 190 3.2. Prepending during a routing leak 192 In April 2010, a service provider experienced a routing leak. While 193 analyzing the leak something peculiar was noticed. When we ranked 194 the approximately 50,000 prefixes involved in the leak based on how 195 many ASs accepted the leaked routes, most of the impact was 196 constrained to Country A routes. However, two of the top five most- 197 propagated leaked routes (listed in the table below) were Country B 198 routes. 200 During the routing leak, nearly all of the ASs of the internet 201 preferred the Country A leaked routes for 192.0.2.0/21 and 202 198.51.100.0/22 because, at the time, these two Country B prefixes 203 were being announced to the entire internet along the following 204 excessively prepended AS path: 64496 64500 64511 64511 64511 64511 205 64511 64511. Virtually any illegitimate route would be preferred 206 over the legitimate route. In this case, the victim is all but 207 ensuring their victimhood. 209 There was only a single upstream seen in the prepending example from 210 above, so the prepending was achieving nothing except incurring risk. 211 You would think such mistakes would be relatively rare, especially 212 now, 10 years later. As it turns out, there is quite a lot of 213 prepending-to-all going on right now and during leaks, it doesn't go 214 well for those who make this mistake. While one can debate the 215 merits of prepending to a subset of multiple transit providers, it is 216 difficult to see the utility in prepending to every provider. In 217 this configuration, the prepending is no longer shaping route 218 propagation. It is simply incentivizing ASs to choose another origin 219 if one were to suddenly appear whether by mistake or otherwise. 221 3.3. Prepending to All 223 Based on analysis done in 2019, Excessive AS Path Prepending [2], out 224 of approximately 750,000 routes in the IPv4 global routing table, 225 nearly 60,000 BGP routes are prepended to 95% or more of hundreds of 226 BGP sources. About 8% of the global routing table, or 1 out of every 227 12 BGP routes, is configured with prepends to virtually the entire 228 internet. The 60,000 routes include entities of every stripe: 229 governments, financial institutions, even important parts of internet 230 infrastructure. 232 Much of the worst propagation of leaked routes during big leak events 233 have been due to routes being prepended-to-all. AS64505 leak of 234 April 2014 (>320,000 prefixes) was prepended-to-all. And the AS64506 235 leak of June 2015 (>260,000 prefixes) was also prepended-to-all. 236 Prepended-to-all prefixes are those seen as prepended by all (or 237 nearly all) of the ASs of the internet. In this configuration, 238 prepending is no longer shaping route propagation but is simply 239 incentivizing ASs to choose another origin if one were to suddenly 240 appear whether by mistake or otherwise. The percentage of the IPv4 241 table that is prepended-to-all is growing at 0.5% per year. The IPv6 242 table is growing slower at 0.2% per year. The reasons for using 243 prepend-to-all appears to be due to 1) the AS forgetting to remove 244 the prepending for one of its transit providers when it is no longer 245 needed and 2) the AS attempting to de-prioritize traffic from transit 246 providers over settlement-free peers and 3) there are simply a lot of 247 errors in BGP routing. Consider the prepended AS path below: 249 64496 64501 64501 64510 64510 64501 64510 64501 64501 64510 64510 250 64501 64501 64510 252 The prepending here involves a mix of two distinct ASNs (64501 and 253 64510) with the last two digits transposed. 255 3.4. Memory 257 Long AS Paths cause an increase in memory usage by BGP speakers. The 258 memory usage is not so much a concern in the control plane BGP 259 implementations, but more so when AS Paths are included in Netflow 260 messages. Netflow is processed in the forwarding plane, where memory 261 is more expensive than in the control plane. 263 A concern about an AS Path longer than 255 is the extra complexity 264 required to process it, because it needs to be encoded in more than 265 one AS_SEQUENCE in the AS_PATH BGP path attribute. 267 3.5. Errant announcement 269 There was an Internet-wide outage caused by a single errant routing 270 announcement. In this incident, AS64496 announced its one prefix 271 with an extremely long AS path. Someone entered their ASN instead of 272 the prepend count 64496 modulo 256 = 252 prepends and when a path 273 lengths exceeded 255, routers crashed 275 4. Alternatives to AS Path Prepend 277 There are various options to provide path preference without needing 278 to use AS Path Prepend: 280 o Use predefined communities that are mapped to a particular 281 behavior when propagated. 283 o Announce more specific routes on the preferred path. 285 o The BGP Origin Code is an attribute that is used for path 286 selection and can be used as a high order tie-breaker. The three 287 origin codes are IGP, EGP and INCOMPLETE. When AS Paths are of 288 equivalent length, users could advertise paths, with IGP or EGP 289 origin, over the preferred path while the other ASBRs (which would 290 otherwise need to prepend N times) advertises with an INCOMPLETE 291 origin code. 293 5. Best Practices 295 Many of the best practices, or lack thereof, can be illustrated from 296 the preceeding examples. Here's a summary of the best current 297 practices when using AS Path Prepending: 299 o Network operators should ensure prepending is absolutely necessary 300 as many networks have excessive prepending. It is best to 301 innumerate what the routing policies are intended to achieve 302 before concluding that prepending is a solution 304 o The neighbor you are prepending may have an unconditional 305 preference for customer routes and prepending doesn't work. It's 306 helpful to check with neighbors to see if they will honor the 307 prepend to avoid wasting effort and potentially causing further 308 vulnerabilities. 310 o There is no need to prepend more than 5 ASs. The following 311 diagram shows that, according to Excessive AS Path Prepending [3], 312 90% of AS path lengths are 5 ASNs or fewer in length. 314 +------------------------------------+ 315 90| | 316 | X | 317 80| X X | 318 | X X | 319 70| X X | 320 | X X | 321 60| X X | 322 | X X | 323 50| X X | 324 | X X | 325 40| X X | 326 | X X | 327 30| X X | 328 | X X | 329 20| X XX | 330 | XX XX | 331 10| XX XXXX | 332 |XX XXXXXXXXXXXXXXXXX| 333 +------------------------------------+ 334 5 10 15 335 AS Path Length in IPv4 337 X Axis = unique AS Paths in millions 339 o Don't prepend ASNs that you don't own. 341 o Prepending-to-all is a self-inflicted and needless risk that 342 serves little purpose. Those excessively prepending their routes 343 should consider this risk and adjust their routing configuration. 345 o The Internet is typically around 5 ASs deep with the largest 346 AS_PATH being 16-20 ASNs. Some have added 100 or more AS Path 347 Prepends and operators should therefore consider limiting the 348 maximum AS-path length being accepted through aggressive filter 349 policies. 351 6. IANA Considerations 353 7. Security Considerations 355 Long prepending may make a network more vulernable to route hijacking 356 which will exist whenever there is a well connected peer that is 357 willing to forge their AS_PATH or allows announcements with a 358 fabricated AS path. 360 8. Acknowledgement 362 The authors would like to thank Greg Skinner, Randy Bush, Dave 363 Farmer, Nick Hilliard, Martijn Schmidt, Michael Still, Geoff Huston 364 and Jeffrey Haas for contributing to this document. 366 9. References 368 9.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 376 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 377 DOI 10.17487/RFC4271, January 2006, 378 . 380 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 381 Documentation Use", RFC 5398, DOI 10.17487/RFC5398, 382 December 2008, . 384 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 385 Reserved for Documentation", RFC 5737, 386 DOI 10.17487/RFC5737, January 2010, 387 . 389 [RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP 390 Large Communities", RFC 8195, DOI 10.17487/RFC8195, June 391 2017, . 393 9.2. URIs 395 [1] https://labs.apnic.net/?p=1264 397 [2] https://blogs.oracle.com/internetintelligence/excessive-as-path- 398 prepending-is-a-self-inflicted-vulnerability 400 [3] https://blogs.oracle.com/internetintelligence/excessive-as-path- 401 prepending-is-a-self-inflicted-vulnerability 403 Authors' Addresses 404 Mike McBride 405 Futurewei 407 Email: michael.mcbride@futurewei.com 409 Doug Madory 410 Kentik 412 Email: dmadory@kentik.com 414 Jeff Tantsura 415 Apstra 417 Email: jefftant.ietf@gmail.com 419 Robert Raszuk 420 Bloomberg LP 422 Email: robert@raszuk.net 424 Hongwei Li 425 HPE 427 Email: flycoolman@gmail.com 429 Jakob Heitz 430 Cisco 431 170 West Tasman Drive 432 San Jose, CA 95134 433 USA 435 Email: jheitz@cisco.com