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
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
Problem Definition and Classification of BGP Route Leaks
BGP路由泄漏的问题定义和分类
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 Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7908.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7908.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3
3. Classification of Route Leaks Based on Documented Events . . 4
3.1. Type 1: Hairpin Turn with Full Prefix . . . . . . . . . . 4
3.2. Type 2: Lateral ISP-ISP-ISP Leak . . . . . . . . . . . . 5
3.3. Type 3: Leak of Transit-Provider Prefixes to Peer . . . . 5
3.4. Type 4: Leak of Peer Prefixes to Transit Provider . . . . 5
3.5. Type 5: Prefix Re-origination with Data Path to
Legitimate Origin . . . . . . . . . . . . . . . . . . . . 6
3.6. Type 6: Accidental Leak of Internal Prefixes and More-
Specific Prefixes . . . . . . . . . . . . . . . . . . . . 6
4. Additional Comments about the Classification . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3
3. Classification of Route Leaks Based on Documented Events . . 4
3.1. Type 1: Hairpin Turn with Full Prefix . . . . . . . . . . 4
3.2. Type 2: Lateral ISP-ISP-ISP Leak . . . . . . . . . . . . 5
3.3. Type 3: Leak of Transit-Provider Prefixes to Peer . . . . 5
3.4. Type 4: Leak of Peer Prefixes to Transit Provider . . . . 5
3.5. Type 5: Prefix Re-origination with Data Path to
Legitimate Origin . . . . . . . . . . . . . . . . . . . . 6
3.6. Type 6: Accidental Leak of Internal Prefixes and More-
Specific Prefixes . . . . . . . . . . . . . . . . . . . . 6
4. Additional Comments about the Classification . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Frequent incidents [Huston2012] [Cowie2013] [Toonk2015-A]
[Toonk2015-B] [Cowie2010] [Madory] [Zmijewski] [Paseka] [LRL] [Khare]
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. Section 2 provides a
working definition of route leaks, keeping in view many recent
incidents that have received significant attention. Section 3
attempts to enumerate (though not exhaustively) different types of
route leaks based on observed events on the Internet. Further,
Section 3 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 [ROUTE-LEAK-DEF]
[ROUTE-LEAK-REQ].
Frequent incidents [Huston2012] [Cowie2013] [Toonk2015-A]
[Toonk2015-B] [Cowie2010] [Madory] [Zmijewski] [Paseka] [LRL] [Khare]
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. Section 2 provides a
working definition of route leaks, keeping in view many recent
incidents that have received significant attention. Section 3
attempts to enumerate (though not exhaustively) different types of
route leaks based on observed events on the Internet. Further,
Section 3 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 [ROUTE-LEAK-DEF]
[ROUTE-LEAK-REQ].
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 [Gao], [Luckie], and [Gill]. For measurements of valley-free violations in Internet routing, see [Anwar], [Giotsas], and [Wijchers].
路由泄漏是指路由公告超出其预期范围的传播。也就是说，从自治系统（AS）向另一AS通告学习的BGP路由违反了接收方、发送方和/或其中一个AS沿前面AS路径的预定策略。预期范围通常由分布在相关ASE之间的一组本地重新分布/过滤策略定义。通常，这些预期策略是根据ASE之间的成对对等业务关系定义的（例如，客户、运输提供商、对等方）。有关AS关系和路由策略的文献，请参阅[Gao]、[Luckie]和[Gill]。有关Internet路由中无谷违规的度量，请参见[Anwar]、[Giotsas]和[Wijchers]。
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.
上述定义并非包罗万象。我们的目标是制定一个适用于足够多观察到的事件的工作定义，以便IETF社区为制定路线泄漏检测和缓解解决方案奠定基础。
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.
如图1所示，当多宿客户As（如图1中的AS3）从一个传输提供商（ISP1）获悉前缀更新，并违反预定的路由策略将更新泄漏给另一个传输提供商（ISP2）时，会发生常见形式的路由泄漏，并且，第二个传输提供商未检测到泄漏，并将泄漏的更新传播给其客户、对等方和传输ISP。
/\ /\
\ 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) |
+---------------+
/\ /\
\ 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
图1：路线泄漏的基本概念
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".
本文件提出了以下分类法，以涵盖观察到的几种类型的路线泄漏，同时承认该列表并非详尽无遗。在下文中，宣布违反预定策略的路线的AS称为“违规AS”。
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 [Kapela-Pilosov], 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
描述：多宿AS从一个上游ISP学习一条路由，并简单地将其传播到另一个上游ISP（该转弯基本上类似于发夹）。更新中的前缀和AS路径均未更改。这类似于直接的路径中毒攻击[Kapela Pilosov]，但具有完整的前缀。应注意，此类泄漏通常是偶然的（即，并非恶意的）。这一更新基本上在令人不快的AS的多宿主AS上做了一个发夹式的转变。泄漏通常会成功（即，泄漏的更新被接受并传播），因为第二个ISP更喜欢客户声明而不是相同前缀的对等声明。数据包将到达合法目的地，尽管
via the offending AS, unless they are dropped at the offending AS due to its inability to handle resulting large volumes of traffic.
通过违规AS，除非由于无法处理由此产生的大量流量而在违规AS处丢弃。
o Example incidents: Examples of Type 1 route-leak incidents are (1) the Dodo-Telstra incident in March 2012 [Huston2012], (2) the VolumeDrive-Atrato incident in September 2014 [Madory], and (3) the massive Telekom Malaysia route leak of about 179,000 prefixes, which in turn Level3 accepted and propagated [Toonk2015-B].
o 示例事件：1类线路泄漏事件的示例包括（1）2012年3月的多道电信事件[Huston 2012]，（2）2014年9月的VolumedDrive Atrato事件[Madory]，以及（3）约179000个前缀的大规模马来西亚电信线路泄漏，这反过来又被3级接受并传播[Toonk2015-B]。
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.
描述：术语“横向”在这里是“非传输”或“对等”的同义词。例如，当涉及三个连续的ISP对等方（如ISP-A、ISP-B和ISP-C）且ISP-B从ISP-A接收到一条路由，然后又将其泄漏到ISP-C时，通常会发生这种类型的路由泄漏。典型的路由策略是横向（即非传输）对等ISP是指它们只应相互传播各自的客户前缀。
o Example incidents: In [Mauch-nanog] and [Mauch], 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. [Mauch] 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.
o 示例事件：在[Mauch nanog]和[Mauch]中，通过监控全局BGP系统中的更新，并在BGP更新的AS路径中按顺序查找三个或更多超大ISP的自主系统号（ASN），报告此类路由泄漏。[Mauch]观察到，其检测算法检测到这些异常情况和潜在的路由泄漏，因为通常情况下，非常大的ISP不会相互购买公交服务。然而，它也注意到，当一个非常大的ISP确实从另一个非常大的ISP购买公交服务时，也存在例外情况，因此，对于已知情况，其检测算法也存在例外情况。
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.
描述：这种类型的路由泄漏发生在违规AS泄漏从其传输提供商学到的路由到横向（即非传输）对等方时。
o Example incidents: The incidents reported in [Mauch] include Type 3 leaks.
o 事件示例：[Mauch]中报告的事件包括3类泄漏。
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.
描述：当违规AS泄漏从侧面（即非传输）对等方学到的路由到其（AS）自己的传输提供商时，会发生这种类型的路由泄漏。这些泄漏的路由通常来自横向对等的客户锥。
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 [Kephart], (2) the Hathway-Airtel route leak of 336 Google prefixes causing widespread interruption of Google services in Europe and Asia [Toonk2015-A], (3) the Moratel-PCCW route leak of Google prefixes causing Google's services to go offline [Paseka], 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 [Huston2012], the leaked routes from Dodo to Telstra included routes that Dodo learned from its transit providers as well as lateral peers.
o 示例事件：第4类路由泄漏事件的示例包括：（1）亚马逊Web服务（AWS）前缀的Axcelx Hibernia路由泄漏，导致AWS和在AWS[Kephart]上运行的各种服务中断；（2）336个谷歌前缀的Hathway Airtel路由泄漏，导致谷歌服务在欧洲和亚洲广泛中断[Toonk2015-A]，（3）谷歌前缀的莫拉泰尔电讯盈科路由泄漏导致谷歌服务离线[Paseka]，以及（4）上述1类路由泄漏的一些示例事件也包括4类路由泄漏。例如，在Dodo Telstra事件中[Huston2012]，从Dodo到Telstra的泄露路线包括Dodo从其运输提供商以及横向同行那里了解到的路线。
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.
描述：多宿AS从一个上游ISP学习路由，并向另一个上游ISP宣布前缀，就好像它是由它发起的一样（即，剥离接收到的AS路径并重新发起前缀）。这可以称为重新发起或错误发起。然而，不知何故，可能存在到合法起源AS的反向路径，并且数据包到达合法目的地，尽管是通过有问题的AS。（注意：此处存在反向路径并非由于违规AS使用了路径中毒伎俩。）但有时反向路径可能不存在，并且发送给泄漏前缀的数据包可能只是在违规AS处丢弃。
o Example incidents: Examples of Type 5 route leak include (1) the China Telecom incident in April 2010 [Hiran] [Cowie2010] [Labovitz], (2) the Belarusian GlobalOneBel route-leak incidents in February-March 2013 and May 2013 [Cowie2013], (3) the Icelandic Opin Kerfi-Simmin route-leak incidents in July-August 2013 [Cowie2013], and (4) the Indosat route-leak incident in April 2014 [Zmijewski]. 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.
o 事件示例：第5类路由泄漏的示例包括（1）2010年4月的中国电信事件[Hiran][Cowie2010][Labovitz]，（2）2013年2月-3月和2013年5月的白俄罗斯GlobalOneBel路由泄漏事件[Cowie2013]，（3）2013年7月-8月的冰岛Opin-Kerfi-Simmin路由泄漏事件[Cowie2013]，以及（4）2014年4月印度卫星航线泄漏事件[Zmijewski]。反向路径（即，从违规AS到合法目的地的数据路径）存在于上述事件1、2和3中，但不存在于事件4中。在事件4中，错误路由的数据包被丢弃在Indosat的AS。
3.6. Type 6: Accidental Leak of Internal Prefixes and More-Specific Prefixes
3.6. 类型6：内部前缀和更具体的前缀意外泄漏
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.
描述：有问题的AS只是将其内部前缀泄漏给一个或多个传输提供商ASE和/或ISP对等方。泄漏的内部前缀通常是由已经公布的、不太具体的前缀所包含的更具体的前缀。更具体的前缀不打算在外部BGP（eBGP）中路由。此外，接收这些泄漏的AS无法过滤它们。
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.
通常，这些泄漏的公告是由于AS内的一些瞬时故障引起的；它们的寿命很短，通常在宣布后很快就会撤回。然而，这些更具体的前缀可能会暂时导致路由优先于其他聚合（即，不太具体的）路由公告，从而从其正常最佳路径重定向流量。
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 [Huston2014] [Toonk2014].
o 事件示例：内部路由泄漏频繁发生（例如，一周内多次），每次事件泄漏的前缀数量从数百到数千不等。2014年8月，AS701和AS705泄漏了大约22000个已经公布的聚合的更具体前缀[Huston2014][Toonk2014]，这是一个非常明显且破坏性极强的内部路由泄漏事件。
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.
值得注意的是，类型1到类型4的相似之处在于，在每种情况下，路由都会违反策略泄漏，但不同之处在于泄漏的路由源AS和目标AS角色的上下文。
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.
第5类路由泄漏（即，前缀误发，数据路径指向合法来源）也可能与第2、3和4类中的AS关系上下文一起发生。虽然这些可能性是公认的，简单地列举更多的类型来考虑所有这样的特殊情况，并没有增加价值，只要解决方案开发的路线泄漏有关。因此，此处提到的特殊情况不包括在列举路线泄漏类型中。
No security considerations apply since this is a problem definition document.
由于这是一个问题定义文档，因此不适用任何安全注意事项。
[Anwar] 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, <http://www.cs.usc.edu/assets/007/94928.pdf>.
[Anwar]Anwar，R.，Niaz，H.，Choffnes，D.，Cunha，I.，Gill，P.，和N.Katz Bassett，“在野外调查域间路由策略”，发表于2015年ACM互联网测量会议记录，DOI 10.1145/2815675.2815712，2015年10月<http://www.cs.usc.edu/assets/007/94928.pdf>.
[Cowie2010] Cowie, J., "China's 18 Minute Mystery", Dyn Research: The New Home of Renesys Blog, November 2010, <http://research.dyn.com/2010/11/ chinas-18-minute-mystery/>.
[Cowie2010]Cowie，J.，“中国的18分钟之谜”，Dyn Research:Renesys博客的新家，2010年11月<http://research.dyn.com/2010/11/ Chinese-18分钟之谜/>。
[Cowie2013] Cowie, J., "The New Threat: Targeted Internet Traffic Misdirection", Dyn Research: The New Home of Renesys Blog, November 2013, <http://research.dyn.com/2013/11/ mitm-internet-hijacking/>.
[Cowie2013]Cowie，J.，“新威胁：有针对性的互联网流量误导”，Dyn Research:Renesys博客的新主页，2013年11月<http://research.dyn.com/2013/11/ mitm互联网劫持/>。
[Gao] 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, <http://www.cs.princeton.edu/~jrex/papers/ sigmetrics00.long.pdf>.
[Gao]Gao，L.和J.Rexford，“没有全球协调的稳定互联网路由”，IEEE/ACM网络交易（TON），第9卷，第6期，第689-692页，DOI 10.1109/90.974523，2001年12月<http://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf>。
[Gill] 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, <http://www.cs.bu.edu/~goldbe/papers/survey.pdf>.
[Gill]Gill，P.，Schapira，M.，和S.Goldberg，“域间路由策略调查”，ACM SIGCOMM计算机通信评论，第44卷，第1期，第28-34页，DOI 10.1145/2567561.2567566，2014年1月<http://www.cs.bu.edu/~goldbe/papers/survey.pdf>。
[Giotsas] 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.
[Giotsas]Giotsas，V.和S.Zhou，“互联网路由中的无谷违规-基于BGP社区数据的分析”，2012年IEEE国际通信会议（ICC），DOI 10.1109/ICC.2012.6363987，2012年6月。
[Hiran] 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, <http://www3.cs.stonybrook.edu/~phillipa/papers/ CTelecom.html>.
[Hiran]Hiran，R.，Carlsson，N.，和P.Gill，“描述大规模路由异常：中国电信事件的案例研究”，载于2013年第14届被动和主动测量国际会议记录，DOI 10.1007/978-3-642-36516-4è，2013年3月<http://www3.cs.stonybrook.edu/~phillipa/papers/CTelecom.html>。
[Huston2012] Huston, G., "Leaking Routes", Asia Pacific Network Information Centre (APNIC) Blog, March 2012, <http://labs.apnic.net/blabs/?p=139/>.
[Huston2012]Huston，G.，“泄漏路线”，亚太网络信息中心（APNIC）博客，2012年3月<http://labs.apnic.net/blabs/?p=139/>.
[Huston2014] Huston, G., "What's so special about 512?", Asia Pacific Network Information Centre (APNIC) Blog, September 2014, <http://labs.apnic.net/blabs/?p=520/>.
[Huston2014]Huston，G.，“512有什么特别之处？”，亚太网络信息中心（APNIC）博客，2014年9月<http://labs.apnic.net/blabs/?p=520/>.
[Kapela-Pilosov] Pilosov, A. and T. Kapela, "Stealing the Internet: An Internet-Scale Man in the Middle Attack", 16th Defcon Conference, August 2008, <https://www.defcon.org/images/defcon-16/ dc16-presentations/defcon-16-pilosov-kapela.pdf>.
[卡佩拉皮罗索夫] PiSOOVO，A和T. Kapela，“窃取互联网：一个互联网规模的中间人攻击”，第十六DeFCON会议，2008年8月，<https://www.defcon.org/images/defcon-16/ dc16演示文稿/defcon-16-pilosov-kapela.pdf>。
[Kephart] Kephart, N., "Route Leak Causes Amazon and AWS Outage", ThousandEyes Blog, June 2015, <https://blog.thousandeyes.com/ route-leak-causes-amazon-and-aws-outage>.
[Kephart]Kephart，N.，“路线泄漏导致亚马逊和AWS停机”，千年行博客，2015年6月<https://blog.thousandeyes.com/ 路由泄漏导致amazon和aws停机>。
[Khare] 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, <http://www.cs.arizona.edu/~bzhang/ paper/12-imc-hijack.pdf>.
[Khare]Khare，V.，Ju，Q.，和B.Zhang，“并发前缀劫持：发生和影响”，《2013年ACM互联网测量会议记录》，DOI 10.1145/2398776.23987802012年11月<http://www.cs.arizona.edu/~bzhang/paper/12 imc hijack.pdf>。
[Labovitz] Labovitz, C., "Additional Discussion of the April China BGP Hijack Incident", Arbor Networks IT Security Blog, November 2010, <http://www.arbornetworks.com/asert/2010/11/additional-discussion-of-the-april-china-bgp-hijack-incident/>.
[Labovitz]Labovitz，C.，“关于4月中国BGP劫持事件的补充讨论”，Arbor Networks IT安全博客，2010年11月<http://www.arbornetworks.com/asert/2010/11/additional-discussion-of-the-april-china-bgp-hijack-incident/>.
[LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", University of Arizona (UA) Network Research Lab: Projects Webpage, 2012, <http://nrl.cs.arizona.edu/projects/ lsrl-events-from-2003-to-2009/>.
[LRL] Khare，V，Ju，Q.和B. Zhang，“大路由泄漏”，亚利桑那大学（UA）网络研究实验室：项目网页，2012，<http://nrl.cs.arizona.edu/projects/ lsrl-events-from-2003-to-2009/>。
[Luckie] 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, <http://www.caida.org/~amogh/papers/asrank-IMC13.pdf>.
[Luckie]Luckie，M.，Huffaker，B.，Dhamdhere，A.，Giotsas，V.，和kc。claffy，“作为关系、客户锥和验证”，摘自2013年ACM互联网测量会议记录，DOI 10.1145/2504730.25047352013年10月<http://www.caida.org/~amogh/papers/asrank-IMC13.pdf>。
[Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke Today", Dyn Research: The New Home of Renesys Blog, September 2014, <http://research.dyn.com/2014/09/ why-the-internet-broke-today/>.
[Madory]Madory，D.，“为什么互联网的各个领域今天都崩溃了”，Dyn Research:Renesys博客的新家，2014年9月<http://research.dyn.com/2014/09/ 为什么今天互联网崩溃了/>。
[Mauch] Mauch, J., "BGP Routing Leak Detection System", Project web page, 2014, <http://puck.nether.net/bgp/leakinfo.cgi/>.
[Mauch]Mauch，J.，“BGP路由泄漏检测系统”，项目网页，2014年<http://puck.nether.net/bgp/leakinfo.cgi/>.
[Mauch-nanog] Mauch, J., "Detecting Routing Leaks by Counting", 41st NANOG Conference, October 2007, <https://www.nanog.org/meetings/nanog41/presentations/ mauch-lightning.pdf>.
[Mauch nanog]Mauch，J.，“通过计数检测路由泄漏”，第41届nanog会议，2007年10月<https://www.nanog.org/meetings/nanog41/presentations/ mauch lightning.pdf>。
[Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about How the Internet Works", CloudFlare Blog, November 2012, <http://blog.cloudflare.com/ why-google-went-offline-today-and-a-bit-about/>.
[Paseka]Paseka，T.，“谷歌为何今天离线，以及互联网如何运作”，CloudFlare博客，2012年11月<http://blog.cloudflare.com/ why-google-Gone-offline-today-and-bit-about/>。
[ROUTE-LEAK-DEF] Dickson, B., "Route Leaks -- Definitions", Work in Progress, draft-dickson-sidr-route-leak-def-03, October 2012.
[ROUTE-LEAK-DEF]Dickson，B.，“路线泄漏——定义”，正在进行的工作，草稿-Dickson-sidr-ROUTE-LEAK-DEF-032012年10月。
[ROUTE-LEAK-REQ] Dickson, B., "Route Leaks -- Requirements for Detection and Prevention thereof", Work in Progress, draft-dickson-sidr-route-leak-reqts-02, March 2012.
[ROUTE-LEAK-REQ]Dickson，B.，“路线泄漏——检测和预防要求”，在建工程，草稿-Dickson-sidr-ROUTE-LEAK-reqts-022012年3月。
[Toonk2014] Toonk, A., "What caused today's Internet hiccup", BGPMON Blog, August 2014, <http://www.bgpmon.net/ what-caused-todays-internet-hiccup/>.
[Toonk2014]Toonk，A.“是什么导致了今天的互联网故障”，BGPMON博客，2014年8月<http://www.bgpmon.net/ 是什么导致了今天的互联网打嗝/>。
[Toonk2015-A] Toonk, A., "What caused the Google service interruption", BGPMON Blog, March 2015, <http://www.bgpmon.net/ what-caused-the-google-service-interruption/>.
[Toonk2015-A]Toonk，A.“谷歌服务中断的原因”，BGPMON博客，2015年3月<http://www.bgpmon.net/ 是什么导致谷歌服务中断/>。
[Toonk2015-B] Toonk, A., "Massive route leak causes Internet slowdown", BGPMON Blog, June 2015, <http://www.bgpmon.net/ massive-route-leak-cause-internet-slowdown/>.
[Toonk2015-B]Toonk，A.“大规模路由泄漏导致互联网减速”，BGPMON博客，2015年6月<http://www.bgpmon.net/ 大规模路由泄漏导致互联网减速/>。
[Wijchers] Wijchers, B. and B. Overeinder, "Quantitative Analysis of BGP Route Leaks", Reseaux IP Europeens (RIPE) 69th Meeting, November 2014, <http://ripe69.ripe.net/ presentations/157-RIPE-69-Routing-WG.pdf>.
[Wijchers]Wijchers，B.和B.Overinder，“BGP路线泄漏的定量分析”，研究IP欧洲（RIME）第69次会议，2014年11月<http://ripe69.ripe.net/ 演示文稿/157-RIME-69-Routing-WG.pdf>。
[Zmijewski] Zmijewski, E., "Indonesia Hijacks the World", Dyn Research: The New Home of Renesys Blog, April 2014, <http://research.dyn.com/2014/04/ indonesia-hijacks-world/>.
[Zmijewski]Zmijewski，E.，“印度尼西亚劫持世界”，Dyn Research:Renesys博客的新家，2014年4月<http://research.dyn.com/2014/04/ 印度尼西亚劫持世界/>。
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.
作者希望感谢贾里德·莫奇、杰夫·哈斯、沃伦·库马里、阿莫·达姆德希尔、雅各布·海茨、杰夫·休斯顿、兰迪·布什、乔布斯·斯奈德尔斯、鲁迪格·沃尔克、安德烈·罗巴切夫斯基、查尔斯·范·尼曼、克里斯·莫罗和桑迪·墨菲的评论、建议和批评。作者还感谢Padma Krishnaswamy、Oliver Borchert和Okhee Kim的评论和评论。
Authors' Addresses
作者地址
Kotikalapudi Sriram US NIST
美国国家标准与技术研究所
Email: ksriram@nist.gov
Email: ksriram@nist.gov
Doug Montgomery US NIST
美国国家标准与技术研究院道格·蒙哥马利
Email: dougm@nist.gov
Email: dougm@nist.gov
Danny McPherson Verisign, Inc.
丹尼·麦克弗森公司。
Email: dmcpherson@verisign.com
Email: dmcpherson@verisign.com
Eric Osterweil Verisign, Inc.
Eric Osterweil Verisign公司。
Email: eosterweil@verisign.com
Email: eosterweil@verisign.com
Brian Dickson
布赖恩迪克森
Email: brian.peter.dickson@gmail.com
Email: brian.peter.dickson@gmail.com