要約

  • draft-ietf-radext-radiusdtls-bis-18では、RadSecの生存判定は接続単位・次ホップ単位である。RADIUSプロキシの背後にあるレルムや資格情報バックエンドの状態までは見えない。
  • Status-Server、TLS/DTLS、keepaliveは正しい局所証拠である。レルム選択、下流処理、再送責任、認可、NASの実行、利用者の結果は別の証拠鎖を要する。

RADIUSの経路を駅にたとえるなら、RadSecクライアントが確認できるのは次の乗換駅までである。その駅の照明が点き、係員が応答し、線路が使えることは確認できる。しかし、その先で分岐する各路線の終点や、終点にある認証データベースの混雑までは見えない。

このたとえで重要なのは、プロキシが単なる中継線ではない点だ。NASから見ればサーバーとして受信し、ホームサーバーから見ればクライアントとして送信する。ユーザー名のrealmを読んで行き先を選び、別のトランスポートへ載せ替え、複数のプロキシを通ることもある。したがって、プロキシ自身が健全でも、一つのrealmだけが停止し得る。

改訂18の第3.8節は、この構造を生存判定の規則に落としている。クライアントはTCP、TLS、DTLSの接続状態だけでなく、RFC 3539のアプリケーション層watchdogも使う。ネットワークスタックが接続不能と判断した場合、D(TLS)に利用可能な接続がない場合、またはwatchdogがdownとした場合に限り、その接続をdownとする。

対象はサーバー名ではなく個々の接続である。複数接続のうち一つが応答しなくても、全接続を停止扱いにしてはならない。負荷分散先の一台だけが故障した場合や、DTLSの共有状態が失われた場合に、正常な接続を巻き込まないためだ。

同時に、この規則からは逆方向の限界も導かれる。一つの接続が応答するからといって、同じピアが持つ全接続、全realm、全バックエンドが正常とは限らない。局所的な成功を集合全体へ拡張する根拠はない。

RFC 5997のStatus-Serverは、その限界を意図的に作る。プロキシまたはサーバーは、このパケットを転送してはならない。宛先IPアドレスとポートの装置が応答するだけであり、User-Nameを見て特定realmへ問い合わせることもない。したがって、応答からrealmの到達可能性は推論できない。

非転送であることにより、通常のAccess-Requestが返らないときでも、最初のプロキシが死んだのか、その先が沈黙しているのかを分けられる。これは強い診断能力である。ただし、分けた後にどの下流要素が故障したかを教える機能ではない。

改訂18はRadSecクライアントにStatus-Server実装を必須とし、サーバーにも応答を求める。RADIUSのIdentifierは256個しかないため、各接続でゼロをwatchdog用に予約することを勧める。TCP keepaliveやDTLS heartbeatは、トランスポート断をより早く検出できる。いずれも「このピアとのこの接続」を測るものであり、「この利用者の認証が完了する」を測るものではない。

運用上の誤りは二方向に現れる。

一つは、特定realmのタイムアウトをプロキシ全体の障害と判断することだ。正常なrealmまで予備プロキシへ移され、新しい接続とキューが増え、二次系が過負荷になる。RFC 3539が指摘するように、エージェントを挟むクライアントはホームサーバーまでのエンドツーエンド特性を直接測れない。ローカルのタイマーだけで全体切替を正当化できない。

もう一つは、watchdogが応答する限り故障realmを同じ経路へ送り続けることだ。観測値は正しいが、その値に与えた権限が過大である。必要なのは、realm判定、選択された下流、ホームサーバーの返答、資格情報ストアの結果、認可、NASの処理を結ぶrealm単位の記録である。

Protocol-Errorも同じhop-by-hopの境界を持つ。現接続で扱えないパケットに対し、クライアントへ再送停止を促し、別経路を試す契機を与えるが、転送されない。先にあるサーバーの判断や利用者へのサービスを証明するものではない。

TLS/DTLSの保護も隣接区間に属する。ピアを認証し、通信を暗号化しても、中間プロキシが次の区間をRADIUS/UDPで送る可能性がある。元のクライアントには、全経路を安全なトランスポートに限定するプロトコル上の手段がない。全区間の機密性が必要なら、各中間者の設定を組織的に保証しなければならない。

トランスポートの境界では再送の所有者も変わる。TCP/TLSは信頼できるトランスポートなので、同一接続でRADIUSパケットを再送しない。UDP/DTLSではアプリケーション再送が必要になる。不信頼区間から受けて信頼区間へ送るプロキシは、上流から来た重複を再び流してはならない。逆方向では、プロキシ自身が下流再送を引き受ける。

上流の信頼接続が閉じたとき、あるいはクライアントがIdentifierを再利用して旧要求を放棄したときは、下流の再送も止める必要がある。つまり、クライアントのtimeout、プロキシの接続状態、下流サーバーのキューは別々の時計で動く。「RADIUS遅延」という一つの数字では、誰がまだ要求を保持しているか分からない。

Accountingでは、その違いがパケット増殖として見える。改訂18は、実際のイベント時刻を示すEvent-Timestampを固定し、再送のたびに更新しないよう求める。Acct-Delay-Timeを更新すると、同じ事実を表す内容の違う新パケットになり、新しいIdentifierが割り当てられ得る。TLSからUDPへ渡すプロキシは、それぞれについて独立した再送列を持つことになる。

附属書A.2では、一つの会計イベントが下流で101、102、103という別IDに展開される。固定時刻は重複認識を助けるが、グローバルな取引IDでもexactly-once保証でもない。イベント、パケット、区間、再送所有者、サーバーの決定を一緒に残す必要がある。

附属書A.1は、暗号検証エラーにも範囲があることを示す。timeout後にIdentifierが再利用され、旧要求への遅い応答が新要求に対して検証されるとResponse Authenticatorは失敗する。この場合は応答だけを破棄し、接続は維持する。パケットの競合を、接続障害や敵対的ピアの証拠へ自動昇格させてはならない。

改訂18は2026年9月30日提出の現役Internet-Draftで、意図する標準化レベルはProposed Standard、期限は2027年4月3日である。RFC番号はまだない。実験的なRFC 6614とRFC 7360を置き換えるという記述は、承認・公開後に初めて効力を持つ。特定の製品、フェデレーション、運用障害の実態を示す資料ではない。

最終的に使える表現は限定的でよい。「この時刻、この接続上で、このRadSecピアは応答した」。サービスを語るなら、要求realm、選択経路、ホームサーバーまたは資格情報基盤、認可判断、NAS実行、利用結果を追加する。最小の共通仕様は隣接者を協調させるが、見えない先の責任まで代行しない。

出典