Cloudflareは、RFC 9234標準がどの程度普及しているかについて分析を発表した。同標準は、BGPプロトコルにおける経路リークの抑制に用いられるもので、同社ネットワークとの交換セッションのデータと、インターネット上でテスト経路を広告した実験の結果に基づいている。同社は、67ネットワークが直接送信する経路にOnly to Customer（OTC）属性を追加していることを確認した。一方で、複数のネットワークが経路の転送中にこの属性を削除していることも発見した。これにより、対応ネットワークがリークを検出して拒否する能力が低下する。
BGP経路リークは、あるネットワークがプロバイダーまたはピアから学習した経路を、インターネット経路に想定される商業関係や階層構造に反して、別のプロバイダーまたはピアへ広告すると発生する。これにより、データトラフィックが、そのトラフィックを処理するよう準備されていない、またはそもそも転送を許可されていないネットワークを経由する可能性がある。その結果、遅延の増大、パケット損失、あるいはより広範な障害が発生するおそれがある。
リーク防止ルールをプロトコルへ移行
従来の保護メカニズムでは、各運用者がプレフィックスフィルターやIRRレジストリから抽出したポリシーなどの手動設定を行う必要があり、各BGPセッションの関係を正確に定義しなければならない。RFC 9234は、BGP RolesとOTC属性という2つの要素によって、この負担の一部をプロトコル自体に移すことを提案している。
BGP Rolesは、Provider、Customer、Peerなど、eBGPセッションにおける隣接者間の関係を定義する。また、インターネットエクスチェンジポイントのルートサーバーに関連するRSおよびRS-Clientも定義する。両者が互換性のない役割を送信した場合、セッションはRole Mismatch通知によって拒否される。これにより、セッションが継続し、後になって実際のリークとしてエラーが現れる事態を防ぐ。部分的な導入の場合は、一方の側だけが役割を送信してもセッションを動作させることができる。ただし、相手側がいかなる役割も通知しないセッションを拒否する厳格モードを運用者が有効にしている場合は除く。
OTC属性には、経路が階層を上向きに移動するのをやめ、顧客へ向けて移動し始めた時点で、最初に属性を追加した自律システム番号が記録される。いったん属性が存在すると、その経路はプロバイダー、ピア、またはルートサーバーへ移動すべきではない。また、対応ルーターは、OTCを含む経路がその転送を許可しない関係から到着した場合、その経路を拒否できる。これにより、各セッションについて運用者が個別にポリシーを記述することだけに依存せず、役割を設定した後は防止を自動化できる。
Cloudflareは実際に何を測定したのか
Cloudflareは自社ルーターからのBMPデータを使用し、3か月間にわたって直接隣接するネットワークから受信したOTCの値を監視した。属性の値が隣接システムの番号と一致する場合、そのネットワークを準拠候補とみなした。この方法により、複数のネットワークを通過した経路を分析する際に生じる曖昧さが軽減される。これらの測定では、67の自律システムがOTCを追加していた。また、ルートサーバーは新機能をより迅速に採用する可能性があり、個人によって運用されるネットワークの一部も結果に目立つ割合で含まれていた。
一方、RouteViewsとRIPE RISの公開RIBデータを分析した結果は、より控えめなものとなった。Cloudflareは、送信時にOTCを追加するネットワークと、受信時に欠落した値を補完するネットワークを区別しようとした。その結果、属性を追加している可能性があるネットワークを18、属性を補完している可能性があるネットワークを20特定した。直接隣接するネットワークの結果と統合すると、RFC 9234に準拠している可能性があるネットワークは36となった。同社は、この方法では経路数や隣接ネットワーク数が限られているネットワークを見落とす可能性があると説明している。
OTCを削除したネットワーク
Cloudflareは、同社の拠点から値13335を含むIPv4プレフィックスとIPv6プレフィックスを1つずつ広告し、OTCの伝播をテストした。その後、RIPE RISとRouteViewsのデータ、およびローカルBMPデータを用いて、広告と撤回の際のBGPメッセージを分析した。第1段階では、属性を削除している6つの自律システムを特定した。その中には、ティア1ネットワークのGTT、AS3257とArelion、AS1299が含まれていた。さらに長い経路の分析を続けた結果、OTCを削除する追加の9ネットワークが特定された。
実験では、IPv4のAS_PATH経路の33.1%、IPv6経路の17%で属性が欠落していた。OTCを失ったIPv4経路の96.6%、IPv6経路の92.9%には、GTT、Arelion、またはその両方が含まれており、その大部分をArelionが占めていた。次ホップがいずれか一方のネットワークである経路を調べたところ、Cloudflareは、GTTが一貫して属性を削除していた一方、該当するサンプルではArelionがIPv4経路の71.4%、IPv6経路の40.7%で属性を削除していたことを確認した。
Cloudflareによれば、両ネットワークは、OTCの削除がBGPエラーの処理に関連するインシデントを受けて生じた防御的な慣行の一部であることを確認した。公開された結果によれば、GTTの設定は引き続き属性を削除していた。一方、ArelionはCloudflareとの連絡後、属性を保持するようになった。この変更は、テスト経路を後から分析することで確認された。
ネットワーク運用者にとって実際に何が変わるのか
結果は、RFC 9234の採用が、ルーターがこの機能をサポートしているかどうかだけでなく、経路上の中間ネットワークがオプションの属性を引き続き転送するかどうかにも左右されることを示している。中央に位置するネットワークでOTCが削除されると、その後ろを複数ホップ離れて通過する対応ネットワークが、本来なら防止できた経路リークを検出できなくなる可能性がある。
Cloudflareによると、Junos OSおよびJunos OS EvolvedはRFC 9234をサポートしており、Cisco IOS XRのサポートはバージョン26.4.1で予定されていた。一方、Arista EOS、Nokia SR OS、Huawei、Extreme SLX-OS、RouterOS、BIRD、OpenBGPD、FRR、ArcOS、GoBGP、ExaBGPなど、その他の実装も同社の表に掲載されているが、サポート状況は完全には特定されていない。同社は、機能を利用できる運用者に対し、メンテナンス時間中にBGP Rolesを段階的に設定するよう推奨している。導入にはBGPセッションの再設定が必要になるためである。また、Cloudflareは自社のグローバルフリート全体に設定を段階的に展開し始めており、採用状況のデータをCloudflare Radarのルーティングセクションで公開する予定である。