要約
- Disconnect-ACK と CoA-ACK は単なる受信通知ではない。NAS が、選択した全セッションについて切断または認可変更を成功させたと表明するプロトコル上の実行証拠である。
- その証拠には観測範囲がある。要求者の権限、選択集合の正しさ、課金の収束、下流状態、実トラフィックは、それぞれ別の記録で確かめなければならない。
運用画面の緑色は、しばしば主語を消す。「成功した」と表示されても、誰が何を観測してそう述べたのかが残らない。RFC 5176 を正確に読むと、ACK の主語は NAS であり、対象はその NAS が選択したセッションに対する定義済みの状態遷移である。
Disconnect-Request は進行中のセッションを終わらせ、CoA-Request は認可内容を変更する。前者への ACK は、関連コンテキストを破棄し、選択されたセッションが接続状態ではないという表明である。後者への ACK は、要求された認可変更が成功したという表明になる。ここには実行意味があり、「パケットを受け取っただけ」と扱うべきではない。
強い証拠にも境界がある
NAS が正しく応答しても、その外側の仕組みが同時に収束するとは限らない。Accounting-Stop が遅れることも、ポリシー複製に時間差があることも、下流装置が別の状態を保持することもある。利用者のパケットが実際に止まったかは、別の観測点が答える問題である。
したがって必要なのは ACK を疑って無価値にすることではない。その主張を、セッション表、課金記録、ポリシー状態、トラフィック計測と時刻で結び、どこまで一致したかを示すことである。各層の証拠が自分の観測範囲だけを語れば、不一致も原因調査の材料になる。
ACK より前に選択があった
NAS は User-Name、NAS-Port、Framed-IP-Address、Calling-Station-Id、Acct-Session-Id、Chargeable-User-Identity などの属性から対象セッションを探す。結果はゼロ、ひとつ、複数のいずれにもなり得る。
一致がなければ NAK となる。複数一致すれば要求はその全体に適用される。複数セッションを扱えない NAS は Error-Cause 508 を返す。つまり選択属性はログ用の付記ではなく、変更の影響範囲そのものである。
実行は原子的でなければならない。CoA では、選択した全セッションに全変更を適用できる場合だけ ACK を返す。ひとつでも失敗すれば NAK とし、何も変更しない。切断も同様に全件かゼロ件である。
この規則は部分適用を防ぐが、対象集合の誤りは直さない。三つを誤って選んだ要求を、NAS が三つすべてに正確に実行することはあり得る。ACK は真実でも、意図は満たされていない。だから監査には要求属性だけでなく一致件数と各セッション ID が要る。
NAK が次の処理開始を示す場合
Service-Type Authorize Only では、直感がさらに裏返る。NAS が要求を受け入れて新たな認可照会を始める場合でも、CoA-ACK を返してはならない。CoA-NAK と Error-Cause 507 Request Initiated を返し、その後 NAS 自身が Access-Request を送る。最終結果は後続の Access-Accept または Access-Reject が決める。
この NAK は単純な失敗ではない。後続処理の開始を確認する中間証拠である。同時に、最終成功でもない。507 と Access 交換の相関を失う監視系は、標準が分けた二つの状態をひとつに潰す。
他の Error-Cause にも固有の意味がある。セッションなし、管理上禁止、プロキシで経路なし、資源不足、未対応属性、複数選択未対応は、対処すべき場所が異なる。検証済み errata は、200 番台の成功原因が ACK だけに閉じないこと、ACK にも Error-Cause が入り得ることを明確にしている。
認証済みの相手にも権限境界がある
従来の UDP 方式では、送信元から共有秘密を選び、MD5 ベースの RADIUS 構造で要求を認証する。Event-Timestamp、再送時の同一性、重複検出は鮮度を別に扱う。それでも共有 NAS では、ある事業者の正当なクライアントが別事業者の加入者を変更してよいとは限らない。
RFC 9765 は、ネゴシエートされた TLS/DTLS 上の RADIUS/1.1 にこの仕組みを更新した。保護チャネルが旧来のパケット認証を置き換え、Message-Authenticator は送信しない。暗号方式が変わっても、どの主体がどの realm と利用者を変更できるかは認可の問題として残る。
RFC 8559 のプロキシ機構も境界を保つ。Operator-Name と不透明な Operator-NAS-Identifier により元の NAS へ戻る経路を作れるが、その値は加入者セッションの一意な識別子ではない。正しい装置へ届くことと、装置内で正しい状態を選ぶことは別である。
最小限のプロトコルは中央集権的な万能証明を作らない。要求者、プロキシ、NAS、課金系、観測系がそれぞれの事実を残す。その分業を可視化することが、実装の自由を保ちながら責任を追跡する方法である。
出典
- https://www.rfc-editor.org/rfc/rfc5176.html
- https://www.rfc-editor.org/rfc/rfc5176.txt
- https://www.rfc-editor.org/info/rfc5176
- https://datatracker.ietf.org/doc/rfc5176/
- https://datatracker.ietf.org/doc/rfc5176/history/
- https://datatracker.ietf.org/doc/rfc5176/references/
- https://www.rfc-editor.org/errata_search.php?rfc=5176
- https://www.iana.org/assignments/radius-types/radius-types.xhtml
- https://www.rfc-editor.org/rfc/rfc3576.html
- https://www.rfc-editor.org/rfc/rfc2865.html
- https://www.rfc-editor.org/rfc/rfc2866.html
- https://www.rfc-editor.org/rfc/rfc2869.html
- https://www.rfc-editor.org/rfc/rfc5080.html
- https://www.rfc-editor.org/rfc/rfc8559.html
- https://www.rfc-editor.org/rfc/rfc9765.html
- https://www.rfc-editor.org/rfc/rfc6614.html
- https://www.rfc-editor.org/rfc/rfc7360.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
