CloudflareのOTC追跡調査で、2つのTier-1ネットワークがBGP経路リーク防止を無効化していることが判明

経路リークはBGPの根深い問題です。トラフィックが本来意図されていない経路に流されてしまうのは、多くの場合、ネットワークが隣接ネットワークとの関係を誤解しているためです。長年にわたり、その修正は手動で行われてきました。オペレーターは各セッションにプレフィックスフィルターやIRR由来のポリシーを手書きで設定しており、このプロセスはエラーが発生しやすく、スケールも困難です。

RFC 9234は、経路リーク防止をプロトコル自体に組み込むことで状況を一変させます。このRFCは、セッション開始時に2つの隣接ネットワークが互いの関係に合意できるようにするBGPロール機能と、カスタマーを超えて伝播してはならない経路をマークするOTC（Only to Customer）経路属性を導入します。OTCを理解するルーターは、オペレーターが作成したポリシーなしで、リークされた経路を独自に拒否できます。

BGPロールとOTCの仕組み

BGPロールは、eBGPセッションにおいて隣接ネットワークとの関係で自分がどこに位置するかを宣言します。ロールは5つあります。プロバイダー、カスタマー、ピア、RS、RS-クライアントです。有効な組み合わせは5つだけです。プロバイダー-カスタマー、カスタマー-プロバイダー、RS-RS-クライアント、RS-クライアント-RS、ピア-ピアです。両側がロールを送信し、その組み合わせが無効な場合、セッションはロール不一致通知（コード2、サブコード11）で拒否されます。

この拒否は機能です。ロールの不一致は、2つのネットワークが互いの関係について意見が食い違っていることを意味し、これはまさに後で経路リークとして表面化する潜在的な誤解の種類です。ハンドシェイクの失敗は、インシデントとしての失敗よりも優れています。

OTCはオプションの推移的経路属性（タイプコード35）で、最初に経路を横方向または下方向に送信したASを記録します。一度設定されると、RFC 9234はそれを変更せずに保持することを要求します。オプションの推移的属性であるため、RFC 9234をサポートしていないルーターでも、破棄せずに転送することが期待されます。

測定と驚き

Cloudflareは、どのピアASがOTC属性を送信するかを監視することでRFC 9234の採用を追跡する方法を開発しました。結果は有望でした。採用は進んでいます。しかし、予期しない発見もありました。2つの大規模Tier-1ネットワークが、転送する経路からOTC属性を除去しているのです。

この除去は、OTCが依存する信頼の連鎖を断ち切るため重要です。Tier-1が属性を除去すると、下流のネットワークはそのTier-1の先で発生したリーク経路を検出して拒否する能力を失います。CloudflareはこれらのTier-1と協議し、OTCの伝播を許可するよう働きかけています。これにより、初期導入者向けの経路リーク防止が可能になります。

これが重要な理由

この発見は、BGPセキュリティメカニズムの段階的展開における重要な課題を浮き彫りにしています。RFC 9234を採用しても、保護は経路上の最も弱いリンクと同じ程度にしか機能しません。Tier-1がOTCを除去すると、ネットワークは必要な経路で属性を受信できず、保護されていると思っていたリークに対して脆弱なままになる可能性があります。

Cloudflareの投稿では、自社ネットワークでBGPロールを有効にする方法と、ロールをASPA検証と一緒に設定することの重要性について説明しています。この2つのメカニズムは相互補完的です。ロールはルーターにどのASPAアルゴリズムを適用するかを指示するため、両方をサポートするルーターでは一緒に展開する必要があります。

完全な投稿には、採用数の詳細な分析と関与する特定のTier-1に関する情報が含まれていますが、要点は明確です。RFC 9234は確かな前進ですが、その実世界での有効性はOTCの普遍的な伝播に依存しています。Tier-1が除去を止めるまで、初期導入者は片翼で飛行しているようなものです。