Summary

  • 21バイト以上の候補データグラムで末尾16バイトが接続に関連付けられたトークンと一致すれば、受信側は接続を終了する。ただし送信元が認証されたわけではない。
  • 状態が消えた理由、担当バックエンド、消失時刻は示さない。
  • 障害解析には経路判断、鍵バージョン、最後の正常パケット、状態ストアの独立証拠が必要だ。

ロードバランサーが別のバックエンドへ流量を切り替えた直後、クライアントが既知のリセットトークンと末尾16バイトの一致するパケットを受け取り、接続を直ちに閉じたとする。信号はクライアントの動作を決めるには十分だが、「サーバーが状態を失った」という原因の断定には足りない。

RFC 9000 §10.3は、接続状態へアクセスできない端点が使う最終手段としてステートレスリセットを定義する。QUIC v1で定義されたAEAD方式では、21バイト未満のショートヘッダーパケットは有効になり得ず、破棄しなければならない。21バイト以上の候補データグラムについて、受信側は末尾16バイトを使用中の接続IDに結び付いたトークンと照合する。一致すれば直ちに接続を終了するが、送信元を認証するものではなく、原因コード、バックエンド名、最初に状態を失った時刻も含まれない。

パケットは通常の短いヘッダーのパケットと容易に見分けられないよう設計される。乱数に見える内容は第三者による識別を難しくし、長さの制約はリセットの応酬を抑える。したがって受動的な観測だけで、似た形のパケットをリセットと決め付けることもできない。

§10.3.1は、静的な鍵と接続IDからトークンを導出する方法を認める。完全な接続状態を持たない経路層でも一致するトークンを生成できる一方、クライアントには鍵バージョン、生成したインスタンス、直前の運用変更は見えない。

§10.3.2は別の重大な境界を置く。異なる接続IDに同じトークンを割り当ててはならない。衝突や誤った再利用は誤検出を生み、正常な接続を終了させ得る。照合が正しくても、発行・保存・更新の全工程が正しかった証明にはならない。

§21.11の安全上の考慮も、原因帰属を狭く保つ。漏えいまたは管理不備のトークンはリセット注入に悪用され得る。トークンの一致だけでは攻撃を断定できず、運用障害を除外できず、フェイルオーバーが状態を保存した証明にもならない。

編集上の運用提案として、観測時刻、送受信アドレスとポート、パケット長と形状、CIDとトークンの指紋、対応するシーケンス番号、発行バックエンドと鍵バージョン、ロードバランサーの判断、最後の正常パケット、配備・切替イベント、状態ストアの独立記録を一つの事故記録に残すべきだ。

これにより、再起動、状態の追い出し、期限切れ、誤配送、複製遅延、鍵更新の不整合、トークン衝突、悪意ある注入を区別できる。リセットは「なぜ今クライアントが閉じたか」を示す。状態が使えなくなった理由は、結合した運用証拠が示す。