3月分も書きました
asnokaze.hatenablog.com
QUICの標準化状況に関して、幾つかトピックを取り上げる
シリーズ化するつもりは無いが、1月に書いたので、今回は2月初旬版
qiita.com
拾いきれてないトピック沢山有るので、皆さんも是非補足して頂ければ
目次
Draft-09
1月末に4つのコアドキュメントのdraft-09が出る
Call for Adoption
1月に行われたQUIC Interimの議論を経て、2つのドキュメントがCall for Adoptionとなっている
QUICのHTTPヘッダ圧縮については幾つか提案があり、ながく議論されていたがその一つがAdoptionされることは追う側としては喜ばしい。WG Draftが出たら読み直そうと思う
詳しくは以前書いた記事を参考に
Interim Meeting
オフラインの中間ミーティングが、1月メルボルンで実施された。
アジェンダは下記の通り
- Summary of interop meeting (EKR)
- Status update from editors (Martin)
- QUIC Invariants (Martin)
- HTTP compression (Mike)
- Multiplexing with other UDP protocols (Jana)
- Greasing (Martin)
- Connection ID and Handshake review (Ian)
- Connection migration (Jana)
- Loss recovery (Ian)
- QUIC Application Abstractions (Jeff / Roberto)
- ECN in QUIC (Ingemar, morning time MEL preferred)
- 3rd implementation draft
- Next Steps (Mark / Lars)
資料と議事録はGithubのリポジトリより確認できる。
github.com
QUIC MTU
QUICのトランスポート draft-09にて、Path Maximum Transmission Unit (PMTU)の記述が増えた。
まず、最初のパケットは1200 octet以上になるように決められた。これは、反射型DDoS攻撃を緩和するためである。UDPだと送信元IPを攻撃対象のものに偽装することで、最初のパケットへの応答を攻撃対象に送信させることが出来る。QUICでは最初のパケットを大きくすることでデータ量を増幅できないようになっている。
クライアントがもし経路がそれ以上でも疎通できることを知っていれば、それ以上のサイズの初期パケットを送信しても良い。
PMTUは、経路上で疎通可能なIPヘッダ + UDPヘッダ + UDPペイロードの最大サイズです。QUICパケットはこのPMTUに収まるように送信すべきです。そのため、Path MTU Discoveryを使うべきです。
これらの仕組みを使用せず、1280 octetより大きいパケットを送信すべきではありません(IPv6で保証される、最小PMTU)。
また、IPv4のPath MTU Discoveryには脆弱性が知られているため、そのための緩和策を取るよう書かれています。
Migration
QUICでは、QUICのレイヤでコネクションを管理しているため、IPやポートが変わっても切断されません。NAT rebindingによってIPが変わっても大丈夫ですし、明示的に4G回線からWi-FI回線に切り替える事もできます。このコネクションのマイグレーションに関して、専用のフレームが用意された。
その変更が先日マージされた。
github.com
PATH_CHALLENGE, PATH_RESPONSEというフレームタイプである。
両方共、Data領域のみを持ちます。新しい経路に切り替える際、推測されにくい値を格納したPATH_CHALLENGEを新しい経路で送信します、それを受け取ったピアは任意の経路で同じ値を持つPATH_RESPONSEを送り返します。このときアドレストークンの検証もちゃんと行います。
こうして経路の確認が取れた後にコネクションをマイグレーションすることが出来ます。
17 octet connection ID
QUICのコネクションIDはサーバから払い出すことが出来ます。この時、そのコネクションに関する情報、例えばそれを払い出したサーバの識別情報を暗号化してコネクションIDに含める事ができます。そうすることで、そのコネクションIDをもつクライアントはそのサーバで処理するといった事ができます。
この使い方は「Manageability of the QUIC Transport Protocol」の4.3でも触れられています。
さて、コネクションIDはもちろんクライアント側から任意の値を使用しようとできるので、サーバ側から発行するコネクションIDに何かしらの情報を埋め込む際は暗号化する必要があります。その時に問題になるのがコネクションIDの長さです。
認証付き暗号を使用のに、128bit長にすることが提案されています。また、使っている鍵の識別子も付け加えて、系17octetになります。
github.com
だたし、可変長コネクションIDという意見も出ており、今後も議論が続くかと思います。
Packet Number Protection
下記記事でも触れているとおり、ファイアウォールなどの中間装置がパケットを読み正しくない挙動を起こす問題が知られています。そのため、そもそもそれらのパラメータを見えないようにするという議論が進んでいます。
asnokaze.hatenablog.com
さらに暗号化を進め、パケット番号も暗号化しようという議論が出ています。
秘密値から導出されるpn_keyと、パケットのデータ領域を暗号化した後に、暗号化領域からサンプリングしてきた値を暗号へのインプットとしてパケット番号を暗号化します。
AES-BasedとChaCha20-Basedがありますが、AES-Basedでは下記のとおりです。
encrypted_pn = AES-CTR(pn_key, sample, packet_number)
EXTENSION Frames
QUICでも拡張フレームを定義する議論が出ています。
github.com
フレームタイプ0x0fで、さらにExtension Typeを持ちます。未知の拡張タイプは無視されます
QUIC IN ECN
QUICにおけるECNは「ECN support in QUIC」としてInternet-Draftが出ていますが、WikiのECN in QUICで編集が進められています。
ECNは詳しくないので、正直良くわからないのですが、「Suggested additions to 'to become' RFCs」と書かれている通り、トランスポート及びロスリカバリのドキュメントに追記されECNサポートへ向かうようだ。
Unbound Server Push (USP) for HTTP/QUIC
メーリングリストで話題になっていないのと、V1のスコープ外なのでどうなるかわからないが、「Unbound Server Push (USP) for HTTP/QUIC」という提案が出ていた。
HTTP/2サーバプッシュは、HEADERSフレームを受けてそれと関連するレスポンスをプッシュすることが出来る。つまり、まずHEADERSフレームを受け取る必要があるが、上記の提案ではそれがなくてもプッシュできるUnbound Server Pushを提案しているようだ。