要約

  • QUICのコネクションIDはパケットを正しい接続状態へ届けるための値であり、加入者やアカウントを認証しない。
  • 確かな保証には、トランスポート事象とアプリケーションが認証した主体を短期間だけ明示的に結ぶ記録が必要であり、プライバシー保護と保存期間の境界も明確にしなければならない。

スマートフォンがオフィスのWi-Fi圏外へ出て、通信をモバイル回線へ切り替える。IPアドレスとUDP経路は変わるが、QUICは接続を維持し、新しい経路で別のコネクションIDを使える。監視画面がこのIDを「同じ加入者が継続していた証拠」と解釈すれば、もっともらしく見える。

しかし、その解釈はプロトコルの境界を越える。RFC 9000が定める主な役割は、下位層のアドレスが変わってもパケットを誤ったエンドポイントへ届けないことだ。各エンドポイントは実装や配備に固有の方法でIDを選ぶ。つまり、これは経路選択と多重分離のための識別子であって、本人確認を担う機関が発行する認証情報ではない。

ライフサイクルも永続的な本人識別情報という見方を否定する。一つの接続が複数の有効IDを持ち、エンドポイントは新しい値を発行し、古い値を廃止し、送信に使う値を変更する。エンドポイントが意図的な移行でパケットを送る場合、複数のローカルアドレスや宛先アドレスで同じIDを再利用してはならない。この規則は送信に適用され、意図しない経路変更すべてを指すものではない。NAT再バインドによって同じ宛先IDのパケットが新しい送信元から届いた場合、受信側は同じローカルアドレスから送信する限り、新しい相手先に現在のIDを使い続けられる。ID数を利用者数とすれば一つの接続を重複計上し、固定値だけを追えば移行後を見失う。

プライバシーも設計の一部である。RFC 9000は、協力しない外部観測者が同一接続の別IDを関連付けられる情報を含めないよう求める。経路ごとのID変更は追跡可能性を下げるためだ。運用上便利だからと恒久的な顧客キーにすれば、この性質を逆に弱める。

経路検証が示すのは別の命題だ。あるアドレスでパケットを受け、必要な応答を返せることは確認できる。しかし契約上の加入者、現在の利用者、アプリケーションのアカウント、認可の有効性までは認証しない。到達性と本人確認は同じではない。

RFC 9312はネットワーク観測者に、コネクションIDによるフロー関連付けが失敗し得ることを前提にせよと注意する。同一接続中にIDは変わり得る。同じ5タプルに異なるID、または同じIDに異なる5タプルが見えても、それだけで接続の同一性は決まらない。エンドポイントと明示的に協調しない限り、値は不透明として扱うべきだ。

運用で使えないわけではない。エンドポイントのログなら、IDを短期的な照合材料として、発行、連番、廃止、経路検証、アプリケーションセッションと結び付けられる。問題は、ほかの証拠なしにトランスポート上の値だけで本人確認を済ませてしまうことだ。

この区別は、権利や責任を伴う操作で決定的になる。アカウント設定の変更、支払いの承認、管理用通信路の開設、不正対策の適用、不正トラフィックの帰属では、アプリケーションが認証済み主体と、その操作に適用された認可状態を記録しなければならない。

必要なのは「認証主体とトランスポートの継続性記録」である。仮名化した主体参照、アプリケーションセッション、認可状態、QUICエンドポイントの役割、ID発行者と連番、発行・廃止、旧経路と新経路、検証結果、観測できる範囲でのNAT再バインドまたは意図的移行の区分、観測点、操作結果、関連付けの根拠、保存期限、例外の責任者を結ぶ。コネクションIDは証拠の一部にはなれるが、本人確認の根拠にはならない。