IETF 126 MASQUE WG セッションまとめ

日時: 2026年7月22日（水）14:00–15:30
場所: Vienna / Grand Park Hall 2（Wednesday Session III）
Chairs: Dennis Jackson, Marten Seemann
情報源: 各発表スライド、および録画の文字起こし

1. WG ステータスと再チャーター

文書ステータス

quic-proxy について Tommy Pauly（Apple）から、Kazuho・MT の指摘を反映した更新を行ったが、Kazuho 提案の変更に関連して CID 管理の teardown に問題が見つかり今週 issue が立ったとの報告。これを閉じて rev すれば WGLC 可能との見通し。

connect-ip-dns については David Schinazi が「自分で実装を書く時間はなかったが Gemini が書いた」と述べ、Yaroslav との相互接続試験を予定していると報告。他に Connect IP 実装を持つ人が同様に実装すれば「3 つの AI が同じ結果を出すか確認できる」と冗談交じりに呼びかけた。

再チャーター

昨年提案したテキスト（PR #15）は「長すぎて読んでいない」というフィードバックを受け、Martin による大幅に短い新提案（PR #17）に差し替えられた。追加される全文は次の趣旨。

採択済み文書（CONNECT-UDP の ECN/DSCP 拡張、HTTP Datagram の圧縮・導出拡張）を完了する。MASQUE アーキテクチャの informational 文書と、MASQUE プロトコル用 qlog イベント文書を採択する可能性がある。それ以外の作業は採択しない。

主なコメント:

• David Schinazi — 「採択済み文書を完了する」という書き方は、何を採択するかを自分で決められてしまうため白紙委任になり IESG に通らない。具体的に列挙すれば良い。それ以外は ship it。
• Eric Kinnear（Apple） — これまで WG が言ってきたことそのもので、テキストがよく反映している。
• Nokia の参加者（文字起こしでは "Jahid"、おそらく Zahed）— 賛成だが、将来 CONNECT-ETHERNET に致命的な欠陥が見つかるなど critical extension が必要になった場合の行き先が書かれていない。AD と相談すべきで、ML を残すのかも整理が必要。→ Chair から「WG を閉じるわけではなく、新規採択をしないだけ。ML も会合も継続する」「このチャーターは他 WG を拘束しない」と回答。
• Mirja Kühlewind — これが全文か（MASQUE 自体の説明がない）と確認。追加分のみと判明。最後の "will not adopt any other work" の一文は必要との意見。
• Martin Duke — 細かい語句を除けば良く、閉じる道筋が明確。ただし今後出てくる作業の長期的な置き場（HTTPBIS か TSVWG か）のストーリーは必要。再チャーター文書に含める必要はないかもしれないが、細かい課題をカバーするために WG を開けたままにする誘惑には抵抗すべき。

実質的な議論は ML に持ち越し。

2. draft-ietf-masque-http-datagram-compression-01

発表者: Yaroslav Rosomakho（Tommy Pauly と共著）

主な更新

• 導出フィールド（derived field）の詳細定義を追加。従来はフィールドを列挙するだけで、定義の所在や導出方法は読者任せだった。今回は各フィールドについて、位置と参照、送信側が削除前に確認すべき事項、受信側が確認・再計算する手順を記述。作業の過程で断片化や IPv6 jumbogram といった「鋭利な角」が見つかった。
  • 例（IPv6 payload length）: 送信側は IPv6 パケットであること・payload length がワイヤ上のオクテット数と一致すること・値が 0 でない（jumbogram でない）ことを確認。受信側は IPv6 であることと、計算値が 0 より大きく 65535 未満であることを確認。
• Ethernet FCS 導出フィールドを追加。CONNECT-ETHERNET が FCS の伝送を要求している点は発表者にとって意外だった（通常 NIC のハードウェアレベルで検査・除去・再計算される）。connect-ethernet ドラフトの「将来の拡張が別のエンコーディングを導入しうる」という記述がまさにこれに当たる、という位置づけ。
• 実装者向けガイダンス。MTU の振動を避けるため十分に広いテンプレートを定義し、必要なら DATAGRAM capsule を使う（ただし PMTU 探索を誤らせないよう注意）。一般にテンプレート化してよいフィールド／すべきでないフィールドを列挙。TOS は変化しうるので原則テンプレート化しないが、イントラネット向けトラフィックなど用途次第。
• 競合動作の定義。checksum offload（擬似ヘッダのみを渡して NIC のオフロードを使う）と checksum derivation（チェックサムを完全に除去し再計算させる）を同時に定義することは不可。不正な圧縮には fail early。
• コンテキスト連鎖の有効／無効例（Magnus のレビューを受けて明確化）。同種のコンテキストを 1 つの連鎖に 2 回登場させることはできず、同じフィールドを offload と derive の両方にすることもできない。

質疑

• Mike Bishop — FCS の追加を歓迎。CONNECT-ETHERNET レビュー時に同じ疑問を持った。ハードウェアオフロードがなければ、再計算の CPU コストを避けるために少し帯域を使うトレードオフは理にかなう。オフロードがあるならバイトを削るべき。
• 会場（no hats） — IPv6 jumbogram をどう扱うのか、そもそも実在するのか、どうテストするのか。→ Erik Nygren が「jumbogram は実在し Linux で動作する。PMTU 探索に注意しネットワーク側の対応も要るが、実際に使われている」と回答し、廃止案は見送りに。
• 同 — UDP データグラムの最終バイトが IP パケットの最終バイトだと仮定しているか（UDP options や dead space の扱い）。→ 現状は UDP options を考慮していないとの回答。Magnus Westerlund から、UDP/IP の length を厳密に検証すべき理由が UDP options であることを明記する issue を既に登録済みとの補足。

今後

公開時点の issue は全て解決済みだが、Magnus のレビューで 8 件の issue が新たに提起されており、これに対応。さらなるレビューと、プロトタイプ実装・早期の相互接続試験を募集。

3. draft-ietf-masque-connect-udp-ecn-dscp-02

発表者: Mirja Kühlewind（Magnus Westerlund, Marcus Ihlar, Marten Seemann と共著）

更新履歴

• 00: WG 文書化のみ（内容変更なし）
• 01: ECN_DSCP_CONTEXT_ASSIGNMENT のバイトアラインメント修正、初期のセキュリティ考察（リソース消費、トンネル観点）を追加
• 02: ECN_DSCP_CONTEXT_CLOSE capsule を追加（会合の直前に提出）

設計

複数拡張に分けず 1 つの拡張に単純化する方針。Context ID で ECN と DSCP を常にセットでシグナルし、新しい DSCP を割り当てる際は 4 つの ECN 値すべてに Context ID を割り当てる（ネットワーク上での誤った書き換えなどでどのマーキングも観測されうるため）。初期セットは ECN-DSCP-Context-ID Structured Header Field で HTTP リクエスト／レスポンスに載せてネゴシエートでき、DSCP 利用が静的ならこれで完結。動的な追加は ASSIGN / ACK / CLOSE capsule で行う。発表中に、ACK に assignment 形式全体を入れているのは不要かもしれないと発表者自身が言及。

Issue #7: DATAGRAM の楽観的送信

assignment 送出と同時にデータグラムを送れるようにしたものの、CLOSE を受けた場合の指針が不足している、また ACK/CLOSE をどれだけ待つべきかという問い。ここが最も議論を呼んだ。

• Gorry Fairhurst — 時間よりも、その後同じ DSCP のパケットを何個見たかがトリガーになるのでは。
• Ted Hardie — CLOSE を受けて未確認のデータグラムを再送する動機が理解できない。→ Mirja「では止めましょう。デプロイ依存でガイダンスを出せないかもしれない」。
• Magnus Westerlund — 通常は登録してトンネルするだけで済むはず。むしろ必要なのは「egress が特定の DSCP を拒否する理由はあるのか」「拒否するなら 0 に bleach するのか drop するのか」というガイダンス。そもそも ACK/CLOSE が必要かという問いに戻る。
• David Schinazi — 他の MASQUE 文書と同じにすればよい。ACK 未受信でも楽観的に送ってよく、失われうるがそれで構わない。UDP なのだから失われ方は 17 通りある。この領域は footgun だらけなので、ここで革新しようとしないこと。
• Mirja — 他の文書も「ACK か CLOSE を送らねばならない」とは書くが、いつ送るか・いつ諦めるかを書いていない。これは一般的な欠落。
• Tommy Pauly — CLOSE は ACK の代わりの拒否なのか、後からも送れるのか（QUIC proxy でも同じ問題に直面中）。後から閉じる人が本当にいるのか疑問で、CLOSE ではなく定義の「置き換え」を可能にする方が自然では。→ Mirja「DSCP は数が限られるので、同じ DSCP に新しい assignment をすればよい」。この議論はセキュリティ考察の作業中に、受信側が assignment 数を管理する手段がないと判明したことから始まったもので、数千個開かせる攻撃（state commitment）が理論上は可能。これもほぼ全拡張に共通の問題との指摘。

Issue #27

初期セットで DSCP=0 の assignment を常に持つことを推奨すべきか。大きな論点ではないため issue でのコメント募集に。

3 つ目の issue: 拡張同士の組み合わせ

Magnus から、CONNECT-UDP で複数拡張を組み合わせる例が WG 内に存在せず、3GPP が定義したメカニズムでは正しく動作するための assignment が抜け落ちている、異なる Context ID を使う例が必要、との指摘。

Mirja は「これはこのドラフト固有ではなく全拡張に共通の問題で、一般論として扱うべき。採択しやすくするためドラフトから外したが依然必要であり、再チャーターにも作業の余地が要る」と主張。これに対し David Schinazi は「採択のために外したのは、採択前にさらに議論が必要だったから」と補足したうえで、「拡張結合の大枠を作るのは boiling the ocean。過去の拡張でも意図的に飛ばしてきたし、実ユースケースが見えるまでこの文書からも再チャーターからも punt すべき。3GPP の動きは出荷されるとは思わない」と反対。Mirja が「ECN が普及すれば全 CONNECT-UDP 接続で使いたくなる拡張であり、2 つ目の拡張が出た時点で即問題になる」と応じ、David は「その橋は渡るときに渡りたい」と返して平行線のまま終了。

4. draft-gakiwate-dnsop-proxy-dns-svcb

発表者: Gautam Akiwate（Tommy Pauly, Erik Nygren と共著）

MASQUE での採択は意図せず DNSOP 向けだが、MASQUE 参加者の関心が高いため紹介、という位置づけの発表。

動機

プライバシー等の理由でプロキシがクライアントに代わって DNS 解決を行うと、SVCB/HTTPS リソースレコードの豊富な情報（ターゲットが H3 に対応しているか、ECH があるか等）が失われる。これがクライアントに届けば、CONNECT と CONNECT-UDP の選択などを適切に行える。

定義する 4 ヘッダ

• Proxy-DNS-SVCB-Request — sf-token。値は SVCB または SVCB 互換のレコードタイプ。
• Proxy-DNS-SVCB-Response — sf-list の各要素が sf-binary で、DNS ワイヤ形式の 1 レコード。解決過程で遭遇した全 SVCB/HTTPS レコード（辿った AliasMode レコードを含む）を返す。非対応プロキシは何も含めず、クライアントは非対応と推測する。
• Proxy-DNS-SVCB-Request-Cancel-On — sf-token の list。事前合意されたトークンで条件を指定し、条件が満たされればプロキシは転送接続を確立せず SVCB RR を返す（例: h3-alpn）。評価は最高優先度の RR に対してのみ実施。
• Proxy-DNS-SVCB-Response-Cancelled-On — 満たされた条件のトークンを報告。

例として、CONNECT www.example.com:443 に proxy-dns-svcb-request: HTTPS と cancel-on: h3-alpn を付け、ターゲットの HTTPS RR に h3 が含まれていればプロキシが 307 とレコードを返し、クライアントが CONNECT-UDP でリトライする流れが示された。

質疑（かなり批判的）

• Marten Seemann（no hats） — 複雑に感じる。DNS レコードを HTTP ヘッダにシリアライズしている。HAPPY WG の作業を踏まえると、トランスポート・ECH・HTTP バージョンの判断はクライアント側が適切な場所。プロキシに DoH サーバを同居させ、同じ QUIC 接続で引いて通常の Happy Eyeballs に食わせればよいのでは。→ Gautam「有効な戦略だがラウンドトリップを 1 つ払う。多くの場合 CONNECT-UDP は非対応なので、楽観的に CONNECT しつつキャンセル可能にすれば happy path でその往復を払わずに済む」。
• Lucas Pardue — 条件付きリクエストの性質は例を見るまで分からなかった。むしろ MASQUE 側に「A または B の条件で CONNECT する」メソッドがあるべきでは。それならさらに 1 往復削れる。
• Martin Thomson — 率直に言ってかなり悪いアイデア。2 つのリクエストを結びつけ、一方をヘッダフィールドに埋め込むのは設計として良くない。「以下の条件下でのみ接続せよ」なら HTTP が if- 系の述語で既に持っている枠組み。リクエストのライフサイクルにも影響が出る。ヘッダ名も長すぎる。
• David Schinazi — 探求する価値のある領域だが同様の懸念。first principles に戻ってどのパスを最適化したいのかを考えるべき。「web の大半は CONNECT」を前提にすると、より良い選択肢がある場合をエラーパス扱いすることになり、古い方の道を最適化してしまう。もっと単純なやり方があるはず。
• Mike Bishop — SVCB の狙いは「接続開始前にクライアントに知っておいてほしい情報のバケツ」。ここではクライアントが接続の途中で学ぶことになる。問題は「どこにトランスポート接続を張るか（プロキシが知る必要があり、その時点で既に起きている）」と「ECH 鍵など上位層でクライアントが必要とするもの」に分かれ、SVCB レコード全体を渡すのが正しい構造か疑問。特に 307 が返ってくるのが落ち着かない（別メソッドへの HTTP リダイレクト？）。→ 307 はプレースホルダとの回答。
• Erik Nygren — この問題は鋭利な角だらけで、このアプローチを採るならこれは比較的角が少ない方。全情報をクライアントに渡す必要があり、単純な条件式では、指紋情報を晒しすぎずに必要なロジックを表現するのは極めて難しい。条件付きが最も効くのはプロキシが HTTP/1.1 で永続接続を再利用したい場合で、H2/H3 前提なら重要度は下がり、別ストリームでの並行 DNS でも近い結果になりうる。cancel が有用なもう一つのケースは、CONNECT と同じ flight で ClientHello を先送りする ECH のケース。
• Yaroslav Rosomakho — SVCB の request/response 部分は良い（response は proxy-status ヘッダに載せる案もある）。ただし cancellation は over-engineered かつ open-ended で、事前合意が必要でユースケース特化すぎる。CONNECT は比較的安価で、CONNECT-UDP はソケットを開いて祈るだけ。conditional は落とすべきで、そうすれば DNS 固有の要素がないので HTTPBIS の方が適切な場かもしれない。

5. draft-rosomakho-idr-bgp-masque-tunnel-00

発表者: Yaroslav Rosomakho（Alvaro Retana と共著）

IDR WG のドラフトで、「普段は交わらない 2 つの海を繋いで相乗効果を探る」試みとして紹介。BGP-4 の概要（TCP 上で動く path vector プロトコル、IPv4 から IPv6・VPN・Flow Spec・EVPN へ拡張、public/private な ASN、iBGP/eBGP、NLRI と path attributes の組を UPDATE で運搬、通常 4096 バイト・Extended Messages で 65535 バイト）を圧縮して説明したうえで、次の主張を展開。

MASQUE プロキシはルーターになりうる。特に CONNECT-IP や CONNECT-ETHERNET を話す場合、クライアントやサーバと同居する必要はなく経路上に置けるため、外から見れば VXLAN や IPsec ベースのトンネル終端ノードの drop-in replacement になる。一方 BGP は SD-WAN オーバーレイの制御プレーンとして採用が拡大しており、BESS / IDR に SD-WAN コントローラとの通信、サイト相互発見、IPsec ゲートウェイ情報の伝播、VPN 経路と preference の通知に関する仕様が揃っている。

提案内容

BGP の機構を MASQUE プロキシに拡張する。

• 新しい tunnel type 4 種: CONNECT-TCP / CONNECT-UDP / CONNECT-IP / CONNECT-ETHERNET（tunnel type は 2 バイトで安価）
• 新しい Tunnel Encapsulation Attribute Sub-TLV 2 種: URI Template / ALPN

MASQUE 専門家への質問（会場からの発言はなし）

1. 非テンプレート型の CONNECT over HTTP/HTTPS をサポートすべきか。サポートすると宛先ホスト名用の Sub-TLV が追加で必要になる。現状はテンプレート化された新しい CONNECT-TCP のみに限定することで、宛先ポートの符号化を考えずに済み仕様が大幅に単純化されている。
2. BGP には既にゲートウェイ IP 用の Sub-TLV（Tunnel Egress Endpoint）がある。ルーターは制御プレーンのコストや遅延を嫌って DNS 解決を避けたがるため、これを許可すべきか。ALPN は既に運べるので、URI Template + ALPN + Tunnel Egress Endpoint という組み合わせにすれば、URI テンプレート中のホスト名は証明書検証と :authority 設定に使いつつ、MASQUE 接続を開始するルーターは DNS 解決をしなくて済む。

金曜 14:00 の IDR セッションへの参加が呼びかけられた。

6. proxy-dns-svcb の議論場所について（セッション末尾）

BGP 発表中にチャットで議論が起きたため、Chair がマイクでの発言を促し、最後の 15 分ほどがこの話題に費やされた。

• Martin Thomson — このドラフトはこの WG（あるいは類する WG）に属する。MASQUE を継続的に所有・保守する主体が MASQUE との統合を議論すべき。DNS 考慮事項について DNSOP に持ち込む価値はあるが、暴力が加えられているのは MASQUE と HTTP であって DNS ではない。
• Lucas Pardue — DNSOP には行かない（時間がない）ので、そこに行くなら助けられない。この作業には助けが要ると思う。MASQUE 側なら参加しやすい（過去の出席率は良くないが）。
• David Schinazi — 複雑さは HTTP 自体・プロキシ・MASQUE の周辺にある。再チャーターに含めて MASQUE でやるか、MASQUE 終了後に作業が移る先である HTTPBIS でやるか。いずれ DNS 専門家に見てもらうべきだが、込み入った部分は HTTP に住む。
• Tommy Pauly — proxy-status ヘッダのように、接続先 IP や CNAME を返す仕組みは既にあり HTTPBIS で行われた前例がある。また「通常の CONNECT と並行して DoH で HTTPS RR を引けばよい」ほど単純ではなく、HTTPS RR を引く行為自体で本来知り得ない別ポートやアドレスを知りうる。そもそもプロキシが HTTPS RR を引くのかが未標準化で、SVCB の場合は URI に関する追加情報なしには引き方が分からない。
• David Schinazi（自ら「悪いアイデア」と前置き）— レイヤリングとして踏み込みが足りない。次のステップはスタックの下ではなく上へ行く「CONNECT to HTTP」で、ClientHello や QUIC Initial を投げて「HTTP が欲しい、あとはよろしく」とやるべきでは。
• Martin Thomson — それはひどいアイデアだが、もっと探求すべき。より興味深い未解明の問いは「プロキシ越しの Happy Eyeballs とは何を意味するか」で、このドラフトはその問題の一部に踏み込んでいる。HAPPY WG でこの問題をより厳密に検討し、そのうえで必要な最適化を議論する方が良い。
• Erik Nygren — David の CONNECT 案は信頼モデル／セキュリティモデルの観点で注意が必要。既に通常のプロキシ以上の権限（DNS リゾルバに相当する力）を与えつつあり、スタックを上がるとセキュリティ機能がクライアントからプロキシへさらに移ってしまう。Happy Eyeballs の視点は良く、このドラフトが最適化にすぎないなら、まず実世界でどこが遅いパスかを実験し、どの最適化が実際に効くかを見てから複雑さを足すべき。
• Tommy Pauly — HAPPY での議論は良い。技術的な building block が固まった後の置き場としては、MASQUE を閉じたい事情もあり、汎用の HTTPBIS が妥当。CONNECT-TCP や proxy-status ヘッダの前例がある。MASQUE は新しいプロキシ関連の全てと思われがちだが、チャーター上は UDP・IP・Ethernet に限られ、この問題は UDP と無関係な通常の CONNECT にも等しく当てはまる。
• Eric Kinnear — これは CONNECT-HTTP ではないと思う。プロキシに鍵を渡して TLS ハンドシェイクをさせるつもりはない。実際にやっているのは下位のトランスポートを繋ぐことで、HTTPBIS かもしれないしそうでないかもしれない。Happy Eyeballs の側面は（HAPPY chair として）その WG で議論するのは良いこと。

Chair は「再チャーターの過程にはあるが、WG が関心を持つものにドアを閉ざすつもりはない」としつつ、HTTPBIS が適切な場のようにも聞こえるとして、offline と ML での継続を提案してセッションを終了した。