QUICのMultipath拡張に関するメモ

2021/10/26 追記
最新仕様は https://datatracker.ietf.org/doc/html/draft-lmbdhk-quic-multipath-00 こちら
asnokaze.hatenablog.com

---

QUICのMultipath(マルチパス)拡張に関して、2020年10月にQUIC WG中間会議で議論が行われているので、現状について簡単にまとめる。

はじめに

QUICおよびHTTP/3のドラフト仕様がLast Call (URL)になり、標準化としては大詰めを迎えている。

それにともない、IETF QUIC WGのメーリングリストではQUICのMultipath拡張について、どう取り組んでいくかの議論が盛り上がっている。

Multipath拡張とは、例えばスマホのWi-FiとLTEのように複数のネットワーク(path)を同時に使ってコネクションを張る方式のことです。Multipathを利用する通信としては、TCPのMultipath拡張であるMultipath-TCPがすでにRFC(RFC 8684)となっており、iOSやLinus Kernelでサポートされている。

このMultipathをQUICでも行いたいという話である。

IETFでQUIC WGを設立した際にcharter(URL)として、作業領域および目的を定めたたが、その中にもMultipath拡張を検討する旨記述されている。今標準化を行っている QUIC v1ではこのMultipath機能は取り込まれず拡張仕様として別途議論することと成ったが、そのv1の標準化の終りが見えてきた今、改てMultipath拡張の標準化をどう進めていくかの議論が始まったのである。

まだ、どうなっていくか分からないところだが、中間会議での議論を踏まえて一旦状況を纏めておきたいと思う。

提案仕様

現在、Multipath拡張を実現する提案仕様は、別々に3つ出されている (そのうち2つが同じ仕様名なので注意)。まず最初に簡単に紹介したい。

• 「Multipath Extensions for QUIC (MP-QUIC)」
• 「QUIC Multipath Negotiation Option」
• 「Multipath Extension for QUIC」

Quentin De ConinckらによるMP-QUIC

1つ目の「Multipath Extensions for QUIC (MP-QUIC)」はルーヴァン・カトリック大学、Quentin De Coninckらによる提案である。

2017年頃から提案している、Multipath拡張仕様のうち一番古くからとりくまれている仕様。初期に、MPTCP v0のデザインの影響を受けている。Connection ID毎に単方向のUniflowsを持つ、

すでにGoを用いた実装が行われており、論文なども出されている。

• 実装: https://github.com/qdeconinck/mp-quic
• 論文: https://multipath-quic.org/conext17-deconinck.pdf

QUIC Multipath Negotiation Option

2つ目の「QUIC Multipath Negotiation Option」はPrivate Octopus IncのChristian Huitema氏による提案である。現在のMultipath 拡張の盛り上がりをうけて、今月提出された仕様である。

これは、その他のMultipath拡張とは異なりPathごとの通信識別子を持たず、QUIC v1がすでに持っているコネクションマイグレーションを利用します。マイグレーションとは異なり、複数のPathをactiveなままに維持します。

AlibabaのMultipath Extension for QUIC

3つ目の「Multipath Extension for QUIC」はアリババ勢による提案である。こちらも、現在のMultipath 拡張の盛り上がりをうけて、今月提出された仕様である。

これは、Quentin De ConinckらによるMP-QUICを参考にしつつも、PathごとにSubConnectionとする構成を持つ。どうやら、すでに中国の特定動画ストリーミングサービスでユーザが使えるようになっているらしく、規模を拡大しつつ実験中らしい。

QUIC WG 中間会議

冒頭に述べたように、Multipath拡張をどう進めていくか盛り上がる中で会議を行い、それぞれのユースケースや知見について共有を行う場が用意された。

発表資料および、議事録は 下記から見ることが出来る。
github.com

この会議の中で

• Googleらによる、gQUIC時代におけるMultipath拡張の実装及び考察が共有された。実装やPathをまたぐ再送制御やスケジューリングが複雑になったこと、多くの場合はコネクションマイグレーションで十分ではないかという話が共有された
• Apple勢による発表では、MPTCPの利用経験から、SiriやApple Musicの例をあげてQUICのMultipath拡張に求められる要件が共有された
• アリババグループによる、動画ストリーミングのMultipath事例や、その他のユースケースに説明された。また、動画読み込みが早くなったというデモ動画も共有されている
• Akamaiのユースケースとして、多段キャッシュサーバ構成において2段目からダイレクトにクライアントにレスポンスを返すユースケースが紹介された

その他にも、衛星通信と地上での通信をMultipathで利用すると言ったユースケースなども共有されている。

これらの議論を通して、Multipath拡張のユースケースと有用性が確認された。

一方で、QUIC WGとしてどのようとりくんでいくかは、進め方の議論をしている段階である。例えば、Martin Thomson氏がメーリングリストに投稿した「My BoF report: multipath」では、Multipath拡張といった大きな取り組みの前に、QUICをデプロイし知見をためつつ、バージョンネゴシエーションといった大きな取り組みの前に準備する必要があると言っています。

その他にも、いくつか目的やデプロイ形式が異なるユースケースを、一つの仕様でカバーしようとすべきではないなどの意見が出ています。

議論の続き

QUIC WGとしてまだ、Multipath拡張をどう進めていくかは議論の最中です。

議論はメーリングリストで行われているので、気になる方はそちらを御覧ください
https://mailarchive.ietf.org/arch/browse/quic/

Permissions PolicyとDocument Policyについて

Chromeに、Permissions PolicyとDocument Policyという仕様の実装が進められています。

今回は、ブラウザがwebページを表示する際に制限を与えるこれらの機能について説明していきます。

仕様は下記から参照できます

• Permissions Policy
• Document Policy

あわせて、blink-devメーリングリストのintentやexplainerを読むと分かりやすいかと思います

• Intent to Ship: Permissions-Policy header
• Intent to Ship: Document-Policy header

これらはiframe先へのdelegationについて違いがあります (追記予定)

Permissions Policy

Permissions-PolicyはHTTPレスポンスヘッダで、ブラウザのカメラや位置情報の取得といったpowerful featuresへのアクセス制御を行えます。これによってFeature Policyは置き換えられます。

下記のヘッダ例は、位置情報の取得はself(今表示しているサイト)及びiframeではhttps://foo.com で利用できます。カメラは利用できません。フルスクリーンの機能は利用できます。（なお、このヘッダはStructured Field Values for HTTPに則ってます）

Permissions-Policy:
    geolocation=(self "https://foo.com"),
    camera=(),
    fullscreen=*

上記のヘッダを踏まえて、iframeで埋め込んだページで、各機能へのアクセスを許可するためにallow属性を付ける必要があります。

<iframe src="https://foo.com/" allow="geolocation; camera">
</iframe>

Document Policy

Document PolicyはHTTPレスポンスヘッダで、Webの表示が遅くなる要素を制限することが出来ます。

下記の例では、マークアップ上でサイズが指定されていない画像や、document.writeを無効にしています。また、画像の最大bppを制限し、デフォルトでframeの読み込みをLazy Loadにしています。（このヘッダもStructured Field Values for HTTPに則ってます。）

Document-Policy: unsized-media=?0, document-write=?0,
                 max-image-bpp=2.0, frame-loading=lazy

Permissions Policyと同様にiframe先のページにも制限を課すことが出来ます。

<iframe src="https://img.example.com/"
        policy="unsized-media=?0, max-image-bpp=2.0">

Document Policyでは埋め込んだページを取得する際に、課せられている制限を通知します。

• 1. クライアントがexample.comにアクセスし、img.exapmle.com へのiframe要素を処理します。このときiframeのpolicy属性でDocument Policyが指定されています。
• 2. クライアントはimg.example.comにアクセスします。このときDocument Policyが課せられていることを示すSec-Required-Document-Policyヘッダを付けてリクエストします。
• 3. img.example.comはDocument Policyの制約を満たすようなレスポンスを返します(Document-Policyヘッダをレスポンスに含める)
• 4. クライアントは受け取ったDocument-Policyヘッダが、example.comによって課されている制約を満たすことを確認します。

Reporting

Permissions PolicyもDocument PolicyもReporting-APIの機能を持っており、policyに違反があった場合レポートをageさせることが出来ます。

Document-Policy-Report-Onlyヘッダを用いることで、policy違反をブロックすること無くレポートのみを送らせることもできます。

詳しくは仕様を参照ください。

ChromeのSecure context restriction for external requests

[目次]

非セキュアコンテキストなWebサイトからプライベートアドレスへのHTTPリクエストをブロックする「Secure context restriction for external requests」の導入が進められています。

概要

インターネットに公開されているWebサイトから、プライベートアドレスに対するCSRF攻撃が問題になっています。ネットワーク機器やプリンタの管理画面で使われるプライベートアドレスにリクエストを行わせることで、攻撃が行われます。

例えば下記のリンクを埋め込むことで、プライベートネットワークを指すrouter.local にHTTPリクエストを行わせます。

<iframe href="https://admin:admin@router.local/set_dns?server1=123.123.123.123">
</iframe>

具体的には下記のドキュメントを御覧ください

• drive-by pharming
• An Exploit Kit dedicated to CSRF Pharming

そういった攻撃を防ぐ仕組みが現在検討されています。

• CORS-RFC1918
• Secure context restriction for external requests

現在、最初のステップとして後者の「Secure context restriction for external requests」が Chromeで導入が進められているので簡単に見ていく。

Secure context restriction for external requests

CORS-RFC1918に先んじて、「Secure context restriction for external requests」がChrome 87のdev/canary/beta版で導入が予定されています。

これは、非セキュアコンテキストのサイト(http://なサイト)から、プライベートアドレス, ループバックアドレスに対するリクエストをブロックする機能です。

Chrome Canaryではabout:flagsから「Block insecure private network requests.」を有効にすることで動作を確認できます。

実際に、http://example.comで、デベロッパーツールからプライベートアドレスに対してリクエストを送信させています。

このように ERR_INSECURE_PRIVATE_NETWORK_REQUEST になってリクエストがブロックされている事が確認できます。

CORS-RFC1918

なおCORS-RFC1918 については、以前書いたとおりです
asnokaze.hatenablog.com

W3Cのミーティングでは、Chromeで実装が進められている事が書かれています
https://github.com/w3c/webappsec/blob/master/meetings/2020/2020-09-15-minutes.md#cors-rfc1918

動作確認できるようになったらまた記事を書ければと思います。

Linux 5.6 から Multipath TCPが使える

Linux 5.6から Multipath TCP(mptcp)が使えるようになった。複数インターフェースを使ってTCPコネクションをはり効率のよく通信を行う仕組みです。mptcp v0がRFC 6824で、mptcp v1がRFC 8684で標準化されています。

すでに、iOSでは利用が始まっています。
asnokaze.hatenablog.com

来月リリース予定である、Ubuntu 20.10 は Kernel 5.8 が入っており、mptcpが使えるのか試してみようと思いました。

有効になってることを確認

イメージを公式サイトから落としてきて起動します。

$ uname -a
Linux y 5.8.0-19-generic #20-Ubuntu SMP Fri Sep 11 09:08:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ sysctl -a |grep mptcp
net.ipv4.tcp_available_ulp = espintcp mptcp
net.mptcp.enabled = 1

すでにmptcpが有効になっていることを確認できます。

試す

redhatさんの記事(URL)では、stapを用いて既存のアプリケーションを変更無くmptcp対応を行っていましたが、うまく行かなかったので自力でmptcp通信を行います。

とは言ってそんなに難しいことはなく、ソケットオプションにIPPROTO_MPTCPを指定するだけで

fd = socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);

下記ページのコード参考にすれば、比較的容易にクライアントとサーバを用意できました。
www.toumasu-program.net

パケットキャプチャ

通信をキャプチャすると、mptcp v1 で通信が行えていることが確認できます。

残課題

ちゃんと複数インターフェースでザブフローしゃべるところまで確認したい

WiresharkがHTTP/3に対応した

本日、Wiresharkが「Development Release (3.3.0)」を公開しました。

このバージョン3.3.0ではHTTP/3のサポートが入っています。ダウンロードして早速試していきましょう。

結果

HTTP/3レイヤの単方向ストリームタイプや、フレームタイプが確認できます
(QUICを復号する必要はあります)

もちろん、「http3」というフィルタも使用できます。

ただ、まだ開発途中であり、基本的な部分しか実装されておりません。そのため、まだパースされない部分もたくさんありますが、今後の開発に期待です。

補足

• 今回はFirefox Nightly と google.com の通信をキャプチャしました
• 現時点でWiresharkがサポートしているのはQUIC(draft-21~draft-30), HTTP/3(draft-29), QPACK(draft-16)になります
• HTTP/3はQUICにより暗号化されているので、復号するために環境変数にSSLKEYLOGFILEを設定しました。復号方法は下記を参照

asnokaze.hatenablog.com

おまけ

こちらもよければ
asnokaze.hatenablog.com

DNSのエラー理由を通知するExtended DNS Errorsの仕様 (RFC8914)

DNSでは、DNSSECでの不整合や、ポリシーによってブロックされて問い合わせがエラーとなることがあります。

Google Chromeでは「Extended DNS Errors(EDE)」という仕様のサポートが検討されています。これは、問い合わせに対するエラー原因を通知するための仕様で、EDNS0のオプション領域にエラーコードとエラー文を含めて応答できるようにするものです。現在IETFで標準化中になります。

これによってDNSのエラー原因がわかりやすくデバッグが用になるほか、ユーザへのエラー画面を出す際により分かりやすい文言を出せるようになります。

Chromeでの実装検討の詳細については下記の資料を参照ください。
https://docs.google.com/document/d/1PItRbCJHgv1CcqjnkOw1F8oup3oISkMf_xxKZmqGhiU/edit#heading=h.7nki9mck5t64

ここでは、Extended DNS Errorsを簡単に紹介します

Extended DNS Error EDNS0 option

EDNS0のOPTIONとして、定義されています。

• OPTION-CODE: EDNS0としてのオプション番号
• OPTION-LENGTH: オプションの長さ
• OPTION-CODE: エラー番号
• EXTRA-TEXT: エラー内容を示す文字列

このオプションがレスポンスに追加されて返されます。

定義済みエラー

下記のエラーコードが仕様で定義されています。ざっと、雰囲気がわかるかと思いますが、エラーコードの詳細については仕様(URL)を参照ください。

• 0 Other
• 1 Unsupported DNSKEY Algorithm
• 2 Unsupported DS Digest Type
• 3 Stale Answer
• 4 Forged Answer
• 5 DNSSEC Indeterminate
• 6 DNSSEC Bogus
• 7 Signature Expired
• 8 Signature Not Yet Valid
• 9 DNSKEY Missing
• 10 RRSIGs Missing
• 11 No Zone Key Bit Set
• 12 NSEC Missing
• 13 Cached Error
• 14 Not Ready
• 15 Blocked
• 16 Censored
• 17 Filtered
• 18 Prohibited
• 19 Stale NXDOMAIN Answer
• 20 Not Authoritative
• 21 Not Supported
• 22 No Reachable Authority
• 23 Network Error
• 24 Invalid Data

HTTP/2の仕様、改定作業が始まる

[追記] 2021年10月時点の変更点について新しく記事を書きました
asnokaze.hatenablog.com

==

もくじ

HTTP/2の改定作業

HTTP/2の仕様は2015年に「RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2)」として標準化されています。

RFCは公開されたあとに、エラッタが見つかることがあります。このようなエラッタを修正するために、新しくRFCを出し直すということが行われます。

HTTP/2においてもいくつかのエラッタが公開されています (参考リンク)。そのため、それらを修正するためのたたき台として、MozillaのMartin Thomson氏によって改訂版の草案となる「http2bis」が提出されています。

Martin Thomson氏のたたき台は用語の修正とエラッタの修正のみが含まれていますが、IETF HTTP WGのメーリングリストでこの改定作業に含める修正ポイントについて議論が行われています(参照: Time to refresh HTTP/2?)

その議論になっている修正ポイントについて目を通していきます

（これらは議論中であることに注意してください。改訂版に必ず含まれるわけではありません。）

修正点

優先度制御について

HTTP/3の標準化の中で、HTTPにおける優先度制御について見直しがされています。そのため、HTTP/2におけるweightとdependencyを用いた優先制御をHTTP/2の仕様に残すかという議論が出ています。

もちろん、相互運用上問題にならないようにフレームのフィールド定義などは変更しないでしょうが、仕様としてどのような言及になるかは気になるところです。

新しい優先制御方式については以前書いたとおりです。
asnokaze.hatenablog.com

TLS1.3および0-RTT

HTTP/2の仕様はTLS1.3より以前に標準化されています。そのため、それらについて言及されていません。

同様に0-RTTについても言及がありません。0-RTT時のサーバSETINGSといったトピックや、RFC8470などへの言及が考えられます。

GREASEのコードポイントの予約

GREASEの予約について。GREASEは以前書いたとおり
asnokaze.hatenablog.com

疑似ヘッダの扱い

定義されていない疑似ヘッダの使用は禁止されていましたが、RFC 8441 WebSockets over HTTP2では :protocol という疑似ヘッダを追加しています。

あとから出たRFCで追加定義を行うことは、仕様上問題ではありませんが、新しく :protocolの使用を許可するか、禁止というのを緩和するかの判断余地があります。

RFC 8441は以前書いた通り
asnokaze.hatenablog.com

h2cの削除

2020/09/10 修正
TLSを利用しない平文のHTTP/2を削除

http/1.1からのupgradeメカニズムの議論
github.com

セマンティクス仕様への参照

HTTP/2の頃は、HTTPのセマンティクスとしてHTTP/1.1の仕様であるRFC 7231を参照していました。

現在、IETF HTTP WGでは、HTTP/1.1の仕様からHTTPのセマンティクスと、HTTP/1.1のフォーマットの仕様を分離し下記のように整理する作業を行っています。

• HTTP Semantics
• HTTP/1.1 Messaging

HTTP/3のdraftではすでにHTTPのセマンティクス定義として上記を参照するような形になっていますが、HTTP/2の改訂版ではどうするか議論の余地があります。

そのた参照の更新

HTML5の仕様として下記をさんしょうしているので更新する

• https://www.w3.org/TR/2014/REC-html5-20141028/

security considerations の追記

RFC発行後に見つかった実装上の脆弱性について、追記を行う。
例えば、CVE-2019-9511 ~ CVE-2019-9518 など

参考: https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md