idnits 2.17.1 draft-ietf-grow-route-leak-problem-definition-01.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 (March 9, 2015) is 3335 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: September 10, 2015 D. McPherson 6 E. Osterweil 7 Verisign, Inc. 8 March 9, 2015 10 Problem Definition and Classification of BGP Route Leaks 11 draft-ietf-grow-route-leak-problem-definition-01 13 Abstract 15 A systemic vulnerability of the Border Gateway Protocol routing 16 system, known as 'route leaks', has received significant attention in 17 recent years. Frequent incidents that result in significant 18 disruptions to Internet routing are labeled "route leaks", but to 19 date we have lacked a common definition of the term. In this 20 document, we provide a working definition of route leaks, keeping in 21 mind the real occurrences that have received significant attention. 22 Further, we attempt to enumerate (though not exhaustively) different 23 types of route leaks based on observed events on the Internet. We 24 aim to provide a taxonomy that covers several forms of route leaks 25 that have been observed and are of concern to Internet user community 26 as well as the network operator community. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 10, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3 64 3. Classification of Route Leaks Based on Documented Events . . 3 65 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Informative References . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 Frequent incidents [Huston2012][Cowie2013][Cowie2010][Madory][Zmijews 75 ki][Paseka][LRL][Khare] that result in significant disruptions to 76 Internet routing are commonly called "route leaks". Examination of 77 the details of some of these incidents reveals that they vary in 78 their form and technical details. Before we can discuss solutions to 79 "the route leak problem" we need a clear, technical definition of the 80 problem and its most common forms. In Section 2, we provide a 81 working definition of route leaks, keeping in view many recent 82 incidents that have received significant attention. Further, in 83 Section 3, we attempt to enumerate (though not exhaustively) 84 different types of route leaks based on observed events on the 85 Internet. We aim to provide a taxonomy that covers several forms of 86 route leaks that have been observed and are of concern to Internet 87 user community as well as the network operator community. 89 2. Working Definition of Route Leaks 91 A proposed working definition of route leak is as follows: 93 A "route leak" is the propagation of routing announcement(s) beyond 94 their intended scope. That is, an AS's announcement of a learned BGP 95 route to another AS is in violation of the intended policies of the 96 receiver, the sender and/or one of the ASes along the preceding AS 97 path. The intended scope is usually defined by a set of local 98 redistribution/filtering policies distributed among the ASes 99 involved. Often, these intended policies are defined in terms of the 100 pair-wise peering business relationship between ASes (e.g., customer, 101 provider, peer). For literature related to AS relationships and 102 routing policies, see [Gao][Gill][Luckie]. For measurements of 103 valley-free violations in Internet routing, see [Giotsas][Wijchers]. 105 The result of a route leak can be redirection of traffic through an 106 unintended path which may enable eavesdropping or traffic analysis, 107 and may or may not result in an overload or black-hole. Route leaks 108 can be accidental or malicious, but most often arise from accidental 109 misconfigurations. 111 The above definition is not intended to be all encompassing. 112 Perceptions vary widely about what constitutes a route leak. Our aim 113 here is to have a working definition that fits enough observed 114 incidents so that the IETF community has a basis for starting to work 115 on route leak mitigation methods. 117 3. Classification of Route Leaks Based on Documented Events 119 As illustrated in Figure 1, a common form of route leak occurs when a 120 multi-homed customer AS (such as AS1 in Figure 1) learns a prefix 121 update from one provider (ISP1) and leaks the update to another 122 provider (ISP2) in violation of intended routing policies, and 123 further the second provider does not detect the leak and propagates 124 the leaked update to its customers, peers, and transit ISPs. 126 /\ /\ 127 \ route-leak(P)/ 128 \ propagated / 129 \ / 130 +------------+ peer +------------+ 131 ______| ISP1 (AS2) |----------->| ISP2 (AS3)|----------> 132 / ------------+ prefix(P) +------------+ route-leak(P) 133 | prefix | \ update /\ \ propagated 134 \ (P) / \ / \ 135 ------- prefix(P) \ / \ 136 update \ / \ 137 \ /route-leak(P) \/ 138 \/ / 139 +---------------+ 140 | customer(AS1) | 141 +---------------+ 143 Figure 1: Illustration of the basic notion of a route leak. 145 We propose the following taxonomy for classification of route leaks 146 aiming to cover several types of recently observed route leaks, while 147 acknowledging that the list is not meant to be exhaustive. In what 148 follows, we refer to the AS that announces a route that is in 149 violation of the intended policies as the "offending AS". 151 o Type 1 "U-Turn with Full Prefix": A multi-homed AS learns a prefix 152 route from one upstream ISP and simply propagates the prefix to 153 another upstream ISP. Neither the prefix nor the AS path in the 154 update is altered. This is similar to a straight forward path- 155 poisoning attack [Kapela-Pilosov], but with full prefix. It 156 should be noted that attacks or leaks of this type are often 157 accidental (i.e. not malicious). The update basically makes a 158 U-turn at the attacker's multi-homed AS. The attack (accidental 159 or deliberate) often succeeds because the second ISP prefers 160 customer announcement over peer announcement of the same prefix. 161 Data packets would reach the legitimate destination albeit via the 162 offending AS, unless they are dropped at the offending AS due to 163 its inability to handle resulting large volumes of traffic. 165 * Example incidents: Examples of Type 1 route-leak incidents are 166 (1) the Dodo-Telstra incident in March 2012 [Huston2012], (2) 167 the Moratel-PCCW leak of Google prefixes in November 2012 168 [Paseka], and (3) the VolumeDrive-Atrato incident in September 169 2014 [Madory]. 171 o Type 2 "U-Turn with More Specific Prefix": A multi-homed AS learns 172 a prefix route from one upstream ISP and announces a sub-prefix 173 (subsumed in the prefix) to another upstream ISP. The AS path in 174 the update is not altered. Update is crafted by the attacker to 175 have a subprefix to maximize the success of the attack while 176 reverse path is kept open by the path poisoning techniques as in 177 [Kapela-Pilosov]. Data packets reach the legitimate destination 178 albeit via the offending AS. 180 * Example incidents: An example of Type 2 route-leak incident is 181 the demo performed at DEFCON-16 in August 2008 182 [Kapela-Pilosov]. An attacker who deliberately performs a Type 183 1 route leak (with full prefix) can just as easily perform a 184 Type 2 route leak (with subprefix) to achieve a greater impact. 186 o Type 3 "Prefix Hijack with Data Path to Legitimate Origin": A 187 multi-homed AS learns a prefix route from one upstream ISP and 188 announces the prefix to another upstream ISP as if it is being 189 originated by it (i.e. strips the received AS path, and re- 190 originates the prefix). This amounts to straightforward 191 hijacking. However, somehow (not attributable to the use of path 192 poisoning trick by the attacker) a reverse path is present, and 193 data packets reach the legitimate destination albeit via the 194 offending AS. But sometimes the reverse path may not be there, 195 and data packets get dropped following receipt by the offending 196 AS. 198 * Example incidents: Examples of Type 3 route leak include (1) 199 the China Telecom incident in April 2010 200 [Hiran][Cowie2010][Labovitz], (2) the Belarusian GlobalOneBel 201 route leak incidents in February-March 2013 and May 2013 202 [Cowie2013], (3) the Icelandic Opin Kerfi-Simmin route leak 203 incidents in July-August 2013 [Cowie2013], and (4) the Indosat 204 route leak incident in April 2014 [Zmijewski]. 206 o Type 4 "Leak of Internal Prefixes and Accidental Deaggregation": 207 An offending AS simply leaks its internal prefixes to one or more 208 of its transit ASes and/or ISP peers. The leaked internal 209 prefixes are often deaggregated subprefixes (i.e. more specifics) 210 of already announced aggregate prefixes. Further, the AS 211 receiving those leaks fails to filter them. Typically these 212 leaked announcements are due to some transient failures within the 213 AS; they are short-lived, and typically withdrawn quickly 214 following the announcements. 216 * Example incidents: Leaks of internal prefix-routes occur 217 frequently (e.g. multiple times in a week), and the number of 218 prefixes leaked range from hundreds to thousands per incident. 219 One highly conspicuous and widely disruptive leak of internal 220 prefixes happened recently in August 2014 when AS701 and AS705 221 leaked about 22,000 more specifics of already announced 222 aggregates [Huston2014][Toonk]. 224 o Type 5 "Lateral ISP-ISP-ISP Leak": This type of route leak 225 typically occurs when, for example, three sequential ISP peers 226 (e.g. ISP-A, ISP-B and ISP-C) are involved, and ISP-B receives a 227 prefix-route from ISP-A and in turn leaks it to ISP-C. The 228 typical routing policy between laterally (i.e. non-hierarchically) 229 peering ISPs is that they should only propagate to each other 230 their respective customer prefixes. 232 * Example incidents: In [Mauch-nanog][Mauch], route leaks of this 233 type are reported by monitoring updates in the global BGP 234 system and finding three or more very large ISP ASNs in a 235 sequence in a BGP update's AS path. Mauch [Mauch] observes 236 that these are anomalies and potentially route leaks because 237 very large ISPs such as ATT, Sprint, Verizon, and 238 Globalcrossing do not in general buy transit services from each 239 other. However, he also notes that there are exceptions when 240 one very large ISP does indeed buy transit from another very 241 large ISP, and accordingly exceptions are made in his detection 242 algorithm for known cases. 244 o Type 6 "Leak of Provider Prefixes to Peer": This type of route 245 leak occurs when an offending AS leaks prefix-routes learned from 246 its provider to a lateral peer. 248 * Example incidents: The incidents reported in [Mauch] include 249 the Type 6 leaks. 251 o Type 7 "Leak of Peer Prefixes to Provider": This type of route 252 leak occurs when an offending AS leaks prefix-routes learned from 253 a lateral peer to its (the AS's) own provider. These leaked 254 prefix-routes typically originate from the customer cone of the 255 lateral peer. 257 * Example incidents: Some of the example incidents cited for Type 258 1 route leaks above are also inclusive of Type 7 route leaks. 259 For instance, in the Dodo-Telstra incident [Huston2012], the 260 leaked routes from Dodo to Telstra included routes that Dodo 261 learned from its providers as well as lateral peers. 263 4. Summary 265 We attempted to provide a working definition of route leak. We also 266 presented a taxonomy for categorizing route leaks. It covers not all 267 but at least several forms of route leaks that have been observed and 268 are of concern to Internet user and network operator communities. We 269 hope that this work provides the IETF community a basis for pursuing 270 possible BGP enhancements for route leak detection and mitigation. 272 5. Security Considerations 274 No security considerations apply since this is a problem definition 275 document. 277 6. IANA Considerations 279 No updates to the registries are suggested by this document. 281 7. Acknowledgements 283 The authors wish to thank Danny McPherson and Eric Osterweil for 284 discussions related to this work. Also, thanks are due to Jared 285 Mauch, Jeff Haas, Warren Kumari, Brian Dickson, Amogh Dhamdhere, 286 Jakob Heitz, Geoff Huston, Randy Bush, Ruediger Volk, Andrei 287 Robachevsky, Chris Morrow, and Sandy Murphy for comments, 288 suggestions, and critique. The authors are also thankful to Padma 289 Krishnaswamy, Oliver Borchert, and Okhee Kim for their comments and 290 review. 292 8. Informative References 294 [Cowie2010] 295 Cowie, J., "China's 18 Minute Mystery", Dyn Research/ 296 Renesys Blog, November 2010, 297 . 300 [Cowie2013] 301 Cowie, J., "The New Threat: Targeted Internet Traffic 302 Misdirection", Dyn Research/Renesys Blog, November 2013, 303 . 306 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 307 global coordination", IEEE/ACM Transactions on Networking, 308 December 2001, . 311 [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of 312 Interdomain Routing Policies", ACM SIGCOMM Computer 313 Communication Review, January 2014, 314 . 316 [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in 317 Internet routing - Analysis based on BGP Community data", 318 IEEE ICC 2012, June 2012, 319 . 322 [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing 323 Large-scale Routing Anomalies: A Case Study of the China 324 Telecom Incident", PAM 2013, March 2013, 325 . 328 [Huston2012] 329 Huston, G., "Leaking Routes", March 2012, 330 . 332 [Huston2014] 333 Huston, G., "What's so special about 512?", September 334 2014, . 336 [Kapela-Pilosov] 337 Pilosov, A. and T. Kapela, "Stealing the Internet: An 338 Internet-Scale Man in the Middle Attack", DEFCON-16 Las 339 Vegas, NV, USA, August 2008, 340 . 343 [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix 344 Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, 345 November 2012, . 348 [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", 349 Project web page, 2012, 350 . 353 [Labovitz] 354 Labovitz, C., "Additional Discussion of the April China 355 BGP Hijack Inciden", Arbor Networks IT Security Blog, 356 November 2010, 357 . 360 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and 361 kc. claffy, "AS Relationships, Customer Cones, and 362 Validation", IMC 2013, October 2013, 363 . 365 [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke 366 Today", Dyn Research/Renesys Blog, September 2014, 367 . 370 [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project 371 web page, 2014, 372 . 374 [Mauch-nanog] 375 Mauch, J., "Detecting Routing Leaks by Counting", NANOG-41 376 Albuquerque, NM, USA, October 2007, 377 . 380 [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about 381 How the Internet Works", CloudFare Blog, November 2012, 382 . 385 [Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August 386 2014, . 389 [Wijchers] 390 Wijchers, B. and B. Overeinder, "Quantitative Analysis of 391 BGP Route Leaks", RIPE-69, November 2014, 392 . 395 [Zmijewski] 396 Zmijewski, E., "Indonesia Hijacks the World", Dyn 397 Research/Renesys Blog, April 2014, 398 . 401 Authors' Addresses 403 Kotikalapudi Sriram 404 US NIST 406 Email: ksriram@nist.gov 408 Doug Montgomery 409 US NIST 411 Email: dougm@nist.gov 412 Danny McPherson 413 Verisign, Inc. 415 Email: dmcpherson@verisign.com 417 Eric Osterweil 418 Verisign, Inc. 420 Email: eosterweil@verisign.com