要約

  • NEW_TOKEN は後続の QUIC 接続でアドレスを検証するためにサーバーが発行する資格情報であり、即時利用の Retry とは異なる。
  • 検証成功が示すのは、サーバーの方針に基づく限定的な送信元アドレスの証拠だけである。
  • トークン検証、ハンドシェイク認証、アプリケーションの本人性、認可、結果は別々に記録しなければならない。

運用ダッシュボードがトークンを含む Initial を見て、「再訪クライアント」と表示する。NEW_TOKEN によってアドレス検証の往復を省けるため、この表示はもっともらしく見える。しかし、プロトコルが提供する証拠はそれほど広くない。問えるのは、サーバーがそのトークンを、送信元アドレスと発行時の接続との関係を示す限定的な材料として受け入れられるかどうかである。

サーバーは接続中に NEW_TOKEN フレームで不透明なバイト列を送れる。クライアントは後続接続の Initial パケットにそれを入れる。これは将来接続用の資格情報だ。Retry は現在の接続試行で直ちに使うもので、後の接続へ持ち越してはならない。NEW_TOKEN は時間が経過した後も利用できる場合があるが、適用範囲と有効期限に従う。

トークン形式と検証方針はサーバーが決める。発行サーバーの権限関係、完全性、QUIC バージョンの範囲、有効期限、送信元 IP の変化を確認できなければならない。RFC 9000 は統一的な有効期間、再利用率、本人性スコアを定めていない。発行時刻を含めることも、そこから期限を導出することもできる。クライアントは通常、適用可能で未使用のトークンを選び、接続試行をまたいで再利用すべきではない。

証拠には限界がある。NAT では複数の端末が一つのアドレスを共有し、アドレスは再割り当てされ、端末はネットワークを移動する。トークンは発行接続と後続利用をサーバーが関連付けることを可能にし、再利用は経路上の観測者にとってもリンク可能性を高める。連続性を断ちたいクライアントは NEW_TOKEN を破棄できる。さらに、アドレス検証トークンは暗号ハンドシェイクに統合されていない。検証成功は相手の認証、アカウント継続性、端末本人性、認可、要求成功を意味しない。

アドレスが変わった場合、トークンによって Retry を送らない判断をしても、サーバーはアンプリフィケーション制限を守る必要がある。有効なトークンは輸送上の安全策を免除しない。無効なトークンは一般に未検証として扱い、必要なら Retry を送る。無効性を本人性の失敗とみなして直ちに接続を破棄するべきではない。推測、改変、偽造への耐性と、再生の防止または制限が必要である。NEW_TOKEN は Retry より長く使える必要があるが、複数回受け入れるべきではなく、可能なら一回限りの利用が望ましい。

DNS over QUIC はプライバシー境界を理解する材料になる。IP アドレスに結び付いたトークンは追加往復を避けられる一方、利用者が気付かないアドレス移動はリンク可能性を生む。セッション再開は緩和策になるが、完全な解決ではない。運用上は遅延上の利点を使いながら、証拠を限定的に記録すべきだ。

証拠台帳では、発行者とサーバー権限、トークン種別、発行時刻と期限、QUIC バージョン、トークン識別子またはプライバシーに配慮したダイジェスト、送信元 IP の一致、初回利用または再利用の判断、検証結果、アンプリフィケーション状態、Retry 判断、ハンドシェイク認証、アカウントまたは端末の本人性、認可、要求結果、保持方針を分離する。ダイジェストと保持期間は運用上の推奨であり、QUIC の要件ではない。

Retry の整合性は即時利用パケットの問題、三倍ルールは検証前の送信上限、Connection ID は経路制御のハンドル、0-RTT は再生可能なデータとコミットの問題、DNS Cookie は別プロトコルの戻り経路証拠である。これらを NEW_TOKEN の意味に混ぜてはならない。