WebでのIPマルチキャストの利用検討 (Multicast Community Group)

W3Cに新しく、Webでのマルチキャストの利用を検討する「Multicast Community Group」が立ち上がるので、そのCharterに目を通しておく。

w3c.github.io

ここまでの関連する動き

まずは、ココまでの動きを簡単に紹介する。

以前、紹介したように、インターネットのトラフィックは日に日に増えている。
その対策として、ブラウザでIPマルチキャストを受け取れるようにし、効率的なデータ配信をするという動きがある。

asnokaze.hatenablog.com

JavaScriptAPIとしては、blink-devでも議論されている通り「Multicast Receive API」がある。
github.com

プロトコルとしてはIETFで、インターネット上でマルチキャストを配信するための仕組みが検討されている。

f:id:ASnoKaze:20210614010641p:plain

最新の情報は、今年4月に発表されたスライド「Multicast for the Web(pdf)」を御覧ください。

Multicast Community Group

Multicast Community Groupは、IPマルチキャストを用いてWebの通信のスケーラブルな効率化を目指す。

ユースケースについて議論し、IPマルチキャスト通信におけるAPIを定義する。パラメータの交換やアプリケーションレイヤのネゴシエーションなどを可能にする。(ネットワーク、プロトコルレイヤはIETFで標準化)

Phase 1

Multicast Receive API」を出発点にし、WebTransportをマルチキャスト受信可能に拡張する。

Phase 2

その他の配信用APIマルチキャストを組み込む。例えば次のものなど

おわりに

CharterのDraftは「Start Date: 2021-06-22」となっているので、本格的にはその日から動き出すのかなと思いつつ

個人的には結構面白そうなので、引き続き動向をウォッチしておきチア。

サーバ証明書の不正発行に対するSCT Auditing

2011年頃、ドメイン所持者が意図せぬ形で、認証局よりサーバ証明書がご発行される事件がありました。この対策として、Certificate Transparency (CT) という仕組みが導入されました。

CTの仕組み

CTの利用の流れは幾つかありますが、一例を示します。
f:id:ASnoKaze:20210613213409p:plain

  • 1. 認証局が証明書を発行する際に第三者が運営するCTログサーバにプレ証明書を登録します。登録時に、登録の証左となるSigned Certificate Timestamp (SCT)が認証局に渡されます。
  • 2. 認証局は、登録時に得られるSigned Certificate Timestamp (SCT)を証明書に付与して発行します。
  • 3. ブラウザ(PC版Chrome)がWebサイトにアクセスする際、証明書にSCTがついてない場合は、エラー画面を表示します。

f:id:ASnoKaze:20210613211032p:plain
( https://no-sct.badssl.com/ )

ログサーバにあるドメインの証明書が登録されていることは誰でも確認することが出来ます。そのため、意図せぬ証明書が発行されていれば検知することが出来ます。

Chromiumが認識するCTログサーバは以下より確認出来ます。
github.com

SCT Auditing

SCTは、証明書がCTログサーバに登録されてる証左として扱われてました。つまり、SCTがついているサーバ証明書は、CTログサーバで必ず確認できるはずです。

しかし、CTログサーバが悪意を持って振る舞った場合、認証局にはSCTを払い出すが、登録情報を公開しないという事もできます。これでは、ドメイン所持者はCTログサーバを意図せぬ証明書が発行されているか確認できません。

そこで、ブラウザは、Webサーバを通して得られたSCTが本当にログサーバ上で公開されているか確認するというのが、Google Chromeで実装が進められているSCT Auditingです。この仕組では、疑わしいSCTをGoogleのサーバにレポートすることで実現されます

f:id:ASnoKaze:20210613231128p:plain

プライバシーの問題

SCT Auditing では SCTをブラウザからGoogleのサーバにアップロードするため、プライバシーの問題が発生します。つまり、ユーザがどのサーバと接続したのかが分かってしまいます。そこで、フェーズを2段階に分け、試しながらSCT Auditingを有効にしていく模様です。

  • phase 1: SCT Auditingをオプトインしたユーザのみ有効
  • phase 2: プライバシー保護を行い、その他のユーザも有効 (今の所デスクトップ版のみ)

現在、 phase 2の設計について議論が行われている段階です。
docs.google.com

phase 1

下記の通り、Opt in したユーザ

Webサイトの閲覧の安全性向上のためにGoogleのサーバに情報を送る Enhanced Safe Browsingを利用している場合に、SCT AuditingのレポートをGoogleのサーバに送るようになっています。

phase 2

オプトアウトしていない、より広いユーザでSCT Auditingを有効にし、CTの仕組みを強固にします。また、ユーザのプライバシーを保護する仕組みが入っています。

SCTリストサブセットの取得

ブラウザはサーバから得たSCTがGoogleに認識されているか、まずGoogleからSCTのリストのサブセットを取得します。SCTリストのサブセットの要求にはk匿名性クエリを用います。

SCTの対応するMerkleTreeLeafのハッシュ数バイトをGoogleサーバに送信します。Googleのサーバはマッチするハッシュのセットを返します (10000ドメイン以上のリストとなる)。

こうすることで、ブラウザは、該当のSCTをGoogleがすでに認識しているか確認できます。

SCTレポートの送信

上記のサブセットに該当のSCTがなく、Googleが該当のSCTを認識していな場合、SCTレポートを送信します。このレポートにはドメインやユーザの情報は含まれないようです。

レポートの送信には、ログサーバがSCTを公開するまでの遅延時間 (Maximum Merge Delay)待ったり、ネットワークエラーがあってもリトライするようになっています。

docs.google.com

さいごに

まだ議論の最中で、色々実証実験などを踏まえて細かいところは変わっていきそうです。

詳しい内容は先にも上げた、phase 1およびphase 2の資料を御覧ください

phase 1
docs.google.com

phase 2
docs.google.com

HTTPセマンティクス仕様の改訂版 まとめ

HTTPのGETといったメソッドやヘッダの意味を定義したHTTPセマンティクス仕様の改訂版である「HTTP Semantics」が標準化の大詰めを迎えている。

既存の仕様から幾つか大事な変更が含まれているので簡単に紹介する。

目次

セマンティクス仕様の改訂作業

HTTPセマンティクス及び、HTTP/1.1の仕様の改定作業がIETFのHTTP WGで行われている。その背景について簡単に紹介する。

現在、HTTPセマンティクスはHTTP/1.1の仕様の中で定義されている。HTTP/1.1 は、RFC 7230 〜 7235で定義されているが、セマンティクスは主に「RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content」に記述される。

この、RFC 7230 〜 7235の仕様を改訂し、HTTPセマンティクスと、HTTPメッセージの送信方法の定義を下記の通り分離するという事が行われている。

こうすることで、HTTP/2(http2bis)やHTTP/3からはHTTP Semanticsの仕様を参照できるようになる。つまり、HTTP/2やHTTP/3はHTTPメッセージの送り方が異なるだけで、HTTPのセマンティクスとは変わらないというのが、仕様の参照関係的にもすっきりする。

ざっくり変更点

セマンティクスとフォーマットの分離以外にも、HTTP/2やHTTP/3に合わせた記述変更など、幾つか重要な変更点あるので紹介したい。

なお、HTTP/3は改訂される「HTTP Semantics」に準拠しているため、用語などを押さえておく必要がある

用語整理 (Field)

新しいセマンティクス仕様では、使い慣れたHTTPの用語の整理がされている。

普段、「HTTPヘッダ」と呼んでいる、キーとバリューからなるHTTPメッセージのメタデータは、「フィールド」と呼ぶことになった。コンテンツ(ボディ)を送った後に送信するフィールド(トレーラ)と区別し、「ヘッダフィールド」「トレーラフィールド」と呼び分けることになる。なお、ヘッダセクションに現れるフィールドのみを簡易的に"ヘッダ"と呼ぶことはできる。

ヘッダやトレーラを区別しない場合は、フィールドと呼ぶ必要がある。例えば、次の例は、ヘッダとトレーラ区別しないので、フィールドという用語を用いている。

以下などを参照
qiita.com
github.com

用語整理 (body)

HTTPボディ、HTTPペイロードと呼ばれていたものは、セマンティクス上はコンテンツ(content)と呼ぶ。このコンテンツは各HTTPバージョンの定義に従って格納される。

このコンテンツは、HTTP/1.1ではHTTP/1.1ボディという形で送られる。

github.com

用語整理 (interim/final レスポンス)

ステータスコード1xx系をinterim responses (non-final response)と呼び、それ以外をfinal responseと呼ぶ

github.com

ステータスコードのレンジを明確化

ステータスコードとして取りうる範囲を、100~599と明示

github.com

ステータスコード418 unused

「418 I'm a teapot」はHyper Text Coffee Pot Control Protocol のステータスコードである。HTTPの仕様上は、418をunusedという形で予約した。

asnokaze.hatenablog.com

Rangeを指定したPUTリクエス

すでに、再開可能なアップロードのために使用されているが、仕様上もPUTリクエストにRangeを許可した。
asnokaze.hatenablog.com

GET, HEAD, DELETEでコンテンツを含めるのを非推奨 (SHOULD NOT)

GET, HEAD, DELETEリクエストにコンテンツ(ボディ)を含めるのを非推奨とした (SHOULD NOT)。仕様上はそれらのコンテンツのセマンティクスを定義してないため、相互運用上問題になる可能性がある。

プロトコルのマイナーバージョンについて

HTTP/2やHTTP/3は、バージョンにマイナー番号を持たない。あえて記述する場合は、マイナーバージョンは0とすることになった。

更に詳しく知りたい場合

「Appendix B. Changes from previous RFCs」に各RFCからの変更点が記載されている。細かく知りたい場合はそちらを参照
www.ietf.org

おわりに

HTTP Cachingは、どなたかキャッシュ詳しい人が解説して貰いたいところ

BGP over QUICの提案仕様

BGP Over QUIC (BoQ)」という提案仕様が出ている。まだ、議論の呼び水の段階で、提案仕様の細かい部分はとりえる選択肢が書かれている部分もある。。

なお、僕自身はBGPについて詳しいわけではないが、ざっと目を通す。

QUICを使うメリット

RFC9000 で定義されるQUICはUDP上で動作するトランスポートプロトコルであり、TCP+TLSのような通信の信頼性と暗号化機能を提供します。

QUICを使うアプリケーションプロトコルとしては、すでにRFC間近になっているHTTP/3の他に、DNSSSHなどででの利用が検討されています。

QUICをトランスポートプロトコルとして使うことで多くのメリットが得られます

  • TCP + TLSに比べ早いコネクション確立 (TLS1.3と同等のハンドシェイクを行う)
  • IPアドレスが変わってもコネクションが切れない
  • 通信管理単位であるストリームを活用する。ストリーム毎の信頼性となっており、パケロス時に回復を待たずに、後続のパケットをアプリケーションで処理できるようになっている
  • 再送制御の表現力の向上
  • トランスポートプロコル領域も含む暗号化、アンプ攻撃対策、
  • その他いろいろ

詳しくは、古いですが、以前書いた記事などを参照してください

BGP over QUIC

BGP Over QUIC」も上記のメリットを享受できます。QUICを利用するために、仕様では以下のことを定義してます。

  • QUICストリームにどうマッピングするか
  • 1-RTTハンドシェイク及び、0-RTTハンドシェイク時の BGP FSM (ステートマシン)の定義
QUICストリームにどうマッピングするか

トランスポートレイヤのヘッドラインブロッキングを避けるために、QUICのストリームを利用する。
通信をどう、QUICの双方向ストリームにマッピングするかは以下の3つが案として挙げられている。

BGP FSM関連

BGPのセッション確立プロセスはBGP FSMで定義されます。トランスポートレイヤでコネクションの確立をしたあとに、BGPセッションが確立されます。

f:id:ASnoKaze:20210606012848p:plain
(wikimedia: File:BGP FSM.svg より)

この仕様では、BoQ FSMとして新しく定義してます。

BoQ FSMでは、QUIC 1-RTTハンドシェイクではTCPのものを継承します。クライアントからアプリケーションを最初に送信する0-RTTハンドシェイク用のために、新しいイベントを定義を追加します。

0-RTTハンドシェイクでは、クライアントはQUIC InitialパケットともにBGP Open Dataメッセージを送信し、BGP OpenSent 状態になります。それを受け取ったサーバーは QUIC Handshakeパケットを送信後に、BGP Open を送信し、ステータスを BGP OpenConfirmedに変更します。その後、クライアントもBGP OpenConfirmedになります。

このようにBoQ FSMで0-RTTを利用すると、BGP Connect とBGP Active がスキップされます。

その他

なお、BGP over QUICではUDPの179番ポートを使用します。ポート番号でアプリケーションプロトコルを区別するため、この仕様では、ALPN識別子は不要としています。

また、QUICではアプリケーションのエラーでコネクションを切る際に、エラーコードを通知します。そのため、BoQではエラーコードを、新しく定義しています。

  • BOQ_NO_ERROR (0x00)
  • BOQ_INTERNAL_ERROR (0x01)

感想

  • QUICではTLSハンドシェイクを行うのでサーバ証明書が必須。そこを運用でどうするか。BGPSecと似たような感じ?(詳しくない
  • BGPで、QUICのメリットがどれくらい嬉しいのか、実感がない
  • ALPN識別子必須でないけど、一旦定義してもいいのかなとおもったり
  • BGP FSM全然わからない...

WebTransport over HTTP/2 の方向性 (2021年5月の中間会議をうけて)

5月21日に行われた WebTransport WGの中間会議で、WebTransport over HTTP/2の方向性が見えてきたのでメモとして残しておく

WebTransportの動向

WebTransportと呼ばれる新しい双方向通信の仕組みが議論されています。

WebSocketの次世代版とも呼ばれており、HTTP/3上で動作します。現在、Chrome で実装が進められていたりします。

さて、このWebTransportの標準化は、IETFプロトコルを、W3Cでインターフェースの仕様が議論されています。

W3C

IETF

1月にあったIETF WebTransport WGの中間会議では、QUICとHTTP/3を使うもののうち、HTTP/3を使うWebTransport over HTTP/3の標準化に注力していくことが決まりました。
asnokaze.hatenablog.com

5月の中間会議

5月の中間会議では以下のトピックなどが発表されました

  • W3C WebTransport WGのアップデート
  • WebTransport over HTTP/3について
    • 仕様のアップデート状況
    • ChromeのOrigin Trials及びサポートスケジュール
    • 既存Issueの議論
  • WebTransport over HTTP/2の仕様説明
  • フォールバック先についてのコンセンサス形成

WebTransport over HTTP/3についても、結構おもしろい議論がありました。しかし、やはりフォールバック先のプロトコルをどうするかの議論が気になる方も多いと思うのでピックアップして書きます。

フォールバック先のプロトコル

UDPがブロックされている環境において、フォールバック先としてTCPベースのWebTransportを検討する必要がありました。今回の会議では、その方向性について参加者の中でコンセンサスが取られました。

議長が投げかけた質問と、ミーティング参加者のコンセンサスは次のとおりです。質問は、前提から順番に合意していく形で進められていきます。

  • 質問1: TCPベースのフォールバック先を用意すべきか => YES
  • 質問2: それはHTTP/2上で動作するものか => YES
  • 質問3: draft-kinnear-webtransport-http2 を採用するか => YES

ミーティング内では、フォールバック先として、以前本ブログでも紹介した仕様を出発点として採用するコンセンサスが得られました。もちろん、作業の出発点ですので、今後変更されることもあります。
asnokaze.hatenablog.com

引き続きメーリングリストで意見が募集されますが、特になにもなければこの方向で進むものと思われます。

クライアント証明書を中継するClient-Certヘッダの提案仕様

Client-Cert HTTP Header」という提案仕様が、IETF HTTP WGのWGアイテムとして採用されそうなので、予習しておきます。

背景

f:id:ASnoKaze:20210518014202p:plain

TLSレイヤでクライアントの証明書を用いてクライアントを認証することができます。この、クライアント認証はもちろんTLSレイヤで行われます。

一方で、Webサービスを提供するとき、ロードバランサでTLSを終端することはよくあります。このとき、クライアント証明書に基づくアクセス制御を、ロードバランサではなくバックエンドのサーバで行いたい場合があります。そのためには、ロードバランサからバックエンドにクライアント証明書の情報を伝達する必要があります。その方法を標準化するのが「Client-Cert HTTP Header」という提案仕様です。

一つのユースケースとしては「RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens」のような例が挙げられるでしょう。

Client-Certヘッダ

Client-Certヘッダは、TLSの終端を行う中間装置がHTTPリクエストを中継する際に追加されます。

値としては、DERエンコード証明書をBase64エンコードしたものになります。

   Client-Cert: MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJM
    ZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0y
    MDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZI
    zj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p5Be5
    F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIwADAfBgNV
    HSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMCBsAwEwYDVR0l
    BAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1wbGUuY29tMAoGCCqG
    SM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMjeSkC3dFCOOB8TAiEAx/kH
    SB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=

TLSの終端装置が受け取った時点ですでにこのClient-Certがあった場合は一旦消してから、ヘッダを追加します。

HTTP/3におけるDATAGRAMの送信と、CAPSULEフレームについて

QUICで再送を必要としないアプリケーションデータを送信するのに、DATAGRAMフレームが利用できます。このDATAGRAMフレームで送ったアプリケーションデータは、パケットの順番が入れ替わったり、パケットロスが起こってもQUICレイヤでの回復は行われません。

HTTP/3を応用したプロトコルであるWebTransportやMASQUEプロトコルでにおいて、このQUIC DATAGRAMフレームを利用するための議論が行われています。

今回は、HTTP/3でQUIC DATAGRAMフレームを使うための仕様を読んでいこうかと思います
www.ietf.org

なお、WebTransportやMASQUEについては過去に書いた記事を御覧ください

Using QUIC Datagrams with HTTP/3

HTTP/3で、QUICのDATAGRAMフレームを使うにあたって、どのHTTPリクエストに紐づくDATAGRAMフレームなのか関連付ける必要があります。

もともとは、ストリームIDで該当のリクエストストリームと紐付ける方法が考えられていました。しかし、ストリームIDはhop-by-hopの値ですので、end-to-endでHTTPリクエストと紐付けられる仕組みに変更されました。こうすることでproxyといった中間装置がいてもend-to-endでDATAGRAMをHTTPリクエストと関連付けることができます。

Using QUIC Datagrams with HTTP/3」のdraft-01では、Context IDを新しく導入し、HTTPリクエストとDATAGRAMフレームを関連付けます。DATAGRAMフレームを使う前に、HTTP/3のCAPSULEフレームで、リクエストストリーム上で明示的にその関連付けを行います。

なお、Context IDは62bit空間をもち、クライアントから払い出す場合は偶数を、サーバから払い出す場合は奇数となります。

HTTP/3 CAPSULEフレーム

CAPSULEフレームは、HTTP/3レイヤの拡張フレームです。HTTPリクエストを送信したリクエストストリーム上で送信されます。

f:id:ASnoKaze:20210516002411p:plain

CAPSULEフレームには、3つのタイプが定義されています。

  • REGISTER_DATAGRAM_CONTEXT: HTTPリクエストとDATAGRAMフレームを関連付けるのに使用するContext IDを通知します。
  • CLOSE_DATAGRAM_CONTEXT: REGISTER_DATAGRAM_CONTEXTをキャンセルします
  • DATAGRAM: QUIC DATAGRAMフレームが使えない場合に、カプセル化してDatagram Payloadを送信します

なお、片方向からREGISTER_DATAGRAM_CONTEXTを送れば、双方向にDATAGRAMフレームが送信できます。

HTTP/3でDATAGRAMフレームを使うときのフォーマット

HTTP/3でQUIC DATAGRAMフレームを使う場合は下記のフォーマットとなります。

f:id:ASnoKaze:20210516003650p:plain

関連付けるストリームは、クライアントが開始した双方向ストリームであるリクエストストリームなので、4で割ってQuarter Stream IDとして記載します。Context IDはCAPSULEフレームで登録したIDを指定します。

なお、REGISTER_DATAGRAM_CONTEXTで登録されていないContext IDを受信したエンドポイントは、バッファしておいたREGISTER_DATAGRAM_CONTEXTが届くのを待つか、単純に破棄します。

仕様には、MASQUEとWebTrasnportの通信例が紹介されています。例えばWebTransportは次のとおりです。

f:id:ASnoKaze:20210516004537p:plain

リクエストストリーム上でREGISTER_DATAGRAM_CONTEXTタイプのCAPSULEフレームを送りContext IDを登録してます。そのご双方向にDATAGAMフレームが送れるようになります。

HTTP/2やHTTP/1.1の場合

HTTP/2やHTTP/1.1でもDatagram Payloadを送れるようにすることを検討しているようです。QUICの接続に失敗するケースで、MASQUEやWebTrasnport個々別にフォールバック先を定義する必要がなくなります。

具体的な方法は今後議論されていくでしょう。