QUIC

QUIC を 4 行で

HTTP/3 のために UDP/443 で使われている
最低限のヘッダとペイロードは TLS で暗号化されている
複数の HTTP ストリームをまとめることができる

QUIC を阻害するネットワークトラブル

NAT や SPI のテーブル溢れ
NAT の送信元ポート番号枯渇
UDP 送信元番号フィルタリング

NAT のテーブル溢れについて

5-tuple で通信を区別して管理している src ip, dest ip, protocol, src port, dest port 通信が終わるとテーブルから削除する NAT テーブルには上限があるあふれると QUIC だけでなく新規通信ができなくなるこれは多くの場合 TCP/UDP を区別せずにテーブルを共有しているため QUIC ではなぜ NAT テーブルがあふれるのか => たくさん使われていて UDP で中身が見えないから TCP の場合は FIN パケットでテーブルからエントリを消せる QUIC は UDP なので能動的にエントリを消せない NAT ルータは無通信時間（タイマー）を元にしかエントリを消せない => タイマーの時間だけエントリが残り続けるので NAT テーブルを圧迫する QUIC にはコネクション終了を知らせるフレームも暗号化されている

対策

IPv6 SPI 問題がある TCP/UDP/ICMP などのポート番号や通信状況を管理してファイアウォールの機能を実現する仕組み 5-tuple で管理していてテーブルサイズがある
NAT UDP タイマーを短くする 2 分未満にしてはならず、デフォ値としては 5 分以上が推奨
NAT アルゴリズム変更 LRU 方式にするのもありなのでは？ポート再利用間隔が 2 分未満になってしまう場合がある keepalive が長いプロトコルが割を食う可能性がある
NAT テーブルサイズ増加機器交換が必要になったり、コストに影響がある
UDP443 を塞ぐやったら負け

NAT 送信元ポート番号枯渇

パブリック IP が 1 つのとき NAT で利用できるのは 64512 ポート 64512 = 65536 - 1024

対策

パブリック IP を増やす IPv4 アドレス枯渇問題
CGN で割り当てポートを増やすサービスイン後の変更は難しい
IPv6 を使うこれしかなさそう

フィルタリング

リフレクション攻撃対応としてフィルタリングしている場合がある HTTP/3 では well-known ポートを使わないが。。。 QUIC クライアントではよく攻撃に使われるポート番号を送信元として使わないようにする動きがある NAT されたときに送信元ポート番号として割り当て割れる可能性がある

対策

IPv6 を使う(ry NAT をしなければ良いので

Path MTU Discovery

Chrome などは 1350 バイトが流れれば QUIC、流れなければ TCP を使う => PMTUD しない PMTUD を使う場合は UDP での PLPMTUD を利用する

途中経路で UDP443 が塞がられている場合

QUIC と TCP どっちも試すので TCP フォールバックするので問題ないはず接続確立後に落とされるとユーザ影響がある

策定者は起きそうな問題考えてなかったのか

TCP フォールバックがあるのでいいだろと考えていたと思う NAT を作っている人からのフィードバックがなかったと思う UDP のポートをたくさん使う問題は QUIC 自体の問題か実装の問題か議論がある

QUIC での Proxy について

HTTP/3 での Proxy についてはクライアントに証明書があるので従来の感じでやろうと思えばできる企業内であれば UDP/443 を落として TCP でやるというのは十分ありな選択肢