1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Internet Engineering Task Force (IETF) K. Sriram
Request for Comments: 7908 D. Montgomery
Category: Informational US NIST
ISSN: 2070-1721 D. McPherson
E. Osterweil
Verisign, Inc.
B. Dickson
June 2016
<span class="h1">Problem Definition and Classification of BGP Route Leaks</span>
Abstract
A systemic vulnerability of the Border Gateway Protocol routing
system, known as "route leaks", has received significant attention in
recent years. Frequent incidents that result in significant
disruptions to Internet routing are labeled route leaks, but to date
a common definition of the term has been lacking. This document
provides a working definition of route leaks while keeping in mind
the real occurrences that have received significant attention.
Further, this document attempts to enumerate (though not
exhaustively) different types of route leaks based on observed events
on the Internet. The aim is to provide a taxonomy that covers
several forms of route leaks that have been observed and are of
concern to the Internet user community as well as the network
operator community.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7908">http://www.rfc-editor.org/info/rfc7908</a>.
<span class="grey">Sriram, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Working Definition of Route Leaks . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Classification of Route Leaks Based on Documented Events . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Type 1: Hairpin Turn with Full Prefix . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Type 2: Lateral ISP-ISP-ISP Leak . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Type 3: Leak of Transit-Provider Prefixes to Peer . . . . <a href="#page-5">5</a>
<a href="#section-3.4">3.4</a>. Type 4: Leak of Peer Prefixes to Transit Provider . . . . <a href="#page-5">5</a>
3.5. Type 5: Prefix Re-origination with Data Path to
Legitimate Origin . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
3.6. Type 6: Accidental Leak of Internal Prefixes and More-
Specific Prefixes . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Additional Comments about the Classification . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Informative References . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="grey">Sriram, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Frequent incidents [<a href="#ref-Huston2012">Huston2012</a>] [<a href="#ref-Cowie2013">Cowie2013</a>] [<a href="#ref-Toonk2015-A">Toonk2015-A</a>]
[<a href="#ref-Toonk2015-B">Toonk2015-B</a>] [<a href="#ref-Cowie2010">Cowie2010</a>] [<a href="#ref-Madory" title=""Why Far-Flung Parts of the Internet Broke Today"">Madory</a>] [<a href="#ref-Zmijewski">Zmijewski</a>] [<a href="#ref-Paseka" title=""Why Google Went Offline Today and a Bit about How the Internet Works"">Paseka</a>] [<a href="#ref-LRL" title=""Large Route Leaks"">LRL</a>] [<a href="#ref-Khare" title=""Concurrent Prefix Hijacks: Occurrence and Impacts"">Khare</a>]
that result in significant disruptions to Internet routing are
commonly called "route leaks". Examination of the details of some of
these incidents reveals that they vary in their form and technical
details. In order to pursue solutions to "the route-leak problem" it
is important to first provide a clear, technical definition of the
problem and enumerate its most common forms. <a href="#section-2">Section 2</a> provides a
working definition of route leaks, keeping in view many recent
incidents that have received significant attention. <a href="#section-3">Section 3</a>
attempts to enumerate (though not exhaustively) different types of
route leaks based on observed events on the Internet. Further,
<a href="#section-3">Section 3</a> provides a taxonomy that covers several forms of route
leaks that have been observed and are of concern to the Internet user
community as well as the network operator community. This document
builds on and extends earlier work in the IETF [<a href="#ref-ROUTE-LEAK-DEF">ROUTE-LEAK-DEF</a>]
[<a href="#ref-ROUTE-LEAK-REQ">ROUTE-LEAK-REQ</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Working Definition of Route Leaks</span>
A proposed working definition of "route leak" is as follows:
A route leak is the propagation of routing announcement(s) beyond
their intended scope. That is, an announcement from an Autonomous
System (AS) of a learned BGP route to another AS is in violation of
the intended policies of the receiver, the sender, and/or one of the
ASes along the preceding AS path. The intended scope is usually
defined by a set of local redistribution/filtering policies
distributed among the ASes involved. Often, these intended policies
are defined in terms of the pair-wise peering business relationship
between ASes (e.g., customer, transit provider, peer). For
literature related to AS relationships and routing policies, see
[<a href="#ref-Gao" title=""Stable Internet Routing Without Global Coordination"">Gao</a>], [<a href="#ref-Luckie" title=""AS Relationships, Customer Cones, and Validation"">Luckie</a>], and [<a href="#ref-Gill" title=""A Survey of Interdomain Routing Policies"">Gill</a>]. For measurements of valley-free
violations in Internet routing, see [<a href="#ref-Anwar" title=""Investigating Interdomain Routing Policies in the Wild"">Anwar</a>], [<a href="#ref-Giotsas" title=""Valley-free violation in Internet routing - Analysis based on BGP Community data"">Giotsas</a>], and
[<a href="#ref-Wijchers" title=""Quantitative Analysis of BGP Route Leaks"">Wijchers</a>].
The result of a route leak can be redirection of traffic through an
unintended path that may enable eavesdropping or traffic analysis and
may or may not result in an overload or black hole. Route leaks can
be accidental or malicious but most often arise from accidental
misconfigurations.
The above definition is not intended to be all encompassing. Our aim
here is to have a working definition that fits enough observed
incidents so that the IETF community has a basis for developing
solutions for route-leak detection and mitigation.
<span class="grey">Sriram, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Classification of Route Leaks Based on Documented Events</span>
As illustrated in Figure 1, a common form of route leak occurs when a
multihomed customer AS (such as AS3 in Figure 1) learns a prefix
update from one transit provider (ISP1) and leaks the update to
another transit provider (ISP2) in violation of intended routing
policies, and further, the second transit provider does not detect
the leak and propagates the leaked update to its customers, peers,
and transit ISPs.
/\ /\
\ route leak(P)/
\ propagated /
\ /
+------------+ peer +------------+
______| ISP1 (AS1) |----------->| ISP2 (AS2)|---------->
/ ------------+ prefix(P) +------------+ route leak(P)
| prefix | \ update /\ \ propagated
\ (P) / \ / \
------- prefix(P) \ / \
update \ / \
\ /route leak(P) \/
\/ /
+---------------+
| customer(AS3) |
+---------------+
Figure 1: Basic Notion of a Route Leak
This document proposes the following taxonomy to cover several types
of observed route leaks while acknowledging that the list is not
meant to be exhaustive. In what follows, the AS that announces a
route that is in violation of the intended policies is referred to as
the "offending AS".
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Type 1: Hairpin Turn with Full Prefix</span>
Description: A multihomed AS learns a route from one upstream ISP and
simply propagates it to another upstream ISP (the turn essentially
resembling a hairpin). Neither the prefix nor the AS path in the
update is altered. This is similar to a straightforward path-
poisoning attack [<a href="#ref-Kapela-Pilosov">Kapela-Pilosov</a>], but with full prefix. It should
be noted that leaks of this type are often accidental (i.e., not
malicious). The update basically makes a hairpin turn at the
offending AS's multihomed AS. The leak often succeeds (i.e., the
leaked update is accepted and propagated) because the second ISP
prefers customer announcement over peer announcement of the same
prefix. Data packets would reach the legitimate destination, albeit
<span class="grey">Sriram, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
via the offending AS, unless they are dropped at the offending AS due
to its inability to handle resulting large volumes of traffic.
o Example incidents: Examples of Type 1 route-leak incidents are (1)
the Dodo-Telstra incident in March 2012 [<a href="#ref-Huston2012">Huston2012</a>], (2) the
VolumeDrive-Atrato incident in September 2014 [<a href="#ref-Madory" title=""Why Far-Flung Parts of the Internet Broke Today"">Madory</a>], and (3)
the massive Telekom Malaysia route leak of about 179,000 prefixes,
which in turn Level3 accepted and propagated [<a href="#ref-Toonk2015-B">Toonk2015-B</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Type 2: Lateral ISP-ISP-ISP Leak</span>
Description: The term "lateral" here is synonymous with "non-transit"
or "peer-to-peer". This type of route leak typically occurs when,
for example, three sequential ISP peers (e.g., ISP-A, ISP-B, and
ISP-C) are involved, and ISP-B receives a route from ISP-A and in
turn leaks it to ISP-C. The typical routing policy between laterally
(i.e., non-transit) peering ISPs is that they should only propagate
to each other their respective customer prefixes.
o Example incidents: In [<a href="#ref-Mauch-nanog">Mauch-nanog</a>] and [<a href="#ref-Mauch" title=""BGP Routing Leak Detection System"">Mauch</a>], route leaks of
this type are reported by monitoring updates in the global BGP
system and finding three or more very large ISPs' Autonomous
System Numbers (ASNs) in a sequence in a BGP update's AS path.
[<a href="#ref-Mauch" title=""BGP Routing Leak Detection System"">Mauch</a>] observes that its detection algorithm detects for these
anomalies and potentially route leaks because very large ISPs do
not, in general, buy transit services from each other. However,
it also notes that there are exceptions when one very large ISP
does indeed buy transit from another very large ISP, and
accordingly, exceptions are made in its detection algorithm for
known cases.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Type 3: Leak of Transit-Provider Prefixes to Peer</span>
Description: This type of route leak occurs when an offending AS
leaks routes learned from its transit provider to a lateral (i.e.,
non-transit) peer.
o Example incidents: The incidents reported in [<a href="#ref-Mauch" title=""BGP Routing Leak Detection System"">Mauch</a>] include
Type 3 leaks.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Type 4: Leak of Peer Prefixes to Transit Provider</span>
Description: This type of route leak occurs when an offending AS
leaks routes learned from a lateral (i.e., non-transit) peer to its
(the AS's) own transit provider. These leaked routes typically
originate from the customer cone of the lateral peer.
<span class="grey">Sriram, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
o Example incidents: Examples of Type 4 route-leak incidents are (1)
the Axcelx-Hibernia route leak of Amazon Web Services (AWS)
prefixes causing disruption of AWS and a variety of services that
run on AWS [<a href="#ref-Kephart" title=""Route Leak Causes Amazon and AWS Outage"">Kephart</a>], (2) the Hathway-Airtel route leak of 336
Google prefixes causing widespread interruption of Google services
in Europe and Asia [<a href="#ref-Toonk2015-A">Toonk2015-A</a>], (3) the Moratel-PCCW route leak
of Google prefixes causing Google's services to go offline
[<a href="#ref-Paseka" title=""Why Google Went Offline Today and a Bit about How the Internet Works"">Paseka</a>], and (4) some of the example incidents cited for Type 1
route leaks above are also inclusive of Type 4 route leaks. For
instance, in the Dodo-Telstra incident [<a href="#ref-Huston2012">Huston2012</a>], the leaked
routes from Dodo to Telstra included routes that Dodo learned from
its transit providers as well as lateral peers.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Type 5: Prefix Re-origination with Data Path to Legitimate Origin</span>
Description: A multihomed AS learns a route from one upstream ISP and
announces the prefix to another upstream ISP as if it is being
originated by it (i.e., strips the received AS path and re-originates
the prefix). This can be called re-origination or mis-origination.
However, somehow a reverse path to the legitimate origination AS may
be present and data packets reach the legitimate destination albeit
via the offending AS. (Note: The presence of a reverse path here is
not attributable to the use of a path-poisoning trick by the
offending AS.) But sometimes the reverse path may not be present,
and data packets destined for the leaked prefix may be simply
discarded at the offending AS.
o Example incidents: Examples of Type 5 route leak include (1) the
China Telecom incident in April 2010 [<a href="#ref-Hiran" title=""Characterizing Large-Scale Routing Anomalies: A Case Study of the China Telecom Incident"">Hiran</a>] [<a href="#ref-Cowie2010">Cowie2010</a>]
[<a href="#ref-Labovitz" title=""Additional Discussion of the April China BGP Hijack Incident"">Labovitz</a>], (2) the Belarusian GlobalOneBel route-leak incidents
in February-March 2013 and May 2013 [<a href="#ref-Cowie2013">Cowie2013</a>], (3) the Icelandic
Opin Kerfi-Simmin route-leak incidents in July-August 2013
[<a href="#ref-Cowie2013">Cowie2013</a>], and (4) the Indosat route-leak incident in April 2014
[<a href="#ref-Zmijewski">Zmijewski</a>]. The reverse paths (i.e., data paths from the
offending AS to the legitimate destinations) were present in
incidents #1, #2, and #3 cited above, but not in incident #4. In
incident #4, the misrouted data packets were dropped at Indosat's
AS.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Type 6: Accidental Leak of Internal Prefixes and More-Specific</span>
<span class="h3"> Prefixes</span>
Description: An offending AS simply leaks its internal prefixes to
one or more of its transit-provider ASes and/or ISP peers. The
leaked internal prefixes are often more-specific prefixes subsumed by
an already announced, less-specific prefix. The more-specific
prefixes were not intended to be routed in External BGP (eBGP).
Further, the AS receiving those leaks fails to filter them.
<span class="grey">Sriram, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
Typically, these leaked announcements are due to some transient
failures within the AS; they are short-lived and typically withdrawn
quickly following the announcements. However, these more-specific
prefixes may momentarily cause the routes to be preferred over other
aggregate (i.e., less specific) route announcements, thus redirecting
traffic from its normal best path.
o Example incidents: Leaks of internal routes occur frequently
(e.g., multiple times in a week), and the number of prefixes
leaked range from hundreds to thousands per incident. One highly
conspicuous and widely disruptive leak of internal routes happened
in August 2014 when AS701 and AS705 leaked about 22,000 more-
specific prefixes of already-announced aggregates [<a href="#ref-Huston2014">Huston2014</a>]
[<a href="#ref-Toonk2014">Toonk2014</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Additional Comments about the Classification</span>
It is worth noting that Types 1 through 4 are similar in that a route
is leaked in violation of policy in each case, but what varies is the
context of the leaked-route source AS and destination AS roles.
A Type 5 route leak (i.e., prefix mis-origination with data path to
legitimate origin) can also happen in conjunction with the AS
relationship contexts in Types 2, 3, and 4. While these
possibilities are acknowledged, simply enumerating more types to
consider all such special cases does not add value as far as solution
development for route leaks is concerned. Hence, the special cases
mentioned here are not included in enumerating route-leak types.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
No security considerations apply since this is a problem definition
document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Informative References</span>
[<a id="ref-Anwar">Anwar</a>] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P.,
and N. Katz-Bassett, "Investigating Interdomain Routing
Policies in the Wild", In Proceedings of the 2015
ACM Internet Measurement Conference (IMC),
DOI 10.1145/2815675.2815712, October 2015,
<<a href="http://www.cs.usc.edu/assets/007/94928.pdf">http://www.cs.usc.edu/assets/007/94928.pdf</a>>.
[<a id="ref-Cowie2010">Cowie2010</a>]
Cowie, J., "China's 18 Minute Mystery", Dyn Research: The
New Home of Renesys Blog, November 2010,
<<a href="http://research.dyn.com/2010/11/chinas-18-minute-mystery/">http://research.dyn.com/2010/11/</a>
<a href="http://research.dyn.com/2010/11/chinas-18-minute-mystery/">chinas-18-minute-mystery/</a>>.
<span class="grey">Sriram, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
[<a id="ref-Cowie2013">Cowie2013</a>]
Cowie, J., "The New Threat: Targeted Internet Traffic
Misdirection", Dyn Research: The New Home of Renesys Blog,
November 2013, <<a href="http://research.dyn.com/2013/11/mitm-internet-hijacking/">http://research.dyn.com/2013/11/</a>
<a href="http://research.dyn.com/2013/11/mitm-internet-hijacking/">mitm-internet-hijacking/</a>>.
[<a id="ref-Gao">Gao</a>] Gao, L. and J. Rexford, "Stable Internet Routing Without
Global Coordination", IEEE/ACM Transactions on Networking
(TON), Volume 9, Issue 6, pp 689-692,
DOI 10.1109/90.974523, December 2001,
<<a href="http://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf">http://www.cs.princeton.edu/~jrex/papers/</a>
<a href="http://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf">sigmetrics00.long.pdf</a>>.
[<a id="ref-Gill">Gill</a>] Gill, P., Schapira, M., and S. Goldberg, "A Survey of
Interdomain Routing Policies", ACM SIGCOMM Computer
Communication Review, Volume 44, Issue 1, pp 28-34,
DOI 10.1145/2567561.2567566, January 2014,
<<a href="http://www.cs.bu.edu/~goldbe/papers/survey.pdf">http://www.cs.bu.edu/~goldbe/papers/survey.pdf</a>>.
[<a id="ref-Giotsas">Giotsas</a>] Giotsas, V. and S. Zhou, "Valley-free violation in
Internet routing - Analysis based on BGP Community data",
2012 IEEE International Conference on
Communications (ICC), DOI 10.1109/ICC.2012.6363987, June
2012.
[<a id="ref-Hiran">Hiran</a>] Hiran, R., Carlsson, N., and P. Gill, "Characterizing
Large-Scale Routing Anomalies: A Case Study of the China
Telecom Incident", In Proceedings of the 14th
International Conference on Passive and Active Measurement
(PAM) 2013, DOI 10.1007/978-3-642-36516-4_23, March 2013,
<<a href="http://www3.cs.stonybrook.edu/~phillipa/papers/CTelecom.html">http://www3.cs.stonybrook.edu/~phillipa/papers/</a>
<a href="http://www3.cs.stonybrook.edu/~phillipa/papers/CTelecom.html">CTelecom.html</a>>.
[<a id="ref-Huston2012">Huston2012</a>]
Huston, G., "Leaking Routes", Asia Pacific Network
Information Centre (APNIC) Blog, March 2012,
<<a href="http://labs.apnic.net/blabs/?p=139/">http://labs.apnic.net/blabs/?p=139/</a>>.
[<a id="ref-Huston2014">Huston2014</a>]
Huston, G., "What's so special about 512?", Asia Pacific
Network Information Centre (APNIC) Blog, September 2014,
<<a href="http://labs.apnic.net/blabs/?p=520/">http://labs.apnic.net/blabs/?p=520/</a>>.
<span class="grey">Sriram, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
[<a id="ref-Kapela-Pilosov">Kapela-Pilosov</a>]
Pilosov, A. and T. Kapela, "Stealing the Internet: An
Internet-Scale Man in the Middle Attack", 16th
Defcon Conference, August 2008,
<<a href="https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf">https://www.defcon.org/images/defcon-16/</a>
<a href="https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf">dc16-presentations/defcon-16-pilosov-kapela.pdf</a>>.
[<a id="ref-Kephart">Kephart</a>] Kephart, N., "Route Leak Causes Amazon and AWS Outage",
ThousandEyes Blog, June 2015,
<<a href="https://blog.thousandeyes.com/route-leak-causes-amazon-and-aws-outage">https://blog.thousandeyes.com/</a>
<a href="https://blog.thousandeyes.com/route-leak-causes-amazon-and-aws-outage">route-leak-causes-amazon-and-aws-outage</a>>.
[<a id="ref-Khare">Khare</a>] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix
Hijacks: Occurrence and Impacts", In Proceedings of the
2013 ACM Internet Measurement Conference (IMC),
DOI 10.1145/2398776.2398780, November 2012,
<<a href="http://www.cs.arizona.edu/~bzhang/paper/12-imc-hijack.pdf">http://www.cs.arizona.edu/~bzhang/</a>
<a href="http://www.cs.arizona.edu/~bzhang/paper/12-imc-hijack.pdf">paper/12-imc-hijack.pdf</a>>.
[<a id="ref-Labovitz">Labovitz</a>] Labovitz, C., "Additional Discussion of the April China
BGP Hijack Incident", Arbor Networks IT Security Blog,
November 2010,
<<a href="http://www.arbornetworks.com/asert/2010/11/additional-discussion-of-the-april-china-bgp-hijack-incident/">http://www.arbornetworks.com/asert/2010/11/additional-</a>
<a href="http://www.arbornetworks.com/asert/2010/11/additional-discussion-of-the-april-china-bgp-hijack-incident/">discussion-of-the-april-china-bgp-hijack-incident/</a>>.
[<a id="ref-LRL">LRL</a>] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks",
University of Arizona (UA) Network Research Lab: Projects
Webpage, 2012, <<a href="http://nrl.cs.arizona.edu/projects/lsrl-events-from-2003-to-2009/">http://nrl.cs.arizona.edu/projects/</a>
<a href="http://nrl.cs.arizona.edu/projects/lsrl-events-from-2003-to-2009/">lsrl-events-from-2003-to-2009/</a>>.
[<a id="ref-Luckie">Luckie</a>] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
kc. claffy, "AS Relationships, Customer Cones, and
Validation", In Proceedings of the 2013 ACM Internet
Measurement Conference (IMC), DOI 10.1145/2504730.2504735,
October 2013,
<<a href="http://www.caida.org/~amogh/papers/asrank-IMC13.pdf">http://www.caida.org/~amogh/papers/asrank-IMC13.pdf</a>>.
[<a id="ref-Madory">Madory</a>] Madory, D., "Why Far-Flung Parts of the Internet Broke
Today", Dyn Research: The New Home of Renesys Blog,
September 2014, <<a href="http://research.dyn.com/2014/09/why-the-internet-broke-today/">http://research.dyn.com/2014/09/</a>
<a href="http://research.dyn.com/2014/09/why-the-internet-broke-today/">why-the-internet-broke-today/</a>>.
[<a id="ref-Mauch">Mauch</a>] Mauch, J., "BGP Routing Leak Detection System", Project
web page, 2014,
<<a href="http://puck.nether.net/bgp/leakinfo.cgi/">http://puck.nether.net/bgp/leakinfo.cgi/</a>>.
<span class="grey">Sriram, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
[<a id="ref-Mauch-nanog">Mauch-nanog</a>]
Mauch, J., "Detecting Routing Leaks by Counting", 41st
NANOG Conference, October 2007,
<<a href="https://www.nanog.org/meetings/nanog41/presentations/mauch-lightning.pdf">https://www.nanog.org/meetings/nanog41/presentations/</a>
<a href="https://www.nanog.org/meetings/nanog41/presentations/mauch-lightning.pdf">mauch-lightning.pdf</a>>.
[<a id="ref-Paseka">Paseka</a>] Paseka, T., "Why Google Went Offline Today and a Bit about
How the Internet Works", CloudFlare Blog, November 2012,
<<a href="http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/">http://blog.cloudflare.com/</a>
<a href="http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/">why-google-went-offline-today-and-a-bit-about/</a>>.
[<a id="ref-ROUTE-LEAK-DEF">ROUTE-LEAK-DEF</a>]
Dickson, B., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Route+Leaks+--+Definitions%22'>"Route Leaks -- Definitions"</a>, Work in
Progress, <a href="./draft-dickson-sidr-route-leak-def-03">draft-dickson-sidr-route-leak-def-03</a>, October
2012.
[<a id="ref-ROUTE-LEAK-REQ">ROUTE-LEAK-REQ</a>]
Dickson, B., "Route Leaks -- Requirements for Detection
and Prevention thereof", Work in Progress, <a href="./draft-dickson-sidr-route-leak-reqts-02">draft-dickson-</a>
<a href="./draft-dickson-sidr-route-leak-reqts-02">sidr-route-leak-reqts-02</a>, March 2012.
[<a id="ref-Toonk2014">Toonk2014</a>]
Toonk, A., "What caused today's Internet hiccup",
BGPMON Blog, August 2014, <<a href="http://www.bgpmon.net/what-caused-todays-internet-hiccup/">http://www.bgpmon.net/</a>
<a href="http://www.bgpmon.net/what-caused-todays-internet-hiccup/">what-caused-todays-internet-hiccup/</a>>.
[<a id="ref-Toonk2015-A">Toonk2015-A</a>]
Toonk, A., "What caused the Google service interruption",
BGPMON Blog, March 2015, <<a href="http://www.bgpmon.net/what-caused-the-google-service-interruption/">http://www.bgpmon.net/</a>
<a href="http://www.bgpmon.net/what-caused-the-google-service-interruption/">what-caused-the-google-service-interruption/</a>>.
[<a id="ref-Toonk2015-B">Toonk2015-B</a>]
Toonk, A., "Massive route leak causes Internet slowdown",
BGPMON Blog, June 2015, <<a href="http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/">http://www.bgpmon.net/</a>
<a href="http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/">massive-route-leak-cause-internet-slowdown/</a>>.
[<a id="ref-Wijchers">Wijchers</a>] Wijchers, B. and B. Overeinder, "Quantitative Analysis of
BGP Route Leaks", Reseaux IP Europeens (RIPE) 69th
Meeting, November 2014, <<a href="http://ripe69.ripe.net/presentations/157-RIPE-69-Routing-WG.pdf">http://ripe69.ripe.net/</a>
<a href="http://ripe69.ripe.net/presentations/157-RIPE-69-Routing-WG.pdf">presentations/157-RIPE-69-Routing-WG.pdf</a>>.
[<a id="ref-Zmijewski">Zmijewski</a>]
Zmijewski, E., "Indonesia Hijacks the World", Dyn
Research: The New Home of Renesys Blog, April 2014,
<<a href="http://research.dyn.com/2014/04/indonesia-hijacks-world/">http://research.dyn.com/2014/04/</a>
<a href="http://research.dyn.com/2014/04/indonesia-hijacks-world/">indonesia-hijacks-world/</a>>.
<span class="grey">Sriram, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7908">RFC 7908</a> Route-Leak Problem Definition June 2016</span>
Acknowledgements
The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari,
Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Job Snijders,
Ruediger Volk, Andrei Robachevsky, Charles van Niman, Chris Morrow,
and Sandy Murphy for comments, suggestions, and critique. The
authors are also thankful to Padma Krishnaswamy, Oliver Borchert, and
Okhee Kim for their comments and review.
Authors' Addresses
Kotikalapudi Sriram
US NIST
Email: ksriram@nist.gov
Doug Montgomery
US NIST
Email: dougm@nist.gov
Danny McPherson
Verisign, Inc.
Email: dmcpherson@verisign.com
Eric Osterweil
Verisign, Inc.
Email: eosterweil@verisign.com
Brian Dickson
Email: brian.peter.dickson@gmail.com
Sriram, et al. Informational [Page 11]
</pre>
|
