うなすけとあれこれ

2025年03月31日

IETF 122 Bangkokにリモート参加しました

IETF 122

バンコクはUTC+7なのでTZ自体は参加しやすいんですが、日中は仕事があるので結局ほとんどリアルタイムでは聞けなかったという……

それでは例によって以下は個人的な感想を無責任に書き散らかしたものです。内容の誤りなどについては責任を取りません。

moq

Agenda

今回のinteropではメディアに関するデモも追加、実施されたよう。

このmoq-wasmの中の方のscrapも参考になるのでは。

Media over QuicTransport(MOQT)動向まとめ

という訳で僕からは軽めに。全然わからないので……あと事前にagendaに記載されていた “Reducing time to first byte” は触れられてないような気がする。見落としているのかな。

Changes since IETF 121 (draft-07)

IETF 122以降、07から10での変更について。いっぱいある！07から08が一番変更が多くて、08から09ではそうでもなく、09から10は文書の位置が移動しただけ。エッジケースでの挙動が明確になったのがほとんど？

PUBLISH and SUBSCRIBE to Tracks in a Namespace

ビデオ会議で、2人目が入ってきた場合に最初に部屋にいた人の挨拶がちゃんと2人目に届くようにしたい。そういう問題を解決するための議論なんだけど、そもそも今のmoqではそれが保証できないのか？どういう理屈で保証できないんだろう。スライドにはプロトコルを理解している人にはわかりそうな図が貼られている。

Track Alias

スライドにはQuestionがあるけど、録画を見た感じでは一気に"Track Alias Alternate Proposal"まで飛ばして議論が始まっていた。pull reqがまた作られる？

MOQT QLOG

QLOGでmoqのイベントも記録できるようにするもの。今回は紹介のみで時間切れかな？

Interop report

全員が08まで実装が完了していて、10まで実装しているのが4人。08から10までの差は大きくないのでよい結果という結果。

LOC update, call for Adoption?

aboptionへの賛否に関する投票が行なわれ、賛成多数でadoptionされる流れに。

AUTH PR

MOQTにおける認証とアクセスコントロールについて。"Common Access Token (CTA-5007-A)“ という既存の標準を使うのだとか。(見るのに住所とか入れないといけなくてやだなあ、となり見れていない)

https://shop.cta.tech/products/cta-5007

"Need to create new CWT claim” とminutesにあるのはなんのことかと思えばCBOR Web Tokenのことか。この仕様を策定している団体？にもう問い合わせをしていて、結果としてはCTAを使うことは問題なくて、ただし拡張する必要はなくてCWTの定義を追加すればいいだけ(IETF内で完結できる)ということらしい。どういうものを作らないといけないのかはスライドにあるとおり(多分9ページ)。

まだadoptionできる段階じゃないのでGitHubで揉んでいこうフェーズかな。

ccwg

Agenda

5033bisがRFC 9743 (Specifying New Congestion Control Algorithms)になった、draft-ietf-ccwg-ratelimited-increaseができた、GitHubの使い方について合意した(https://github.com/ietf-wg-ccwg)というのがIETF 121からのupdate。

HPCC++についてはagendaにあったけど時間が足りなくて取り上げられなかった。

New Tools for Testing Congestion Control and Queue Management Algorithms

agendaにあったhackathon updateっていうのは、これのことだろうか。新しい輻輳制御アルゴリズムのテストを行うツールの紹介？と結果について。ns-3上に実装されたccperfとNeSTというもの。ccperfではTCP BBRとFQ-CoDCelとFQ-PIEを、NeSTではTCP BBRをそれぞれテストしてグラフにしている。

NeSTは"a python wrapper on Linux network namespaces"とのこと。QUICのサポートについても取り組む予定とのことで、既にmerge requestは出ている。

https://gitlab.com/nitk-nest/nest/-/merge_requests/306

こういうツールがあれば輻輳制御アルゴリズムの変更を提案する人が自分達で全てのテストをしなくてよくなるので重要だ、という意見があった。

BBRv3

121から122で01から02になった。変更としては BBRIsProbingBW() の疑似コードの追加やいくつかの識別子のrenameなど。次やることはClarification、Simplification、RenoやCUBICとのより良い共存、パフォーマンスの向上、実ユースケースにおいてのパフォーマンスリグレッションの回避が挙げられてる。"Multiple deployments at scale in QUIC and TCP" や “Text both TCP and QUIC implementations can follow” などがRFC化にあたってのやるべきことのひとつに挙げられている？issueとしてはTCPでないtransportについての適応、ProbeRTTの間隔、inflight_shorttermの必要性などについて。

Rate-limited senders

前回から、投票によってwg draftになったもの。"rate-limited"が指すものについて明確にすべきだ、など文書の明確化についてが今後の課題。

SEARCH

SEARCHを実際に運用してみた結果の報告かな？HyStart、HyStart++、BBRとの比較のグラフがある。帯域がどう増加していくか、メモリ使用量はどうか、それらのテストはどのように行ったか。"Looking for volunteers to try it out!“ という点については前回と変わらず。

httpbis

Agenda

QUERY Method

Location headerに関する議論の決着がついたらWGLCに進むっぽい。

Template-Driven CONNECT for TCP

00からの更新は、non-capsule modeが削除された。終了時の扱いについてどうするかの合意ができてないので、そこが議論のポイントだったぽい。まだまだGitHub issueでの議論が続くのかな。

Security Considerations for Optimistic Use of HTTP Upgrade

GitHub上で CONNECT.*HTTP\/1.1 を含むPythonのコードを検索したところ、最初の50件のうちの少なくとも4つの異なるclientがステータスコードのチェックをしていなかった(レスポンスは待ち続けていた)とのこと。

https://httpwg.org/specs/rfc9110.html#CONNECT

RFC 9110によれば、サーバーが拒否する場合に400を返すので、無条件に成功すると見做すものではない(それはそう)。

07において明確にHTTP/1.1に対しての推奨であると記載された。ある一文においてMAYをMUSTにするかSHOULDにするかの議論が決着したらWGLCに進むぽい。

Resumable Uploads

06においては記述の大幅な変更(editorial overhaul)、expiresがmax-ageになったりとか。media-typeでapplication/partial-upload を使う際、今はPATCHだけどPUTもしくはPOSTのほうがよいか？という議論があったがPATCHで進みそう？WGLCも近そう。

Secondary Certificate Authentication of HTTP Servers

HTTPにおいて追加の証明書を使用した認証を行う方法について。耐量子暗号の証明書(という表現は正しいのか？)の場合はサイズが大きいために複数のフレームに分割せざるをえないという問題について、新しいストリームタイプを使う場合についての調査を行うことで落ち着いたよう。実装ボランティア募集中！

No-Vary-Search

スライドなし。サポートしているサイトは https://chromestatus.com/metrics/feature/timeline/popularity/4425 で確認できる。これをクライアント側として実装しているブラウザはChromeのみ。WGLCに進みそうな感じがする……

Incremental HTTP Messages

Comic Sansだなあ。シグナリングについて3つ(もしくはそれ以上)の状態を持つべきかどうか、クライアント側がincrementalいけるぜ状態をどうサーバーに伝えるか、サーバーに中間者がincrementalできるかを伝える方法はどうか、などが議論。シンプルであることがより良いという意見があり、tri-stateにはならなそう？

HTTP Unencoded Digest

例えばgzippedされたresponseを返すとき、そのdigest値を Repr-Digest で返し、gzipする前の内容のdigest値を Unencoded-Digest で返すようにするもの。range requestとかHTTP Signatureでユースケースがあるということだけど、いまいちピンと来てない……名前に関してどうするかという議論がある。

Delete-Cookie and HttpOnly Prefix

スライドなし。rfc6265bisが更新されることはないっぽい、が、rfc6265bisをさらに修正するための取り組みはあって、そっちには入る可能性がある？Shopifyの人だ！

Cookies: HTTP State Management Mechanism

スライドなし。rfc6265bisではない版のやつ。このwgでやるのが相応しいかどうかの質問で終わったか？

HTTP Client Hints Reliability

Client Hintsは最初のリクエストではサーバーが何に対応しているか不明なので最適化できず、例えば何もかもを送信するとそれはそれでプライバシーの問題がある、と。そのためにCritical-CHヘッダやACCEPT_CH frameを提案している。多くの人がmic queueに並んだようで、質疑が多い。やりとりするデータが増えることによるパフォーマンスの低下が懸念されていたり。

tls

Agenda

ECHのキャッチアップが足りなかった、というのが僕の感想です。

Encrypted Client Hello, DNS Service Bindings

Last Callになって色々なレビューがあった。ECHに関してはDNSDIRからちょっとした質問が返ってきている。svcb-echのほうは同じくDNSDIRから "I think it’s ready to go.” が返ってきている。

rfc8446bis and -rfc8447bis

これ(IETF 122)が終わったらLast Callするって！！

SSLKEYLOGFILE

IETFでやることか？というところに関して一悶着あったけど、結局は取り組みが継続されそう。一悶着あったというのは、これはメッセージ内容を復号できるのでよくない、いやいやデバッグ用のツールなので通信内容の漏洩にはならない、という議論。

rfc8773bis FATT Report

Formal Analysis Triage Team (FATT)による8773bis(External Pre-Shared Key)のレポート。果たしてPSKは量子耐性があるのか。ということで8773bisを複数の研究者にレビューしてもらった。研究者は暗号計算と記号解析の分野を研究対象としている人達で。全員がTLSに関する公開された成果がある。研究者は公開されているが、レビューコメントのどれが誰によるものかは公開されない。レビュワーに直接連絡はせず、リエゾンに対して質問やコメントを送ってほしいというお願い。

解析結果そのものは「8773bisは既存のTLSに対する脆弱性を導入するものではなく、追加の解析を行う必要もないだろう」「量子耐性については懸念事項がある」というもの。なので量子耐性に関する主張を削るか、または維持するのであればさらなる解析が必要ということに？

議論はそもそもTLS wgとして量子耐性についてどういう立場でいくべきか、という内容になっていそう。結果いくつかの投票が行われ、一番賛成票を集めたのは「TLS wgがセキュリティに関する主張を改訂するべき」という設問。

Request mTLS

クライアント側からmTLSできますよをサーバーに伝えられるようにして、認証されたbotからのアクセスを許可したいというユースケース。侃々諤々？DANEで役立つかもしれないという話が出た。

Trust Anchor IDs

*No discussion*

PAKEs

PAKE(Password Authenticated Key Exchange Extension for TLS 1.3) に関する2つのdraft。ユーザーがパスワードやPINを入力することでの認証、組み込み機器のセットアップ、ペアリング時のユースケースが提示されている。AirPlayやMiracastのときのPIN入力の画像がスライドに添付されている。

TLS wgとしてやることには賛成多数、やるならhandshakeでやるべきで、post-handshakeではないという結論になった。

Implicit ECH

ロシアでECH(Encrypted ClientHello)がブロックされてる(されてた？)のか……ECHを使うクライアントが、ECHを使っていることがわかってしまうのでプライバシー的に問題だったり、ECHを解釈できないサーバーはどう振る舞うのが正しいのか、などの問題がある。提案されているのは、ECH configとouter SNI(これなんだっけ？)が一致しない場合にサーバーは中断してはならない、outer SNIは事実上の非推奨にするなど。

ECHが普通になれば目立たなくなるのでそうなっていくべきとか、確かにこれは懸念すべき事項で、ECHは遅らせたくないがこれにも取り組むべきだ、という意見があった。これはちょっと気にしておかないといけなそうだ。

ECN public Names

IETFでは初めて見る雰囲気のスライドだ。これECHのことがわかってないとわからないな……

議論自体の結論は、ECHが完了したらやろうという感じか。

Anonymity sets in ECH

これもECHのことがわかっていないと何もわからない 😇

既存のECHのワークを中断させるものではないとのこと。

Identity Crisis in Attested TLS for Confidential Computing

Remote Attestationということで、rats wgと関連のあること？スライドの内容も、minutesに書いてあることもよくわからない……

httpapi

Agenda

HTTP Link Hints

updateがあったので確認してね、くらい？

REST API Media Types

OpenAPIのmedia typeが登録中？open issuesが2つ。次のIETF meetingまでにWGLCしたい。

RateLimit header fields for HTTP

様々なフィードバックが得られた。https://github.com/darrelmiller/ratelimiting が C# での実装。フィードバック次第では次のIETFまでにWGLCになる？

New JSON Schema

MSの jsonschema の拡張提案見た。
$defsで再利用する型を厳格化するの、理想はそうだけど運用で上手くいくとは思えない。$offers でallOfやif/then/else を拡張仕様で分離するのは、逆に実装の乱立を招く気がする$import は外部参照解決を複雑化する

総じて反対https://t.co/szxUmN3yBJ

— mizchi (@mizchi) March 20, 2025

これC#の言語仕様が念頭にあるように見えるな。C#にうまくマッピングする水準に見える

— mizchi (@mizchi) March 20, 2025

今の時代これやるんだったらせめて WASM の Canonical ABI とか Component Model も念頭においてほしい気がする

— mizchi (@mizchi) March 20, 2025

提案しているClemensさんはMicrosoftでFabric Eventstreamなどのメッセージングサービスに関するリードアーキテクトの人らしい。https://cloudevents.io/ にも関わっているのだそう。mizchiさんの言ってる「C#にうまくマッピングする水準に見える」についても、口頭でTypeScriptやJavaScript、C#、Javaへのマッピングができるように設計していると言っている、多分。

強い賛成や反対があったというよりは「とりあえずGitHub repositoryじゃなくてdraftにしてもってきてほしい」っていう結論になった感じかな？

HTTP Problem Types for Digest Fields

セキュリティ上の懸念事項(上記issue)があるのでSECDIRのレビューを受けたいという意見があった。

quic

Agenda

qlogに関しては時間がなくて軽めに。qlogの拡張をRTP over QUIC(AVTCORE)、Careful Resume(TSVWG)、MOQT(MOQ)など他wgでやってるよ。

あと、 https://github.com/quicwg/base-drafts/wiki が停滞している状況について改善する流れがあり、今はstaging環境が https://quicwg.org/staging.quicwg.github.io/ で見れるようになっている。

Multipath Extension for QUIC

11から13までの変更点は、PATH_CIDS_BLOCKED frameの追加、複数パスでのPTOにおけるガイダンス、0-RTTにおけるMP frameのエラーコードの修正、その他さまざまな明確化。draft13に対する相互運用性の確認についてもほぼ成功。

PATH_CIDS_BLOCKED frameって本当に必要？という議論に関しては、これはデバッグのために便利で、既に実装が存在するのでそのまま残すということになったのかな。次の版でWGLCになるかも。

Multipath QUICはアリババもう本番投入している？ホントに？

QUIC Address Discovery

wg draftになってますね。議事録では “Extension Negotiation” に関する質疑だけ記載されている。草案から “negotiation” という言葉を削除したと。

QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps

「遅延を正確に計測することで帯域幅の計測がより正確になる、などのモチベーション」って118のまとめのときに書いてた。他にもAckの頻度を減らすことに関しても重要。ACK frameにいくつかのtimestampに関するfieldを追加したACK_RECEIVE_TIMESTAMPS frameを使う。そもそも複数のoptional fieldを持てるようACK frameを拡張可能にするか。新しいframeを定義するか、常にtimestampを送信するようにするかという議論がある。

とりあえずdraft自体をquic wgとしてやっていくことは賛成多数だった。

Extended Key Update for QUIC

QUICのセッション中に鍵交換は1回行われる。これを draft-ietf-tls-extended-key-update をベースとして、CRYPTO streamでTLS 1.3のメッセージを送り新規の鍵交換をやる。long-lived sessionにおいて重要だと。具体的にはtelco signaling、IoT、MASQUE/VPNとかだと。

wgとしてこれに取り組むことに関しては賛成多数で可決。

Source Buffer Management

遅いネットワーク上でMacのscreen shareが重いという問題があった。ネットワークのバッファが溢れているんじゃ？という疑いがあり、実際は送信側のバッファにあったと。送信待ちのデータがめちゃくちゃ増えちゃっており、そのため TCP_NOTSENT_LOWAT が導入されてバッファの量が制限されるようになった。IETF 121のside meetingで、これはバイト数ではなくミリ秒単位の制御であるべきだという話があった。で、QUICはどうする、と。なんかメーリングリストもできてる。

各位この問題にどう対処してる？的な問い掛けのセッションってことだったのかな。IETF 123で何かしらの進捗がありそう。

QMux Formerly QUIC on Streams

QUIC on Streams（QoS）名前が不評すぎてウケる🤣 ネタに走った名前をつけたことについては反省してます…

— Kazuho Oku (@kazuho) March 17, 2025

QoS、言われるまで気づかなかったな……

“This will require a recharter” ということで、recharterが行われるかもしれない。

tiptop

Agenda

“Taking IP To Other Planets” の略で、惑星間通信のようなRTTがなっっっがい環境における通信では、既存のプロトコルをそのまま展開するのが難しくなるので、そのための拡張などについて議論するworking group。

唯一リアルタイムで聞けたセッション(祝日だった)。tiptopのミーティングは今回が初だったので、記念すべき1回目(？)に参加できたのはよかったです。

IP in Deep Space: Key Characteristics, Use Cases, and Requirements

そもそもtiptopで想定しているユースケースとはどんなものかについてのdraft(だと思う)。月や火星のような領域がテーマで、低軌道、中軌道、静止衛星くらいまでの地球と近い距離における通信においてはスコープ外。

通信のユースケースとしては、宇宙船などへのコマンド送信、テレメトリデータの送受信、リアルタイムメディア、一時的に通信できない場合の遅延、緊急メッセージ(救助要請とか)、科学的データ、メッセージングとか。

セキュリティやパケロスの問題についての質疑が行われていた。

An Architecture for IP in Deep Space

non-goalとして挙げられているのは、Webサーフィン、sshなどのterminal access、Facetime(などのビデオ通話？)、何かしらのインタラクティブ性が要求されるものとか。

IPv4やIPv6には変更は不要だろう。deep spaceにおいては、パケットを転送する先が存在しない場合があるので、転送可能になるまで長期間保持しておく必要があるだろうというのは確かに。UDPはそのまま使えるが、QUICはRTTが数百ミリ秒であるのが通常なので、デフォルトの構成だと宇宙には持っていけない。これに関してはシミュレーション環境において適切なパラメータのもとではQUICスタックが機能することが確認されている。TCPに関しては未調査。HTTPは、Cache-ControlやExpiresなど時間がかかわってくるheaderを使うのは適していない。などなどなど。

QUIC Simulation Results and Profile

で、そのQUICをdeep spaceにもっていく場合の話。RTTが7日間にも及ぶというのはすさまじい。長いRTTのために、initial_rtt、max_idol_timeoutなどのパラメータを調整したプロファイルの話が出ている。実験環境というのはこれ https://github.com/aochagavia/quinn-workbench かな。

Key Exchange Customization for TIPTOP

スライドの副題が “Implementing MLS inside QUIC” となっていてリアルに声が出た。QUICはセキュアな通信路の確立のためにTLSを使うけど、同期的な通信を要求する。かといって0-RTTではFoward Secrecyが低下する。そもそも非同期的に通信を行うため(？)にはContinuous Key Agreement (CKA)を行う必要があり、TLSはCKAではない。ならMLSを使おう！という提案。その発想はなかった。

提出されたスライドで、QUIC protocol stack内でMLSを使うことを示している図

MLS詳しいパーソンからの解説が待たれる……

QUIC wgにも持っていこうという話になった。TLS Extended Key Updateなら解決するのか？という点に関しては、それも依然として同期的なために根本解決ではないという返答。

その他

他にも、このwgで文章をどう編集していくかについて、GitHubでは特定の国からアクセスできない問題があるのでGitHubに依存したワークフローを採用するのが正しいのか？であるとか、使用すべきフォントは何にすべきか、自転車小屋の屋根は何色に塗るのかなどの質疑応答があった。できたばかりのwgなのでこれから色々決まっていくんでしょう。

webtrans

Agenda

2月に亡くなられたBernard Aboba氏への追悼があった。

W3C WebTransport Updateはほぼ完了、最終的には9月にW3C勧告として公開される予定。変更点はリダイレクトをネットワークエラーとして扱うようになったり、stats.atSendCapacityが追加されたりと色々。

Forward and Reverse HTTP/3 over WebTransport

WebTransport上にHTTP/3を実装する……？反応としてはこれは独自のWGでやるべきだとか、webtrans wgのcharterでは対象としてないとか、結構攻めた提案という印象。

wish

Agenda

う～～んminutesが淡白！

https://datatracker.ietf.org/doc/draft-ietf-wish-whip がAUTH48になってるという議事録が残ってるけど、今見ると https://datatracker.ietf.org/doc/rfc9725/ もうRFC 9725になってましたね。

このwgは閉じられるのか？に関しては、whepがまだあるということでもうちょっと残る？

masque

Agenda

Proxying Listener UDP in HTTP

リクエスト、レスポンスのヘッダに connect-udp-bind を使うことで、proxyのportをbindする。前回からの更新はeditorialなもののみ。実装はGoogle QUICHEがある、他の実装も探していて、実装しようと思っている人はいる。充分な相互運用性が確認できたらWGLCになりそう。

QUIC-Aware Proxying Using HTTP

Googleが実装に対して積極的だけど時間がない、次のIETFでconnect-udpと合わせてinterop testをやろうという提案があった。でも残ってるissueをcloseできたら、そのテストの前にWGLCにする予定？

Proxying Ethernet in HTTP

121からの変更点は配信できないEthernet frameに関しては、endpointはdropしなければならなくなったことと、輻輳制御によるパフォーマンスの懸念事項が追加された。相互運用のための実装募集中。WGLCしたいけど、その前にIEEEからレビューを受けるべきという意見。

DNS Configuration for Proxying IP in HTTP

これも相互運用性の確認のための実装を募集中か～。

The MASQUE Proxy

スライドの写真、良い……状況は謎だけど。MASQUEを使うとはどういうことなのか？について明らかにするための文書。Informationalだ。実際、このdraftはMLS architectureのdraftからリンクが貼られている(RFC 9750になる？)。

これが文書としてまとまってるのはいいことだけど、pearg(Privacy Enhancements and Assessments Research Group)の仕事かもしれないという意見。これに時間を割いて議論すべきか？という投票は賛成多数で可決された。

IETF 127について

IETF 127は現時点で2026年11月14日からの開催が予定されています。

しかし、現在の米国の状況から、本当にサンフランシスコで開催するのかどうか、そしてサンフランシスコで開催された場合に現地参加できるのかどうかという懸念が高まっています。

これについては今回のPlenaryでも話題に挙がっており、1:57:28以降がそれについての議論です(多分)。ここで発言しているトランスジェンダーの方は、ドイツ政府から「あなたのパスポートで米国に入国しようとすれば、パスポートの詐称とみなされるので逮捕されるだろう」というアドバイスを受けたと述べています。

マジかよ……という感じですね。そしてIETF 127をサンフランシスコから別の場所で開催することを検討しているのか？という質問に対しての返答は「3/5時点では開催地の移動はしないことになっている。ただし再度議論は行われる」というものでした。財政的にも厳しいというのは、Kaigi on Railsの運営として大人数が集まる会議の場所を抑えることの難しさを知っているので十分理解できますが、しかし入国するだけで逮捕される可能性があるっていうのはちょっとなあ……

そしてこんなページができていました。

https://boycott-ietf127.org

Post by @q@glauca.space
View on Mastodon

ページを作成したのは、Plenaryで質問していたMisellさんですね。

The IETF Administration LLC has decided to continue to hold meetings in the US, in spite of significant threats to the safety of the community in traveling there. As an Internet community we strive to include everyone. Holding a meeting in the US is incompatible with our values. We call on the IETF community to refuse to travel to the 127th IETF meeting, to be held in San Francisco.

IETF Administration LLCは、米国への移動におけるコミュニティの安全に対する重大な脅威があるにもかかわらず、引き続き米国でミーティングを開催することを決定した。インターネット・コミュニティとして、私たちはすべての人を包含するよう努めています。米国で会議を開催することは、私たちの価値観と相容れない。われわれは、サンフランシスコで開催される第127回IETF会合への渡航を拒否するよう、IETFコミュニティに呼びかける。 (DeepL訳)

このページの “The US is dangerous” の項目を見れば、永住権を持っていようが拘留されうるという状況になっているのがわかります。なんなら、この声明に賛同、署名してリストに名前を載せるだけで入国拒否されても不思議ではないのかもしれません。

まとめ

毎度前回からのupdateを記載していますが、これまでの経緯なんかを自分でも参照するのが面倒になってきたので自分向けでもいいからどこかにまとめておきたくなってきました。

2025年03月31日