要約

  • draft-ietf-radext-connectinfo-00 は、送受信レート、RSSI、フレーム損失・再送、Global Operating Class、集約条件を RADIUS Connect-Info で表す ABNF を定める。NAS の主張を解析可能にするが、無線測定そのものは検証しない。
  • Access-Request の瞬時値と Accounting-Request の期間集計は異なる証拠である。メッセージ種別、対象サンプル、アルゴリズム、窓、重み、周期を落とせば、同じ単位の数字から誤った比較が生まれる。
  • RADIUS/TLS は経路を保護できるが、測定の真偽、用途の正当性、認可ロジック、適用先、利用者の体験を保証しない。各段階に独立した受領証が要る。

フェデレーションでは構文より先に責任が分かれる

ローミングでは、無線設備を運用する Access Network Provider と、資格情報を検証する Identity Provider が異なることがある。前者が RSSI やビットレートを観測し、後者がその値を認可の補助に使う。値は組織境界を越えるが、アンテナ、ドライバ、サンプリング手順は越えてこない。

RADEXT 草案の本文、HTML、XML は、この受け渡しに明確な文法を与える。RFC 2869 が RADIUS 属性 77 として Connect-Info を定義し、先頭に接続速度を置くよう勧告した後、Wi-Fi 実装は 802.11 世代、信号、チャネルなどを複雑な文字列に追加してきた。

新しい ABNF は TxBitRate、RxBitRate、RSSI、FrameLoss、FrameRetry、Global-OC を名前付きで扱う。RFC 6158 は、代替手段がある場合の複雑なデータ型を慎重に扱う。草案は、新しい複雑型を発明するのではなく、既存実装の形式を定義して拡張すると説明する。互換性のための現実的な選択であり、測定機器の同等性を証明する選択ではない。

Identity Provider が受け取るのは NAS の陳述である。どのフレームが対象か、複数リンクをどう扱ったか、値はいつ更新されたか、機器はどう丸めたかは、文字列だけから復元できない。解析成功は送信者の測定工程を監査したことにはならない。

瞬時値と会計期間を同じ品質スコアに入れない

草案は MIN、MAX、AVG-LIN、AVG-EXP、ACC を定義し、秒または分の時間窓を付けられる。指数平均には重みと任意のサンプル周期も記載できる。集約情報は付加的な表示ではなく、数値が何を表すかを決める一部である。

Access-Request が送られる接続初期には、利用できるフレームが少ない。送受信レートと RSSI は瞬時値でもよく、その場合 AGGR を含めるべきではない。一方、Accounting-Request の期間集計では、レートに最大、RSSI に平均、損失と再送の比率に累積を用いることが推奨される。

瞬間の 600 Mbps と、10 分のうち一度だけ現れた 600 Mbps は、同じ数字でも同じ状態ではない。どちらも継続スループットを証明しない。データ基盤がメッセージ種別と窓を捨てて一列に並べると、存在しなかった比較可能性が後から生成される。

RSSI の表記にも互換性上の事情がある。41 と -41 はともに -41 dBm と読まれる。符号差を正規化するのは正しいが、異なる製品のアンテナチェーン、サンプル頻度、平均処理、校正まで一致するわけではない。

チャネル番号も単独では 6 GHz を含む帯域を一意に定められない。Global Operating Class が必要な文脈を補い、multi-link operation では複数回現れ得る。中継システムが反復値を一つに潰せば、構文は保存されても無線構成は失われる。

未知のキーは将来性であって、判断権限ではない

拡張可能なキー・値構文により、将来の名前を旧受信側が直ちに拒否せずに済む。ただし、未知のキーには単位、重複規則、サンプル範囲、集約意味、バージョン合意がまだない。「構文上は有効、意味は未合意」という状態を監視できなければ、新機能が静かに認可スコアへ混入する。

証拠の順序を分けると、責任も分かる。無線部が観測し、実装がサンプルを選び、アルゴリズムが変換し、NAS が特定の RADIUS メッセージで主張する。安全な経路が届け、サーバーが解析・正規化し、制度上の目的と保持条件を確認した後で、認可規則が評価される。応答がアクセス網で適用され、その後に初めて無線状態とアプリケーション結果を測れる。

途中の成功は後段を代行しない。正しいパースは新鮮なサンプルを証明しない。Access-Accept は正しいセッションへの設定適用を証明しない。関連付け成功は、通話や動画が使えることを証明しない。

暗号化は誤った観測も完全なまま届ける

草案は Connect-Info を安全な経路だけで送るよう推奨し、TLS で保護した RADIUS を例示する。RFC 6614 は RADIUS/TLS、RFC 7360 は RADIUS/DTLS を規定する。相手を認証し、転送中の盗聴や改変を抑えられるが、古い RSSI や誤集計された再送率の内容までは訂正しない。

ANP と IDP の間には、証明書だけでなく意味と用途の協定が要る。どのパラメータを、どの測定・集約定義で、何の目的に使い、未知値をどう扱い、いつ削除し、誰に開示できるかを決める必要がある。草案は認可技法を定義していない。しきい値、履歴、派生指標は例であり、標準化された妥当性判定ではない。

RSSI は名前を持たずに行動履歴へ変わる

作業部会版はプライバシーを独立節とし、RFC 6973 の概念を使う。RSSI はアクセスポイントの既知位置、時刻、持続的なアカウントと組み合わされると、存在、近接、移動を推測できる。属性自体に利用者名や MAC アドレスがなくても、識別可能な記録の一部になり得る。

草案はデータ最小化、必要以上の保持回避、持続識別子との結合回避を勧告する。また、利用者への通知や同意の仕組みは定義せず、必要性は運用者の方針と適用法に委ねると明記する。したがって、規格どおりの文字列であっても、目的外利用や過剰保持まで正当化されない。

最小化は削除期限、識別情報の分離、結合操作の記録、目的別アクセス制御として実装されなければならない。「運用目的」という説明だけでは、将来の横断分析を止められない。

作業部会採択は導入台数の裏付けではない

凍結した Datatracker API、文書ページ、履歴 は、00 版を 2026 年 9 月 24 日付の RADEXT 作業部会 Internet-Draft として記録する。本文ヘッダーの intended status は Informational だが、担当 AD、shepherd、telechat はなく、表示上の RFC status も null である。RFC ではない。

前身の draft-grayson-connectinfo-10 には、概念実証と 17,000 台のアクセスポイントを挙げる非規範的な実装節があった。採択版はその節を削除した一方、安全経路と相互接続方針を追加し、プライバシーを分離して最小化、unlinkability、通知・同意の範囲を明確化した。旧記述の削除は導入が存在しなかった証明ではないが、現行文書がその台数を証拠として提示していないことは明確である。

出典と限界

技術的根拠は現行の テキスト、HTML、XML、版を限定する API、状態ページ、履歴、比較対象の前身 10 版 である。RADIUS とプライバシーの背景には RFC 2869、RFC 6158、RFC 6614、RFC 7360、RFC 6973 を用いた。これらは現在の導入台数、製品間校正、認可精度、法的評価、利用者体験を示さない。