要約

  • IESGは2026年9月3日、Segment Routing IPv6 Security Considerations第16版の最終意見募集を開始し、9月17日を期限とした。想定はInformational RFCであり、承認済みRFCや導入実績ではない。
  • SID処理にSRHは必須ではなく、SRH付きパケットが当該ドメイン宛てとも限らない。信頼境界はSIDと送信元の範囲、入口と各ノードの遮断、カプセル化の作成者、実機の資源で成立する。

「信頼ドメイン」を場所として扱うと、同じスイッチにつながる端末や同じ会社の別ネットワークまで内部に見えてしまう。第16版は、信頼を論理的・運用的な構成とする。物理的に近いホストでも統制下になければ外部であり、同一管理者の別SRインスタンスも別ドメインになり得る。

SRHだけを検出する規則は、その定義と合わない。SRv6ではIPv6宛先に置かれた一つのSIDだけで処理できる。一方、Routing Type 4を持つパケットが単に通過している場合もある。前者を許し後者を捨てる規則は、安全性と相互接続性を同時に損なう。

必要なのはアドレスに基づく二段の防御だ。境界入口は、外部から来てドメイン内SIDを宛先とするパケットを落とす。各SID実装ノードも、ローカルSID宛てなのに送信元が許可範囲外なら落とす。片方の設定事故をもう片方が封じられる。両方が欠ければfail-openとなり、内部限定と想定した攻撃面が外へ開く。

RFC 9602の専用ブロックは、SID集合を短い規則で表しやすくする。ブロック自体が防御するわけではなく、利用も強制されない。別のプレフィックスを使う自由には、漏れのない棚卸しと複雑なフィルターを維持する責任が伴う。

入口で新しい外側IPv6ヘッダーと任意のSRHを付ければ、内部の命令を信頼ノードが作ったという来歴を得られる。しかし境界判定を誤った外部パケットまで包めば、誤りが内部形式になっただけだ。カプセル化はフィルターの補完であり代替ではない。

HMAC TLVも限定的である。segment listなどを共有鍵で保護するが任意で、手動管理は鍵の使い回しを招き得る。有効期間中の再送が可能で、Segments Leftは保護対象外だ。検証成功は一部フィールドの完全性であって、送信元の許可やfreshnessではない。

中間装置では、active segmentの変化によりIPv6宛先も変わる。SRv6非対応のファイアウォールは最終宛先を誤認し、往復を別フローと判断することがある。拡張ヘッダーを一律に落とせばドメイン内の正当なSRv6を壊し、SRHのないSID宛てパケットは残る。

そして規則はTCAMやACL容量を消費する。VLAN、経路、MAC表と資源を共有する装置では、正しい設計が実機に収まらない場合がある。格納不能時に許可へ倒れるなら、構成管理上は成功でも境界は開いている。

Heng Luの現実層に従えば、Last Call、草案、意図した設定、ASIC上の状態、観測パケット、サービス結果を別々に扱うべきだ。前の記録は次の記録を自動的には証明しない。

出典

  1. IESGの最終意見募集
  2. SRv6セキュリティ草案第16版
  3. Datatrackerの文書記録
  4. RFC 8402：Segment Routingアーキテクチャ
  5. RFC 8754：SRH
  6. RFC 8986：SRv6ネットワークプログラミング
  7. RFC 9602：SID専用ブロック
  8. RFC 9288：IPv6拡張ヘッダーのフィルター
  9. RFC 7872：拡張ヘッダー破棄の測定
  10. RFC 8200：IPv6
  11. RFC 9098：IPv6拡張ヘッダーのセキュリティ
  12. RFC 9099：IPv6運用セキュリティ
  13. RFC 9259：SRHのOAM
  14. RFC 4381：信頼ドメインの運用指針
  15. RFC 3552：Security Considerationsの指針
  16. Heng Lu：Running-Code Primacy
  17. Heng Lu：Minimum Initial Specification
  18. Heng Lu：Reality Layers