要約

  • OPSAWGのUCL草案第15版は、グループに基づくACL、時間指定ACE、RADIUS User-Access-Group-IDを定義する。RFC Editorのキューにあるが、まだRFCでも実装結果でもない。
  • 草案はGroup ID文字列からパケット内のタグやフィールドへの対応を規定範囲外としている。同じGroup IDを保存していても、対応表の版が違えばPEPは別の主体やパケットを扱いうる。

監査担当者が最初に見た三つの画面は、すべて一致していた。AAAはユーザーを field-ops に割り当て、コントローラのポリシーも field-ops を参照し、二台のPEPにも同じグループ名が表示されていた。

一致していなかったのは、パケット上の印をその名前へ戻す対応表だった。新しいファブリックではタグ37が field-ops、古いゲートウェイではタグ37が廃止済みの別グループを意味した。人が読む識別子は同一でも、転送面の述語は同一ではなかった。

この事故は、グループ抽象化そのものを否定しない。むしろ抽象化がどこで終わり、実行証拠がどこから始まるかを示す。利用者、端末、アプリケーションが移動する環境で、IPアドレスだけにポリシーを結び付けるのは脆い。Group IDは意図を安定させる。しかし安定した参照から変動するパケットへ到達するには、必ず何らかの分類または変換が要る。

A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control 第15版は、その構造をYANGとRADIUSで表現する。RFC 8519のACLモデルを拡張し、エンドポイントグループ、送信元・宛先Group IDの一致条件、ACEの有効スケジュールを加える。認証を起点とするユーザー中心の場面には、User-Access-Group-ID属性を定義する。

Datatracker上では、OPSAWGのワーキンググループ文書で、Proposed Standardを意図し、IESGへ提出済み、RFC Editorの最終レビュー段階にある。IANAレビューはアクションありで完了している。第15版は2026年4月2日付、10月4日失効予定で、RFC番号はまだない。標準化の進捗は文書の状態を示す。運用ネットワークの一貫性までは示さない。

文字列とワイヤ上の値は別の名前空間にある

草案では group-id は1〜64文字の文字列であり、ユーザー、デバイス、アプリケーションなどの group-type とは別に扱われる。管理ドメイン内で階層的な識別を使えるよう文字列が選ばれている。

しかし、パケットにグループをタグ付けする場合、そのタグはポリシーを設定するGroup IDを正確に複製する必要がない。文字列を封装のタグやヘッダフィールドへどう対応させるかは、草案の範囲外だ。RFC 9638のGroup Policy Optionは例として挙げられるが、普遍的な符号表ではない。

したがって、証拠には少なくとも二つの識別子が要る。制御面のGroup IDと、転送面で観測された値である。そして両者を結ぶ対応表の版、適用ドメイン、発効時刻、発行主体も必要になる。

パケットキャプチャにタグ37があっても、それだけでは field-ops を証明しない。最新の対応表ではそうでも、対象PEPが旧版を使っていたかもしれない。逆に設定画面に field-ops があっても、そのPEPがタグ37を分類できるとは限らない。

この違いを消す設計は、分かりやすいUIを作れる。その代わり、事故時に最も必要な問いへ答えられなくなる。「この装置は、この時刻に、この値を、何として読んだのか」である。

二つの配備方式は別の証拠を求める

草案は大きく二つの運用方式を示す。一つは、SDNコントローラがGroup IDからIPやトランスポートのフィールド、例えば5タプルへの動的対応を保持し、従来型ACLとしてPEPへ配る方式だ。PEPはグループ固有の機能を持たなくてもよい。

この方式では、移動の速度と配布の速度が競合する。利用者の一時IPv6アドレスが変わる、NAT対応が変わる、VMやコンテナが移る。コントローラが新しい5タプルを計算しても、全PEPに有効化される前に旧ルールが残る。構文上正しいACLが、過去の主体を守っていることになる。

もう一つは、デバイス側のPEPがGroup IDを理解し、入ってくるパケットを送信元・宛先グループへ対応させる方式だ。コントローラからの頻繁な更新を減らせる一方、専用のハードウェアやソフトウェアが必要になり、転送性能への影響もありうる。草案はその運用上の取引を範囲外とする。

前者の受領書には、Group ID、5タプル、マッピング版、移動イベント、ACL版が必要だ。後者には、分類器版、タグ対応表、PEP能力、観測されたタグが必要だ。同じ deployed フィールドでは足りない。

第8.3節は、Group IDをパケットフィールドへ対応させるため十分な設定が必要であり、RADIUSなど複数の仕組みを使う場合は、対応が適切に強制されるよう特別な注意が要るとする。標準が「注意」を要求する場所は、運用者が測定可能な不変条件を設ける場所でもある。

RADIUSの値も置かれた文脈で意味が変わる

User-Access-Group-IDはAccess-Acceptに置ける。そこでは認証後に関連するアクセス制御を適用するための値になる。Access-Requestにも置けるが、こちらはサーバへの希望を示すヒントにすぎず、サーバは従う必要がない。

イベント処理がパケット種別を捨てて group_id だけを残せば、クライアントの希望がサーバの決定に変わる。暗号化された正しいRADIUSメッセージでも、取り込み後のスキーマが意味を壊せる。

Access-Acceptに複数の値があれば、ユーザーは複数グループに属する。これは、競合するACLの優先順位を自動的に決める規則ではない。許可と拒否、恒久ルールと時間指定ルールが重なるなら、PEPが用いたACL版、順序、競合方針、最終一致ルールを保存しなければならない。

属性はCoA-Requestにも置ける。セッション中の所属変更は、AAA、NAS、コントローラ、複数PEPの間に過渡状態を作る。最初の応答を全体完了と見なすべきではない。

Accounting-Requestでは、NASが属性を受け取り、ポリシーを強制していることの確認に使える。これは重要な自己申告だが、外部ファイアウォールやサービスゲートウェイの状態を観測したものではない。話者と範囲を付けて保持すべきである。

複数PEPに単一の現在はない

草案のアーキテクチャは複数PEPを明示的に認める。実運用でも、入口NAS、セグメンテーション装置、ファイアウォール、サービス境界が別々の執行点になる。

コントローラの望ましい状態は一つでも、各PEPの状態は 未送信、送信済み、検証済み、インストール済み、有効、失敗、不明 に分かれる。対象PEP集合も版管理しなければならない。インベントリから漏れた装置は、永遠に失敗として数えられないからだ。

中央のAPIが200を返したことは配布要求の受付を示せる。各装置のreadbackは保存状態を示せる。有効化時刻は実行開始を示せる。ルールカウンタは一部パケットの一致を示せる。アプリケーションプローブは特定経路でのサービス結果を示せる。どれも他の証拠を代替しない。

特に否定命題は難しい。「禁止パケットが通らなかった」を一つのカウンタだけで証明できない。代替経路や別PEPを経由する可能性がある。正のテストと負のテストは、観測点と経路を明示して設計する必要がある。

スケジュールはポリシーに時計を持ち込む

YANG拡張はACEに effective-schedule を加える。期間またはRFC 9922の反復規則を利用できる。設定がなければACEは直ちに常時適用される。

時間指定は、保守窓や当番時間だけ権限を与えるのに有効だ。同時に、タイムゾーン、例外日、時計同期、コミット遅延をアクセス制御の一部にする。二台が同じテキストを保存していても、境界時刻に同じルールを有効にするとは限らない。

証拠にはスケジュール版、タイムゾーン識別子、例外集合、時計ソースと健全性、PEPが報告した有効状態が必要だ。コントローラの時刻だけで装置の判断を推定してはいけない。

草案のセキュリティ考慮事項は、スケジュールへの不正書き込みがサービス停止を招きうると述べる。また、読み取りによってルール適用時刻が漏れ、攻撃のタイミングに利用されうるとも述べる。完全性だけでなく機密性も扱うべき制御データである。

形式検証と実装証拠を混ぜない

DatatrackerのYANG Validationは第15版についてエラー0、警告0を示す。これはモジュールの形式に関する良い証拠だ。異なる実装が同じ反復規則やタグ対応を実行する証拠ではない。

第14版から15版の差分は、日付、文言、NVO3の展開、RFC 9907への参照更新などが中心である。配備測定、相互接続試験、性能結果は追加されていない。文書が最終レビューにある事実から、稼働中の一貫性を推論してはならない。

NETCONFやRESTCONFには安全なトランスポートと相互認証が必要で、NACMは操作を制限できる。不正なグループ一覧の変更は存在しないグループを作り、不正な一致条件は許可と拒否を逆転させ、不正なスケジュール変更は可用性を壊す。

しかし、正当に認証された管理者が古い対応表を配る可能性は残る。チャネルの真正性は、内容の新鮮さや対象集合の完全性を保証しない。

最小の対応証明を設計する

第一に、認証された主体とセッション、Group IDを決めた権威、Access-Requestの希望とAccess-Acceptの決定を分けて保存する。複数グループは全て保持する。

第二に、Group IDから実行可能な述語への変換を記録する。5タプルなら入力、版、有効期間、移動トリガー。タグなら名前空間、値、封装境界、対応表版。装置分類なら分類器と入力を残す。

第三に、ACL版、規則順序、競合方針、スケジュールと時刻基準を結び付ける。第四に、必要なPEP集合と各装置の能力を確定する。第五に、PEPごとに検証、インストール、有効化、readbackを保存する。

最後にパケットとサービスを観測する。証拠がない経路は成功に埋めず、不明とする。Heng LuのMinimum Initial Specificationが求めるのは巨大な統一アーキテクチャではなく、この境界を越えるための小さな共通契約だ。

Reality Layersの観点では、Group IDは記号、AAA決定とACLは制御、装置上の規則は実行状態、パケットは観測現実である。同じ文字列が各層に現れても、層を越える証明にはならない。

Running-Code Primacyの試験は、対応表を意図的にずらす。アドレスをローテーションし、VMを移動し、CoA中に一台のPEPを切り離し、スケジュール境界で時計をずらす。安全な実装は、誤差を隠して一つの成功にまとめず、どこまで一致したかを示す。

冒頭の事故で必要だったのは、もっと分かりやすいグループ名ではない。人向けのGroup IDとワイヤ上の値を結ぶ版付き証拠だった。抽象化は変化を扱いやすくする。対応の履歴まで消してよいという意味ではない。

Sources