今や、仕事からプライベートまで、日常で誰もが利用する様々なオンラインサービスへの架け橋となるインターネットには、数々の危険が潜んでいます。2019年6月の1か月間だけでも、このインターネットがどれだけ壊れやすい存在で、そこにどれだけの危険が潜んでいるかが３度の障害で露呈されました。
6月2日、YouTube、G Suite、Google Compute Engineなどのサービスへのアクセスに影響を与えるGoogleによる大規模な障害が4時間続きました。
6月6日、ヨーロッパのホスティングプロバイダからのルートリークにより、WhatsAppなどへのトラフィックがChina Telecomを経由して転送され、その途中でドロップされました。
6月24日の午前7時から9時(東部標準時)の約2時間、ThousandEyesは重大なルートリークを検出し、一部のAWSサービスへのアクセスにも影響を及ぼしていたことがわかりました。
悲劇の序章
６月２４日午前7時頃、ThousandEyesは、世界各国で稼働中のアプリケーションやサービスへの影響を検出しました。図1画面右側にはCloudflare（Cloudflare CDNエッジIPアドレス104.20.91.61を介して）によって提供されているアプリケーションを示しています。そして画面左側の米国、カナダ、イギリスからのアプリケーションへのアクセスの際に深刻なパケットロスが発生していることがわかります。右側の赤いノードは、103.20.91.61宛のパケットがCloudflareへの転送中にドロップされていることを示しています。これらのノードでの100％のパケットロスは、ネットワークの転送プレーンで重大な輻輳が発生していることを示しています。さて一体何が起こっているのでしょうか？果たしてCloudflareのネットワーク内の問題なのか、それとも他の問題なのでしょうか？
図1のパス可視化ビューと同時刻のBGPビューにドリルダウンすることで、興味深い現象がわかりました。図2に示すように、このサービスのIPアドレスを含むCloudflareがアナウンスしたインターネット経路のプレフィックス104.20.80.0/20で、奇妙なパス変更がありました。左から右への通常のパスは画面上部の点線で表示され、 Verizon AS 701（旧MCI Communications）およびLevel 3 Communications AS 3356を通過してCloudflare AS 13335に到達しています。ただし、赤い点線は変更が発生したこと、およびこのパスが現在使用されていないことを示します。下段には、VerizonからAllegheny Technologies社のAS 396531、DQE（以前のMetNet）のAS 33154、およびCogent CommunicationsのAS 174からCloudflareへと、新しいASパスが左から右に見えます。赤い実線は、点線だったパスが置き換わったことを示しています。
この経路の奇妙な点は、本来Allegheny TechnologiesはVerizonとCloudflareの間にあるべきトランジットプロバイダーではないということです。 実際、Allegheny Technology(https://ir.atimetals.com/)はISPではなく、世界的な金属メーカーなのです。 さらに、影響を受けたルートは、この/ 20だけではありませんでした。 図3は、同様のパス変更があった別のCloudflareプレフィックス104.16.0.0/12を示しています。 / 12プレフィックスは約100万個のIPアドレスが対象のため、経路変更されるIPアドレス空間の影響範囲は非常に大きなものでした。 さらに調べると、他のさまざまなCloudflareプレフィックスも経路変更されていることがわかりました。 これらの事象により、ルートリークの疑いが増してきました。
このルーティングの異常性を調査している間に、この疑わしいルートリークがAWSにも影響を及ぼしていることがわかりました。 図4は、画面左のVerizonから最上部のQwest（Now CenturyLink）を通過してAWS East-2 Ohio地域のプレフィックスまでの当初の経路が、ビュー中央に表示されているAlleghenyとDQEを含む新しい経路に変更されたことを示しています。 ルート変更の詳細は、ThousandEyesが提供するスナップショットの共有リンクでご覧ください。
午前7時36分、Cloudflareのステータスページで、「Cloudflare の一部のIPの範囲に影響を及ぼしている可能性のあるルートリークを特定」と発表されました。
他の業界筋からも、大規模なルートリークが発生しているとのレポートがあり、さらにあるレポートでは最大20,000ルートがリークされたと報告されました。
曲げられた真実
その後我々は、これらのルートリーク情報の中からさらに興味深いことに気づきました。このリーク内には、既存の正しいCloudflareへの経路も含まれていました。たとえば、図5はプレフィックス104.20.88.0/21を示しています。これはCloudflareのアドレススペースの一部であり、他のルート変更時に新しくアナウンスされたものです。ただし、このアドレススペースは、既に-104.20.80.0 / 20の上で見た、より大きなプレフィックスの一部としてすでに広報されていました。より細かいプレフィックスがインターネットに広報されるとき、そのルートはより大きなプレフィックスよりも優先されます。第三者のネットワークに対してある特定のルートを広報することは、一般的には許されていません。実際、ある特定プレフィックスの意図的な広報は、犯罪者がサイバーセキュリティを悪用して正規のサービスホストからトラフィックを奪い取ろうとする「BGPハイジャック」の手法とされています。今回のケースでは、世界的な金属メーカーがCloudflareのトラフィックから何かの情報を得たいとは考えにくかったため、悪意のある意図的な広報とはみなされませんでした。しかし、ある特定の細かいルートが複数混在することは珍しいことでした。
ミステリーの結末は？
この時点で、今回のルートリークは、悪意のある意図的な広報とは考えられない特定のルートも含まれた興味深い事象であることがわかりました。では、このルートリークは一体どこからやって来たのでしょうか？我々のルートリーク検出データを調べてみると、インターネット（またはDefault Free Zone - DFZ）が最初にルートリークにさらされた時点では、AlleghenyからVerizonへの広報がきっかけだったことがわかりました。しかし、Allegheny AS 396531がその発生元とはとても思えませんでした。なぜなら、 Allegheny TechnologyはISPではなく、DQEとVerizonの2つのトランジットプロバイダーとのみ接続され、たった1つの/ 24プレフィックスのみを広報していました。基本的に、AS 396531は外向けのInternetへのアクセスを主用途とした企業ネットワークですし、そのルートリークの範囲は自社のプロフィールと一致しませんでした。さらに、AlleghenyがCloudflareへの複数の/ 21ルートを発生させる理由は考えられませんでした。このルートリークされたプレフィックスはVerizonに送信されていたことから、次に我々はAlleghenyのもう一つのアップストリームプロバイダであるDQEに注意を向けました。下の図6に示すように、DQE AS 33154は複数のTier 1 ISPとピアリングしているTier2 ISPであるため、ルートリークの原因の一つとして睨むには意味がありました。
まずは、なぜ細かいプレフィックスが広報されたかを探ってみました。悪意のない細かいプレフィックスが広報される可能性のシナリオの1つは、トランジットプロバイダーが使用するルート最適化ソフトウェアです。このソフトウエアは、インターネットサイトからトランジットプロバイダーのピアリングやバックボーンを経由して流れてくるトラフィックをロードバランスします。このルート最適化を行う主な理由は以下の３つです。
• 一部のリンクへのトラフィック集中の回避により設備投資やアップグレードの必要性を縮小。
• 複数のトランジットリンクの使用によるコストの最適化。
• 顧客へのパフォーマンス向上のためのバックボーンリンク利用効率の改善。
今回のケースに当てはめた場合、ルートの最適化とロードバランシングのためのルーティングの細分化により、 / 20が/ 21に分割された可能性があります。しかし残念ながら、これらのルートがインターネットという荒野に放たれると（例えば、外部へのリークというエラーを介して）、かなりの混乱を引き起こす可能性があるのです。インターネット識者の一部が、BGPルート最適化ソフトウェアとそれがインターネットルーティングの整合性に与えるリスクについて非常に批判的なのはそのためです。実際、NTTのJob Snijders氏は、2017年にこのトピックについて下記の意見を書いています。
「トラフィックエンジニアリングを目的として、意図的により細かいBGP経路を生成するソフトウェアを使用することは、非常に無責任な行動です。これらの経路情報がグローバルDFZに漏れる可能性は拭えないからです。」
DQEとAlleghenyの間のピアリング関係、およびルートリークの範囲、さらに恐らくルート最適化ソフトウェアから生成されたと思われる第３者の特定のプレフィックスの存在から推測すると、DQEがルートリークの元の原因であると我々は考えました。 DQEはCloudflareルートを含むこれらのリークされたルートをAlleghenyにアドバタイズし、そのルートはVerizonを介してインターネットに伝播されました。その結果、Cloudflareや他のプロバイダに向かう大量のユーザートラフィックが、小規模な企業ネットワークを経由することとなり、予想通りの結末となりました。トラフィックのリダイレクトによる大量の輻輳により、重度のパケットロスとサービス中断が発生しました。ユーザーは、Cloudflareエッジサーバーやそれに依存するアプリやサービスにアクセスすることができませんでした。 Cloudflareは、ピーク時に、ルートリークイベントが世界のトラフィックの約15％に影響を及ぼしたことを発表しました。
静かなる毎日を過ごすために
ルートリークは日頃から頻繁に発生していますし、ルーティングの世界は複雑です。ナイジェリアのISP: MainOneの設定ミスが原因のルートリークにより、Googleのトラフィックの一部がグローバルレベルで経路変更されるような人的エラーや、Googleの機能停止で見たように、自動化システムがサービスの中断を引き起こすこともあります。
上流のトランジットプロバイダーからのルートを受け入れたAllegheny社を非難することはできませんが、これらのルートをVerizonに伝播したことにより問題が発生したことは事実です。一方、ここにはルーティングの世界が持つ根本的な問題があるとも言えます。 Verizonが下流の企業ネットワークから大量のルートリークを受け入れて伝播したことにより、個別の問題として解決できた可能性の事象を重大な障害にまで引き上げてしまったのです。
Cloudflareや他のインターネット識者からは、「Verizonは複数あるフィルタリングメカニズムのうちの1つでこの問題を捉えるべきだった。」といったコメントがありました。そして、これらの批評は正しいと言えるでしょう。たとえば、長年にわたるルートフィルタリングの習慣では、ピアから受け入れられるプレフィックス広報の最大数を制限し、そのしきい値を超えた場合にはピアリングセッションをシャットダウンすることです。もう1つの標準的な方法は、インターネットルーティングレジストリ（IRR）に基づいたフィルタリングです。これにより、プロバイダはIRRに登録されているピアからのルートのみを受け入れることになります。特定ルートの検出については、リソース公開鍵基盤（RPKI）を利用することで、/ 21がCloudflareに違法に広報されたことをVerizonが検出し、Alleghenyからのルートの受け入れを拒否することができるのです
しかし、このインターネットのルーティングセキュリティの問題は、Verizonの例だけに留まりません。大規模プロバイダーが小規模プロバイダーからのルートリークを受け入れて伝播することはよくあり、場合によってはアプリケーションやサービスが停止することがあります。その対策としては、インターネット上でのルーティングとIPアドレッシングのベストプラクティスをさらに厳守する必要があります。インターネットの難問はその構造自体がベストエフォートで形作られているボランティア型のネットワークであるということです。 BGPルーティングは運用者間の暗黙の信頼に基づいて運用されており、同業者からの圧力と市場の要求以外では何らかの改善が実施されることは無いのが現実です。
ISPからトランジットサービスを購入している企業やその他の組織は、これらを契約の要件として記載することで、インターネットルーティングのベストプラクティスへの順守を推進することができるでしょう。また、これらの条項を守ることが不可能な場合でも、ISPが要件に繰り返し遭遇することにより、自身のルーティングセキュリティの強化の必要性を認識し市場での優位性を持つことも可能にします。
予測不可能なインターネットでは可視性が重要
「障害」を、その復旧までただただじっと耐えなければならない現象として考えがちです。しかし、それは間違った考えです。確かに、大規模障害によりインターネットやクラウドプレイヤーによる解決を待たなければならない場合があります。しかし一方で、自社のビジネスに影響を与える可能性のある小規模なクラウドおよびインターネット障害も数多く発生しています。たとえばThousandEyesは、ビジネスクリティカルなアプリケーションやサービスの中断の原因となる契約プロバイダの様々な障害を定期的に検出します。そしてこれらの問題の多くには、それぞれ解決策があります。プロバイダに連絡し、問題回避や解決のためのサポートを受けることが先決です。また、SaaS、セキュリティ、クラウドプロバイダは、それぞれ独自の障害を抱える可能性があることを忘れないでください。問題が自社のネットワークなのか、SaaS、クラウドプロバイダ、またはISPのいずれに起因するのか？DNS、ネットワーク、サーバー、またはアプリケーション層のどこの問題なのか？をまず切り分けることが最も重要です。予測不可能なインターネットに接続されたクラウドプロバイダーへの依存度がますます高まっている時代には、自分の世界を超えた先の可視性が不可欠なのです。
