要約

  • RFC 4014は、成功したRADIUS Access-Acceptの属性をネットワークアクセス装置が一時保持し、後のDHCPリレー通信にサブオプション7として含める道を設けた。
  • DHCPサーバーはその情報を設定パラメーターの選択に使う。RADIUSの認可、リレーによる運搬、DHCPのアドレス割り当ては別の役割であり、同一の管理ドメイン内での信頼を前提とする。

認証が終わっても、設定はまだ終わらない

端末が無線LANや有線ポートに接続する。802.1X認証は成功し、スイッチやアクセスポイントはネットワークへのアクセスを認める。しかし、通常のIP通信に進むには、端末がDHCPでアドレスなどの設定を受け取らなければならない。アクセス許可の後に、もう一つの判断が残っている。どの設定をこのセッションに渡すのか。

RADIUSとDHCPは、同じ問いに答えているわけではない。RADIUSは認証やサービス認可の情報を返す。DHCPは自身の構成に基づいてクライアントへパラメーターを提示する。RFC 3580は、IEEE 802.1XにはIPアドレスを割り当てる仕組みがないと明記している。Framed-Poolのような属性も、アドレス割り当てを担える認証装置があって初めて意味を持つ。

現場では、認証とアドレス管理が別の機器やチームに分かれていることが多い。RADIUSサーバーは認証を集中管理し、DHCPサーバーはアドレスプールとオプションを管理する。端末に近いNASは、認可されたセッションを知っている一方で、DHCPリレーも兼ねることがある。問題はどちらか一方に権限を集めることではなく、必要な文脈を別々のサービス間でどう渡すかだった。

Ralph DromsとJohn Schnizleinが2005年2月に発行したRFC 4014は、その継ぎ目を標準化した。NASは成功したAccess-Acceptから属性をローカルに保持し、後から端末のDHCPメッセージを中継する際に、その一部を追加できる。RADIUSの判断がそのままDHCPリースになるのではない。次のサービスが判断するための情報を渡すのである。

リレー情報という既存の封筒

この仕組みはRFC 3046が定めたRelay Agent Information、通称Option 82を利用する。リレーは、クライアント自身よりもアクセス網の事情を知っている。要求が入ってきた回線を表すCircuit IDや、遠端装置を識別するRemote IDなどがその例だ。DHCPサーバーはこれらを使い、アドレスや他のパラメーターを選べる。

応答ではDHCPサーバーが中継情報をそのまま返し、リレーがクライアントへ転送する前に取り除く。端末はネットワーク内部の回線名を理解しなくてよい。Option 82は、運用網の内部で必要な情報をリレーとサーバーの間にとどめる仕組みだった。

RFC 4014は、その封筒にコード7の「RADIUS Attributes」サブオプションを加えた。NASはAccess-Acceptに含まれる属性のオクテット列をそこへ入れ、後続のDHCP要求とともに送れる。DHCPサーバーは受け取った属性を設定選択に利用する。リレーは文脈を運ぶが、アドレス割り当ての最終判断を代行しない。

RFCは対象を802.1Xだけに限定しなかった。リレーが別の理由で取得したRADIUS属性も、RADIUSの意味に従う限り運べる。一方、堅牢な相互運用性の範囲は一つの局所的な管理ドメインである。独立した組織やネットワーク間で同じ属性解釈が成り立つとは保証していない。

属性の一覧が示した境界

RFC 4014では、一つのメッセージに同サブオプションを二つ以上入れてはならない。User-NameとFramed-Poolが利用可能なら含めなければならず、その他の属性は任意とされた。アドレス割り当てがRADIUSサーバー側の別状態に依存しないよう、リレーは六つの属性に絞るべきだと推奨された。User-Name、Service-Type、Vendor-Specific、Session-Timeout、Framed-Pool、Framed-IPv6-Poolである。

DHCPサーバーは受け取った値を構成パラメーターの選択に使うが、一覧外の属性は無視すべきとされた。プール名は設定選択に影響しても、DHCPサーバーが管理していない範囲のアドレスを強制的に割り当てるものではない。認可コンテキストとアドレスプールの所有権は別に残る。

サブオプションには大きさの限界がある。RFC 4014は、収まるようにリレーが属性を切り詰めるとする一方、何を優先して残すかを一般化していない。したがってAccess-Acceptに含まれた属性が、必ず完全な形でDHCPサーバーまで届いたとは言えない。どの属性を選び、実際のメッセージで何が送られたかは運用上の観測対象となる。

また、NASは認可属性を後のDHCP要求に結び付ける状態を保持しなければならない。RFCは、その状態をどのようなセッション表で管理するか、再認証やポリシー変更でどう更新するかまでは決めていない。これは標準が曖昧というより、実装と運用が担う範囲を示している。

信頼もリレーを越える

DHCPサーバーがリレー提供の値を設定選択に使う以上、リレーとサーバーの間の信頼は制御経路の一部である。RFC 4014はRFC 3046と同じ信頼関係に依存し、周辺で信頼されたリレーだけを許可する対策に加え、リレーオプション認証やIPsecといった、より深い保護を推奨する。

クライアントにOption 82が見えないことは、内容が本物である証明にはならない。サーバーは誰が送信したのか、経路が保護されていたのかを確かめる必要がある。偽造された値や古い状態が境界を通れば、サーバーのポリシー選択に影響する可能性がある。これは設計から導かれるリスクであり、特定のネットワークで事故が起きたという主張ではない。

「誰がアドレスを決めたのか」に単独の答えはない。RADIUSはセッションを認可し、NASは文脈を中継し、DHCPサーバーは管理するプールから設定を選ぶ。仕様は情報経路を定義できるが、保存状態が最新か、リレーが信頼できるか、選択結果が意図に合っているかを証明しない。実際の答えは、動作中のリレーとDHCPサーバーに表れる。

2023年の拡張は別の仕組みも加えた

2023年のRFC 9445は、新しいサービスで必要となる設定項目に対応し、RFC 4014を更新した。以前はRADIUS Attributesサブオプションに含める属性の集合が固定だった。RFC 9445はこれをIANAの許可属性レジストリーへ移し、専門家の審査を通じて追加できるようにした。これはサブオプション7の許容範囲の拡張である。

同時に、RFC 9445はDHCPオプションを運ぶ別のRADIUS属性、DHCPv6-Options（245.3）とDHCPv4-Options（245.4）も定めた。暗号化DNSの例は想定用途を示すが、普及率を示すものではない。これらはRFC 4014のサブオプション7とは別の経路である。現行のIANA登録は許可された値を記録するのであって、運用者が実際に使っていることまでは証明しない。

この歴史の核心は、RADIUSがDHCPを置き換えたことではない。二つのサービスの境界を越えて、必要な認可文脈を渡しながら決定権を分けておく方法を作ったことだ。サービスが広がれば許可範囲を拡張できるが、誰が何を信頼し、どの設定を適用するかは局所運用に残る。

Lu HengのNote 64を後からの分析視点として用いると、RFC 4014は共通の最小インターフェースを定め、先の選択を管理ドメインに残す例と読める。Note 65は、文書が公開されたこととコードが実際にその通り動くことを区別させる。これらはRFCの設計原因や史料ではない。最後に問うべきなのは、稼働中のNAS、リレー、DHCPサーバーが正しい文脈を渡し、予期したとおりに判断しているかである。

出典