[要約] RFC 7908は、BGPルートリークの問題定義と分類に関するものであり、BGPルートリークの理解と対策のためのガイドラインを提供することを目的としています。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
ルートリークとは、意図した範囲を超えてルーティングアナウンスが伝播することです。つまり、学習したBGPルートの自律システム（AS）から別のASへのアナウンスは、レシーバー、センダー、および/または先行するASパスに沿ったASの1つの意図されたポリシーに違反しています。意図されたスコープは通常、関係するAS間で配布される一連のローカル再配布/フィルタリングポリシーによって定義されます。多くの場合、これらの意図されたポリシーは、AS（たとえば、顧客、トランジットプロバイダー、ピア）間のペアワイズピアリングビジネス関係の観点から定義されます。 AS関係とルーティングポリシーに関連する文献については、[Gao]、[Luckie]、および[Gill]を参照してください。インターネットルーティングにおける谷のない違反の測定については、[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など）が1つのトランジットプロバイダー（ISP1）からプレフィックスの更新を学習し、違反して別のトランジットプロバイダー（ISP2）に更新をリークすると、一般的なルートリークが発生します。さらに、2番目のトランジットプロバイダーはリークを検出せず、リークされたアップデートを顧客、ピア、トランジット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) |
+---------------+
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 via the offending AS, unless they are dropped at the offending AS due to its inability to handle resulting large volumes of traffic.
説明：マルチホームASは、1つの上流ISPからのルートを学習し、それを単に別の上流ISPに伝搬します（ターンは基本的にヘアピンに似ています）。更新のプレフィックスもASパスも変更されません。これは単純なパスポイズニング攻撃[Kapela-Pilosov]に似ていますが、完全なプレフィックスが付きます。このタイプのリークは、多くの場合偶発的です（つまり、悪意のないものです）。このアップデートは、基本的には問題のASのマルチホームASでヘアピンを回転させます。 2番目のISPは同じプレフィックスのピアアナウンスよりも顧客アナウンスを優先するため、リークはしばしば成功します（つまり、リークされた更新が受け入れられて伝播されます）。データパケットは、結果の大量のトラフィックを処理できないために問題の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月のDodo-Telstraインシデント[Huston2012]、（2）2014年9月のVolumeDrive-Atratoインシデント[Madory]、および（3）大規模なTelekomマレーシアです。約179,000のプレフィックスのルートリーク、これはLevel3を受け入れて伝播しました[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.
説明：ここでの「ラテラル」という用語は、「非トランジット」または「ピアツーピア」と同義です。このタイプのルートリークは通常、たとえば、3つの連続する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のシーケンスで3つ以上の非常に大きなISPの自律システム番号（ASN）を見つけることによって報告されます。更新のASパス。 [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）アマゾンウェブサービス（AWS）プレフィックスのAxcelx-Hiberniaルートリークにより、AWSとAWSで実行されるさまざまなサービスの混乱を引き起こします（2） Googleプレフィックスが336あるHathway-Airtelルートリークにより、ヨーロッパとアジアで広範囲にGoogleサービスが中断されている[Toonk2015-A]、（3）GoogleプレフィックスがMoratel-PCCWルートリークがあり、Googleのサービスがオフラインになる[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）ベラルーシのGlobalOneBel 2013年2月〜3月および2013年5月のルートリークインシデント[Cowie2013 ]、（3）2013年7月から8月にかけてのアイスランドのオピンケルフィ-シミンのルートリークインシデント[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は、その内部プレフィックスを1つまたは複数のトランジットプロバイダーASや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がすでにアナウンスされたアグリゲートの特定のプレフィックス約22,000をリークしたときに、内部ルートの非常に目立って広範囲に破壊的なリークが発生しました[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インターネット測定会議（IMC）、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。、「China's 18 Minute Mystery」、Dyn Research：The New Home of Renesys Blog、2010年11月、<http://research.dyn.com/2010/11/ chinas-18-minute-mystery />。
[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。、「The New Threat：Targeted Internet Traffic Misdirection」、Dyn Research：The New Home of Renesys Blog、2013年11月、<http://research.dyn.com/2013/11/ mitm-internet -hijacking />。
[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、L。およびJ. Rexford、「グローバルな調整なしの安定したインターネットルーティング」、IEEE / ACM Transactions on Networking（TON）、Volume 9、Issue 6、pp 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>.
[ギル]ギル、P。、シャピラ、M。、およびS.ゴールドバーグ、「ドメイン間ルーティングポリシーの調査」、ACM SIGCOMM Computer Communication Review、Volume 44、Issue 1、pp 28-34、DOI 10.1145 / 2567561.2567566、1月2014、<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 International Conference on Communications（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、「大規模ルーティング異常の特徴付け：China Telecom Incidentのケーススタディ」、パッシブおよびアクティブ測定に関する第14回国際会議（PAM）の議事録）2013、DOI 10.1007 / 978-3-642-36516-4_23、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。、「Leaking Routes」、アジア太平洋ネットワーク情報センター（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>.
[Kapela-Pilosov] Pilosov、A.およびT. Kapela、「インターネットを盗む：中間攻撃におけるインターネット規模の男」、第16回Defcon会議、2008年8月、<https://www.defcon.org/images/ defcon-16 / dc16-presentations / 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。、「ルートリークが原因でAmazonおよびAWSが停止する」、ThousandEyesブログ、2015年6月、<https://blog.thousandeyes.com/ route-leak-causes-amazon-and-aws-outage>。
[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、「Concurrent Prefix Hijacks：Occurrence and Impacts」、Proceedings of the 2013 ACM Internet Measurement Conference（IMC）、DOI 10.1145 / 2398776.2398780、2012年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 Security Blog、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、「Large Route Leaks」、アリゾナ大学（UA）ネットワークリサーチラボ：プロジェクトWebページ、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>.
[ラッキー]ラッキー、M。、ハッファッカー、B。、ダムデア、A。、ジョッツァス、V.、kc。 claffy、「AS関係、顧客コーン、および検証」、2013 ACMインターネット測定会議（IMC）の議事録、DOI 10.1145 / 2504730.2504735、2013年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/>.
[マドリー]マドリー、D。、「なぜインターネットの遠い部分が今日壊れたのか」、Dyn Research：The New Home of Renesys Blog、2014年9月、<http://research.dyn.com/2014/09/なぜ-the-internet-broke-today />。
[Mauch] Mauch, J., "BGP Routing Leak Detection System", Project web page, 2014, <http://puck.nether.net/bgp/leakinfo.cgi/>.
[Mauch] Mauch、J。、「BGP Routing Leak Detection System」、プロジェクトWebページ、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。、「Detecting Routing Leaks by Counting」、第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。、「Googleが今日オフラインになった理由とインターネットの仕組みについて少し」、CloudFlareブログ、2012年11月、<http://blog.cloudflare.com/why-google-went-offline-today -そして-少しについて/>。
[ROUTE-LEAK-DEF] Dickson, B., "Route Leaks -- Definitions", Work in Progress, draft-dickson-sidr-route-leak-def-03, October 2012.
[ROUTE-LEAK-DEF]ディクソン、B。、「ルートリーク-定義」、作業中、draft-dickson-sidr-route-leak-def-03、2012年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]ディクソン、B。、「ルートリーク-その検出と防止のための要件」、作業中、draft-dickson-sidr-route-leak-reqts-02、2012年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/ what-caused-todays-internet-hiccup />。
[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。、「Googleサービスの中断の原因」、BGPMONブログ、2015年3月、<http://www.bgpmon.net/ what-caused-the-google-service-interruption />。
[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/ massive-route-leak-cause-internet-slowdown />。
[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. Overeinder、「BGPルートリークの定量分析」、Reseaux IP Europeens（RIPE）69回ミーティング、2014年11月、<http://ripe69.ripe.net/ presentations / 157-RIPE- 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：The New Home of Renesys Blog、2014年4月、<http://research.dyn.com/2014/04/ indonesia-hijacks-world /> 。
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.
著者は、コメント、提案について、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、Sandy Murphyに感謝します。そして批評。また、コメントやレビューをいただいたPadma Krishnaswamy、Oliver Borchert、Okhee Kimにも感謝しています。
Authors' Addresses
著者のアドレス
Kotikalapudi Sriram US NIST
コティカラプディスリラムUS NIST
Email: ksriram@nist.gov
Doug Montgomery US NIST
ダグモンゴメリーUS NIST
Email: dougm@nist.gov
Danny McPherson Verisign, Inc.
ダニー・マクファーソン・ベリサイン社
Email: dmcpherson@verisign.com
Eric Osterweil Verisign, Inc.
Eric Osterweil Verisign、Inc.
Email: eosterweil@verisign.com
Brian Dickson
ブライアンディクソン
Email: brian.peter.dickson@gmail.com