idnits 2.17.1 draft-mcbride-grow-as-path-prepend-00.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (July 13, 2020) is 1383 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) ** Downref: Normative reference to an Informational RFC: RFC 8195 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: January 14, 2021 Oracle 6 J. Tantsura 7 Apstra 8 July 13, 2020 10 AS-Path Prepend 11 draft-mcbride-grow-as-path-prepend-00 13 Abstract 15 AS_Path prepending provides a tool to manipulate the BGP AS_Path 16 attribute through prepending multiple entries of an AS. AS_Path 17 prepend is used to deprioritize a route or alternate path. By 18 prepending the local ASN multiple times, ASes can make advertised AS 19 paths appear artificially longer. Excessive AS_Path prepending has 20 caused routing issues in the internet. This document provides 21 guidance,to the internet community, with how best to utilize AS_Path 22 prepend in order to avoid negatively affecting the internet. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 14, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Excessive Prepending . . . . . . . . . . . . . . . . . . 3 62 2.2. Prepending during a routing leak . . . . . . . . . . . . 3 63 2.3. Route Competition . . . . . . . . . . . . . . . . . . . . 4 64 2.4. Prepending to All . . . . . . . . . . . . . . . . . . . . 5 65 2.5. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.6. Errant announcement . . . . . . . . . . . . . . . . . . . 6 67 3. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_Path 77 attribute which enumerates the ASs that must be traversed to reach 78 the networks listed in the BGP UPDATE message. If the UPDATE message 79 is propagated over an external link, then the local AS number is 80 prepended to the AS_PATH attribute, and the NEXT_HOP attribute is 81 updated with an IP address of the router that should be used as a 82 next hop to the network. If the UPDATE message is propagated over an 83 internal link, then the AS_PATH attribute and the NEXT_HOP attribute 84 are passed unmodified. 86 A common practice among operators is to prepend multiple entries of 87 an AS (known as AS_Path prepend) in order to deprioritize a route or 88 a path. This has worked well in practice but the practice is 89 increasing, with both IPv4 and IPv6, and there are inherit risks to 90 the global internet especially with excessive AS_Path prepending. 91 Prepending is frequently employed in an excessive manner such that it 92 renders routes vulnerable to disruption or misdirection. AS_Path 93 prepending is discussed in Use of BGP Large Communities [RFC8195] and 94 this document provides additional, and specific, guidance to 95 operators on how to be a good internet citizen with the proper use of 96 AS_Path prepend. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2. Problems 106 Since it it so commonly used, what is the problem with the excessive 107 use of AS_Path prepend? Here are a few examples: 109 2.1. Excessive Prepending 111 The risk of excessive use of AS_Path prepend can be illustrated with 112 real-world examples. Consider the Ukranian prefix (95.47.142.0/23) 113 which is normally announced with an inordinate amount of prepending. 114 A recent analysis revealed that 95.47.142.0/23 is announced to the 115 world along the following AS path: 117 3255 197158 197158 197158 197158 197158 197158 197158 197158 197158 118 197158 197158 197158 197158 197158 197158 197158 197158 197158 197158 119 197158 197158 197158 197158 121 In this example, the origin AS197158 appears 23 consecutive times 122 before being passed on to a single upstream (AS3255), which passes it 123 on to the global internet, prepended-to-all. An attacker wanting to 124 intercept or manipulate traffic to this prefix might enlist a 125 datacenter of questionable morals who would allow announcements of 126 the same prefix with a fabricated AS path such as 999999 3255 197158. 127 Here the fictional AS999999 represents the shady datacenter. This 128 malicious route would be pretty popular due to the shortened AS path 129 length and might go unnoticed by the true origin, even if route- 130 monitoring had been implemented. Standard BGP route monitoring 131 checks a route's origin and upstream and both would be intact in this 132 scenario. The length of the prepending gives the attacker room to 133 craft an AS path that would appear plausible to the casual observer, 134 comply with origin validation mechanisms, and not be detected by off- 135 the-shelf route monitoring. 137 2.2. Prepending during a routing leak 139 In April 2010, China Telecom experienced a routing leak. While 140 analyzing the leak something peculiar was noticed. When we ranked 141 the approximately 50,000 prefixes involved in the leak based on how 142 many ASes accepted the leaked routes, most of the impact was 143 constrained to Chinese routes. However, two of the top five most- 144 propagated leaked routes (listed in the table below) were US routes. 145 Was there some grand conspiracy to intercept traffic destined for 146 these routes? Actually, it was due to something much more troubling: 147 gratuitous AS path prepending. 149 During the routing leak, nearly all of the ASes of the internet 150 preferred the Chinese leaked routes for 12.5.48.0/21 and 151 12.4.196.0/22 because, at the time, these two US prefixes were being 152 announced to the entire internet along the following excessively 153 prepended AS path: 3257 7795 12163 12163 12163 12163 12163 12163. 154 With this odd configuration, virtually any illegitimate route, 155 whether a deliberate hijack or an inadvertent leak, would be 156 preferred over the legitimate route. In this case, the victim is all 157 but ensuring their victimhood. 159 There was only a single upstream seen in the prepending example from 160 above, so the prepending was achieving nothing while incurring risk 161 of hijacked traffic during a routing leak or hijack. You'd think 162 such mistakes would be relatively rare, especially now, 10 years 163 later. As it turns out, there is quite a lot of prepending-to-all 164 going on right now and during leaks, it doesn't go well for those who 165 make this mistake. While one can debate the merits of prepending to 166 a subset of multiple transit providers, it is difficult to see the 167 utility in prepending to every provider. In this configuration, the 168 prepending is no longer shaping route propagation. It is simply 169 incentivizing ASes to choose another origin if one were to suddenly 170 appear whether by mistake or otherwise. 172 2.3. Route Competition 174 So what happens when a non-prepended route competes against an 175 excessively prepended route? Let's consider a real-world example. 176 The Polish route 91.149.240.0/22 is normally announced with the 177 origin prepended three times (41952 41952 41952) to three providers 178 and prepended twice to a fourth. Beginning at 15:28:14 UTC on June 179 6, a new origin that was not prepended appeared in the routing table 180 for this route. As is illustrated in the graphic below, AS60781 181 quickly became the most popular version of this route for the next 182 week until it disappeared. 184 When both AS41952 and AS60781 were in contention for being considered 185 the origin of this prefix, the non-prepended route was dominating as 186 we would expect. In some cases, the impact of prepending isn't as 187 straightforward. Let's take 66.220.224.0/19 as an example. This 188 prefix is prepended but isn't one of the 60,000 prepended-to-all 189 routes mentioned earlier because its prepending is only visible to a 190 little more than half of our BGP sources. In any event, this prefix 191 is announced to the internet in two ways: it's prepended to AS6939 192 and not prepended to AS174: 194 ...6939 17356 17356 17356 17356 17356 17356 17356 17356 17356 17356 195 17356 197 ...174 17356 199 From these two route options, one might reasonably infer that it is 200 17356's intention to deprioritize routes to AS6939 by prepending 201 itself 10 times on routes to that upstream. It may seem to follow 202 that the non-prepended path to AS174 would be the most popular. 203 However, the opposite is true. Despite extensive prepending, AS6939 204 is the more popular choice. In this case, prepending is going up 205 against the local preferences of a legion of ASes: AS6939 has an 206 extensive peering base of thousands of ASes. These ASes opt to send 207 traffic for free through their AS6939 peering links instead of having 208 to pay to send traffic through a transit provider (and via AS174) 209 regardless of the AS path length. AS17356 could prepend their routes 210 to AS6939 100 times (please don't!) and AS6939 would still be the 211 more popular provider. Keep in mind that the average AS diameter of 212 the internet is only around 4 hops, so prepending more than a couple 213 of times buys you nothing. 215 2.4. Prepending to All 217 Out of approximately 750,000 routes in the IPv4 global routing table, 218 nearly 60,000 BGP routes are prepended to 95% or more of hundreds of 219 BGP sources. About 8% of the global routing table, or 1 out of every 220 12 BGP routes, is configured with prepends to virtually the entire 221 internet. The 60,000 routes include entities of every stripe: 222 governments, financial institutions, even important parts of internet 223 infrastructure. 225 Much of the worst propagation of leaked routes during big leak events 226 have been due to routes being prepended-to-all. AS4671 leak of April 227 2014 (>320,000 prefixes) was prepended-to-all. And the AS4788 leak 228 of June 2015 (>260,000 prefixes) was also prepended-to-all. 229 Prepended-to-all prefixes are those seen as prepended by all (or 230 nearly all) of the ASes of the internet. In this configuration, 231 prepending is no longer shaping route propagation but is simply 232 incentivizing ASes to choose another origin if one were to suddenly 233 appear whether by mistake or otherwise. The percentage of the IPv4 234 table that is prepended-to-all is growing at 0.5% per year. The IPv6 235 table is growing slower at 0.2% per year. The reasons for using 236 prepend-to-all appears to be due to 1) the AS forgetting to remove 237 the prepending for one of its transit providers when it is no longer 238 needed and 2) the AS attempting to de-prioritize traffic from transit 239 providers over settlement-free peers and 3) there are simply a lot of 240 errors in BGP routing. Consider the prepended AS path of 241 181.191.170.0/24 below: 243 52981 267429 267429 267492 267492 267429 267429 267492 267492 267429 244 267429 267492 267492 267429 246 The prepending here involves a mix of two distinct ASNs (267429 and 247 267492) with the last two digits transposed. 249 2.5. Memory 251 Some BGP implementations have had memory corruption/fragmentation 252 problems with long AS_PATHS. 254 2.6. Errant announcement 256 There was an Internet-wide outage caused by a single errant routing 257 announcement. In this incident, AS47868 announced its one prefix 258 with an extremely long AS path. Someone entered their ASN instead of 259 the prepend count 47868 modulo 256 = 252 prepends and when a path 260 lengths exceeded 255, routers crashed 262 3. Best Practices 264 Many of the best practices, or lack thereof, can be illustrated from 265 the preceeding examples. Here's a summary of the best current 266 practices of using AS-Path prepend: 268 o Network operators should ensure prepending is absolutely 269 necessary. Many of your networks have excessive prepending 271 o Prepending more than a couple of times buys you nothing. So don't 272 do it. 274 o Prepending-to-all is a self-inflicted and needless risk that 275 serves little purpose. Those excessively prepending their routes 276 should consider this risk and adjust their routing configuration. 278 o It is not typical to see more than 20 ASes in a AS_PATH in the 279 Internet today even with the use of AS_Path prepend. The Internet 280 is typically around 5 ASes deep with the largest AS_PATH being 281 16-20 ASNs. Some have added 100 or more AS_Path prepends and 282 operators should therefore consider limiting the maximum AS-path 283 length being accepted 285 4. IANA Considerations 286 5. Security Considerations 288 There are no security issues introduced by this draft. 290 6. Acknowledgement 292 7. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, 296 DOI 10.17487/RFC2119, March 1997, 297 . 299 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 300 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 301 DOI 10.17487/RFC4271, January 2006, 302 . 304 [RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP 305 Large Communities", RFC 8195, DOI 10.17487/RFC8195, June 306 2017, . 308 Authors' Addresses 310 Mike McBride 311 Futurewei 313 Email: michael.mcbride@futurewei.com 315 Doug Madory 316 Oracle 318 Email: douglas.madory@oracle.com 320 Jeff Tantsura 321 Apstra 323 Email: jefftant.ietf@gmail.com