QUICにおけるヘッダ圧縮の提案仕様 QPACK(旧QCRAM) その2 (draft-04)

QUIC HTTP HTTP ヘッダ圧縮

20180313追記
QCRAMと呼ばれていた仕様は、QPACKに改称されました。
github.com

HTTP over QUICでは、HTTP/2のフレームを利用するが、HTTPヘッダ圧縮にHTTP/2のHPACKをそのまま使用するのはHoLBの問題が知られている。

HPACKでは、ヘッダが送った順番通りに届く事を想定しており、送信側と受信側が完全に同じ状態を保てる。しかし、QUICではメッセージの届く順番は入れ替わる可能性があり、動的テーブルの参照する際にまだそのインデックスが挿入されていないというケースが生じうる。QUICでは、届いたメッセージから処理できるはずが、ここで待ち状態になってしまう。

そこでQUICでのHTTPヘッダ圧縮は新しい仕組みを導入することが検討されており、幾つか提案されているなかの一つが「Header Compression for HTTP over QUIC」であり、QCRAMと呼ばれている。

そのQCRAMが Call for Adoption となっている、またGo実装でもあるminhqでもQCRAMが試験的に実装されている。IETF101に向けて、事前に仕様を読んでおく。

今回は、前回のdraft-02からのアップデートのみ触れる。詳しくは前回を参照のこと。
asnokaze.hatenablog.com

draft-04

Call for Adoption となっている、現在のQCRAMはdraft-04であり、draft-02から幾つかの変更点がある。

主な変更点である、下記について書く

  • HEADER_ACK
  • BLOCKING flag
  • ヘッダブロックプレフィックス
HEADER_ACK フレーム

新しく HEADER_ACKフレームが定義される。これは、デコーダ側がヘッダブロックを処理した際にControl Streamでエンコーダ側へ通知される。このHEADER_ACKフレームをエンコーダ側が受信することで、送ったヘッダがどこまで処理されてるか判別することが出来るようになる。

f:id:ASnoKaze:20180212221216p:plain

  • Stream ID: ヘッダブロックを処理したストリームID(可変長)

trailersなどで複数回ヘッダブロックを処理する可能性があるが、おそらくその都度送信される。

BLOCKING フラグ

HEADERSフレームとPUSH_PROMISEフレームにBLOCKING フラグが追加されます。

前述のHEADER_ACKによってエンコーダ側は送信したヘッダブロックがどこまで処理されているかを知ることが出来ます。そこで、ヘッダブロックを送信する際に、そのデコーダ側がヘッダブロックを処理するのにブロックされうるのかが分かります。

このフラグが0の場合は、デコーダ側はすぐにそのヘッダブロックを処理できます。1の場合は、依存するヘッダブロックが処理されるまで待つ可能性があります。

ヘッダブロックプレフィックス

以前の記事で説明したとおり、QCRAMではヘッダブロックにプレフィックスが追加されます。このプレフィックスもdraft-02から変更されています。

このヘッダブロックプレフィックスは、BLOCKING フラグによって変わります。
BLOCKINGフラグが0の場合が左、BLOCKINGフラグが1の場合は右です。


f:id:ASnoKaze:20180212231947p:plain

  • Base Index: 現在のヘッダブロックを初果する前の、追加されたエントリの合計
  • Depends: Base Indexの位置よりどれくらい前のインデックスに依存するか。Base Index - Dependsが依存する最大のインデックス値になります。

HPACKではエントリを挿入するたびにインデックス値がずれていきましたが、Base Indexから場所を計算することで順番通りでない挿入でも正しい場所にエントリを挿入できます。

Dependsがあることで、ブロックの処理を開始する前に必要なインデックス値を確認できるようになっています。

NginxがHTTP2サーバプッシュに対応したので試す

HTTP nginx

追記
[nginx-announce] nginx-1.13.9
http://mailman.nginx.org/pipermail/nginx-announce/2018/000207.html

1.13.9でサーバプッシュがサポートされました

先程、Nginxでサーバプッシュをサポートするコミットが入ったので試す。

HTTP/2: server push.
http://hg.nginx.org/nginx/rev/641306096f5b

ビルド

$ git clone https://github.com/nginx/nginx.git
$ cd ./nginx

$ ./auto/configure  --with-http_ssl_module --with-http_v2_module
$ make
$ sudo make install #一旦インストールしてしまう

設定

一旦 h2cで設定する。

$ sudo vim /usr/local/nginx/conf/nginx.conf
    server {
        listen       80 http2; #h2を有効化
        server_name  localhost;

        http2_push_preload on; #preload方式のプッシュを有効化
        location / {
            root   html;
            add_header "Link" "</test.js>;rel=preload"; #Linkヘッダを付ける
            index  index.html index.htm;
        }
    }
  • http2_push_preload onとすることで、Linkヘッダでpreload指定されたファイルをプッシュするようになる (リバースプロキシでバックエンドから送っても良い)
  • 今回は、add_header ヘッダで直接Linkヘッダを指定

preloadの詳しい仕様は
https://w3c.github.io/preload/ 参照

試す

$ sudo ./objs/nginx #起動

#nghttpで確認する。適宜インストールしてね
$ nghttp http://localhost -vn
....
[  0.004] recv (stream_id=13) :method: GET
[  0.004] recv (stream_id=13) :path: /test.js
[  0.004] recv (stream_id=13) :authority: localhost
[  0.004] recv (stream_id=13) :scheme: http
[  0.004] recv PUSH_PROMISE frame <length=23, flags=0x04, stream_id=13>

ちゃんと、PUSH_PROMISEが送られている。

良さそう。

ちなみに、Apacheの場合はこちら
asnokaze.hatenablog.com

Bundled HTTP Exchanges とは (WebPackagingの議論より)

internet-draft Web

20190709追記
draft 01が出ました。幾つかの修正が入っています。そのため、本記事は内容が古くなっています。
https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges-01

20180615追記
Bundled HTTP Exchangesの仕様がIETFに提出されました
https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges-00

WebPackagingという仕様が議論されている。簡単な概要は以下の記事に書いたとおり
asnokaze.hatenablog.com

WICG/webpackageで書かれている通り、WebPackagingは以下の2つに分離して標準化が進められそうです

  • Signed HTTP exchanges: HTTPリクエスト/レスポンスをブラウザが信頼できるように署名する仕組み
  • Bundled HTTP exchanges: 複数のHTTPリクエスト/レスポンスを一つのCBOR形式で表現できるようにする仕組み


Signed HTTP exchangesの方は、既にIETFに提案しようが出ており下記の記事で軽く触れた。
asnokaze.hatenablog.com


Bundled HTTP exchangesの方は、未だIETFには提出されていないが、著者様の個人リポジトリにdraftがあるため軽く読んでおく。
（まだIETFに提出されていないため変更される可能性があります）

Bundled HTTP exchanges

仕様は「https://jyasskin.github.io/webpackage/bundles/draft-yasskin-dispatch-bundled-exchanges.html」から確認できる

bundleは複数のHTTPリクエストレスポンスを一つにまとめる。データ構造はCDDLで記述する。

bundle = [
  ; 🌐📦 in UTF-8.
  magic: h'F0 9F 8C 90 F0 9F 93 A6',
  section-offsets: {* (($section-name .within tstr) => uint) },
  sections: [* $section ],
  length: bytes .size 8,  ; Big-endian number of bytes in the bundle.
]

$section-name /= "index" / "manifest" / "critical" / "responses"

$section /= index / manifest / critical / responses

responses = [*response]

まず最初にメタ情報のロードが行われる

  • bundleは🌐📦であるmagicから開始される
  • 続いて、0以上のsection-offsetsが続く。
    • section-offsetsのkeyは、"index", "manifest", "critical", "responses"のどれかである (未知のセクションは無視される)
    • section-offsetsのvalueは、それらのセクションが何バイト目から開始されるかのオフセットである。
  • sectionは各セクションの構造毎にパースされる
    • responsesは実際にデータをロードする際にパースされる。
  • lengthは、このbundleの長さ

indexセクション

HTTPリクエストに対応するレスポンスが、responsesセクションのどこに存在するかのインデックス。responsesセクション開始からのオフセットと長さが与えられる。

index = {* http-request => [ offset: uint,
                             length: uint] }

http-requestは下記の構造で表現される

http-request = {
  * bstr => bstr
}

manifestセクション

bundle自身を識別するためのマニフェストファイル(Web App Manifest形式)へのHTTPリクエスト情報。

manifestセクションはhttp-requestからのみなる

manifest = http-request

詳しくは (Web App Manifest形式)

criticalセクション

将来のバージョンを想定して、未知のセクションは無視されるが、サポートすべきセクション名を記述できる。

criticalセクションは以下の通り

critical = [*tstr]

ココに書かれているsection-nameをサポートしていない場合はパースは失敗となる。

responseセクション

responseセクションは下記の通りである

response = [headers: {* bstr => bstr}, payload: bstr]

各responseはレスポンスヘッダと、HTTPボディであるペイロードからなる。ヘッダとしてステータスコードを示す":status"を含めなければなりません。

QUICの現状確認をしたい 2018/2 (MTU, Migration, Packet Number Encryptionなど)

QUIC 雑 internet-draft

3月分も書きました
asnokaze.hatenablog.com

QUICの標準化状況に関して、幾つかトピックを取り上げる

シリーズ化するつもりは無いが、1月に書いたので、今回は2月初旬版
qiita.com

拾いきれてないトピック沢山有るので、皆さんも是非補足して頂ければ

目次

Draft-09

1月末に4つのコアドキュメントのdraft-09が出る

Call for Adoption

1月に行われたQUIC Interimの議論を経て、２つのドキュメントがCall for Adoptionとなっている

QUICのHTTPヘッダ圧縮については幾つか提案があり、ながく議論されていたがその一つがAdoptionされることは追う側としては喜ばしい。WG Draftが出たら読み直そうと思う

詳しくは以前書いた記事を参考に

接続性テスト(Interoperativity)

QUICにおいても、標準化段階から実装を持ち寄って接続性テストを行うことで仕様の確度を高めている。

1月に行った3rd Implementation Draftのinterop結果は以下の通り表にまとめられている。
docs.google.com


今後は4th Implementation Draftでinteropが実施される

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というフレームタイプである。
f:id:ASnoKaze:20180206001133p:plain


両方共、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を持ちます。未知の拡張タイプは無視されます
f:id:ASnoKaze:20180206155611p:plain

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を提案しているようだ。

Application-Layer TLS の標準化動向

HTTP TLS internet-draft 雑

IETFでApplication-Layer TLSの議論が行われ始めているので、雑に書き留めておく

Application Transport LAyer Security (Atlas)

前回、アプリケーションレイヤでTLSを喋る「HTTP over TLS」について、記事を書いた。
asnokaze.hatenablog.com


その後、IETFでは、Application Transport LAyer Security (Atlas) というメーリングリストが開設され、WG化のためのチャータの議論が行われています。


以前取り上げたHTTP over TLSのユースケースの他にも

f:id:ASnoKaze:20180201082004p:plain
f:id:ASnoKaze:20180201084938p:plain

例えばIoT機器などのデバイスが、Zigbeeであったり、CoAP/DTLS などでゲートウェイと通信し、ゲートウェイからプロトコルを変えインターネットに出ていくようなケースにおいても、エンドツーエンドで暗号通信したい場合があります。その際にエンドツーエンドでの鍵交換の仕組みを新しく作るのではなく、アプリケーションレイヤでTLSのやり取りを行い、鍵交換を行い、中間装置の影響を受けずに暗号通信できるようにします。


まだ、チャーターの議論が始まったばかりで、たたき台(URL)はあるものの、これからいろいろな人の意見を受けて変わるでしょう。ただ、IoT関連を強く意識しているようです。


いまのところでは、下記の提案仕様をWGアイテムとして扱うところを目指し


さらに、大津先生が書かれていたGoogleのATLSもスコープに含まれているようです。
しかし、紛らわしいですが今あるIETF側のドキュメント類はGoogle ATLSとは別物です。
jovi0608.hatenablog.com


2018年 秋頃にユースケースやApplication-Layer TLSのドキュメントをIESGに送る事を考えているようです。

Application-Layer TLS

ATLS (WGとしてATLASだけど、プロトコルはATLSと描かれる)に関するドキュメントとして、下記の２つがありました

  • draft-friel-tls-over-http-00
  • draft-tschofenig-layered-tls-00

これらはマージされて、「Application-Layer TLS (ATLS)」draft-friel-tls-atlsとなりました。それぞれのユースケースを想定し、ATLS over HTTP, ATLS over CoAP について記述されています。


接続の確立時の、クライアント・サーバの各コンポーネント間のやり取りは下記のとおりです。
AppはATLSコンポーネントにTLSメッセージを作らせ、使用するトランスポート上で送信します。そのようにしてTLSハンドシェイクを行います。
f:id:ASnoKaze:20180201083853p:plain

DNSで負荷分散を可能にするLBレコードの提案

internet-draft dns

名前解決を行っているクライアントの国や地域によって、近い場所のサーバのIPを返すといったことは既に行われている。しかし、そのDNSによる負荷分散の方法は標準化されていない。

「DNS load balancing」という提案仕様では、新しくLBレコードを定義し、権威DNSサーバからフルリゾルバに対して負荷分散のための情報を伝達できるようにします。

日本の方が書かれている提案なので緊張感がありつつも、ざっと読んでみたので簡単に書く。

LBレコード

LBレコードは、分散のための情報と重みと、分散先を示すを持つ

例えば

# <owner> <ttl> <class> LB <weight> <location> <target>
   example.jp. 3600 IN LB 1 AP ap.example.com.
   example.jp. 3600 IN LB 1 JP jp1.example.jp.
   example.jp. 3600 IN LB 3 JP jp2.example.jp.
   example.jp. 3600 IN LB 1 JP-13 tokyo.example.jp.
   example.jp. 3600 IN LB 1 AS2496 as2497.example.jp.
   example.jp. 3600 IN LB 1 AS2496:1 as2497.example.jp.
   example.jp. 3600 IN LB 1 +BEER beer.example.jp.

地域としてAP, 国としてJP, 日本の都道府県コードで東京を示すJP-13, AS番号も指定可能であるほか、プライベートユースとして+から始まる文字列が使用できる。

が同じ場合は、Weightによって使い分けることが出来る。

流れ

f:id:ASnoKaze:20180127020236p:plain
(一部省略)

Authoritative name serverが下記のようなレコードを持つとする

   example.jp. 3600 IN A 198.51.100.1
   example.jp. 3600 IN LB 1 * www.example.com.
   example.jp. 3600 IN LB 1 JP jp1.example.com.
   example.jp. 3600 IN LB 3 JP jp2.example.com.
  • 1) スタブリゾルバがフルリゾルバに問い合わせる
  • 2) フルリゾルバはAuthoritativeサーバに問い合わせる際に、LBレコードに対応している旨を示すLB Support Flagを立てて名前解決を行う。
  • 3) Authoritativeサーバは問い合わせに対応するLBレコードを返す。
  • 4) フルリゾルバは受け取ったLBレコードの中からスタブリゾルバに適切なLocationを選択しWeightより「jp1.example.com.」を選び、解決しスタブリゾルバに応答する

DNS ALTSVC recordの提案仕様

HTTP dns internet-draft

Alternative ServicesをDNSで通知できるように、ALTSVCレコードを定義する「Finding HTTP Alternative Services via the Domain Name Service」という仕様が出ています。

DNSレコードタイプの議論ですが、HTTPbis WGから議論が始まっています。

HTTP Alternative Services

Alternative Servicesは、オリジンを別のエンドポイント、別のプロトコルで提供できることをクライアントに通知する仕組みです。

例えば、現在もQUICの通信を始める際はHTTPレスポンスヘッダで自身のサービスはQUICでも提供できることを通知しています。

googleにアクセスすると、下記のようにalt-svcヘッダを付けてきます

alt-svc:hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"

現在alt-svcを通知する方法は 「RFC7838 HTTP Alternative Services」で定義されているとおり

  • alt-svcレスポンスヘッダを用いる
  • HTTP/2でALTSVC frameを使用する

これらは、HTTPの通信が始まってから切り替えを行う流れになります。

より早いタイミングで、Alternative Servicesを通知するためにDNSレコードを使う方法が出てきたというわけです。

DNS ALTSVCレコード

Alternative Servicesを通知するALTSVCレコーとタイプを新しく定義します。

例えば、このようなalt-svcレスポンスヘッダは

Alt-Svc: h2=":8000"; ma=60

このようなDNSレコーとなります

_https._443.www.example.com. 60S IN ALTSVC "h2=\":8000\""

クライアントは、A/AAAAレコードを取得する際にALTSVCレコードも問い合わせ、Alternative Servicesを確認することでより早く代替エンドポイント・プロトコルで接続することが出来ます。

何故SRVレコードを使わないのか

似たようなレコードとして、SRVレコードが有ります。SRVレコードはそのドメインが対応しているか確認できる。

例えば、「_http2._tcp.example.com.」のように問い合わせる。

このSRVレコードを使わない理由としては以下などがあげられている

  • プロトコルのアップグレードすることを指示できない
  • パラメータの拡張性がない
  • 後の接続でAlt-Svc情報の処理をスキップ出来ない