本日、誰でもインターネット上のルートリークに関する情報を取得できるようにする、Cloudflare RadarのルートリークデータとAPIについて紹介します。Cloudflareは、一般公開されているデータと、自社の巨大なグローバルネットワークから引き出された当社のインターネットに対する視点を取り入れた包括的なシステムを構築しています。現在、このシステムではCloudflare RadarのASNページやAPIを通じて、ルートリークのデータを提供しています。
このブログ記事は2部構成になっています。BGPとルートリークに関する議論に続き、当社のルートリーク検出システムの詳細と、それがどのようにCloudflare Radarで利用されるかを説明しています。
BGPとルートリークについて
ドメイン間ルーティング、すなわちネットワーク間で到達可能性情報を交換することは、インターネットの健全性とパフォーマンスにとって重要です。ボーダーゲートウェイプロトコル（BGP）は、組織やネットワーク間でルーティング情報を交換する事実上のルーティングプロトコルと言えるでしょう。そのBGPでは、交換される情報が本物で信頼に値することを前提としていますが、残念ながら現在のインターネットではもはや有効な前提とは言えません。多くの場合、ネットワークは到達可能性情報について間違いを犯したり、意図的に嘘をついたりして、それをインターネットの残りの部分に伝播させることができます。このようなインシデントは、インターネットの正常な運用に重大な混乱をもたらす可能性があります。そのような破壊的なインシデントのタイプの1つがルートリークです。
ルートリークとは、ルーティングアナウンスメントが意図した範囲を超えて伝播することと考えています（RFC7908）。ルートリークは、過去の多くの注目すべき事件で見られたように、数百万人のインターネットユーザーに影響を与える重大な混乱を引き起こす可能性があります。例えば、2019年6月の米国ペンシルベニア州の小規模ネットワークにおける設定ミス（AS396531 - Allegheny Technologies Inc）によりCloudflareプレフィックスがVerizonに誤ってリークされ、Verizonは残りのピアや顧客に誤って設定したルートを伝播するよう処理しました。その結果、インターネットの大部分のトラフィックが、小さなネットワークの限られた容量のリンクで圧迫されることになって輻輳が生じ、影響を受けたIP範囲におけるCloudflareのトラフィックのほとんどがドロップされることになりました。
2018年11月の類似の事件では、ナイジェリアのISP（AS37282 - Mainone）が多数のGoogle IPプレフィックスをそのピアやプロバイダーに誤ってリークしたことでバレーフリーの原則に違反し、Googleのサービスが広範囲で使用できなくなりました。
これらの事件は、ルートリークが非常に大きな影響を与えるだけでなく、小さな地域のネットワークにおける設定ミスが、グローバルなインターネットに雪だるま式に影響を与える可能性があることを物語っています。
ルートリークを迅速に検出して修正することは非常に重要であるにもかかわらず、ユーザーがルートリークの顕著な影響を報告し始めたときになって初めて明るみに出ることがよくあります。ルートリークの検出と防止に関する問題は、ASのビジネス関係とBGPルーティングポリシーが一般的に非開示であり、影響を受けるネットワークがルートリークのルートから離れている場合が多いことに起因しています。
ここ数年、リークしたルートの伝播を防ぐためのソリューションが提案されています。BGPを拡張し、接続した2つのASネットワーク間の関係タイプをセッションに注釈して、ルートリークの抑止と防止を可能にするRFC9234やASPAなどです。
BGPの役割に関する同様のシグナルを実装する代替案として、BGPコミュニティの利用が挙げられます。これは、BGPアナウンスメントのメタデータをエンコードするために遷移属性を利用するものです。これらの方向性は長期的には有望ですが、まだ非常に予備的な段階にあり、すぐに大規模に採用されることはないと思われます。
Cloudflareでは、ルートリークイベントを自動的に検出し、複数のチャネルに通知を送信して可視性を高めるシステムを開発しました。より関連性の高いデータを一般に公開するための取り組みを継続する中で、本日、ルートリーク検出結果のオープンデータAPIを開始し、結果をCloudflare Radarページに統合することをお知らせします。
ルートリークの定義とタイプ
システムの設計について説明する前に、ルートリークとは何か、そしてなぜそれを検出することが重要なのかについて簡単に説明します。
ルートリークの定義については、公開されているIETF RFC7908文書"Problem Definition and Classification of BGP Route Leaks"を参照しています。
> ルートリークとは、ルートアナウンスメント（複数可）が意図した範囲を超えて伝播することです。
_意図した範囲_は、多くの場合自律システム（AS）間のビジネス関係に基づくドメイン間ルーティングポリシーとして具体的に定義されます。これらのビジネス関係は、大きくはカスタマー、トランジットプロバイダー、ピア、兄弟の4つのカテゴリに分類されますが、より複雑な取り決めも可能です。
カスタマーとプロバイダーの関係では、カスタマーASは他のネットワークと、そのトラフィックをグローバルルーティングテーブルにトランジットさせることに同意します。ピアツーピアの関係では、2つのASは自由な二者間トラフィック交換に同意しますが、自社のIPとそのカスタマーのIPの間にのみ限定されます。最後に、同じ管理エンティティに属するASは兄弟とみなされ、そのトラフィック交換は多くの場合無制限です。下図は、3つの主要な関係タイプをエクスポートポリシーにどのように反映させるかを示しています。
ASレベルの関係のタイプと、それがBGPルートの伝播に与える影響を分類することで、伝播時のプレフィックス起点アナウンスメントの複数のフェーズを定義することができます。
上向き：このフェーズのすべてのパスセグメントはカスタマーからプロバイダーへ
ピアリング：1つのピア-ピアのパスセグメント
下向き：このフェーズのすべてのパスセグメントはプロバイダーからカスタマーへ
バレーフリールーティングの原則に従うASパスには、上向き、ピアリング、下向きの各フェーズがあり、すべてオプションですが、その順序を保つ必要があります。バレーフリールーティングに準拠するASパスの例を以下に示します。
RFC7908の"Problem Definition and Classification of BGP Route Leaks"では6種類のルートリークを定義しており、当社のシステム設計にあたってはこれらの定義を参考にしています。各ルートリークのタイプを以下に図解で説明します。
タイプ1：完全なプレフィックスの付いたヘアピンターン
> マルチホームASは、1つの上流ISPからのルートを学習し、それを単に別の上流ISPに伝播します（ターンは基本的にヘアピンに似ています）。更新のプレフィックスもASパスも変更されません。
プロバイダー-カスタマーおよびカスタマー-プロバイダーセグメントを含むASパスは、タイプ1のリークとみなされます。次の例のAS4 → AS5 → AS6は、タイプ1のリークを形成しています。
タイプ1は、ルートリークの中で最も認知度が高く、影響力の大きいタイプです。多くの場合、ピアまたはプロバイダールートよりもカスタマールートの方が優先されます。この例では、AS6が他のピアまたはプロバイダールートではなくAS5経由でトラフィックを送信することを優先する可能性が高く、AS5が意図せずトランジットプロバイダーとなる原因となっています。これは、リークしたASが大量のトラフィックの流入を処理するようにプロビジョニングされていない場合、リークしたプレフィックスに関連するトラフィックのパフォーマンスに大きな影響を与えたり、停止を引き起こす可能性があります。
2015年6月、地域ISPのテレコム・マレーシア（AS4788）は、そのプロバイダーやピアから学習した17万以上のルートを、別のプロバイダーであるLevel3（AS3549、現Lumen）にリークしていました。Level3はこのルートを受け入れ、さらに下流のネットワークに伝播し、世界的に重大なネットワーク問題を引き起こしました。
タイプ2：ラテラルISP-ISP-ISPリーク
タイプ2のリークは、あるピアから取得したパスを別のピアに伝達し、2つ以上の連続したピアツーピアのパスセグメントを作成することと定義されています。
以下はその一例です。AS3 → AS4 → AS5はタイプ2のリークを形成しています。
このようなリークの例として、3つ以上の非常に大規模なネットワークが順番に現れることが挙げられます。非常に大規模なネットワーク（VerizonやLumenなど）は相互にトランジットを購入することがなく、パス上に3つ以上のそのようなネットワークが順番に存在することは、多くの場合ルートリークの兆候となります。
しかし、現実の世界では、複数の小規模なピアリングネットワークが相互にルートを交換し、パスオンを行っているケースは珍しくありません。このようなネットワークパスを使用することには、ビジネス上の正当な理由があります。このタイプのルートリークについては、タイプ1ほど心配する必要はありません。
タイプ3、4：プロバイダーからピアへのルーティング、ピアからプロバイダーへのルーティング
この2つのタイプは、プロバイダーまたはピアからカスタマーにではなく、別のピアまたはプロバイダーにルートを伝播するものです。ここでは、2つのタイプのリークを図解します。
前述の例と同様に、GoogleとピアリングしているナイジェリアのISPが誤ってプロバイダーAS4809にルートをリークし、タイプ4のルートリークを引き起こしました。通常、カスタマー経由のルートは他のルートよりも優先されるため、大手プロバイダー（AS4809）はカスタマー、つまりリークしたASNを介してGoogleにトラフィックを再ルーティングしたことで、小規模なISPが過負荷の状態となり、Googleが1時間以上ダウンすることになりました。
ルートリークの概要
これまでRFC7908で定義されている4種類のルートリークについて見てきました。4種類のルートリークの共通点はAS関係、すなわちピア、カスタマー、プロバイダーを使用して定義されていることです。ルートがどこから学習され、どこへ伝播されるかに基づいてASパスの伝播を分類することで、リークのタイプをまとめた表を以下に示します。
ルーティング元 / 伝播先
| Routes from / propagates to | To provider | To peer | To customer |
|---|---|---|---|
| From provider | Type 1 | Type 3 | Normal |
| From peer | Type 4 | Type 2 | Normal |
| From customer | Normal | Normal | Normal |
プロバイダーへ
ピアへ
カスタマーへ
プロバイダーから
タイプ1
タイプ3
正常
ピアから
タイプ4
タイプ2
正常
カスタマーより
正常
正常
正常
表全体は、非カスタマーのASから取得したルートは、カスタマーにのみ伝播することができるという1つのルールにまとめることができます。
注：タイプ5とタイプ6のルートリークは、プレフィックスの再オリジネーションとプライベートプレフィックスのアナウンスメントとして定義されています。タイプ5はプレフィックスのハイジャックとより密接な関係があり、次のステップとして当社のシステムをこのタイプに向けて拡張する予定ですが、タイプ6のリークはこの作業の対象外です。興味のある方は、RFC7908の3.5節と3.6節をご参照ください。
Cloudflare Radarのルートリークシステム
ルートリークについて理解したところで、Cloudflareがルートリーク検出システムをどのように設計したかを説明いたします。
Cloudflareは、自社のシステムを非常に高いレベルから3つの要素に区分しています。
生データ収集モジュール : 複数のソースからBGPデータを収集し、BGPメッセージストリームを下流のコンシューマーに提供する役割を担います。
リーク検出モジュール : 提示されたASレベルのパスがルートリークであるかどうかを判断し、評価の信頼度を推定し、イベントのさらなる分析に必要なすべての外部エビデンスを集約して提供する役割を担います。
ストレージと通知モジュール : 検出されたルートリークイベントへのアクセスを提供し、関連する団体に通知を送信する役割を担います。また、履歴イベントに簡単にアクセスし検索するためのダッシュボードを構築し、イベントの高度な分析のためのユーザーインターフェースを提供することも含まれます。
データ収集モジュール
Cloudflareは、次の3種類のデータ入力を考慮しています。
履歴：過去の特定の時間範囲のBGPアーカイブファイルa. RouteViewsおよびRIPE RISのBGPアーカイブ
準リアルタイム：利用可能になり次第、10～30分程度の遅れで保存されるBGPアーカイブファイルa. RouteViewsとRIPE RISのアーカイブに、定期的に新しいファイルをチェックするデータブローカーを設置（例：BGPKIT Broker）
リアルタイム：真のリアルタイムデータソースa. RIPE RIS Liveb. Cloudflare内部BGPソース
現在のバージョンでは、検出システムのデータソースとして、RouteViewsとRIPE RISのBGP更新ファイルを準リアルタイムで使用しています。データの完全性のために、これら2つのプロジェクトのすべてのパブリックコレクター（合計63のコレクターと2,400以上のコレクターピア）からのデータを処理し、データファイルが利用可能になったときにBGPデータ処理を実行できるパイプラインを実装しています。
データファイルのインデックス作成と処理のために、メッセージの受け渡しで有効になっているKafka機能を備えたオンプレミスのBGPKITブローカーインスタンスと、カスタム同時MRTデータ処理パイプライン（BGPKIT Parser Rust SDKに基づく）をデプロイしました。データ収集モジュールはMRTファイルを処理し、結果を1日あたり20億を超えるBGPメッセージ（毎秒約30,000メッセージ）のBGPメッセージストリームに変換します。
Route Leak Detection
ルートリーク検出モジュールは、個々のBGPアナウンスメントレベルで動作します。検出コンポーネントは、一度に1つのBGPメッセージを調査し、与えられたBGPメッセージがルートリークイベントの結果である可能性がどの程度高いかを推定します。
Cloudflareの検出アルゴリズムは主にバレーフリーモデルをベースとしており、重要なルートリークインシデントのほとんどを捉えることができると考えています。前述したように、バレーフリーモデルでルートリークを検出する際の誤検出を少なくするための鍵は、正確なASレベルの関係を維持することです。これらの関係タイプはすべてのASで公開されているわけではありませんが、公開されているBGPデータを用いた関係タイプの推論に関する研究が20年以上前から行われています。
最先端の関係推論アルゴリズムは非常に正確であることが示されていますが、わずかな誤差でもルートリークの検出に不正確さが生じる可能性があります。このような不適切な結果を軽減するために、CAIDA/UCSDのAS関係データおよび自社で構築したAS関係のデータセットなど、ASレベルの関係を推測するための複数のデータソースを合成します。2つのASレベルの関係上に、プレフィックスごととピアごとのレベルではるかに詳細なデータセットを作成します。改善されたデータセットにより、コレクターピアXによって観察されたプレフィックスPに関するAS1とAS2の関係は何かなどの質問に答えることができます。これにより、ネットワークがプレフィックスと地理的位置に基づいて複数の異なる関係を持つ場合のあいまいさの多くが排除され、システム内の誤検出の数を減らすのに役立ちます。AS関係データセットに加えて、ASヘゲモニーデータセットをIHR IIJから適用して、誤検出をさらに削減します。
ルートリークの保管と提示
各BGPメッセージを処理した後、長期保管と検索を目的として、生成されたルートリークエントリをデータベースに保管します。また、個々のルートリークBGPアナウンスメントを集約し、同じリークASNからの短期間の関連リークをルートリークイベントにまとめています。ルートリークイベントは、Web UI、API、またはアラートなどのさまざまな下流のアプリケーションで利用することができるようになります。
Cloudflare Radarでのルートリーク
Cloudflareは、より良いインターネットを構築することを目指し、インターネットルーティングの監視と保護に関する取り組みも行っています。本日、ルートリーク検出システムをパブリックベータ版としてリリースします。
本日より、Cloudflare RadarのASNページにアクセスすると、そのASに影響を与えるルートリークのリストが表示されるようになりました。Cloudflareでは、リーク元ASが前後左右に1ホップ離れた時点で、影響を受けていると判断します。
Cloudflare RadarのASNページは、**https://radar.cloudflare.com/as{ASN}**から直接アクセスできます。例えば、[https://radar.cloudflare.com/as174](https://radar.cloudflare.com/as174)に移動して、Cogent AS174の概要ページを見ることができます。ASNページには、選択した時間範囲内で現在のASNに関連して検出されたルートリークの専用カードが表示されるようになりました。
また、公開データAPIを使用して、任意のASNに関するルートリークイベントを検索することもできます。当社のAPI は、時間範囲や関連するASによるルートリーク結果のフィルタリングをサポートしています。ルートリークイベントAPIドキュメントページ（新しく更新されたAPIドキュメントサイト上）のスクリーンショットを以下に示します。
ルーティングセキュリティの今後の計画
ルートリーク検出については、計画していることがまだまだあります。Cloudflare Radarには、グローバルビューページ、ルートリーク通知、より高度なAPI、カスタムオートメーションスクリプト、過去のアーカイブデータセットなどの機能が順次搭載される予定です。また、皆様からのフィードバックやご意見は、当社の検出結果の改善を継続し、より良いデータを提供するために非常に重要です。
さらに、当社の顧客ネットワークに限らないグローバルなBGPハイジャック検出、RPKI検証監視、オープンソースツールやアーキテクチャ設計、集中型ルーティングセキュリティWebゲートウェイなど、インターネットルーティングセキュリティの他の重要なトピックについても、引き続き活動を拡大していく予定です。Cloudflareの目標は、ルーティングセキュリティのための最高のデータとツールをコミュニティに提供し、より良い、そしてより安全なインターネットを共に構築していくことです。
同時にRadar roomを当社のDevelopers Discord Server上に開設しました。ぜひルームに参加していただき、話しかけていただければと思います。フィードバックを受け、質問に答えることをチーム一同楽しみにしています。
Cloudflare Radarでは、より多くのインターネットに関するインサイトをご覧いただけます。また、Twitterをフォローしていただくと、Radarの最新情報を入手することができます。