要約

  • connection IDは、IPアドレスやポートが変わった後の保護済みパケットを既存のQUIC接続へ結び付ける。利用者の身元、アドレスの所有権、新経路の安全性を証明するものではない。
  • PATH_CHALLENGE/PATH_RESPONSE、検証前の反射増幅制限、経路ごとの輻輳・RTT・ECN処理、IDの使い分けによって、接続継続と経路への信頼を分離する。

スマートフォンが社内Wi-Fiで長いセッションを始め、そのまま屋外へ出る。Wi-Fiが途切れ、モバイル回線へ切り替わると、送信元IPアドレスとUDPポートは変わる。この場面は仕組みを説明するための例であり、特定サービスの障害や実測事例ではない。

受信側がアドレスだけを接続の正体と考えれば、次のパケットは別人のように見える。QUICではconnection IDを手掛かりに、暗号学的に保護されたパケットを既存の接続状態へ届けられる。しかし、新しい送信元が詐称されていないか、応答が本当に戻るか、MTUやRTTが同じか、旧経路の送信レートを持ち込んでよいかは、まだ分からない。

RFC 9000は、この「続いているもの」と「変わったもの」を混ぜない。接続は存続できる。経路は再び検証対象になる。

接続の座標と接続そのもの

RFC 9000は2021年5月にIETF Standards Track文書として公開され、Jana IyengarとMartin Thomsonが編集者として記載されている。IETF DatatrackerのIyengarのプロフィールにはRFC 9000とRFC 9002を含む7本のRFCが並び、現在のIABメンバー一覧ではNetflix所属として掲載される。ここから言えるのは、IyengarがQUIC中核仕様の共同編集者であることまでだ。単独の発明者として描くことはできない。

IPアドレスとポートは、ある時点のネットワーク上の座標である。connection IDは、パケットを適切な接続状態へ一貫してルーティングするために使われる。一つの接続が複数の有効なIDを持ち、相手へ未使用IDを供給することもできる。

名前に「ID」とあっても、人のIDではない。アカウントの資格情報でも、住所の所有証明でも、アプリケーション取引の再実行許可でもない。暗号保護された接続の内部で、状態との対応を維持する輸送層の識別子である。

この限定が、移動やNAT rebindingを扱いやすくする。外部ポートが変わるたびに完全な接続を作り直す必要はない。一方、以前の接続状態が新しいアドレスのすべてを保証するわけでもない。変更に耐えることと、変更を無条件に信じることは別である。

新経路へ送る、推測しにくい問い

経路検証は、ローカル側とピア側の特定のIPアドレス・ポート組み合わせを対象とする。検証する端点は、その経路上で予測不能なデータを入れたPATH_CHALLENGEを送る。受信した相手は、同じデータをPATH_RESPONSEに入れ、チャレンジを受け取った経路から返す。対応する応答を受けたとき、送信した問いが相手へ届き、答えが戻ったという証拠になる。

通常のACKでは足りない。十分なエントロピーがなく、悪意ある相手が誤解を招く確認を作る余地がある。チャレンジの値は、当てるより受信する方が容易になるよう設計される。

それでも、成功が証明する範囲は小さい。各端点は各方向の到達性を独立に判断する。一方の成功は、もう一方が逆方向を独自に検証したことを意味しない。人や組織の認証、経路制御の正当性、将来の配達品質、NAT traversalも証明しない。

検証は万能証明ではなく、特定のアドレス対に対する観測である。その限定があるからこそ、実装は証拠のない結論へ飛ばずに次の動作を選べる。

三倍という数字の対象

未検証の送信元アドレスは、反射増幅攻撃に利用され得る。攻撃者が被害者のアドレスを詐称して小さなパケットを送り、サーバーが大量の応答を被害者へ返せば、通信量が増幅される。RFC 9000は、応答する端点が未検証アドレスへ送れる量を、そこから受信した量の三倍までに制限する。

これはQUIC全体の速度制限ではない。未検証アドレスへの応答に適用される反射増幅予算であり、クライアントや移行開始時についてはRFCのセキュリティ節に明確な適用上の注意がある。実装は経路別の受信・送信バイトを把握しなければならない。

到達性とパスMTUも別々に確認される。増幅予算のためPATH_CHALLENGEを1,200バイトまで拡張できなかった場合、応答はアドレスの到達性を検証しても、必要なデータグラムサイズを通せることまでは示さない。予算が整った後、十分な大きさで再検証する必要がある。

検証タイマーは、新経路のRTTが長い可能性を見込む。一回のチャレンジや応答の損失だけで失敗にしてはならない。最終的に検証を断念した場合、その経路は利用不能と判断されるが、別の経路が残っていれば接続は続く。移行の安全性は、古い経路をいつ手放すかにも左右される。

古い輻輳状態を新しい道へ持ち込まない

輻輳ウィンドウとRTT推定値は、旧経路から学習した結果である。容量や遅延が違うモバイル経路へそのまま移すと、適応するまで過剰な送信を行う恐れがある。

RFC 9000は、新アドレスをピアが制御していると確認した後、新経路の輻輳制御器とRTT推定器を初期値へ戻すよう求める。ただし変更がポートだけなら、NAT rebindingであることが多いため、旧状態を保持してよい。例外を使う場合でも、実際の特性が大きく変わっていれば慎重さが必要だとする。

ECNも経路依存なので再検証される。移行中に新旧経路の遅延が異なれば、受信側には並べ替えが起きたように見える。接続が一つであることと、二つの経路で得た測定値が同じであることは一致しない。

継続性は、状態を全部保存することではない。接続そのものが支える状態は残し、経路が生んだ状態はリセットまたは再測定する。これは「状態の選択的な継承」である。

接続継続が追跡ラベルになるとき

同じconnection IDを異なるネットワークで使えば、外部の観測者は二つの通信を直接結び付けられる。RFC 9000は、同じ接続の別IDと相関できる情報をIDへ含めることを禁じ、異なるローカルアドレスや宛先アドレスで同じIDを再利用しないよう求める。

経路ごとにIDを変えれば、その直接の手掛かりは消える。しかし、タイミングやパケットサイズなどは依然として相関に使える。IPv6 flow labelも固定的な印にならないよう扱う必要がある。プライバシーは一つのフィールドではなく、観測可能な特徴全体の問題だ。

サーバーが示すpreferred addressにも範囲がある。示された接続についての希望であって、将来の接続を拘束する一般命令ではない。クライアントはその経路を検証する。希望先は到達性の代わりにならない。

「シームレス」を検証可能にする記録

運用者が移行をシームレスと呼ぶなら、旧・新アドレス対、IDの発行と廃止、チャレンジと応答、再送とタイマー、検証前のバイト予算、MTU確認、旧経路の残存、輻輳・RTTのリセットまたはポート限定例外、ECN検証、アプリケーションの中断や再試行を一つの記録で示す必要がある。

さらに、どの識別子が変わり、どの可視特性が相関可能だったかを残す。「接続オブジェクトが閉じなかった」「新アドレスに届いた」「新経路が安定した」「利用者の処理が一度だけ完了した」は別の判定である。

独立した編集上の比較

Sofia Renは、後に公表された二つの文章から比較枠組みを適用する。

両者を合わせると、主張の権威は稼働中のシステムから得られる反証可能な証拠を越えてはならない、という読みになる。これは本稿の編集的解釈であり、Iyengar、Thomson、Netflix、IAB、IETFの内心を述べるものではない。

QUIC接続がアドレスを越えて続けるのは、過去の信頼を丸ごと運ぶからではない。必要な状態だけを残し、新経路へ必要な問いをもう一度送るからである。

出典