QUIC,HTTP/3 の draft-17に関するメモ

12月8日に現在標準化が進められているQUICの仕様のdraft-17が出ました。

以下の記事で書いたように、"HTTP over QUIC" のHTTP/3への名称が含まれています。
asnokaze.hatenablog.com

その他にも幾つかの変更が含まれているのでざっと目を通す。

この draft-17 は「9th Implementation Draft」であり、2019年1月に東京で開催されるQUIC WGの中間会議において draft-17対応実装を持ち寄って相互接続性試験が実施される予定です。

チャーターに書かれている通り、2019年7月に次のステップとなるIESGへの提出に向けて作業が続けられています。

spin bit

QUICではAckなどの制御情報も暗号化されます。経路上からはRTTやパケットロスの観測はできないようになっています。トラブルシュートの役に立てるために、経路上でRTTを推測可能にするSpin Bitという仕組みが長らく議論されてきました。

仕組みはいぜん書いたとおりです。
asnokaze.hatenablog.com

IETF 103 でも議論されました。この機能の実装意思についても実装者によって大きく別れました (議事録より)

最終的には拡張機能であり、コアの仕様ではショートパケットヘッダに予約ビットを確保はする形になりました。
draft-17ではビットの予約とSpin Bitの仕様である「The QUIC Latency Spin Bit」への参照が付きました

packet header

上記Spin Bitの予約のほか、ロングパケットヘッダ、ショートパケットヘッダの1バイト目について整理がされました。また今までのパケット番号保護から仕組みが変わって、ヘッダ保護(header protection)が付きました。これによって、パケットヘッダの特定のフィールド及び、パケット番号が暗号化されます。接続中は同じヘッダー保護キーが仕様されます。

ロングパケットでは1バイト目の下位4bit (予約領域と、パケット長)

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |1|1|T T|R R|P P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...

   +-+-+-+-+-+-+-+-+
   |1|1|T T|E E E E|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Version -> Length Fields                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ショートパケットでは1バイト目の下位5bit (予約領域と、鍵フェーズ、パケット長)

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |0|1|S|R|R|K|P P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ....

   +-+-+-+-+-+-+-+-+
   |0|1|S|E E E E E|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Destination Connection ID (0/32..144)         ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

両方のパケットで、上記続くパケット番号もマスクされます。
TLSレイヤから得られたシークレットから導出するヘッダ保護鍵と、パケット保護を行いサンプリングされた値を入力として得られたビット列をマスク値として使用します。

off-path migration attacks対策

経路上でパケットを観測し、複製したパケットを本来のパケットよりも早く届けることで、アドレスが変わったと思わせることが出来る。これによって、以降のパケットが観測者の経路を通るようになる。PATH_CHALLENGEを使って攻撃を緩和

その他トランスポートレイヤの変更
  • クローズ後のアンプ攻撃対策。未検証アドレスへのデータ送信量の制限
  • PMTUを1280以下に変更しない

などなど

HTTP/3

"HTTP/QUIC" から "HTTP/3" に名称が変更されました。その他にも幾つかの機能お改善が入ってます

優先度処理

HTTP/2の優先度制御はクライアントとサーバで状態を同期する必要があります。HTTP/3ではもともとコントロールストリーム上でプライオリティを扱っていましたが、HoLBとなるのでdraft-17で変更されました。

各リクエストストリームの最初にPRIORITYフレームを送信可能になったほか、exclusiveフラグが廃止されました。

DUPLICATE_PUSHフレーム

HTTP/2とは異なりパケットロスによりフレームが失われるかもしれないので、同じリソースのPUSH_PROMISフレームを複数送れるようになっていましたが、明示的なDUPLICATE_PUSHフレームが定義されました。

もともとの同一のリソースの複数のPUSH_PROMISフレームでは、同じリクエストヘッダであることが必要でしたが、それは今まで送られてきたPUSH_PROMISEフレームを覚えておく必要があることと同義でした。

DUPLICATE_PUSHフレームではリクエストヘッダは記述せず、すでに送ったPUSH IDのみであるため、そのような間違いは怒らなくなっています。

0長DATAフレーム

ペイロード長が0のDATAフレームが許可されました。その場合は、明示的な長さを持たずデータが終わるまで受信できるようになります。

最初から長さがわかってない場合のデータを返す場合に使用されるものと思われます。