要約

  • QUICのConnection IDは、受信側が選ぶ経路制御と接続照合の手掛かりである。一つの接続に複数の値を用意し、IPアドレスやUDPポートが変わっても正しい状態へ届けられる。
  • 既知のIDだけでは新経路を認めない。予測困難なPATH_CHALLENGEとPATH_RESPONSEでアドレスを試し、検証前の送信量を反増幅規則で制限する。
  • 接続が続いても、経路の仮定は引き継がない。輻輳制御とRTTは原則として初期化し、経路ごとに新IDを使って追跡を減らし、状態を失った端点だけが最後の手段としてStateless Resetを使う。

会話はインターフェースより長かった

従来の運用では、送信元と宛先のIPアドレス、ポートの組で通信を見分けることが多い。この組が変われば、別の接続に見える。しかし端末の内部には暗号鍵、ストリーム位置、確認待ちのデータが残っている。

RFC 8999 は、QUICの版が変わっても残る性質としてConnection IDを定めた。不透明なフィールドであり、UDPやIP以下のアドレスが変わった時にも、パケットを正しいQUIC端点へ運び、そこで対象の接続を見つける。

RFC 9000 では、一接続がIDの集合を持つ。両端は独立に値を選ぶが、自分が発行するのは相手が自分宛てのパケットに入れる値である。受信側が、自らの状態へ戻るための取っ手を用意する。

永久番号ではなく交換できる在庫

確立中の長いヘッダーは送信元IDと宛先IDを運ぶ。その後は NEW_CONNECTION_ID で新しい値を渡し、RETIRE_CONNECTION_ID で不要な値を退役させる。連番が順序を守り、active_connection_id_limit が保持数を制限する。

複数値にはプライバシー上の意味もある。同じ接続に発行するIDは、協力しない外部観測者が相互に関連付けられる情報を含んではならない。同じ値を接続内で再発行することも許されない。

ローカルなアドレス情報だけで振り分けられる場合は、長さゼロも選べる。ただし同じIPとポートで複数接続を扱うと、移動、NATの再割当て、ポート再利用に弱くなる。ハンドシェイクでゼロを選んだ端点は、通常の交換用IDを後から発行できない。フィールドを消せば、区別の責任がアドレスや別の状態へ戻る。

最初のIDは、パケットに書かれていたという理由だけで信用されない。RFC 9000は関連値をトランスポートパラメータへ含め、暗号ハンドシェイクで照合する。RFC 9001 がTLS 1.3とパケット保護を定める。攻撃者が成功する接続のIDを注入で選ぶことは防げるが、ID単体が証明書や人の身元になるわけではない。

同じ接続でも新しい道は試験する

能動的な移動はハンドシェイク確認後に始める。NATが外側のポートやアドレスを変える場合は、利用者が移動を選んでいなくても相手の送信元が変わる。以前に確認していないアドレスなら経路検証が必要である。

端点は予測困難なデータを入れた PATH_CHALLENGE を送り、相手は受信した経路上で同じデータを PATH_RESPONSE に入れて返す。証明されるのは、そのIPとポートへ送った課題が対応する返答を作れる相手に届いたことだけである。住所の法的支配、善意、最適性、将来の可用性までは示さない。

検証は方向ごとに行う。通常のACKは偽造を避けるだけの予測困難性がなく、代用できない。NATを一般に越えるための同期機構でもない。

未検証の新アドレスへ送れる量は反増幅制限で抑える。偽の送信元がサーバーを第三者への増幅器に変えるのを防ぐためである。新経路が失敗しても、以前の検証済み経路が残るなら、接続全体ではなく新経路だけを捨てて戻れる。

移せるのは接続であって測定ではない

新しい経路は帯域、遅延、損失、ECN能力が違う。新アドレスを確認した後、RFC 9000は通常、輻輳制御器とRTT推定を初期値へ戻す。旧経路のパケットを新経路の証拠として数えてはならない。

ポートだけの変化はNATの再割当てであることが多く、慎重に以前の状態を残してよい。それでも実際の経路まで変わっていれば、古い推定で過剰送信する危険がある。ストリームは接続の状態、容量は経路の状態である。

移動する接続を追跡標識にしない

同じIDを会社のWi-Fiと携帯網で使えば、受動観測者は二つの通信を結べる。QUICは、複数のローカルアドレスから送る時や、複数の宛先へ送る時に同じIDを再利用することを禁じる。

新しい値は直接の手掛かりを消し、パケット番号の保護も別の手掛かりを隠す。時刻や大きさ、協力する経路設備までは消えない。目的は関連付けを狭めることで、匿名性の保証ではない。

未使用IDの在庫が尽きると、新経路を試すことも応答することも難しくなる。移動に必要な状態は、移動前に相手へ渡しておかなければならない。

状態を忘れた端点の最後の応答

障害後のサーバーは、相手が覚えている接続を忘れていることがある。通常の CONNECTION_CLOSE を作る状態がないため、Stateless Resetが最後の手段になる。

各IDには推測困難な16バイトのreset tokenを対応させ、保護された文脈で渡す。受信データグラム末尾が正しいtokenなら、相手は接続を直ちに停止する。IDを退役させればtokenも無効になる。

Resetパケット自体に暗号保護はなく、短いヘッダーの通常パケットに似せる。tokenが漏れれば第三者も停止させられるので、IDとtokenの再利用は危険である。これは活動中の接続にエラーを伝える方法ではなく、記憶を失った端点からの限定された終了通知である。

情報源と限界

閉じた資料は RFC 8999、RFC 9000、RFC 9001 である。現在の普及率、実装ごとの動作、移動成功率、性能向上は示さない。Connection IDは世界共通の身元ではなく、経路検証はアドレス所有権の証明でもない。