idnits 2.17.1 draft-ietf-grow-route-leak-problem-definition-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 : ---------------------------------------------------------------------------- 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 (February 25, 2015) is 3345 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: August 29, 2015 D. McPherson 6 E. Osterweil 7 Verisign, Inc. 8 February 25, 2015 10 Problem Definition and Classification of BGP Route Leaks 11 draft-ietf-grow-route-leak-problem-definition-00 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 August 29, 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 . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Informative References . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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). 103 The result of a route leak can be redirection of traffic through an 104 unintended path which may enable eavesdropping or traffic analysis, 105 and may or may not result in an overload or black-hole. Route leaks 106 can be accidental or malicious, but most often arise from accidental 107 misconfigurations. 109 The above definition is not intended to be all encompassing. 110 Perceptions vary widely about what constitutes a route leak. Our aim 111 here is to have a working definition that fits enough observed 112 incidents so that the IETF community has a basis for starting to work 113 on route leak mitigation methods. 115 3. Classification of Route Leaks Based on Documented Events 117 As illustrated in Figure 1, a common form of route leak occurs when a 118 multi-homed customer AS (such as AS1 in Figure 1) learns a prefix 119 update from one provider (ISP1) and leaks the update to another 120 provider (ISP2) in violation of intended routing policies, and 121 further the second provider does not detect the leak and propagates 122 the leaked update to its customers, peers, and transit ISPs. (Note: 123 The Figure was modified from a similar Figure in 124 [I-D.ietf-grow-simple-leak-attack-bgpsec-no-help].) 125 /\ /\ 126 \ route-leak(P)/ 127 \ propagated / 128 \ / 129 +------------+ peer +------------+ 130 ______| ISP1 (AS2) |----------->| ISP2 (AS3)|----------> 131 / ------------+ prefix(P) +------------+ route-leak(P) 132 | prefix | \ update /\ \ propagated 133 \ (P) / \ / \ 134 ------- prefix(P) \ / \ 135 update \ / \ 136 \ /route-leak(P) \/ 137 \/ / 138 +---------------+ 139 | customer(AS1) | 140 +---------------+ 142 Figure 1: Illustration of the basic notion of a route leak. 144 We propose the following taxonomy for classification of route leaks 145 aiming to cover several types of recently observed route leaks, while 146 acknowledging that the list is not meant to be exhaustive. In what 147 follows, we refer to the AS that announces a route that is in 148 violation of the intended policies as the "offending AS". 150 o Type 1 "U-Turn with Full Prefix": A multi-homed AS learns a prefix 151 route from one upstream ISP and simply propagates the prefix to 152 another upstream ISP. Neither the prefix nor the AS path in the 153 update is altered. This is similar to a straight forward path- 154 poisoning attack [Kapela-Pilosov], but with full prefix. It 155 should be noted that attacks or leaks of this type are often 156 accidental (i.e. not malicious). The update basically makes a 157 U-turn at the attacker's multi-homed AS. The attack (accidental 158 or deliberate) often succeeds because the second ISP prefers 159 customer announcement over peer announcement of the same prefix. 160 Data packets would reach the legitimate destination albeit via the 161 offending AS, unless they are dropped at the offending AS due to 162 its inability to handle resulting large volumes of traffic. 164 * Example incidents: Examples of Type 1 route-leak incidents are 165 (1) the Dodo-Telstra incident in March 2012 [Huston2012], (2) 166 the Moratel-PCCW leak of Google prefixes in November 2012 167 [Paseka], and (3) the VolumeDrive-Atrato incident in September 168 2014 [Madory]. 170 o Type 2 "U-Turn with More Specific Prefix": A multi-homed AS learns 171 a prefix route from one upstream ISP and announces a sub-prefix 172 (subsumed in the prefix) to another upstream ISP. The AS path in 173 the update is not altered. Update is crafted by the attacker to 174 have a subprefix to maximize the success of the attack while 175 reverse path is kept open by the path poisoning techniques as in 176 [Kapela-Pilosov]. Data packets reach the legitimate destination 177 albeit via the offending AS. 179 * Example incidents: An example of Type 2 route-leak incident is 180 the demo performed at DEFCON-16 in August 2008 181 [Kapela-Pilosov]. An attacker who deliberately performs a Type 182 1 route leak (with full prefix) can just as easily perform a 183 Type 2 route leak (with subprefix) to achieve a greater impact. 185 o Type 3 "Prefix Hijack with Data Path to Legitimate Origin": A 186 multi-homed AS learns a prefix route from one upstream ISP and 187 announces the prefix to another upstream ISP as if it is being 188 originated by it (i.e. strips the received AS path, and re- 189 originates the prefix). This amounts to straightforward 190 hijacking. However, somehow (not attributable to the use of path 191 poisoning trick by the attacker) a reverse path is present, and 192 data packets reach the legitimate destination albeit via the 193 offending AS. But sometimes the reverse path may not be there, 194 and data packets get dropped following receipt by the offending 195 AS. 197 * Example incidents: Examples of Type 3 route leak include (1) 198 the China Telecom incident in April 2010 199 [Hiran][Cowie2010][Labovitz], (2) the Belarusian GlobalOneBel 200 route leak incidents in February-March 2013 and May 2013 201 [Cowie2013], (3) the Icelandic Opin Kerfi-Simmin route leak 202 incidents in July-August 2013 [Cowie2013], and (4) the Indosat 203 route leak incident in April 2014 [Zmijewski]. 205 o Type 4 "Leak of Internal Prefixes and Accidental Deaggregation": 206 An offending AS simply leaks its internal prefixes to one or more 207 of its transit ASes and/or ISP peers. The leaked internal 208 prefixes are often deaggregated subprefixes (i.e. more specifics) 209 of already announced aggregate prefixes. Further, the AS 210 receiving those leaks fails to filter them. Typically these 211 leaked announcements are due to some transient failures within the 212 AS; they are short-lived, and typically withdrawn quickly 213 following the announcements. 215 * Example incidents: Leaks of internal prefix-routes occur 216 frequently (e.g. multiple times in a week), and the number of 217 prefixes leaked range from hundreds to thousands per incident. 218 One highly conspicuous and widely disruptive leak of internal 219 prefixes happened recently in August 2014 when AS701 and AS705 220 leaked about 22,000 more specifics of already announced 221 aggregates [Huston2014][Toonk]. 223 o Type 5 "Lateral ISP to ISP Leak": This type of route leak 224 typically occurs when, for example, three sequential ISP peers 225 (e.g. ISP-A, ISP-B and ISP-C) are involved, and ISP-B receives a 226 prefix-route from ISP-A and in turn leaks it to ISP-C. The 227 typical routing policy between laterally (i.e. non-hierarchically) 228 peering ISPs is that they should only propagate to each other 229 their respective customer prefixes. 231 * Example incidents: In [Mauch-nanog][Mauch], route leaks of this 232 type are reported by monitoring updates in the global BGP 233 system and finding three or more very large ISP ASNs in a 234 sequence in a BGP update's AS path. Mauch [Mauch] observes 235 that these are anomalies and potentially route leaks because 236 very large ISPs such as ATT, Sprint, Verizon, and 237 Globalcrossing do not in general buy transit services from each 238 other. However, he also notes that there are exceptions when 239 one very large ISP does indeed buy transit from another very 240 large ISP, and accordingly exceptions are made in his detection 241 algorithm for known cases. 243 4. Summary 245 We attempted to provide a working definition of route leak. We also 246 presented a taxonomy for categorizing route leaks. It covers not all 247 but at least several forms of route leaks that have been observed and 248 are of concern to Internet user and network operator communities. We 249 hope that this work provides the IETF community a basis for pursuing 250 possible BGP enhancements for route leak detection and mitigation. 252 5. Security Considerations 254 No security considerations apply since this is a problem definition 255 document. 257 6. IANA Considerations 259 No updates to the registries are suggested by this document. 261 7. Acknowledgements 263 The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari, 264 Jakob Heitz, Geoff Huston, Randy Bush, Ruediger Volk, Andrei 265 Robachevsky, Chris Morrow, and Sandy Murphy for comments, 266 suggestions, critique at the IETF-90 in the hall-ways and/or during 267 the GROW WG meeting and/or on the GROW mailing list. The authors are 268 also thankful to Padma Krishnaswami, Oliver Borchert, and Okhee Kim 269 for their comments and review. 271 8. Informative References 273 [Cowie2010] 274 Cowie, J., "China's 18 Minute Mystery", Dyn Research/ 275 Renesys Blog, November 2010, 276 . 279 [Cowie2013] 280 Cowie, J., "The New Threat: Targeted Internet Traffic 281 Misdirection", Dyn Research/Renesys Blog, November 2013, 282 . 285 [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing 286 Large-scale Routing Anomalies: A Case Study of the China 287 Telecom Incident", PAM 2013, March 2013, 288 . 291 [Huston2012] 292 Huston, G., "Leaking Routes", March 2012, 293 . 295 [Huston2014] 296 Huston, G., "What's so special about 512?", September 297 2014, . 299 [I-D.ietf-grow-simple-leak-attack-bgpsec-no-help] 300 McPherson, D., Amante, S., Osterweil, E., and D. Mitchell, 301 "Route-Leaks & MITM Attacks Against BGPSEC", draft-ietf- 302 grow-simple-leak-attack-bgpsec-no-help-04 (work in 303 progress), April 2014. 305 [Kapela-Pilosov] 306 Pilosov, A. and T. Kapela, "Stealing the Internet: An 307 Internet-Scale Man in the Middle Attack", DEFCON-16 Las 308 Vegas, NV, USA, August 2008, 309 . 312 [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix 313 Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, 314 November 2012, . 317 [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", 318 Project web page, 2012, 319 . 322 [Labovitz] 323 Labovitz, C., "Additional Discussion of the April China 324 BGP Hijack Inciden", Arbor Networks IT Security Blog, 325 November 2010, 326 . 329 [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke 330 Today", Dyn Research/Renesys Blog, September 2014, 331 . 334 [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project 335 web page, 2014, 336 . 338 [Mauch-nanog] 339 Mauch, J., "Detecting Routing Leaks by Counting", NANOG-41 340 Albuquerque, NM, USA, October 2007, 341 . 344 [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about 345 How the Internet Works", CloudFare Blog, November 2012, 346 . 349 [Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August 350 2014, . 353 [Zmijewski] 354 Zmijewski, E., "Indonesia Hijacks the World", Dyn 355 Research/Renesys Blog, April 2014, 356 . 359 Authors' Addresses 361 Kotikalapudi Sriram 362 US NIST 364 Email: ksriram@nist.gov 365 Doug Montgomery 366 US NIST 368 Email: dougm@nist.gov 370 Danny McPherson 371 Verisign, Inc. 373 Email: dmcpherson@verisign.com 375 Eric Osterweil 376 Verisign, Inc. 378 Email: eosterweil@verisign.com