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