要約

  • draft-ietf-spring-srv6-security-16 は、RFC 8402 の境界フィルタリング前提が実際に成立する SR ドメインを信頼ドメインとする。物理的な境界ではなく、論理的・運用上の構成である。
  • 同じ管理主体の下でも複数の SR インスタンスは別々であり得る。所有会社、施設、ブランドが同じというだけでは共通信頼を証明できない。
  • 誤ったルール変更や装置能力の限界で境界は fail-open になり得る。SRH の有無だけを見るフィルターも十分ではない。
  • 運用者は、メンバー、範囲、鍵、意図したルール、実装結果、容量、否定試験を結ぶ信頼ドメイン境界マニフェストと実施レシートを持つべきだ。これは Daniel Kade の提案であり、IETF の要件ではない。

組織図から先に消えた境界

別々に設計された二つの SRv6 網を考える。SID の割り当て、コントローラー、事前共有鍵、運用担当、入口と出口の方針は独立している。買収後、経営資料では両方が一社のネットワークになる。すると、間にあるフィルターを外し、「自社トラフィック」として扱う提案が自然に見えてくる。

だが、法的所有権の変更は技術的な認可ではない。片方でセグメント経路を指示できるノードが、もう片方でも同じ権限を持つとは限らない。アドレス計画も装置能力も違うかもしれない。境界を外せば、統合を確認したのではなく、権限を拡大したことになる。

第 16 版 Segment Routing IPv6 Security Considerations は、この混同を明確に避ける。信頼ドメインとは RFC 8402 の境界フィルタリング前提が有効な SR ドメインであり、論理的・運用上の構成であって物理境界ではない。同じ物理ネットワーク上のホストやサーバーも、明示的に制御下へ入れられなければメンバーではない。

さらに、同じ管理主体の下に複数の SR インスタンスがあっても、論理的または運用上は別ドメインであり得るとする。別の信頼ドメインから来る攻撃は、この脅威モデルでは外部として扱われる。企業名は境界の識別子ではない。

Last Call は配備証明ではない

IESG は 2026 年 9 月 3 日に第 16 版の Last Call を開始し、意見期限を 9 月 17 日とした。9 月 9 日の調査時点で、Datatracker は文書を SPRING 作業部会の活動中 Internet-Draft、想定ステータス Informational と記録している。telechat の日付はなく、作業部会 Last Call で出た論点に対応する改訂が必要との状態も残っていた。

したがって 9 月 17 日は承認予定日ではない。第 16 版は RFC でも、特定ネットワークの適合証明でもない。文書自身、新しいセキュリティプロトコルや拡張を定義しないと説明している。ここで重要なのは、既存アーキテクチャが依存する前提を具体化している点だ。

RFC 8402 は、Segment Routing が既定で信頼ドメイン内にあり、境界でトラフィックをフィルターしなければならないとする。また、セグメントリストや SRH を付与するノードは、それを許されたものと仮定する。この強い仮定を企業統合だけで広げれば、経路を操作できる主体も無記録で増える。

信頼を構成する三つの状態

第 16 版は、全境界で正しいフィルターを保つこと自体が難しく、誤りやすいと認める。ルールの削除や調整ミスは流入・流出の漏れを生む。装置によっては、必要なサイズ、複雑さ、プロトコル対応を持たず、想定どおりのルールを置けない。

そこで fail-open が起きる。本来は内部の攻撃者に限られるはずの行為が、境界を定義する装置の一つが方針を実施しなくなったために、外部から可能になる。

信頼には少なくとも三つの状態がある。第一は宣言されたメンバーで、ノード、送信元、コントローラー、役割を定める。第二は意図した制御で、入口、出口、SID と送信元範囲、例外を定める。第三は観測された実施で、各装置に入ったルール、残容量、カウンター、試験結果を示す。

設定の受付成功は第三の状態を保証しない。全エッジが受け付けたか、テーブルが不足していないか、再起動後も残ったか、外部からの試験を本当に落としたかは別に確かめる必要がある。

統合時には差が隠れやすい。一方は SID 用の明瞭なプレフィックスを使い、他方は複雑な割り当てかもしれない。一方は入口でカプセル化し、他方は別の前提に依存する。ACL や TCAM の余裕も同じとは限らない。同じ株主はハードウェアの制約を変更しない。

SRH だけを見ても境界は分からない

SRH を含むかどうかだけで判断する案は単純だが、草案は二つの限界を示す。SID 処理には SRH が必須ではない。一方、SRH を持つパケットがドメインを単に通過している場合もある。存在だけの検査は、必要なパケットを見逃し、正当な通過を妨げ得る。

より重要なのは送信元、宛先、範囲の関係だ。外部から入り、内部 SID を宛先とするパケットは入口で落とす。SRv6 対応ノードでも、ドメイン外の送信元からローカルに実体化された SID へのパケットを落とす。両方が失敗すれば、外部が内部と同じ機会を得る。

この判断には正確なインフラアドレス計画が要る。RFC 9602 は SRv6 SID 専用プレフィックスを用意する。第 16 版は、別のプレフィックスを使うとフィルターが複雑になり、SID プールの経路漏れや人為ミスの可能性が高まると述べる。重要なのは統一形式ではなく、実際の範囲をルールが捉えることだ。

入口で新しい外側 IPv6 ヘッダーと SRH を付与するカプセル化も有効である。内部の転送判断を、信頼されていない送信元が供給したフィールドから切り離せる。ただし、これは境界フィルターの補完であって代替ではない。

一台のノードに二つの鍵ドメイン

RFC 8754 の HMAC TLV は任意で、セグメントリストなど特定フィールドを保護する。第 16 版は、事前共有鍵の手動運用が鍵の使い回しを招くと警告する。そして、同じノード上に存在する場合であっても、異なる信頼ドメインで同じ鍵を使うべきではないと明記する。

物理装置が一つでも、認可境界は二つであり得る。シャーシの共用は鍵共用の根拠にならない。

HMAC が成功しても権限全体は証明されない。鍵を持つ正規ノードが侵害されれば内部攻撃者である。鍵を持たない内部者も、有効期間内に取得した SRH と HMAC を再送できる場合がある。暗号は限定された完全性を示すが、誰がどの経路を指示してよいかを単独では決めない。

統合の便宜で全社共通鍵を使えば、検証成功がドメイン統合の証拠に見えてしまう。後で分離する費用も高くなり、過去の権限を復元しにくくなる。

実在する境界を記録する

必要なのは、版を持つ信頼ドメイン境界マニフェストと、変更ごとの実施レシートである。SRv6 を変更する仕組みではない。「内部」という一語に埋もれた複数の事実を再び分ける運用記録だ。

マニフェストはドメイン ID、許可ノードと役割、入口と出口、SID と許可送信元範囲、コントローラー権限、カプセル化点、鍵そのものではない鍵ドメイン ID を保持する。他ドメインへの通路には、責任者、理由、期限を付ける。

レシートは承認済み意図と装置上の結果を結ぶ。各装置が報告する実装済みルール、利用可能容量、関連カウンター、外部からの否定試験、内部からの許可試験、例外と未完了事項を残す。トポロジー、ソフトウェア、ハードウェア、プレフィックス、役割、鍵が変われば、以前のレシートは古くなる。

この記録は絶対安全を宣言しない。「このドメイン版は、この時刻に、この境界・範囲・装置で試され、これらの例外が残る」という検証可能な主張を作る。

The Policy Mirror が問うのは、効力ある規則がどこに書かれているかだ。ここではメンバー、範囲、フィルター、カプセル化、鍵に分散している。Running-Code Primacy は、それらが実際に同時に働く証拠を求める。Reality, Not Advocacy に従えば結論は限定的だ。草案は特定の運用者を非難せず、ドメイン間 SRv6 を解決もしない。それでも、共通所有が共通信頼を生まない理由は十分に示している。

出典