要約

  • Packet Number フィールドは下位 1〜4 バイトだけを運び、header protection で隠される。
  • 受信側は同じ packet-number space の最大処理済み番号と次の期待値から候補を選ぶ。
  • 下位値の反復、飛び、ラップ、復号失敗だけでは損失、再生、攻撃、アプリ影響は確定しない。

受動キャプチャは、QUIC の番号を単純な連番に見せがちだ。16 ビットに見える値が二度現れれば再生、値が大きく飛べば大量損失、と解釈したくなる。しかし RFC 9000 と RFC 9001 が要求するのは、三つの状態の分離である。第一は回線上の保護されたバイト、第二は header protection を外した後の明示的な切り詰め値、第三は受信側の状態から得た完全な Packet Number だ。完全な番号は 0 から 2^62-1 の整数だが、long header と short header の Packet Number フィールドは下位ビットの 1〜4 バイトしか送らない。フィールド長も保護されている。

番号は接続全体で共有されない。QUIC には Initial、Handshake、application data の三つの packet-number space があり、application-data space には 0-RTT と 1-RTT が含まれる。各空間はゼロから始まる。送信方向と受信方向の番号も別々に管理されるため、同じ整数が異なるパケットを指し得る。Retry と Version Negotiation は Packet Number を持たず、通常の ACK の対象でもない。

送信側の符号化幅は状態に依存する。ある空間でまだ ACK を受け取っていない間は、完全な番号を使う。ACK を受け取った後は、送信する番号と Largest Acknowledged の差の二倍を超える範囲を覆えるだけのビットを選ぶ。RFC の連続した未 ACK 番号に関する例はアルゴリズムの説明であり、運用上の時間しきい値でも、遅延した全パケットの復元を保証するものでもない。

受信側はまず header protection を外す。そこで初めて切り詰め値と長さが得られる。示された再構成手順の入力は、同じ空間で正常に処理された最大番号、切り詰め値、フィールド長の三つである。次の期待値は最大の正常受信番号に一を加えたものだ。受信側は符号化ウィンドウ内で、その期待値に最も近い候補を選ぶ。キャプチャだけでは、この履歴を持たないため完全番号を確定できない。

多くの高い番号が先に到着した後でパケットが遅れて届くと、下位ビットが意図した番号とは別の候補に近づくことがある。したがって deprotection や認証の失敗だけで、相手のプロトコル違反や攻撃を断定してはならない。再構成された番号は AEAD nonce の生成に使われ、packet protection を外す際には Packet Number までのヘッダーが associated data として認証される。この一連の処理を離れた推測は、認証済みの復号ではない。

ACK の意味も別に記録する。Largest Acknowledged は完全な可変長整数であり、保護されたヘッダーの番号のように切り詰められていない。ACK ranges は、その ACK を載せたパケットと同じ packet-number space で受信・処理された番号を示す。これは端点側の事実を支えるが、受動キャプチャの欠落を後から埋めるものでも、別の空間へ移せる証拠でもない。重複の扱いも、保護を外して番号を認証的に回復した後に行われる。同じ下位値だけでは重複とは言えない。

証拠台帳には、接続識別子と方向、パケット種別と空間、保護されたバイトとキャプチャ完全性、鍵の文脈と deprotection 成否、符号化長と下位値、同じ空間の最大処理済み番号、期待値とウィンドウ、再構成された完全番号とパケット認証、さらに ACK 値とその空間を別々に残すべきだ。損失、再送、並べ替え、再生、注入、攻撃、経路、アプリケーション配信は別の証拠を要する。欠落は収集位置、サンプリング、切り詰め、復号状態、実際の通信のいずれでも生じ得る。

これは TR-038 の spin bit、TR-042 の key phase、TR-045 の ACK とアプリケーション配信、TR-049 のパケット集約、TR-051 の PTO 探査を扱う分析ではない。ここで問うのは、保護された断片が正しい状態でどう再構成されるかである。