プロンプトとスコープ
モバイルクライアントがWi-Fiからセルラー回線に移動しながら、データをダウンロード中であるか、または長時間存続する接続を保持しています。その送信元IPアドレスとUDPポートは変化します。QUICがどのようにして同一接続を認識し、新しいパスを検証し、いつ再接続するかを決定できるのかを説明してください。スコープはQUIC v1トランスポート層に絞り、アプリケーション層のリトライ、HTTPセッションの復旧、0-RTTについては自動マイグレーションと呼ぶのではなく、個別に議論してください。
面接官が評価するポイント
優れた回答では、4タプル（4-tuple）とQUIC Connection IDを明確に区別します。アドレスの変更は必ずしも接続状態を破棄するわけではありませんが、新しいパスは検証されなければなりません。未確認のハンドシェイク、disable_active_migration、NATリバインディング、コネクションIDの枯渇、サーバーの優先アドレス（server preferred address）、および0-RTTにおけるリプレイリスクに関する質問を想定してください。「UDPはコネクションレスであるため切り替え可能である」という回答は、QUICの状態管理やセキュリティ境界を見落としています。
回答前の確認質問
- これはクライアントによる意図的なネットワーク切り替えですか、それとも受動的なNATリバインディングですか？ トリガーと検証パスが異なります。
- ハンドシェイクは確認（confirmed）されていますか？ QUIC v1では確認前の能動的なマイグレーションを許可していないため、元のアドレスが引き続き使用されます。
- 対向側（peer）は能動的なマイグレーションを無効化していますか？
disable_active_migrationの後、クライアントはサーバー提供の優先アドレスを使用する場合を除き、新しいローカルアドレスから能動的に送信することはできません。 - コネクションIDの長さはゼロですか？ 長さゼロのIDは新しいIDでパスを分離できないため、ルーティングとプライバシーの選択肢が弱まります。
- アプリケーションはデータの中断を許容できますか？ 古いパスが消失し、新しいパスが検証できない場合、エンドポイントは待機、切断、またはアプリケーションによるセッションの再構築に委ねます。
30秒の回答フレームワーク
「QUICは接続をTCPの4タプルにバインドせず、対向側から提供されたConnection IDを使用します。ハンドシェイクが確認された後、クライアントは新しいアドレスからプローブを送信します。データが移動する前に、サーバーはPATHCHALLENGEとPATHRESPONSEでパスを検証します。NATリバインディングにも検証が必要です。Connection IDを異なる送信パス間で再利用することはできず、対向側は能動的マイグレーションを無効化することも可能です。古いパスが残っている場合、マイグレーションの失敗によって直ちに状態が破棄されるわけではありません。残っていない場合、エンドポイントは待機または再接続します。0-RTTはハンドシェイクの再開であり、マイグレーションが安全であることの証明ではないため、アプリケーションはリプレイを処理する必要があります。」
ステップバイステップの解説
QUICの状態には、Connection ID、暗号鍵、ストリーム状態、および輻輳制御が含まれます。Connection IDにより、受信側はIPやポートの変更後もパケットを同一接続にマッピングできます。これは認証クレデンシャルではなく、単体で新しいアドレスが元のクライアントのものであることを証明するものではありません。
ハンドシェイク確認後、エンドポイントは新しいローカルアドレスからプローブを送信できます。新しいパスはPATHCHALLENGEを送信し、PATHRESPONSEの受信後にのみ使用可能になります。検証の失敗はそのパスが使用不能であることを意味しますが、他に有効なパスがある接続を閉じる必要はありません。NATリバインディングなど対向側アドレスの突然の変更でも、なりすました送信元がトラフィックをリダイレクトしたり増幅攻撃を引き起こしたりしないよう、パス検証が必要です。
各送信パスは、他のパスで使用されていないDestination Connection IDを使用する必要があります。これにより、マルチインスタンス構成のサービスがパケットをルーティングしやすくなり、オブザーバーが2つのパスを関連付けるリスクを低減できます。エンドポイントは事前に複数のIDを提供しておく必要があります。これらが枯渇すると、安全なプロービングやマイグレーションができなくなります。長さゼロのIDの場合、サーバーは他の情報を使用して多重分離（demultiplex）する必要があり、マイグレーションとプライバシーの境界が弱まります。
マイグレーションは輻輳制御に影響を与えます。アドレス変更により対向側が輻輳状態をリセットする可能性があるため、プロトコルではアドレスの変更頻度を抑えることを推奨しています。サーバーはハンドシェイク中に優先アドレスを提供できますが、クライアントはまずそれを検証し、検証に失敗した場合は元のアドレスを維持します。disable_active_migrationは、クライアントが新しいアドレスから恣意的に送信することを防ぎます。
0-RTTは再開されたハンドシェイク中にアプリケーションデータを許可しますが、RFCではリプレイ保護を提供していません。ネットワークの切り替えには確認済みの1-RTT状態を使用すべきです。非べき等なリトライを行うアプリケーションでは、QUICがトランスポート接続を維持している場合でも、べき等性キーやサーバー側の重複排除が依然として必要です。
質の高い模範解答
「私は接続の同一性とネットワークパスを切り離して考えます。QUICはConnection IDを使用するため、Wi-Fiからセルラー回線への切り替え時のIPまたはポートの変更でも状態を保持できます。ハンドシェイク確認後、エンドポイントは新しいアドレスからPATHCHALLENGEを送信し、PATHRESPONSEで検証された後にのみそのパスを使用します。NATリバインディングも同じルールに従います。エンドポイントは送信パス間で1つのIDを再利用してはならず、IDの枯渇やdisable_active_migrationを考慮する必要があります。検証に失敗した場合、エンドポイントは機能している古いパスを維持するか、待機してアプリケーションセッションを再構築します。私は0-RTTをマイグレーションのセキュリティではなく、リプレイに注意が必要な再開処理として扱います。」
よくある間違い
- 間違い → UDPは本質的にマイグレーションをサポートしていると主張する。理由 → UDPには接続セマンティクスがなく、QUICがID、鍵、ストリームを管理しているため。修正方法 → Connection IDとパス検証について説明する。
- 間違い → アドレス変更直後にパケットを受け入れる。理由 → なりすましアドレスによる増幅や誤ルーティングの恐れがあるため。修正方法 → PATHCHALLENGE/PATHRESPONSEを必須とする。
- 間違い → 0-RTTをマイグレーションと呼ぶ。理由 → 0-RTTはリプレイ保護なしでEarly Dataを送信するため。修正方法 → 再開とマイグレーションを明確に区別する。
- 間違い → 複数のパスで1つのConnection IDを送信する。理由 → パス関連付けルールに違反し、プライバシーを損なうため。修正方法 → 送信パスごとに未使用のIDを使用する。
- 間違い →
disable_active_migrationを無視する。理由 → 対向側が能動的なローカルアドレス変更を明示的に禁止しているため。修正方法 → 優先アドレスなど、プロトコルの条件を満たす場合にのみマイグレーションを行う。
フォローアップの質問と回答
新しいパスが検証されない場合はどうなりますか？
新しいパスのみが使用不能になります。古いパスが有効なままであれば、そのパスで送信を続けます。有効なパスが存在しない場合は、別のパスを待つか、利用不可を報告して接続を閉じるか、アプリケーションセッションを再構築します。PATH_RESPONSEのタイムアウトは、自動的にアプリケーションデータが失われた証拠になるわけではありません。
なぜ複数のConnection IDを提供するのですか？
マイグレーションとプロービングには、他のパスで使用されていないIDが必要です。プールが枯渇すると、エンドポイントは安全にプローブを送信したり、対向側のマイグレーションに応答したりできなくなります。サーバーはactive_connection_id_limitの範囲内でIDを補充する必要があります。
マイグレーションはどのようにして関連付け可能性（linkability）を低減しますか？
新しいパスで新しいConnection IDを使用し、パケット番号が直接関連付けられないようにヘッダー保護（header protection）を使用します。タイミングやパケットサイズのパターンからトラフィックが相関付けられる可能性は依然として残るため、マイグレーションは完全な匿名性を意味するものではありません。
マイグレーションは輻輳ウィンドウを維持しますか？
新しいパスの容量が不明であるため、実装によっては輻輳制御をリセットまたは調整する場合があります。アドレスの変更頻度を抑え、検証後に利用可能な帯域幅を再推定します。アプリケーションは、瞬間的なスループットが変わらないことではなく、トランスポート層での最終的な配信に依存するべきです。