RFC 7908: BGP経路漏洩の問題定義と分類
要旨
ボーダー・ゲートウェイ・プロトコル・ルーティング・システムのシステム的な脆弱性は、「経路漏洩」(ルートリーク)として知られ、近年大きな注目を集めている。インターネット・ルーティングに重大な混乱をもたらし、頻発するインシデントは経路漏洩に分類されるが、これまでのところ、この用語の共通の定義がなかった。この文書では、実際に発生し、大きな注目を集めた出来事を念頭に置きながら、経路漏洩の実用的な定義を規定する。さらに、本文書は、インターネット上で観測された事件に基づいて、さまざまなタイプの経路漏洩を(すべてではないが)列挙することを試みる。その目的は、これまでに観測され、インターネット・ユーザ・コミュニティだけでなく、ネットワーク・オペレータ・コミュニティにとっても懸念される、いくつかの形態の経路漏洩をカバーする分類法を規定することにある。
本文書の位置付け
本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。
本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。
文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7908 で入手できる。
著作権表示
Copyright (c) 2016 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。
1. はじめに
インターネット・ルーティングに重大な混乱をもたらし、頻繁に発生するインシデント[Huston2012] [Cowie2013] [Toonk2015-A] [Toonk2015-B] [Cowie2010] [Madory] [Zmijewski] [Paseka] [LRL] [Khare]は、一般に「経路漏洩」(ルートリーク)と呼ばれている。これらのインシデントの詳細を調べると、その形態や技術的な詳細はさまざまであることが分かる。「経路漏洩問題」のソリューションを追求するには、まず問題の明確な技術的定義を規定し、その最も一般的な形態を列挙することが重要である。セクション2では、最近大きな注目を集めた多くのインシデントを念頭に置きながら、経路漏洩の実用的定義を規定する。セクション3では、インターネット上で観測された事件に基づいて、(網羅的ではないが)さまざまなタイプの経路漏洩を列挙することを試みる。さらに、セクション3では、これまでに観測され、インターネット ・ユーザ・コミュニティだけでなく、ネットワーク事業者コミュニティにとっても懸念される、経路漏洩のいくつかの形態をカバーする分類法を規定する。この文書は、IETFの[ROUTE-LEAK-DEF] [ROUTE-LEAK-REQ]における以前の作業を基に拡大したものである。
2. 経路漏洩の実用的定義
「経路漏洩」の実用的定義案は次のとおりである。
経路漏洩とは、意図した範囲を超えてルーティング・アナウンスが伝播すること。つまり、学習したBGP経路を、あるASから別のASにアナウンスすることは、受信者、送信者、および/またはここまでのASパスの途中にあるASの意図したポリシーに違反する。意図された範囲とは通常、関係するAS間で配布される一連のローカル再配布/フィルタリング・ポリシーによって定義される。多くの場合、この意図されたポリシーは、AS間の互いのピアリング・ビジネスの関係(例えば、顧客、トランジット・プロバイダ、ピア)の観点から定義される。ASの関係とルーティングポリシーに関連する文献については、[Gao]、[Luckie]、および[Gill]を参照のこと。インターネット・ルーティングにおけるバレーフリー違反の測定については、[Anwar]、[Giotsas]、[Wijchers] を参照のこと。
バレーフリー違反
経路漏洩の結果、意図しないパスにトラフィックがリダイレクトされ、盗聴やトラフィック分析が可能になったり、過負荷やブラックホールが発生する場合がある。経路漏洩には偶発的なものと悪意のあるものがあるが、多くの場合、偶発的な設定ミスが原因で発生する。
上記の定義は、すべてを網羅することを意図したものではない。ここでの目的は、IETFコミュニティが経路漏洩の検出と緩和のためのソリューションを開発するための基礎となるよう、観測されたインシデントに十分一致する実用的定義を作成することにある。
3. 記録のある事件に基づく経路漏洩の分類
図1に示すように、一般的な経路漏洩は、マルチホームの顧客AS(図1のAS3など)が、あるトランジット・プロバイダ(ISP1)からプレフィックス・アップデートを学習し、意図したルーティング・ポリシーに反して、そのアップデートを別のトランジット・プロバイダ(ISP2)に漏洩し、さらに、2番目のトランジット・プロバイダが漏洩を検出せず、漏洩したアップデートをその顧客、ピア、トランジットISPに伝播する場合に発生する。
図 1: 経路漏洩の基本概念
本文書は、網羅的なリストを作ることを意図していないことを認識しつつ、観測された経路漏洩のいくつかのタイプをカバーするため、以下の分類法を提案する。以下では、意図したポリシーに違反する経路をアナウンスするASを「加害AS」(offending AS)と呼ぶ。
3.1. タイプ1: フルプレフィックスを伴うヘアピンカーブ
説明: マルチホームASは、あるアップストリーム(上流)ISPから経路を学習し、それを別のアップストリームISPに伝播する(カーブは本質的にヘアピンに似ている)。アップデートの中のプレフィックスもASパスも変更されない。これは単純なパス・ポイズニング攻撃[Kapela-Pilosov]に似ているが、フル・プレフィックス(フル経路)を使用する。このタイプの漏洩は、多くの場合偶発的(つまり悪意がない)であることに注意する必要がある。このアップデートは基本的に、加害ASとなるマルチホームASでヘアピンカーブとなる。ISP2は同じプレフィックスを、ピアよりも顧客のアナウンスを優先するため、漏洩は多くの場合成功する(つまり、漏洩したアップデートが受け入れられ、伝播される)。データパケットは、結果的に大量のトラフィックを処理できない加害ASでドロップされない限り、加害ASを経由するものの、正規の宛先に到達する。
- インシデントの例: タイプ1の経路漏洩インシデントの例としては、(1) 2012年3月のDodo-Telstraのインシデント[Huston2012]、(2) 2014年9月のVolumeDrive-Atratoのインシデント[Madory]、(3) 約179,000のテレコム・マレーシアのプレフィックスが大規模に経路漏洩し、Level3がこれを受け入れて伝播した[Toonk2015-B]。
タイプ1から4
3.2. タイプ2: ラテラルISP-ISP-ISPの漏洩
説明: ここでの「ラテラル」という用語は、「非・トランジット」または「ピアツーピア」と同義である。このタイプの経路漏洩は、例えば3つの連続したISPピア (ISP-A、ISP-B、ISP-Cなど)が関係し、ISP-BがISP-Aから経路を受け取り、それをISP-C に送信することで、漏洩が発生する。ラテラル(つまり、非・トランジット)のピアリングISP間の典型的なルーティングポリシーは、各ISPが自身の顧客プレフィックスのみを互いに伝播するというものである。
- インシデントの例: [Mauch-nanog]と[Mauch]では、このタイプの経路漏洩は、グローバルBGPシステムでアップデートを監視し、BGPアップデートのASパスの中で3つ以上連続する非常に大規模なISPの自律システム番号(ASN)を見つけることで報告している。[Mauch]は、非常に大規模なISPは通常、相互にトランジット・サービスを購入することはないため、検出アルゴリズムはこの異常と潜在的な経路漏洩を検出すると述べている。しかし、ある非常に大規模なISPが別の非常に大規模なISPからトランジットを実際に購入する例外が存在する。したがって、既知のケースの検出アルゴリズムに例外があることも指摘しておく。
3.3. タイプ 3: ピアにトランジット・プロバイダ・プレフィックスが漏洩
説明: このタイプの経路漏洩は、加害ASがトランジット・プロバイダから学習した経路をラテラル(つまり、非・トランジット)ピアに漏洩することで発生する。
- インシデントの例: [Mauch]で報告されたインシデントには、タイプ3の漏洩も含まている。
3.4. タイプ 4: トランジット・プロバイダにピア・プレフィックスが漏洩
説明: このタイプの経路漏洩は、加害ASがラテラル(つまり、非・トランジット)ピアから学習した経路を、その(AS)自身のトランジット・プロバイダに漏洩することで発生する。この漏洩経路は通常、ラテラル・ピアのカスタマ・コーンから発信される。
カスタマ・コーン
カスタマ・コーンとは、自身の顧客経路のみを通って辿り着くすべてのASをいう。図のAのカスタマコーンはA、B、C、D、E、Fであり、Bのカスタマ・コーンはB、D、Eであり、Cのカスタマ・コーンはC、E、Fである。
- インシデントの例: タイプ4の経路漏洩インシデントの例としては、(1) Axcelx-HiberniaによるAmazon Web Services (AWS)プレフィックスの経路漏洩により、AWSとAWS上で動作するさまざまなサービスの中断を引き起こした[Kephart]、(2) Hathway-Airtelによる336件のGoogleプレフィックスの経路漏洩により、ヨーロッパとアジアでGoogleサービスが広範囲に中断した[Toonk2015-A]、(3) Moratel-PCCWによるGoogleプレフィックスの経路漏洩により、Googleのサービスがオフラインになった[Paseka]、(4) 上記のタイプ1経路漏洩で引用したインシデントの例には、タイプ4の経路漏洩も含まれる。例えば、Dodo-Telstraインシデント[Huston2012]では、DodoからTelstraに漏洩した経路に、Dodoがトランジット・プロバイダやラテラル・ピアから学習した経路が含まれていた。
3.5. タイプ5: 正規の発信元へのデータパスによるプレフィックスの再オリジネーション
説明: マルチホームASが、あるアップストリームISPから経路を学習し、そのプレフィックスをあたかもそのISPが発信しているかのように、別のアップストリームISPにアナウンスすること(つまり、受信したASパスを取り去り、プレフィックスを再発信する)。これを、再オリジネーションまたは誤オリジネーションと呼ぶ。しかし、何らかの理由で、正当な発信元ASへのリバースパスが存在し、データパケットが加害ASを経由したとしても、正当な宛先に到達することがある。(注: ここでのリバースパスの存在は、加害ASによるパス・ポイズニングのトリックの使用に起因するものではない。) しかし、リバースパスが存在せず、漏洩したプレフィックス宛てのデータパケットが加害ASで単に破棄されることもある。
- インシデントの例: タイプ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月のIndosat経路漏洩インシデント[Zmijewski]。リバースパス(違反ASから正当な宛先へのデータパス)は、上で引用したインシデント#1、#2、 #3には存在したが、インシデント#4には存在しなかった。インシデント#4では、誤ってルーティングされたデータパケットが IndosatのASでドロップされた。
タイプ5
あえて、タイプ5を図にすると次のようになる。
3.6. タイプ6: 内部プレフィックスとMore Specificプレフィックスの偶発的漏洩
説明: 加害ASが、単純に内部プレフィックスを1つ以上のトランジット・プロバイダASおよび/またはISPピアに漏洩する。漏洩した内部プレフィックスは、多くの場合、すでにアナウンスされているLess-Specificプレフィックスに包含されるMore-Specificプレフィックスである。More-Specifcプレフィックスは、外部BGP(eBGP)でルーティングされることを意図していない。さらに、この漏洩経路を受信するASは、漏洩経路をフィルタリングすることができない。
通常、このような漏洩したアナウンスは、AS内の一時的な障害によるもので、短期間で、通常はアナウンス後すぐに撤回される。しかし、このようなMore-Specificプレフィックスは、瞬間的に経路が他の集約経路(つまり、Less-Specific)よりも優先され、トラフィックが通常の最適パスからリダイレクトされる可能性がある。
- インシデントの例: 内部経路の漏洩は頻繁に発生し(例えば、週に複数回)、漏洩したプレフィックス数は1インシデントあたり数百から数千に及ぶ。非常に顕著で広範囲にわたって破壊的な内部経路の漏洩が2014年8月に発生した。このとき、AS701とAS705は、すでにアナウンスされていた集約経路の約22,000件のMore-Specificプレフィックスを漏洩させた[Huston2014] [Toonk2014]。
タイプ6
あえて、タイプ6を図にすると次のようになる。
4. 分類に関する追加コメント
タイプ1～4は、いずれの場合もポリシー違反で経路が漏洩しているという点では似ているが、漏洩した経路の送信元ASと宛先ASの役割のコンテクストが異なることに注目すべきである。
タイプ5の経路漏洩(つまり、正当な送信元へのデータパスを持つプレフィックスの送信元の誤り)は、タイプ2、3、4におけるASの関係性のコンテクストと関連して発生する可能性もある。この可能性は認識されているが、そのような特殊ケースはすべてを考慮するために、多くのタイプを列挙するだけでは、経路漏洩のソリューション開発に関する限り、価値を高められない。したがって、ここで言及した特殊ケースは、経路漏洩タイプの一覧には含まれていない。
5. セキュリティに関する考慮事項
これは問題定義文書であるため、セキュリティに関する考慮事項は適用されない。
6. 参考規格
[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://conferences2.sigcomm.org/imc/2015/papers/p71.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/.
[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/.
[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.
[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.
[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.
[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, https://link.springer.com/chapter/10.1007/978-3-642-36516-4_23
[Huston2012] Huston, G., "Leaking Routes", Asia Pacific Network Information Centre (APNIC) Blog, March 2012, 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/.
[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.
[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.
[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.
[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/.
[LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", University of Arizona (UA) Network Research Lab: Projects Webpage, 2012, https://www2.cs.arizona.edu/~bzhang/paper/lsrl.pdf
[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.
[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/.
[Mauch] Mauch, J., "BGP Routing Leak Detection System", Project web page, 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.
[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/.
[ROUTE-LEAK-DEF] Dickson, B., "Route Leaks -- Definitions", Work in Progress, draft-dickson-sidr-route-leak-def-03, October 2012.
[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.
[Toonk2014] Toonk, A., "What caused today's Internet hiccup", BGPMON Blog, August 2014, 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-B] Toonk, A., "Massive route leak causes Internet slowdown", BGPMON Blog, June 2015, 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.
[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/.
謝辞
著者らは、ジャレッド・マウフ、ジェフ・ハース、ウォーレン・クマリ、アモグ・ダムディア、ジェイコブ・ハイツ、ジェフ・ヒューストン、ランディー・ブッシュ、ジョブ・スナイダース、リュディガー・ヴォルク、アンドレイ・ロバチェフスキー、チャールズ・ヴァン・ニマン、クリス・モロウ、サンディー・マーフィーのコメント、提案、批評に感謝する。著者らは、コメントとレビューを提供してくれたパドマ・クリシュナスワーミ、オリヴァー・ボルヒェルト、オクヒ・キムにも感謝する。
著者のアドレス
コティカラプディ・シュリラーム
米国NIST
メール: ksriram@nist.gov
ダグ・モンゴメリー
米国NIST
メール: dougm@nist.gov
ダニー・マクファーソン
Verisign, Inc.
メール: dmcpherson@verisign.com
エリック・オスターワイル
Verisign, Inc.
メール: eosterweil@verisign.com
ブライアン・ディクソン
メール: brian.peter.dickson@gmail.com
変更履歴
- 2024.1.12
- 2024.1.25
- 2024.1.31
Discussion