QUIC, HTTP/3, Web関連の標準化トピック (IETF 107)


IETFで議論されている、HTTP/3やWeb関連の応用トピックについて、次回ミーティングセッションに合わせ紹介していく。

## IETF 107について
QUICやHTTP/3は現在IETFで標準化が進められています。

そんなIETFの107回目のミーティングが今週(3/23~27)から開催されます。元々はバンクーバーで開催予定でしたが、急遽リモートでの開催となりました。

それに合わせ、開催セッションも少なくなっています([Agenda](https://datatracker.ietf.org/meeting/107/agenda)参照)。開催されるセッションは、今後の作業の進め方を決める必要がある初開催のWGや、BoF（同じ課題に興味を持つ人々の集まり。ここからWGになることもある）

開催されるセッションは少ないものの面白いトピックが多いので、HTTP/3やWeb関連のものを簡単に紹介していく。
(HTTP WG, QUIC WGは非開催のためそっちの標準化動向は[マイルストーン](https://datatracker.ietf.org/wg/quic/about/)を確認ください)

なお、技術的詳細を説明することは避ける。需要があれば別途解説を行う

## WebTransport BoF
WebSocketに変わるWebTransportという新しい双方向メッセージングプロトコルについて議論を行うBoF。

QUICやHTTP/3上を利用するのが特徴です。これらはUDPであるため、下記のようなことが実現できます。

- パケットロスがあっても、再送を要求しない
- パケットの順番が入れ替わっても届いた順に処理することができる

![EO4eOCfVUAIucp9.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/32425/53c68e0e-1d7c-339a-d855-bb08ce6f3770.jpeg)
(IETF106の発表資料より)

また、ブラウザ側のAPI仕様については、W3CのWICGで議論がされています[WICG/web-transport](https://github.com/WICG/web-transport)


細かい話は手前味噌ですが、ここらへんに書いてあります。

- [新しいWebの双方向通信 "WebTransport" について](https://asnokaze.hatenablog.com/entry/2019/05/04/012514)
- [WebTransport over QUIC について](https://asnokaze.hatenablog.com/entry/2019/10/10/015423)
- [WebTransport over HTTP/2 の仕様について](https://asnokaze.hatenablog.com/entry/2020/03/11/015557)

## Web Packaging BoF
AMP(Accelerated Mobile Pages)が持つ課題を改善するために、登場したSigned HTTP Exchanges（SXG）は、ヤフージャパン様を始めすでに使用され始めております。([SXG（Signed HTTP Exchanges）始めました](https://techblog.yahoo.co.jp/web/trial_sxg/))

このように、Webサイトをオリジンの証明をつけて再配布できるように、Webパッケージ形式の標準化を検討するBoFです。

もちろん、CDN以外にもオフラインなど再配布経路は様々なユースケースが考えられています。

現在は主に2つの仕様が議論されているところになります。

- [Signed HTTP Exchanges](https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-08)
- [Web Bundles(Bundled HTTP Exchanges)](https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges-02)

その他にも、W3C側でもパッケージングされたファイルをどうブラウザでローディングするか議論がされています([Loading Signed Exchanges](https://wicg.github.io/webpackage/loading.html))

## Multiplexed Application Substrate over QUIC Encryption BoF (MASQUE)
MASQUEプロトコルと呼ばれる、QUICやHTTP/3上で複数のフローをトンネリングする方法について議論をするBoFです。

少々古いですが「[HTTP/3で接続してVPNとして使うMASQUEプロトコルの提案仕様](https://asnokaze.hatenablog.com/entry/2019/03/02/144708)」に書いたとおりになります。

これからユースケースや要件について議論が始まるところです。

提案仕様は以下の通り

- [The MASQUE Protocol](https://tools.ietf.org/html/draft-schinazi-masque-protocol-01)
- [MASQUE Obfuscation](https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-02)

## Realtime Internet Peering for Telephony BoF (RIPT)
SIP(Session Initiation Protocol)に変わるWeb上で動作する新しいRIPTというプロトコルの議論を行う、今回から議論が始まるBoF。

RIPTでは、既存のWeb技術上で動作するようことが念頭に置かれており、HTTP/3上で通話のシグナリングや動画音声をやりとり可能なものを目指している。現在のクラウドサービスでも利用できるように、ロードバランサやオートスケールも行えるようにする。

そのために、TG URIというエンドポイントおよび、やりとりするメッセージを定義する。

現在以下の提案が提出されている

- [RealTime Internet Peering for Telephony](https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ript-00)
- [RIPT Compatibility with webRTC](https://datatracker.ietf.org/doc/draft-rosenberg-dispatch-ript-webrtc/)
- [RIPT Comparison with the SIP](https://datatracker.ietf.org/doc/draft-rosenberg-dispatch-ript-sipdiffs/)
- [RealTime Internet Peering for Single User Endpoints](RealTime Internet Peering for Single User Endpoints)

## Transactional Authorization and Delegation BoF (TxAuth)
発起人によりXYZやOAuth3.0と呼ばれることもある、OAuth 2.0とOpenID Connectなどのユースケースをカバーする Transactional Authorization and Delegation を実現する新しいプロトコルの議論を行う。

今の所、発起人を含む2名からそれぞれ別の提案が出ています

- [Transactional Authorization](https://tools.ietf.org/html/draft-richer-transactional-authz-06)
- [The XAuth Protocol](https://tools.ietf.org/html/draft-hardt-xauth-protocol-05)

## Adaptive DNS Discovery BoF (ADD)
DNS over HTTPS (DoH)、DNS over TLS(DoT)というプロトコルがすでに標準化されています。これらに対応したDNSサーバをどのように検出し選択するか様々な観点で議論が行われています。

例えば、ブラウザベンダーはそれぞれ独自に検討している状況です。

- Chrome: すでに使っているDNSサーバが対応していれば自動アップグレードする([chromium wiki](https://www.chromium.org/developers/dns-over-https))
- Firefox: 自動で使用するが、ネットワーク管理者がオフにすることができる(Canary Domain)

Adaptive DNS Discovery BoFは、パブリックネットワーク、プライベートネットワーク、VPN上で技術的にどのように実現するか議論を行うBoFです。

以下のような提案仕様が出されています。

- [DNS Resolver Discovery Protocol (RDP)](https://datatracker.ietf.org/doc/draft-mglt-add-rdp/)
- [Signaling resolver's filtering policies](https://datatracker.ietf.org/doc/draft-mglt-add-signaling-filtering-policies/)
- [DNS Server Selection: DNS Server Information with Assertion Token](https://datatracker.ietf.org/doc/draft-reddy-add-server-policy-selection/)


## privacy-pass BoF
Privacy Passという技術について議論するBoFです。

これは、以前承認したユーザを、ユーザは特定しないが以前承認したことがあるというのを証明する技術です。複数のサイトで同じようなにBOTでないことを確認させられます。

privacy-passでは、ユーザがいつどのサイトを訪れたかは確認できないが、たしかに以前BOTではないことを証明したユーザであるということが証明できるようになります。これにより何度もBOTの確認は行われない上、行動トラッキングも防ぐことができます。

(もちろん、CAPTCHAの例を上げましたがユースケースはこれだけに限定されるものではありません。)

CloufFlareがすでに提供しています「[プライバシーパスプロトコル最新バージョンのサポート](https://blog.cloudflare.com/jp/supporting-the-latest-version-of-the-privacy-pass-protocol-jp/)」


## おわりに
紹介したトピックのうち、Web Packaging、WebTransport、Privacy Passのように実装が進めらられているものもあります。

一方で、まだまだ技術的な部分や作業領域がこれから議論となる取り組みもあります。

IETFのリモート参加は無料ですので、是非興味のある方は参加してみてはいかがでしょうか (日本時間で朝5:00~9:00の枠ですが...)

IETF107のトップページから参加申込みができます

https://www.ietf.org/how/meetings/107/