要約

  • RFC 10065はRADIUSとYANGアクセス制御モデルの間でグループIDを渡せるようにするが、世界共通の名前空間や所属決定者は定めない。
  • AAA、コントローラー、各ポリシー実行点が同じ最新の対応づけを持つかが運用上の検証点になる。

端末がネットワークに接続し、認証される。AAAサーバーはグループIDを返す。その文字列を実際の通信に対する許可・拒否へ結びつけるには、コントローラーやポリシー実行点（PEP）が同じ意味を共有しなければならない。RFC 10065はその流れを表す共通モデルを用意するが、ラベルだけでアクセス判断が完結するとはしていない。

この違いが標準の境界だ。IDはインターフェース間を移動できても、その意味とパケットへの対応づけは各運用環境で管理する。

規格が運べるもの

RFC 10065はIETFのACLモデルを拡張するYANGモジュールを定める。ユーザー、端末、アプリケーションのエンドポイントグループを作り、ACLの送信元または宛先をグループで指定できる。Ethernet、IPv4、IPv6、トランスポート層のフィールドとの組み合わせも可能だ。ルールに期間や繰り返しのスケジュールを付ける機能は、RFC 9922の共通YANGスケジュールモデルを利用する。

ユーザー認証を伴うケースでは、RADIUS属性User-Access-Group-ID（タイプ241.12）を定義した。値はユーザーグループを示す文字列で、Access-Acceptに含められる。Access-Requestに希望値として含めることもできるが、サーバーに受け入れる義務はない。Access-Acceptに複数の同属性があれば、そのユーザーは複数グループに属するという意味になる。

端末のIPアドレスが変わるたびに個別ACLを作り直す代わりに、ネットワークはグループという抽象を使える。ただし、ユーザーとグループと規則の関係を維持する作業そのものがなくなるわけではない。

意味づけは運用環境に残る

RFCの例では、ユーザーはNASで認証され、AAAサーバーがアクセスを判定し、受理した場合にグループIDを割り当てる。次にAAAかNASが、グループIDと一般的なパケットヘッダー属性（5タプルなど）の対応をSDNコントローラーへ通知する。コントローラーはポリシーを管理し、関係するPEPに設定を配布する。

RFC 10065は、その通知を具体的にどう行うかを規定対象外としている。グループ定義も導入ごとに異なる。職務、デバイス証明書、IPアドレス、場所、時刻、企業ポリシーなどで所属を決められ、条件が変われば同じユーザーが別グループに移ることもある。誰がグループの権威者か、変更がどう伝播するか、IDが他の管理ドメインでも同じ意味を持つかは、この規格だけでは決まらない。

YANGのリスト内でIDがグループを区別することと、組織をまたいだ世界的な一意性は別だ。短い文字列が別のネットワークで再利用され、異なる意味を持つこともある。RADIUSが値を正しく運んでも、各PEPが同じ定義を参照している証明にはならない。

時刻が作用する二つの場所

時刻は二つの異なる判断に使える。ACLの有効スケジュールは、ルールがいつ効くかを定める。一方、時刻をユーザーのグループ分類基準にすれば、所属グループ自体が変わる。勤務時間の境目では、ルールの時間条件と所属判定を分けてテストする必要がある。

実装は、コントローラーでIDを一般的なパケットフィールドへ変換して従来型ACLを配る方式と、PEPがグループIDを直接照合する方式に分かれる。直接照合には機器のハードウェアやソフトウェア対応が必要な場合があり、転送性能にも影響し得る。規格はこの選択肢を示すが、すべてのネットワークに適用できる性能評価は提供しない。