idnits 2.17.1 draft-ietf-grow-route-leak-problem-definition-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 : ---------------------------------------------------------------------------- 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 (October 12, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations K. Sriram 3 Internet-Draft D. Montgomery 4 Intended status: Informational US NIST 5 Expires: April 14, 2016 D. McPherson 6 E. Osterweil 7 Verisign, Inc. 8 B. Dickson 9 Twitter, Inc. 10 October 12, 2015 12 Problem Definition and Classification of BGP Route Leaks 13 draft-ietf-grow-route-leak-problem-definition-03 15 Abstract 17 A systemic vulnerability of the Border Gateway Protocol routing 18 system, known as 'route leaks', has received significant attention in 19 recent years. Frequent incidents that result in significant 20 disruptions to Internet routing are labeled "route leaks", but to 21 date we have lacked a common definition of the term. In this 22 document, we provide a working definition of route leaks, keeping in 23 mind the real occurrences that have received significant attention. 24 Further, we attempt to enumerate (though not exhaustively) different 25 types of route leaks based on observed events on the Internet. We 26 aim to provide a taxonomy that covers several forms of route leaks 27 that have been observed and are of concern to Internet user community 28 as well as the network operator community. 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 http://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 April 14, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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 (http://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 2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3 66 3. Classification of Route Leaks Based on Documented Events . . 3 67 3.1. Type 1: U-Shaped Turn with Full Prefix . . . . . . . . . 4 68 3.2. Type 2: Lateral ISP-ISP-ISP Leak . . . . . . . . . . . . 5 69 3.3. Type 3: Leak of Transit-Provider Prefixes to Peer . . . . 5 70 3.4. Type 4: Leak of Peer Prefixes to Transit Provider . . . . 5 71 3.5. Type 5: U-Shaped Turn with More Specific Prefix . . . . . 6 72 3.6. Type 6: Prefix Re-Origination with Data Path to 73 Legitimate Origin . . . . . . . . . . . . . . . . . . . . 6 74 3.7. Type 7: Accidental Leak of Internal Prefixes and More 75 Specifics . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Additional Comments about the Classification . . . . . . . . 7 77 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 81 9. Informative References . . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Frequent incidents [Huston2012][Cowie2013][Toonk2015-A][Toonk2015-B][ 87 Cowie2010][Madory][Zmijewski][Paseka][LRL][Khare] that result in 88 significant disruptions to Internet routing are commonly called 89 "route leaks". Examination of the details of some of these incidents 90 reveals that they vary in their form and technical details. Before 91 we can discuss solutions to "the route leak problem" we need a clear, 92 technical definition of the problem and its most common forms. In 93 Section 2, we provide a working definition of route leaks, keeping in 94 view many recent incidents that have received significant attention. 96 Further, in Section 3, we attempt to enumerate (though not 97 exhaustively) different types of route leaks based on observed events 98 on the Internet. We aim to provide a taxonomy that covers several 99 forms of route leaks that have been observed and are of concern to 100 Internet user community as well as the network operator community. 101 This document builds on and extends earlier work in the IETF by 102 Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route- 103 leak-reqts]. 105 2. Working Definition of Route Leaks 107 A proposed working definition of route leak is as follows: 109 A "route leak" is the propagation of routing announcement(s) beyond 110 their intended scope. That is, an AS's announcement of a learned BGP 111 route to another AS is in violation of the intended policies of the 112 receiver, the sender and/or one of the ASes along the preceding AS 113 path. The intended scope is usually defined by a set of local 114 redistribution/filtering policies distributed among the ASes 115 involved. Often, these intended policies are defined in terms of the 116 pair-wise peering business relationship between ASes (e.g., customer, 117 transit provider, peer). For literature related to AS relationships 118 and routing policies, see [Gao] [Luckie] [Gill]. For measurements of 119 valley-free violations in Internet routing, see [Anwar] [Giotsas] 120 [Wijchers]. 122 The result of a route leak can be redirection of traffic through an 123 unintended path which may enable eavesdropping or traffic analysis, 124 and may or may not result in an overload or black-hole. Route leaks 125 can be accidental or malicious, but most often arise from accidental 126 misconfigurations. 128 The above definition is not intended to be all encompassing. 129 Perceptions vary widely about what constitutes a route leak. Our aim 130 here is to have a working definition that fits enough observed 131 incidents so that the IETF community has a basis for developing 132 solutions for route leak detection and mitigation. 134 3. Classification of Route Leaks Based on Documented Events 136 As illustrated in Figure 1, a common form of route leak occurs when a 137 multi-homed customer AS (such as AS3 in Figure 1) learns a prefix 138 update from one transit provider (ISP1) and leaks the update to 139 another transit provider (ISP2) in violation of intended routing 140 policies, and further the second transit provider does not detect the 141 leak and propagates the leaked update to its customers, peers, and 142 transit ISPs. 144 /\ /\ 145 \ route-leak(P)/ 146 \ propagated / 147 \ / 148 +------------+ peer +------------+ 149 ______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> 150 / ------------+ prefix(P) +------------+ route-leak(P) 151 | prefix | \ update /\ \ propagated 152 \ (P) / \ / \ 153 ------- prefix(P) \ / \ 154 update \ / \ 155 \ /route-leak(P) \/ 156 \/ / 157 +---------------+ 158 | customer(AS3) | 159 +---------------+ 161 Figure 1: Illustration of the basic notion of a route leak. 163 We propose the following taxonomy for classification of route leaks 164 aiming to cover several types of recently observed route leaks, while 165 acknowledging that the list is not meant to be exhaustive. In what 166 follows, we refer to the AS that announces a route that is in 167 violation of the intended policies as the "offending AS". 169 3.1. Type 1: U-Shaped Turn with Full Prefix 171 Description: A multi-homed AS learns a route from one upstream ISP 172 and simply propagates it to another upstream ISP. Neither the prefix 173 nor the AS path in the update is altered. This is similar to a 174 straight forward path-poisoning attack [Kapela-Pilosov], but with 175 full prefix. It should be noted that leaks of this type are often 176 accidental (i.e. not malicious). The update basically makes a 177 U-shaped turn at the offending AS's multi-homed AS. The leak often 178 succeeds because the second ISP prefers customer announcement over 179 peer announcement of the same prefix. Data packets would reach the 180 legitimate destination albeit via the offending AS, unless they are 181 dropped at the offending AS due to its inability to handle resulting 182 large volumes of traffic. 184 o Example incidents: Examples of Type 1 route-leak incidents are (1) 185 the Dodo-Telstra incident in March 2012 [Huston2012], (2) the 186 Moratel-PCCW route leak of Google prefixes in November 2012 187 [Paseka], (3) the VolumeDrive-Atrato incident in September 2014 188 [Madory], (4) the Hathway-Airtel route leak of 336 Google prefixes 189 causing widespread interruption of Google services in Europe and 190 Asia [Toonk2015-A], and (5) the massive Telekom Malaysia route- 191 leaks of about 179,000 prefixes, which in turn Level3 accepted and 192 propagated [Toonk2015-B]. 194 3.2. Type 2: Lateral ISP-ISP-ISP Leak 196 Description: The term "lateral" here is synonymous with "non-transit" 197 or "peer-to-peer". This type of route leak typically occurs when, 198 for example, three sequential ISP peers (e.g. ISP-A, ISP-B, and ISP- 199 C) are involved, and ISP-B receives a route from ISP-A and in turn 200 leaks it to ISP-C. The typical routing policy between laterally 201 (i.e. non-transit) peering ISPs is that they should only propagate to 202 each other their respective customer prefixes. 204 o Example incidents: In [Mauch-nanog][Mauch], route leaks of this 205 type are reported by monitoring updates in the global BGP system 206 and finding three or more very large ISP ASNs in a sequence in a 207 BGP update's AS path. Mauch [Mauch] observes that these are 208 anomalies and potentially route leaks because very large ISPs such 209 as ATT, Sprint, Verizon, and Globalcrossing do not in general buy 210 transit services from each other. However, he also notes that 211 there are exceptions when one very large ISP does indeed buy 212 transit from another very large ISP, and accordingly exceptions 213 are made in his detection algorithm for known cases. 215 3.3. Type 3: Leak of Transit-Provider Prefixes to Peer 217 Description: This type of route leak occurs when an offending AS 218 leaks routes learned from its transit provider to a lateral (i.e. 219 non-transit) peer. 221 o Example incidents: The incidents reported in [Mauch] include the 222 Type 3 leaks. 224 3.4. Type 4: Leak of Peer Prefixes to Transit Provider 226 Description: This type of route leak occurs when an offending AS 227 leaks routes learned from a lateral (i.e. non-transit) peer to its 228 (the AS's) own transit provider. These leaked routes typically 229 originate from the customer cone of the lateral peer. 231 o Example incidents: Some of the example incidents cited for Type 1 232 route leaks above are also inclusive of Type 4 route leaks. For 233 instance, in the Dodo-Telstra incident [Huston2012], the leaked 234 routes from Dodo to Telstra included routes that Dodo learned from 235 its transit providers as well as lateral peers. 237 3.5. Type 5: U-Shaped Turn with More Specific Prefix 239 Description: A multi-homed AS learns a route from one upstream ISP 240 and announces a subprefix (subsumed in the prefix) to another 241 upstream ISP. The AS path in the update is not altered. Update is 242 crafted by the offending AS to have a subprefix to maximize the 243 success of the attack while reverse path is kept open by the path 244 poisoning techniques as in [Kapela-Pilosov]. Data packets reach the 245 legitimate destination albeit via the offending AS. 247 o Example incidents: One example is the demo performed at DEFCON-16 248 in August 2008 [Kapela-Pilosov]. Another example is the earlier- 249 mentioned incident of route leaks from Telekom Malaysia via 250 Level3, in which out of about 179,000 total route-leaked prefixes, 251 about 10,000 were more specifics of previously announced less 252 specific prefixes [Toonk2015-B]. [Note: An attacker who 253 deliberately performs a Type 1 route leak (with full prefix) can 254 just as easily perform a Type 5 route leak (with subprefix) to 255 achieve a greater impact.] 257 3.6. Type 6: Prefix Re-Origination with Data Path to Legitimate Origin 259 Description: A multi-homed AS learns a route from one upstream ISP 260 and announces the prefix to another upstream ISP as if it is being 261 originated by it (i.e. strips the received AS path, and re-originates 262 the prefix). This can be called re-origination or mis-origination. 263 However, somehow (not attributable to the use of path poisoning trick 264 by the offending AS) a reverse path is present, and data packets 265 reach the legitimate destination albeit via the offending AS. But 266 sometimes the reverse path may not be there, and data packets get 267 dropped following receipt by the offending AS. 269 o Example incidents: Examples of Type 6 route leak include (1) the 270 China Telecom incident in April 2010 [Hiran][Cowie2010][Labovitz], 271 (2) the Belarusian GlobalOneBel route leak incidents in February- 272 March 2013 and May 2013 [Cowie2013], (3) the Icelandic Opin Kerfi- 273 Simmin route leak incidents in July-August 2013 [Cowie2013], and 274 (4) the Indosat route leak incident in April 2014 [Zmijewski]. 276 3.7. Type 7: Accidental Leak of Internal Prefixes and More Specifics 278 Description: An offending AS simply leaks its internal prefixes to 279 one or more of its transit-provider ASes and/or ISP peers. The 280 leaked internal prefixes are often more specifics subsumed by an 281 already announced less specific prefix. The more specifics were not 282 intended to be routed in eBGP. Further, the AS receiving those leaks 283 fails to filter them. Typically these leaked announcements are due 284 to some transient failures within the AS; they are short-lived, and 285 typically withdrawn quickly following the announcements. However, 286 these more specifics may momentarily cause the routes to be preferred 287 over other aggregate route announcements, thus redirecting traffic 288 from its normal best path. 290 o Example incidents: Leaks of internal routes occur frequently (e.g. 291 multiple times in a week), and the number of prefixes leaked range 292 from hundreds to thousands per incident. One highly conspicuous 293 and widely disruptive leak of internal routes happened recently in 294 August 2014 when AS701 and AS705 leaked about 22,000 more 295 specifics of already announced aggregates [Huston2014][Toonk2014]. 297 4. Additional Comments about the Classification 299 It is worth noting that Types 1 through 4 are similar in that a route 300 is leaked in violation of policy in each case, but what varies is the 301 context of the leaked-route source AS and destination AS roles. 303 It is also worth noting that Type 5 route leak involves a subprefix 304 and is a special case of Type 1, which involves a full prefix. 305 Similarly, subprefix versions of other types of route leaks may also 306 be considered, for example, for Types 2, 3, and 4. Similarly, Type 6 307 (i.e. prefix mis-origination with data path to legitimate origin) can 308 be also conceived to happen in conjunction with Types 2, 3, and 4. 309 While these possibilities are acknowledged, simply enumerating more 310 types to consider all such special cases does not add value as far as 311 solution development for route leaks is concerned. Hence, the 312 special cases mentioned here are not included in enumerating route 313 leak types. 315 5. Summary 317 We attempted to provide a working definition of route leak. We also 318 presented a taxonomy for categorizing route leaks. It covers not all 319 but at least several forms of route leaks that have been observed and 320 are of concern to Internet user and network operator communities. We 321 hope that this work provides the IETF community a basis for pursuing 322 possible BGP enhancements for route leak detection and mitigation. 324 6. Security Considerations 326 No security considerations apply since this is a problem definition 327 document. 329 7. IANA Considerations 331 No updates to the registries are suggested by this document. 333 8. Acknowledgements 335 The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari, 336 Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Ruediger 337 Volk, Andrei Robachevsky, Charles van Niman, Chris Morrow, and Sandy 338 Murphy for comments, suggestions, and critique. The authors are also 339 thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim for 340 their comments and review. 342 9. Informative References 344 [Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P., 345 and N. Katz-Bassett, "Investigating Interdomain Routing 346 Policies in the Wild", ACM Internet Measurement 347 Conference (IMC), October 2015, 348 . 350 [Cowie2010] 351 Cowie, J., "China's 18 Minute Mystery", Dyn 352 Research/Renesys Blog, November 2010, 353 . 356 [Cowie2013] 357 Cowie, J., "The New Threat: Targeted Internet Traffic 358 Misdirection", Dyn Research/Renesys Blog, November 2013, 359 . 362 [draft-dickson-sidr-route-leak-def] 363 Dickson, B., "Route Leaks -- Definitions", IETF Internet 364 Draft (expired), October 2012, 365 . 368 [draft-dickson-sidr-route-leak-reqts] 369 Dickson, B., "Route Leaks -- Requirements for Detection 370 and Prevention thereof", IETF Internet Draft (expired), 371 March 2012, . 374 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 375 global coordination", IEEE/ACM Transactions on 376 Networking, December 2001, 377 . 380 [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of 381 Interdomain Routing Policies", ACM SIGCOMM Computer 382 Communication Review, January 2014, 383 . 385 [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in 386 Internet routing - Analysis based on BGP Community data", 387 IEEE ICC 2012, June 2012. 389 [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing 390 Large-scale Routing Anomalies: A Case Study of the China 391 Telecom Incident", PAM 2013, March 2013, 392 . 395 [Huston2012] 396 Huston, G., "Leaking Routes", March 2012, 397 . 399 [Huston2014] 400 Huston, G., "What's so special about 512?", September 401 2014, . 403 [Kapela-Pilosov] 404 Pilosov, A. and T. Kapela, "Stealing the Internet: An 405 Internet-Scale Man in the Middle Attack", DEFCON-16 Las 406 Vegas, NV, USA, August 2008, 407 . 410 [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix 411 Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, 412 November 2012, . 415 [Labovitz] 416 Labovitz, C., "Additional Discussion of the April China 417 BGP Hijack Incident", Arbor Networks IT Security Blog, 418 November 2010, 419 . 422 [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", 423 Project web page, 2012, 424 . 427 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 428 kc. claffy, "AS Relationships, Customer Cones, and 429 Validation", IMC 2013, October 2013, 430 . 432 [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke 433 Today", Dyn Research/Renesys Blog, September 2014, 434 . 437 [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project 438 web page, 2014, 439 . 441 [Mauch-nanog] 442 Mauch, J., "Detecting Routing Leaks by Counting", 443 NANOG-41 Albuquerque, NM, USA, October 2007, 444 . 447 [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about 448 How the Internet Works", CloudFare Blog, November 2012, 449 . 452 [Toonk2014] 453 Toonk, A., "What caused today's Internet hiccup", August 454 2014, . 457 [Toonk2015-A] 458 Toonk, A., "What caused the Google service interruption", 459 March 2015, . 462 [Toonk2015-B] 463 Toonk, A., "Massive route leak causes Internet slowdown", 464 June 2015, . 467 [Wijchers] 468 Wijchers, B. and B. Overeinder, "Quantitative Analysis of 469 BGP Route Leaks", RIPE-69, November 2014, 470 . 473 [Zmijewski] 474 Zmijewski, E., "Indonesia Hijacks the World", Dyn 475 Research/Renesys Blog, April 2014, 476 . 479 Authors' Addresses 481 Kotikalapudi Sriram 482 US NIST 484 Email: ksriram@nist.gov 486 Doug Montgomery 487 US NIST 489 Email: dougm@nist.gov 491 Danny McPherson 492 Verisign, Inc. 494 Email: dmcpherson@verisign.com 496 Eric Osterweil 497 Verisign, Inc. 499 Email: eosterweil@verisign.com 501 Brian Dickson 502 Twitter, Inc. 504 Email: bdickson@twitter.com