大規模なルートリークがCloudflareを含むインターネットの大部分に影響
詳細情報
本日10時30分 (UTC: 協定世界時)、インターネットで小規模な心臓発作的な事象が発生しました。ペンシルベニア州北部にある小さな会社が、大手インターネットトランジットプロバイダVerizon (AS701) を経由する多くのネットワークの経路の優先経路になったというものです。今回のトラフィックの集中は、Wazeに例えると、高速道路全体の交通を近隣の一般道に迂回させたのに相当する規模のもので、Cloudflareや他の多くのプロバイダが持つ多数のウェブサイトへのアクセスが不能になりました。Verizonはインターネットでこのようなルートの転送をすべきではありませんし、絶対に起きてはならないことです。その理由をご理解いただくため、以下をお読みください。
過去、我々はこのように稀な不幸な出来事についてブログに書き記しています。今回、被害は世界中で見られました。今回問題が悪化したのは、Noctionの「BGPオプティマイザ」製品が関わっていたためです。この製品は、受信したIPプレフィックスをより小さな構成要素 (more-specificと呼ぶ) に分割する機能を持っています。たとえば、弊社のIPv4ルートである104.20.0.0/20は、104.20.0.0/21と104.20.8.0/21になりました。これは、例えるなら「ペンシルバニア州」の方向を指し示す道路標識が、「ペンシルバニア州ピッツバーグ」と「ペンシルバニア州フィラデルフィア」の方向を示す2つの道路標識に置き換えられたような状態です。ネットワークには、この大きなIPブロックをより小さな単位に分割してトラフィックを誘導するメカニズムがありますが、この分割がそのまま世界に公開されるべきではありませんでした。それが起こってしまったために、今回の大規模な通信障害が発生したのです。
次に何が起こったかを説明するために、インターネットの基礎にある「マップ」の機能について簡単に説明します。「インターネット」は文字通りネットワーク間のネットワークを意味し、自律システム (AS) と呼ばれる複数のネットワークで構成され、これらのネットワークはそれぞれ固有の識別子(AS番号)を持っています。これらのネットワークはすべて、ボーダーゲートウェイプロトコル (BGP) と呼ばれるプロトコルを使用して相互に接続されています。BGPはこれらのネットワークを結合し、たとえば皆さんがお使いのインターネットサービスプロバイダーを介して世界中どこからでも人気のウェブサイトにトラフィックを移動できるようにする、インターネットの「マップ」を構築しています。
BGPを使用して、ネットワークは経路情報、つまり今いるところから目的地への行き方の情報を交換していると言うことができます。こうしたルートは、GPSで特定の都市を検索するために詳細なものであったり、州を指定するために極めて広範囲なものであったりするのです。これが今回の状況を悪化させた理由です。
ペンシルバニア州にあるインターネットサービスプロバイダー (AS33154 - DQE Communications) は、同社のネットワーク内でBGPオプティマイザを使用していた、つまり同社のネットワーク内には、より詳細なルートが多数存在していました。詳細ルートはより一般的なルートより優先されます (たとえば、Wazeではバッキンガム宮殿へのルートは、ロンドンへのルートよりも具体的です)。
DQEは、これらの特定ルートを顧客 (AS396531 - Allegheny Technologies Inc)に公開しています。このルート情報はすべて、他のトランジットプロバイダー (AS701 - Verizon) に送信され、ここから全インターネットに向けて「より良い」ルート情報が伝えられました。これらのルートはより精密で具体的であったため「より良い」ルートとみなされたのです。
リークはVerizonで阻止されるべきでした。ところが、以下で概要を説明するように、ベストプラクティスが多数存在しているのにも関わらず、Verizonのフィルタリング機能が欠如していたために、今回のインシデントはAmazon、Linode、Cloudflareなどの多くのインターネットサービスにまで影響を及ぼす重大なインシデントへと進展していってしまったのです。
つまり、VerizonやAllegheny、DQEといった各社は、突如として、ネットワーク経由でサービスにアクセスしようとする膨大な数のインターネットユーザーに対処しなければならなくなってしまったのです。これらのネットワークはいずれも、急激なトラフィックの増加に対処するのに十分な設備を持っておらず、サービスの中断に陥ってしまったということになります。たとえAlleghenyとVerizonが十分な容量のDQEを持っていたとしても、Cloudflareやアマゾン、リノード等に対して最良のルートを持っているとは決して言うべきではありません。
インシデント発生中、世界中のトラフィックが最大で15%減少。
どうすれば、このリークを防げたのか?
今回のリークは次の複数の方法で防げたと考えられます。
BGPセッションは、受信するプレフィックスのハード制限を設定することができます。つまり、プレフィックスの数がしきい値を超えた場合に、ルーターでセッションのシャットダウンを判断することが可能です。Verizonにこのようなプレフィックス制限が設定されていたら、今回のことは発生しなかったと思われます。このような制限を設けておくことも一つのベストプラクティスです。Verizonのようなプロバイダーでこのような制限を設けるには、一切コストがかかりません。そして、制限を設けていなかったことについては、Verizonのずさんさや怠惰であること以外に、正当な理由はありません。
ほかにネットワーク オペレーターがこのようなリークを防止する手段としては、IRRベースのフィルタリングの実装があります。IRRはインターネット・ルーティング・レジストリの略で、ネットワークでこれらの分散データベースにエントリを追加することができます。他のネットワークオペレーターは、これらのIRRレコードを使用して、各々のピアとのBGPセッション用に特定のプレフィックスリストを生成することができます。IRRフィルタリングが使用されていれば、関係するネットワークのいずれも、問題のあるmore-specificを受け入れなかったでしょう。それにしても衝撃的なのは、IRRフィルタリングが存在し始めてから24年以上が経過している (そして十分なマニュアルも存在している) にもかかわらず、VerizonがAllegheny TechnologiesとのBGPセッションにこのフィルタリングを実装していなかったということです。IRRフィルタリングは、Verizonにとってコスト負担になるものでも、サービスを制限したりするものでもありません。繰り返しになりますが、実装されていなかったのは彼らのずさんさや怠惰によるものとしか言いようがないのです。
昨年弊社が全社で実装、展開したRPKIフレームワークは、この種のリークを防ぐように設計されています。これで送信元のネットワークとプレフィックスのサイズによるフィルタリングを行うことができます。Cloudflareが公開するプレフィックスは、最大サイズ20です。RPKIは、どんな経路でもこのサイズを超えたmore-specificプレフィックスを受信しないよう指示します。このメカニズムが機能するには、ネットワークでBGPオリジン検証を有効にする必要があります。AT&Tをはじめとして多数のプロバイダーが既に各社ネットワークでこれを有効にしています。
Verizonは、RPKIを使用していればアドバタイズされたルートが有効でないことをわかっていたはずで、ルータによってその経路が自動的に切断していたと考えられます。
Cloudflareでは、すべてのネットワークオペレーターでRPKIを今すぐ導入されることをお勧めします！
上記の提案は、MANRS (ルーティングセキュリティのための相互に合意された規範) にわかりやすくまとめてあります
どのようにして解決したか
Cloudflareのネットワークチームは、当事者であるネットワーク、AS33154 (DQE Communications) とAS701 (Verizon) への支援を試みました。いずれのネットワークにも到達が難しかったのですが、これはルートリークが始まったのが、米国東海岸時間の早い時間だったためと考えられます。
弊社ネットワークエンジニアの一人がすぐにDQE Communicationsと連絡を取り、少し経ってから我々は同社の問題解決の担当者と連絡を取り合えるようになりました。電話でやりとりしたDQEの担当者経由で、Allegheny Technologiesへの「最適化された」ルートのアドバタイズを停止してもらいました。協力いただいたことに感謝しています。この後インターネットが安定して通常の状態に戻りました。
残念ながら、この記事の執筆時点 (インシデントから8時間以上) では、Verizonに対して電子メールと電話の両方での連絡を試みましたが、折返しもなく、問題解決のために行動を起こしているかどうかも分かっていません。
Cloudflareでは、このような事象が二度と発生しないことを願っていますが、残念ながらインターネットでは現状、このようなインシデントを防止するためにできることはほとんどありません。そろそろ業界で、RPKIのようなシステムを介したより良いルーティングセキュリティをシステムを採用する時期でしょう。我々は、主要プロバイダーがCloudflareやアマゾン、AT&Tに倣ってルート検証を始めることを希望します。特にVerizonには期待していますし、Verizonからの返信も待っています。
今回の件は我々の管理の及ばない所で発生したものですが、通信障害について皆様に謝罪いたします。当社のチームは誠実にサービスの提供を行っており、今回の問題の特定から数分後に、米国、英国、オーストラリア、シンガポールでエンジニアをオンラインで待機させています。