要約

  • Cloudflareによれば、2024年6月27日18時51分（UTC）、AS267613が1.1.1.1/32をオリジンとして広告し始めた。
  • その1分後の18時52分、AS262504がCloudflareの正規オリジンAS13335を含む1.1.1.0/24をAS1031経由でリークした。
  • /32のオリジン広告と、/24の不正な経路伝播は別々の事象であり、原因、検証方法、影響経路を一つにまとめてはならない。
  • Cloudflareは、名称を公表していないティア1ネットワークが/32をRTBH経路として受理し、その経路を選んだトラフィックが破棄されたと報告した。
  • /32はRPKI上で無効と判断できる一方、/24は正規オリジンAS13335を保持していたため、オリジン検証だけでは不正なASパスの伝播を止められない可能性がある。
  • Cloudflareが報告した利用者への影響は、1.1.1.1へ到達できない状態または高遅延であり、世界規模のDNS全面停止を証明するものではない。
  • APNICは、この事象が世界全体から一様に可視だったわけではなく、インターネット利用者全体に対する影響はおそらく限定的だったと分析した。
  • RouteViewsとRIPE RISは経路観測の証拠を保存するが、経路を認可したり、ルーターへフィルターを設定したりする権限は持たない。
  • 説明責任は、経路生成、顧客経路の輸出、上流での受理、経路サーバーやトランジットによる伝播、ブラックホールの認可、監視、封じ込め、撤回確認という実際の制御点に沿って配分されるべきである。
  • 本件を象徴する画像は、複数の経路がルーティング制御点へ集まる様子を抽象化した決定論的な編集用ネットワーク図であり、写真、Cloudflare施設、実際の障害経路の再現ではない。

二つの経路事象を分けて考える

本件の分析で最も重要なのは、同じ宛先アドレスに関係した二つのBGP事象を混同しないことである。両者は時間的に近接し、利用者から見れば同じ1.1.1.1の到達性問題として現れ得る。しかし、ルーティング制御面では異なる種類の異常だった。

Cloudflareの報告では、最初の事象は2024年6月27日18時51分（UTC）に始まった。AS267613が、単一のIPv4アドレスだけを示す1.1.1.1/32を自らのオリジンとして広告した。これは1.1.1.0/24全体を対象にした経路ではない。1.1.1.1という一つのアドレスへ、より具体的な経路を提示する広告である。

二つ目の事象は18時52分に始まった。Cloudflareによれば、AS262504が1.1.1.0/24をAS1031経由でリークした。この経路にはCloudflareの正規オリジンAS13335が残っていた。つまり、オリジンだけを見れば正しく見え得る一方、その経路が通過し、外部へ輸出された関係は正規の伝播として認められていなかった。

この違いは単なる用語上の区別ではない。/32では、誰がそのプレフィックスのオリジンを名乗ったか、なぜ受信側がそれをRTBHとして受理したかが中心になる。/24では、正規オリジンを含む経路が、どの顧客・プロバイダー関係から、どの輸出ポリシーを通じて外部へ漏れ、上流や経路サーバーに受理されたかが中心になる。

一方を調べただけでは、もう一方の原因も制御責任も説明できない。「1.1.1.1の経路が誤って広告された」という一文へ縮約すると、オリジン認可、ASパス、顧客輸出、RTBH、最長一致という別個の制御面が消えてしまう。

時系列と確認できる範囲

Cloudflareが示した主要時刻を整理すると、経過は次のようになる。

時刻（UTC） Cloudflareが報告した出来事 分析上の意味
2024-06-27 18:51 AS267613が1.1.1.1/32の広告を開始 より具体的な単一アドレス経路のオリジン事象
2024-06-27 18:52 AS262504が1.1.1.0/24をAS1031経由でリーク 正規オリジンを含み得るが、伝播経路が不正な/24事象
2024-06-27 20:03 Cloudflareがインシデントを起票 サービス運用側で正式な対応が開始された時点
2024-06-28 02:28 /24経路リークの完全解消をCloudflareが記録 /24について、撤回と収束を確認した時点

この時系列から直ちに、18時51分から02時28分まで全利用者が継続的に影響を受けた、と結論付けることはできない。BGP経路は、すべてのネットワークに同一時刻、同一経路、同一選択結果で伝わるわけではない。各ネットワークの接続関係、受信ポリシー、フィルター、RPKIオリジン検証、ローカルプリファレンス、経路集約、より具体的な経路の受理可否によって、可視性と転送結果は変わる。

また、Cloudflareが記録した02時28分は/24リークの完全解消時刻である。公開資料だけから、すべてのネットワークがその瞬間に同じ転送状態へ戻ったと断定することもできない。撤回が送信された時刻、観測装置から経路が消えた時刻、各ネットワークのルーターが選択を更新した時刻、利用者が正常性を体感した時刻は一致しない場合がある。

したがって、責任ある時系列には少なくとも四種類の時刻が必要になる。誤経路が最初に生成された時刻、第三者に観測された時刻、運用者がインシデントとして認識した時刻、そして撤回後の正常状態を複数地点で確認した時刻である。本件の公開資料は重要な節目を示すが、あらゆるネットワークの内部時刻を網羅するものではない。

最長一致が/32を強くする理由

IP転送では、一般に宛先アドレスと一致する経路のうち、最も長いプレフィックス、すなわち最も具体的な経路が優先される。1.1.1.1宛てのパケットについて、1.1.1.0/24と1.1.1.1/32の双方が転送表に存在すれば、/32の方がより具体的である。

この性質により、/32の経路を受理したネットワークでは、その経路が1.1.1.1への転送を強く引き付け得る。ただし、「どこでも必ず/32が選ばれた」と表現するのは正確ではない。インターネット上のすべてのネットワークがIPv4の/32を外部BGP経路として受け入れるわけではなく、長さに基づくフィルターや顧客別の認可が存在し得るからだ。

問題の中心は、/32という形式そのものだけではない。受信側が、どの隣接ネットワークから、どの用途として、どのプレフィックスについて、どの長さまで受理することを許していたかである。通常の到達性経路としては受け入れない長さでも、攻撃トラフィックを捨てるRTBH用途では限定的に受理する設計があり得る。

Cloudflareは、名称を示していないティア1ネットワークが、当該/32を遠隔トリガー型ブラックホール経路として受理したと報告している。その結果、その経路を利用したトラフィックは破棄された。これは公開情報から確認できる範囲であり、そのティア1ネットワークの内部ルーター構成、具体的なコミュニティ変換、顧客認証方式、個別ポリシーを推測してはならない。

RTBHは防御策であり、認可の失敗が危険を生む

RTBHは、サービス妨害攻撃などへの対処で使われる正当な防御手段である。攻撃対象へのトラフィックをネットワーク内の適切な地点で破棄し、回線や周辺インフラへの負荷を抑える。RFC 3882は遠隔トリガー型ブラックホールの考え方を説明し、RFC 7999はブラックホールを示す広く認識可能なBGPコミュニティを定義する。

防御策が危険になるのは、「ブラックホールだから悪い」のではなく、破壊的な転送結果を生む要求を誰から、どの範囲で受け入れるかが曖昧な場合である。受理した経路の宛先に対する正当な権限を送信者が持たなければ、第三者の重要アドレスへの通信を破棄できてしまう。

RTBHの受理には、少なくとも顧客識別、認可されたプレフィックス集合、許可するプレフィックス長、受理可能な隣接関係、適用範囲、保存ログ、期限、撤回権限が必要になる。顧客が所有または正当に運用する範囲だけを対象とすること、通常の経路広告とは別の厳格なポリシーを設けること、過度に具体的な経路を無条件に受け入れないことが重要である。

さらに、ブラックホールを実行した主体には、開始だけでなく終了を管理する責任がある。誰が解除を要求できるのか、誤った要求を誰が停止できるのか、撤回がすべての適用点へ伝わったことをどう確認するのか、設定が残存していないことをどう検証するのかが問われる。

本件から導かれる教訓は、RTBHを避けるべきだということではない。高速で有効な防御制御ほど、その権限境界を狭く、検証可能にしなければならないということだ。

/24リークと「正しいオリジン、誤った経路」

1.1.1.0/24の事象は、/32とは異なる検証上の盲点を示す。Cloudflareによれば、AS262504がAS1031を経由してリークした/24には、CloudflareのAS13335がオリジンとして含まれていた。

RPKIのROAは、特定のプレフィックスについて、どのASがオリジンになることを認可されているか、またどの最大プレフィックス長まで認めるかを示す。受信側はRPKIオリジン検証を使い、観測した経路のオリジンとプレフィックス長をROAへ照合できる。

しかし、オリジン検証が確認するのは経路末尾のオリジン認可である。途中に並ぶすべてのAS間関係や、各ASが顧客、プロバイダー、ピアのどの方向へその経路を輸出してよいかまでは検証しない。

したがって、AS13335という正しいオリジンを持つ1.1.1.0/24が、オリジン検証では有効と評価されながら、実際には認められていない顧客経路や輸出関係を通じて伝播することがあり得る。ここで「RPKIが機能しなかった」とだけ評価すると、RPKIが対象としていないASパス認可まで期待したことになる。

より正確な評価は、RPKIオリジン検証は必要な制御の一つだが、完全な経路認証ではない、というものだ。/32のようにオリジンや最大長が不正な経路を拒否する助けにはなる。一方、正しいオリジンを保持したリークには、顧客別プレフィックスフィルター、明示的な輸出ポリシー、AS関係の役割設定、Only-to-Customer属性など、別の制御が必要になる。

登録情報とROAは証拠であって、実行中の設定ではない

1.1.1.0/24に関する割り当て記録やROAは、誰がその番号資源を正当に管理し、どのASがオリジンとして認可されているかを判断する基礎になる。インシデント後には、観測された広告と認可情報を照合し、どの境界で逸脱が生じたかを再構成するための重要な証拠となる。

しかし、登録データベースに正しい情報が存在するだけでは、ルーターのインポートフィルターは設定されない。ROAが作成されていても、受信ネットワークが検証データを取得し、検証状態をポリシーへ結び付け、無効経路を拒否または低優先度化しなければ、転送結果は変わらない。

反対に、ルーター側で厳格なフィルターを設定していても、参照する顧客プレフィックス台帳が古ければ、正当な経路を落としたり、不正な経路を許したりする。記録の正確性と、実行中の設定の正確性は別々に管理されなければならない。

RFC 6811はBGPプレフィックス・オリジン検証の枠組みを示す。RFC 8893は検証状態をネットワーク内部で扱うための制御文脈を与える。これらは、特定のネットワークが実際にどの方式を導入し、どの経路を拒否し、どの程度有効に運用していたかを証明するものではない。

RFCは設計と運用を評価する共通言語を提供するが、導入証拠ではない。この区別を保たなければ、「標準がある」ことを「制御が稼働していた」ことと誤認してしまう。

経路リーク対策の層

RFC 7908は経路リークを分類し、正当な経路情報が意図されていない方向へ伝播する問題を整理している。RFC 7454はBGP運用上のセキュリティ慣行を扱い、RFC 8212は明示的なインポート・エクスポートポリシーの重要性を強化する。RFC 9234はBGP RolesとOnly-to-Customer属性を定め、AS間関係に応じたリーク抑制の仕組みを提供する。

これらの制御は相互に代替するものではない。

顧客別プレフィックスフィルターは、その顧客から受け取ってよいプレフィックスを制限する。最大長フィルターは、不必要に具体的な経路を抑える。明示的な輸出ポリシーは、何も設定されていない状態を暗黙の許可にしない。BGP Rolesは隣接関係の意味を明示し、Only-to-Customerは経路が顧客方向にだけ伝播すべきことを示す。RPKIオリジン検証はプレフィックス、最大長、オリジンASの整合性を見る。

どれか一つだけを導入しても、すべての誤経路を防げない。むしろ重要なのは、制御が失敗した際に別の層が止められる構成である。顧客が誤って輸出しても最初のプロバイダーが拒否する。そこを通過しても、次のトランジットが不自然な顧客経路を拒否する。オリジンが不正ならRPKI検証が止める。正しいオリジンを含むリークなら関係ベースの制御が止める。伝播してしまった場合は監視と撤回手順が時間的な被害を抑える。

影響について確認できること、できないこと

Cloudflareは、一部の利用者が1.1.1.1へ到達できなかった、または高い遅延を経験したと報告した。この表現は、影響の性質を示す一方、全利用者、全地域、全時間帯に同じ結果が生じたことを意味しない。

1.1.1.1は広く利用されるパブリックDNSリゾルバーのアドレスであるため、到達性の変化は重要である。ただし、その重要性から「世界規模のDNS停止だった」と推論することはできない。利用者のネットワークがどの経路を選んだか、代替リゾルバーを利用できたか、アプリケーションや端末にキャッシュがあったか、影響が断続的だったかは、公開資料だけでは一様に判断できない。

APNICの分析は、本件が世界全体で一様に可視だったわけではなく、インターネット利用者全体に対する影響はおそらく限定的だったとする。この評価は、問題を軽視するものではない。限定的な可視性でも、重要なDNSアドレスへの到達性を第三者の経路広告が変え得たこと自体が、制御上の重大な警告だからである。

Internet Society Pulseは、より広いネットワークおよび国にまたがる観測として本件を記述している。その観測範囲は同資料への帰属を保つ必要がある。APNICの「世界的に一様ではなく、おそらく全体では限定的」という評価と、Pulseの広域観測表現は、必ずしも直接矛盾しない。複数の国やネットワークで観測されることと、世界の利用者全体へ大規模な影響が及ぶことは同じではないからだ。

公開情報からは、正確な影響トラフィック量、利用者数、顧客数、完全な地理分布、すべての転送経路を確定できない。パケットがどの地点で破棄されたか、代替経路へ切り替わったか、遅延だけが増えたかも、個々のネットワーク内部データがなければ完全には再構成できない。

悪意、過失、違法性、隠蔽、法的責任についても、提示された資料は証明していない。技術的な制御責任を分析することと、個人や組織の意図や法的責任を断定することは分けなければならない。

観測システムは証人であって認可者ではない

RouteViewsとRIPE RISは、複数地点からBGP経路を収集し、ある時点でどの経路が見えていたかを保存する。インシデント調査では、経路の出現時刻、ASパス、可視地点、撤回、収束を比較するために不可欠な証拠となる。

ただし、収集装置が経路を観測したことは、その経路を正当と認可したことを意味しない。収集装置は経路を送信したASの契約関係を決定せず、顧客の輸出権限を保証せず、各ネットワークのルーターへ拒否ポリシーを設定しない。

また、ある経路がRouteViewsやRIPE RISに見えたからといって、すべての利用者トラフィックがその経路を通ったとも限らない。コレクターへ提供される経路情報と、個々のネットワーク内部で選ばれた最良経路、実際のデータ面の転送は異なる。

逆に、コレクターで見えなかったことも、どこにも経路が存在しなかった証明にはならない。観測地点、ピア、時間分解能には範囲がある。したがって、経路コレクターの証拠は、サービス側のテレメトリー、トランジットやピアのログ、RPKI検証状態、顧客セッションの更新記録、データ面の到達性測定と組み合わせるべきである。

予防：最初の輸出と最初の受理を狭くする

誤経路が広く伝播してから止めるより、最初の隣接境界で拒否する方が安全である。予防の第一線は、経路を広告する側と、それを最初に受信する側にある。

顧客ネットワークは、自らが外部へ広告するプレフィックスと経路を管理しなければならない。経路生成を自動化する場合でも、認可プレフィックス、許可オリジン、最大長、送信先、コミュニティを変更管理の対象にする必要がある。/32のように破壊的な効果を持ち得る経路には、通常経路とは別の承認と短い有効期限を設けるべきである。

受信プロバイダーは、顧客ごとの認可プレフィックス集合を持ち、IRR、RPKI、契約情報、運用申請を照合してフィルターを構築する必要がある。ただし、外部記録を機械的に取り込むだけでは不十分だ。顧客関係と実際の運用責任を確認し、過度に広い許可や古い例外を除去しなければならない。

経路サーバーやトランジットは、単なる通過点ではない。実際に受信した経路を他者へ再広告できるなら、その伝播ポリシーは結果を変える制御点である。経路サーバーがデータ面でトラフィックを転送しない場合でも、制御面の経路選択と配布を通じて到達性へ影響し得る。

検知：異常な経路をサービス症状より先に捉える

サービス運用者は、DNS問い合わせ成功率や遅延だけを監視しても、原因がBGPにあるかを直ちに判断できない。経路監視には、所有プレフィックスのオリジン変更、より具体的な経路の出現、予期しないASパス、RPKI無効状態、地域別の可視性変化、特定トランジット経由への偏りを含める必要がある。

1.1.1.1のような重要アドレスでは、/24の監視だけでなく、/25から/32までのより具体的な経路が外部で現れた場合に警告する設計が有効である。通常のインターネット経路としては受け入れられにくい長さでも、特殊なコミュニティやRTBH経路として一部ネットワークへ影響する可能性があるからだ。

/24については、オリジンASが変わっていないことだけで正常と判断してはならない。経路が予期しない顧客、プロバイダー、ピアを経由していないか、ASパスが突然伸長または変形していないかを見る必要がある。

サービス側の観測も欠かせない。複数地域からの到達性、DNS応答、遅延、パケット損失、ピア別トラフィック変化を経路イベントと時刻で突き合わせることで、制御面の異常と利用者影響の関連を絞り込める。ただし、相関は因果の完全な証明ではない。内部ログ、隣接ネットワークの記録、撤回時刻を合わせて検証する必要がある。

封じ込め：伝播範囲を限定し、別々に撤回する

二つの事象を別々に扱う原則は、封じ込めでも重要である。/32広告を止めても、/24リークが残っていれば、正規オリジンを含む不正経路が伝播し続け得る。逆に、/24リークが解消しても、RTBHとして受理された/32が残れば、1.1.1.1へのトラフィック破棄が続く経路があり得る。

封じ込めでは、各異常経路について、生成元、直接の受信者、再広告した主体、適用されたコミュニティ、撤回責任者を分けて確認する必要がある。関係するすべてのネットワークを一括して「インターネット側」と扱うと、誰が何を止められるかが曖昧になる。

経路広告元には、誤った生成を停止し、明示的な撤回を送る能力がある。直接のプロバイダーには、セッション単位またはプレフィックス単位で受理を止める能力がある。上流や経路サーバーには、再広告を止め、影響するピアへ通知する能力がある。RTBHを適用したネットワークには、破棄経路の削除と残存確認を行う能力がある。Cloudflareには、ピアおよびトランジットへ正規経路を確認し、利用者影響と経路可視性を追跡する能力がある。

緊急時にセッション全体を遮断する措置は効果が大きい一方、正当な経路まで失わせる可能性がある。プレフィックス単位のフィルター、特定コミュニティの拒否、限定した隣接関係への対応など、より狭い手段を優先し、範囲を拡大する条件を事前に定めるべきである。

復旧：撤回ではなく、正常性の確認までを含める

BGP UPDATEの撤回を送っただけでは、復旧完了とは言えない。上流が撤回を受信し、選択経路を更新し、他のネットワークへの再広告を停止し、データ面の到達性が戻るまでには段階がある。

復旧確認では、少なくとも次を別々に確認すべきである。

  • 1.1.1.1/32が関連する観測地点から消えたこと。
  • 不正に伝播した1.1.1.0/24のASパスが消え、期待される経路へ戻ったこと。
  • RPKI検証状態が期待どおりであること。
  • RTBHによる破棄状態が対象ネットワーク内に残っていないこと。
  • 複数の外部地点から1.1.1.1へ到達できること。
  • DNS問い合わせの成功率と遅延が通常範囲へ戻ったこと。
  • ピア別、トランジット別のトラフィックが不自然な迂回を続けていないこと。

Cloudflareが02時28分に記録したのは、/24リークの完全解消である。この時刻は重要な運用証拠だが、あらゆる外部ネットワークで同時に収束したことを単独で証明するものではない。復旧報告には、どの経路について、どの観測方法で、どの範囲の解消を確認したかを明記する必要がある。

制御点に沿った説明責任

説明責任は、知名度や組織規模ではなく、実際に結果を変えられた制御権に沿って考えるべきである。

制御主体 実際の制御点 求められる証拠
/32の広告元 オリジン生成、プレフィックス長、送信先、コミュニティ 生成設定、変更履歴、BGP更新ログ、認可記録
/24をリークしたネットワーク 顧客経路の受信、輸出方向、隣接関係 インポート・エクスポートポリシー、セッションログ、顧客別フィルター
AS1031など伝播経路上の主体 経路受理、再広告、関係ベースのフィルター 受信時の経路、検証状態、再広告先、撤回時刻
経路サーバー・トランジット 経路配布、参加者別ポリシー、異常検知 ポリシー設定、配布ログ、RolesやOTCの運用状況
名称非公表のティア1 RTBH受理、破棄範囲、解除 顧客認可、対象プレフィックス、長さ制限、適用・撤回ログ
プレフィックス管理者・ROA管理者 登録情報、オリジン認可、最大長 割り当て記録、ROA履歴、変更手続き
Cloudflare 経路・サービス監視、ピア連携、封じ込め、復旧確認 検知時刻、連絡記録、到達性測定、正常化の判定根拠
RouteViews・RIPE RIS 外部観測と履歴保存 観測地点、時刻、ASパス、撤回記録

この表は、法的責任を断定するものではない。誰がどの制御を保有し、どの証拠を提示できるかを整理するためのものだ。ある主体が経路を観測できたことと、それを停止できたことは同じではない。反対に、停止権限を持つ主体が観測やログを欠いていたなら、その運用設計自体が説明責任上の問題となる。

防止から証拠保全までの責任連鎖

本件が示すのは、インターネット経路の安全性が単一の認可機関や単一の暗号検証で成立するものではないという現実である。

予防では、広告元と最初の受信者が認可範囲を狭くする。検知では、プレフィックス所有者、サービス運用者、トランジット、外部コレクターが異なる視点から異常を発見する。封じ込めでは、経路を再広告している主体とブラックホールを適用した主体が、それぞれの制御点で停止する。復旧では、撤回だけでなく、外部可視性とデータ面の正常化を確認する。事後分析では、登録記録、ROA、BGP更新、ポリシー、サービス指標、連絡履歴を時刻順に保存する。

この連鎖のどこか一つに制御が存在しても、他の層が無条件に正しいとは限らない。RPKIが/32を無効と判断できても、受信側が結果を拒否へ結び付けなければ止まらない。/24のオリジンが有効でも、AS関係と輸出方向が不正ならリークは起こり得る。RouteViewsやRIPE RISが異常を保存しても、経路を撤回するのは運用主体である。Cloudflareが症状を検知しても、第三者ネットワーク内部のフィルターを直接変更することはできない。

だからこそ、説明責任は「誰が最初に間違えたか」だけで終わらない。誰が受け入れ、誰が伝え、誰が破棄し、誰が見つけ、誰が止め、誰が正常化を確認したかまで追跡しなければならない。