2021/11/23 追記
進展があったので、新しく記事を書きました
asnokaze.hatenablog.com
==
QUIC Version 1はQUIC WGとしてはとりくみが終わり、RFCとして出るのを待つばかりとなっています。
現在は、v1以後のQUICバージョンの前準備として、バージョンネゴシエーションの仕組みづくりの議論が活発に行われています。先日も、中間会議でバージョンネゴシエーションについて議論が行われました (詳細へのリンク)
そのバージョンネゴシエーションの議論のなかで、「QUIC Version 2 (draft-duke-quic-v2-00)」という DraftがIETFに提出されました。
draftは個人が自由に提出出来るということに注意してください。審査などもありません。これは、IETFやQUIC WGとしての意見を表すものではなく、何かが決まってしまうというものではありません(説明)。ほぼ多くのdraftは個人ドラフトから始まりますし、議論の呼び水と提出されることもよくあります。
このdraftもバージョンネゴシエーションに対する整理および議論のために書かれたものです。その論点について軽く紹介します。
draft-duke-quic-v2-00
いま取り上げているQUICv2を、ドラフト版数込みで明示するために、「draft-duke-quic-v2-00」と呼ぶこととします。
このdraft-duke-quic-v2-00では、QUICのバージョンとして2が与えられるところ以外、ほぼQUIC Version 1と同様です。そしてその目的として、QUICプロトコルの硬直化(Ossification)を防ぐためと、バージョンネゴシエーションを試すという点に主眼をおいています。
硬直化(Ossification)
硬直化とは、新しいバージョンのプロトコルを使おうとしたときに、対応していないネットワーク機器やミドルウェアが不具合を起こし、通信が阻害されることを言います。
具体的には以前書いた記事に書いてあります。
asnokaze.hatenablog.com
QUICも硬直化する可能性があります。将来デプロイされるQUICv2に対応してない実装が誤ってそのパケットを処理し、不具合が起き通信が阻害される可能性があります。Google QUICでの実験ではその問題がすでに起こっていたことを明らかにしています。もちろん、IETF QUICでは硬直化が起きないように対策されています。
QUICv1のパケットは、暗号化にバージョン固有のソルトを使用しています。将来のQUICでも同様にバージョン固有のソルトを使えば、そのバージョンに対応していない(=ソルトを知らない)実装は、暗号的に初期パケットを解読できません。ですので、間違えて処理をするという問題を軽減しています。
draft-duke-quic-v2-00ではソルトとしてv1とは異なり次の値を指定しています。
initial_salt = 0xa707c203a59b47184a1d62ca570406ea7ae3e5d3
実装がこのように、ソルトを変更できる事が確認できるように、draft-duke-quic-v2-00を使うことができます。
