NW屋的新幹線通勤日記(3ヶ月限定名称)

ネットワークを専門にする元社内SEの日常とITネタ諸々を綴って行きます。

OCN通信障害がGoogleの誤経路制御情報送信だった件

 こんばんは。昨日(日付が変わってますから一昨日ですね)は残業&呑みの関係で情報収集は行っていたのですが、ブログ記事を書くには至りませんでした。

 若干乗り遅れ気味ですが、本件について少し書いてます。多くのメディアで取り上げられていましたが、その中からいくつかの記事のURLを記しておきます。ITproとInternet Watch朝日新聞デジタルです。

itpro.nikkeibp.co.jp

internet.watch.impress.co.jp

www.asahi.com

 原因はGoogleが誤った経路制御情報を流してしまったことで

  当初は「インターネットにつながらない」「OCNで障害が起きてることが原因?」というような話が出ていました。こうなると、ISP内部の問題か?と考えてしまいます。KDDIでも同様に影響が出ていたとの情報もありました。その後、「うちには問題はないです」という宣言が出てました。

 今回の場合は、OCN(NTTコミュニケーションズ)もKDDIも被害者ですので、「うちは悪くない」と言いたくなるのは理解できます。「つながらないのはお前のところの問題なんじゃないか!」と責められていたのでしょう。「弊社の障害ではありませんが御迷惑おかけしております」と最初に言っておければ、また違ったのかなと思ったりもしました。

 「ネットワークの集合体」であるが故の問題でしょうか

 今回の問題は上記記事にもありますように、Googleが正しくない経路情報をうっかり流してしまったために、それを受け取ってしまったNTTコミュニケーションズなどの他の事業者のネットワークがとばっちりで巻き添えを喰らってしまったというところが真相のようです。(かなり荒っぽい言い方ですが。<(_ _)>)

 インターネット自体は分散管理である以上、このような事態が発生する可能性はゼロではありません。送信先サーバにパケットを届けるためには複数のルータ(ネットワーク)を経由して行くことになります。よく言われる「バケツリレー」ですね。ルータ同士が相互接続していて、ルータはルーティングテーブル(次はどのルータにパケットを転送するかを示す表)を持っていて、その内容を参照して転送を重ねて最終目的地である機器に転送します。

 基本は上記の仕組みです。事業者から他の事業者への経路制御をBGP(Border Gateway Protocol)を使って行います。その際に「送信された経路制御情報は正しいもの」という前提で流しますし、受け取ります。ここに問題が2点あります。

  • 送られてきた経路制御情報が正しく設定されたものなのか?
  • 送られてきた経路制御情報が正当な(本来の)相手からのものなのか?

 今回の場合は前者ですね。後者を弾くための方法論として、ITproの以下の記事にある「経路ハイジャック」について書かれています。悪意の第三者が偽経路制御情報を流しても受け取らないようにする仕組みを検討中だそうですが、しばらく時間がかかりそうだということのようです。

itpro.nikkeibp.co.jp

 「誰が送ってきたか」は検証できても、「情報の中身の正当性」までは…

 送信元の真偽を検証することは出来るかもしれませんが、変更された経路制御情報が正しいかどうかを送信元以外の第三者がどうやって確認出来るのか?という疑問が残ります。機械的に「こっちの事業者に転送してね♪」というわけには行かないところが難しいところです。政治的・経済的要素も踏まえて経路制御情報を定義する以上、そのあたりの事情をルータに忖度しろというのは酷ですよね。(^^;

 結局は「事業者担当の方々は細心の注意を払って下さいね」しかないんでしょうね。BGPもDNSも階層構造になってますので、上流であるTier1の事業者がやらかしてしまった場合は、下流に属する側はどうすることも出来ないんですよね…。今回のようにTier1同士でつながっている他のTier1事業者がやらかしてしまった場合、その事業者以外のTier1事業者も「うちが原因ではありません」というしかないことが改めてはっきりしましたね。(^^;

 このへんはインターネットの構造の根幹に関わるお話ですから、如何ともし難いというところでしょうか。

 今回の障害について、togettterにまとめが載っていましたので、こちらも御参考まで。

togetter.com