うなすけとあれこれ

2024年11月25日

IETF 121 Dublinにリモート参加しました

IETF 121 Dublin

はい。今回はTZ的にはいわゆる仕事が終わった後に開始、というセッションが多く日本からのリモート参加も比較的しやすい回ではありましたが、Kaigi on Rails 2024のアフターイベントとか何やらとかでリアルタイム参加はひとつもできませんでした……

それでは例によって以下は個人的な感想を無責任に書き散らかしたものです。

httpbis

Agenda

minutesがいつものHedgeDocじゃなくて https://httpwg.org/wg-materials/ietf121/minutes.html になっているのはなにゆえ……?

Resumable Uploads

05での更新はUpload-Lengthヘッダの追加など。次やることは文書の整理、実装の最新draftへの追従、相互運用性のテスト、本番環境での運用経験を得ること。クライアント側実装はSwiftとObjective-C(というかiOS用のライブラリ)、JavaScript。サーバー側実装はSwift、Go、.NETの3つ。

ハッカソンにおいて相互運用性のテストが行われ、全ての実装が最新のdraftに追従、試験もたくさん成功したとのこと。

https://wiki.ietf.org/en/meeting/121/hackathon#resumable-uploads-for-http-rufh

アップロードの進捗を取得するために1xx status codeを使うことについての議論があった。もしかしたら現在未使用の104が割り当てられるかもしれない?

QUERY Method

120からの主要なupdateとして、Content-Location ヘッダと Location ヘッダの用途についてとそれに設定するURIのガイダンス、Accept-QueryヘッダのIANAへの登録が挙げられている。議事録にはAccept-Queryの値に対してStructued Field Valuesは使わないでくれ、くらいしか記載がない。

Cache Groups

スライドがない。とはいえIn WG Last Callだし、もう特に議論すべきこともない段階?

Incremental HTTP Messages

last updatedが10/15で新しい、奥さん(連名)のdraft。

This document specifies the “Incremental” HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally.

abstractを読むとやはりCDNベンダっぽい課題感だなと感じる(とはいえ連名はFastly, Apple, Mozillaだけど)。HeaderにIncremental を指定することで、通信の中継者が全てのメッセージをクライアントから受信する前に背後(クライアント)に渡し始められる。これによって最終的にクライアントがタイムアウトとなる前にサーバーからのレスポンスを返せるようになる(例としてserver side events)……ってことかなあ。

スライドのmemeっぷりたるや。incremental enthusiastが多めで前向きな感じがする。

The HTTP Wrap Up Capsule

“GOAWAY is a sledgehammer”

00 → 01でIntroductionが大幅に加筆された。WRAP_UPによって、(MASQUEの例として)あるclientがCONNECT-UDPとCONNECT-TCP(あるいは別のproxy connection)の2つの接続を互いに別々のoriginに、単一のproxyを介して接続しているとき、CONNECT-UDPのほうでGOAWAYが起こると全部のconnectionが突然に終了されてしまう問題を解決できる。proxyの側がWRAP_UPをclientに送信することでclientがgracefullyにconnectionをdrainできる。client側からWRAP_UPを送信することを可能にするか?という議題がある。前進しそう。

Guidance for HTTP Capsule Protocol Extensibility

Capsuleプロトコルについては以下。

RFC 9297をupdateするもの。RFC 9297のwgはmasqueだけど、このdraftはhttpbisの議題になっている。capsuleの拡張性について。

Endpoints that receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule and skip over it to parse the next Capsule.

という文書における “endpoint” が一体何であるかが曖昧、というのを出発点にしている。proxyは含まれるのか、とか。

結論としてはもうすこし議論しようということっぽい。

Cookie eviction

Delete-Cookie ヘッダーで明示的にCookieを削除できるようにする?

https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ がちゃんとRFCになってから取り掛かるのでいいのでは?という意見があった。

AD-Requested Feedback (draft-ietf-netconf-http-client-server)

YANG(ヤン、英: Yet Another Next Generation)は、データモデル言語の一種である。NETCONF や RESTCONF などのネットワーク管理用プロトコルによりアクセスされるネットワーク機器の設定や状態、遠隔手続き呼出し (RPC)、通知をモデル化するために開発された。 https://ja.wikipedia.org/wiki/YANG

netconf wgのdraftについてhttpbis wgからのフィードバックはあるか、というやつかな。肯定的ではあるものの、もっと議論が必要という感じ。

Template-Driven CONNECT for TCP

MASQUE for TCPってスライドには書いてるし、そういうものを実現するためのもの?

HTTPの拡張CONNECTメソッド について復習する - ASnoKaze blogconnect-upd を使うという解説があるけど、こっちは TCPの上に載せるのでconnect-tcp を新しく定義して使うとある。

Capsuleを使うべきでは?という意見がいくつか。賛否両論で、さらに議論しようという結論。

Security Considerations for Optimistic Protocol Transitions in HTTP/1.1

もともと “Security Considerations for Optimistic Use of HTTP Upgrade” という名前だったのが後半が “Protocol Transitions in HTTP/1.1” に変更されている。

101(Switching Protocols) が返ってきた場合やCONNECT methodを使用する場合に使用されるプロトコルが変わることがあり、その場合におけるセキュリティ上の問題を解決するためのもの。Proxying UDP in HTTP" (RFC 9298)を更新するとも。 https://datatracker.ietf.org/doc/rfc9298/

スライドには120以降の変更についてと、HTTP CONNECTについて新規に追加された記載についてしか書いてないな?実際最終段階らしく、last callに向けてもっとreviewしようという感じで終わっている。

No-Vary-Search

No-Vary-Search というヘッダーで、URLのparamsに入っているものがレスポンスに影響するかどうかを知らせることができるようになる。なのでparamsのバリエーションによるキャッシュのうんぬんを制御できるってことだろうか。既にChromeにはサポートが入っているっぽい?call for adoptionされそう。

上記は前回の自分のblogより。

スライドで「CG Draft」にsuspendedとなっているのは、WICGでの策定?はやめて、httpbis wgでの作業に一本化したということ?なのか?

Editorial: Move No-Vary-Search to IETF HTTPbis by jeremyroman · Pull Request #338 · WICG/nav-speculation

IP Geolocation & HTTP

いわゆるGeoIPの話。間に中間者を挟むなどで自分のIP addrは知られたくないが、地理情報は伝えたい(?)ケースがある。そのときに Sec-CH-IP-Geo で地理情報をサーバーに送信できるようにする提案。目的としてはIP addrによる地理情報の推測をやめていきたい、というものだとか。問題意識はわかるような……とりあえず継続して議論しようというステータス。

moq

この章を書いている途中で 第2回 Media over QUIC とか勉強会 - moq-wasm 開発秘話!!【Media over QUIC とか勉強会】 | 高田馬場 Live Cafe mono に参加し、nttcom/moq-wasmを実装している方々とお話しすることができました。なので色々なワケワカラナイだった部分がだいぶわかるようになりました。やっぱ実装してるとより理解が進むし、実装しなければわからないこともあるということで。

Agenda

IETF 120からinterim meetingsが12も実施されている。やば。そしてこの記事を書いてる間にもどんどんinterimが予定されていって、今ではこうなっている。

めちゃくちゃ予定されているinterimの様子

https://quic.video/blog/transfork/ が気になってるけど、議題にはないのかな?まあないか……

Interop

一番実装が進んでいるものでも 6 (unsubscribe) までで、7 (goaway) を実装できているものはない。そもそもinteropの内容が120から変わっていなかった、という話も(前述のスライドで)ありましたね。

MoQT Updates Since Vancouver

IETF 120以降でMoQ Transportに入った変更まとめ。超interimがあったので、こういうのがあるのが本当に助かる……そしてまあ、いっぱいありますね。

JOIN

複数のgroupにobjectが配置されている場合においてRTTを削減できるってことか?beneftとしてスライド内で説明されているのが以下。例えば解像度の切り替えなんかで嬉しいというように読める。議事録によると、スライドにあるproposal #2が賛成多数ということでその方向で進むらしい。

スライド読んで!

Updating MoQT Priorities based on Implementation Experience

priorityについての記述のあいまいさがあるみたいで、そのための議論のよう。複数のgroup間でのpriorityの順序がどうなるか、ということっぽい。これもproposalが2つ挙げられており、決を取ったところproposal 2が賛成多数となった。proposal 2はsubgroup内でuniqueなpriority値をつける方式。見た感じgroupにもまたがっていそうだけど……?

スライド読んで!!

Process / Workflow

moq wgのプロセス及びワークフローについて。chairがコンセンサスを確認できていない、virtual interimで物事が進んでいて参加できない人がおいていかれる、運営が難しいという問題が挙げられている。いくつかの解決策が挙げられていて、議事録を見た感じではそれで合意した……?

WARP + Catalog Merge

なんか色々ある……まず、10月のinterimにおいて、CatalogについてはWARPにmergeし、個別のdraftにはしない。interopはメディアストリーミングフォーマットに焦点をあてる。この2つがCatalog design teamのsummaryとして合意を得られている。

interopに関するInformationalなdraft (MOQ-MI)も作成されている。

https://datatracker.ietf.org/doc/draft-cenzano-moq-media-interop/

WARPとMOQ-MIでサポートしている機能が異なることについての議論がされたっぽいけど、議事録は簡潔すぎてちょっとわからない。Core featureとして最低限どこまでサポートするべきか、みたいなところが今後のワークで明確になる?

スライド読んで!!!

SWITCH

解像度を変えるなどしたい場合に、新しいgroupを受信しても今ある解像度から新しい解像度とのgroupの間のobject(?)をもらわないといけないとき、SUBSCRIBE+UNSUBSCRIBEか、それにFETCHもまざってくるかというケースの複雑さを解決するために導入する仕組みがSWITCH。具体的にどうするかについてはこれからっぽい。

スライド読んで!!!!

Timestamps

Delivery TimeoutとMax Cache Durationが相対的でありベストエフォートである。もしパケロスや順序の入れ替わりがある場合にskewedとなる。エンコードに時間がかかるケースにおいてはcaches upできない??optionalな"timestamp"を導入することで解決するということらしいが。わかりません!

STOMP

latencyの計測のためにmoqt上で時刻のmetadataを交換できるようにするっぽい。地理情報も含められるようになっている。しかし事情によりskipとなった。

ccwg

Agenda

recharterするっぽい?その兼ね合いでテストスイートがあると嬉しい、古くならないよう長期的にメンテされているべきだ、みたいな話がされていた。これ、Hackathonと関係していそうだけど。ns-3っていうやつが便利なツールっぽい。

https://www.nsnam.org

なんか日本の大学の名前が見える……

Hackathon Update

なんかあったらしい。"Design a suite of test cases based on 5033bis, the proposed new BCP on Specifying New Congestion Control Algorithms" は超ステキだと思うが。成果は……どこにまとまってるんだろう???

BBRv3

変更点としては、wg draftになっているとか、元文書がXMLからMarkdownになっているとか、明確化したとかとか。軽微なアルゴリズムの変更をするpull reqが2つopenになっていて、TCPでないtransport(主にQUICのことを指してる)に対する一般化についてのissueがopenになっている。

SEARCH

現実世界でのdeployに協力してくれるボランティアを募集している段階?ccwgのワークとして取り組むことに賛成の意見が多いので、引き続きなにかしら行われそう。

Increase of the Congestion Window when the Sender is Rate-Limited

送信者のデータ送信がrate limitedな場合における輻輳ウィンドウの増加について……?この挙動について、十分な送信が行われていない場合には輻輳ウィンドウの増加に制限をかけるようにする提案。"Who thinks we should not do work on this topic" が0 votesなので、肯定的な反応。

が、前回。これも投票の結果、ccwgのワークとして取り組むことに前向き。

SCReAMv2

スライドの最後がオシャレ。ccwgのワークとして取り組むことの賛成は反対より多かったけど、no opinionを含めてあまり差がない感じ。どうなるんだろう?

他のものについては時間切れ。

wish

Agenda

こんなwgありましたっけ……?って思ったけどpast meetingsは110からあって完全に節穴でしたね。

WebRTC Ingest Signaling over HTTPSなのでWHIP/WHEPのwg。

WebRTC のシグナリング規格 WHIP と WHEP について が概要をつかむのにはわかりやすいかも。

WebRTC-HTTP Egress Protocol (WHEP)

agendaはこれだけ。そしてin WG Last Call状態。行われた議論自体はGitHubで未解決のissueについてとWHEPについて。WHEPはURLをどうするかについてどうしようか状態なのと、失敗(何に?)した場合の振る舞いについて定義しないといけない、ということについての議論があった。minutesを読むと議論があったことはわかるけど結論は書かれていなくて、合意に至らなかったのかな。

quic

Agenda

Multipath QUIC

10から11の変更点は4-tuple addressがhas already been validatedな場合にendpointがchallenge(とは何だ)なしでpacketをsendできるようになった、PATH_ABANDON frameのerror codeについての再定義とreason phaseの削除、最大path identifierに達したことを通知するPATHS_BLOCKED frameの追加、transport parameterの変更といったところ。hackathonでのinterop testの結果報告も。

話し合われたissueは4つ。issue 459はendpointがCIDを有効な各Path IDに対して発行しなかった場合どうなるかについて。現在のdraftにおいてはpeerが新規pathを開いたらCIDを発行するのがRECOMMENDED。 ただしMAX_PATH_IDがnegotiateされるまではPATH_NEW_CIDを送ることができないので、遅延させたい。合意に至らず。

issue 414はPath Abandonのerror codeについて。UNSTABLE_INTERFACENO_CID_AVAILABLEのようなものが必要か?という話。新規にpull reqを作成して議論するみたい。

issue 457はPTO handlingについて。ある1つのpathにendopointがpacketを送り、突然そのpathがブラックホールになった場合(つまりpacketが虚空に消えた場合か?)の挙動かな。RFC 9002に従えば、endpointはackがそのpathから戻されない場合、PTOが発生するまでそのpacketが失われたと見做されない。議論の結果、何らかの指針を追加することが決まったみたい。

issue 458はmultipathがnegotiatedな場合においてPath migrationかnew pathのどちらをすべきかについて。endpointは通信内容を送信するために新規4-tuple addressを使いたい。新規pathを作成するのがREDOMMENDEDとなっている。ここの内容、どういうことなんだ……

WG last callになるかどうかについては、もう一回改訂を重ねるということになった。そもそもやろうとしてることが多くて大変とも。

qlog

なんだこのbikeshedは(スライドp6)。qlog-main-schemaについては09で識別子の名前が変更されたりなんだり。

JSON-SEQがpainfulであるというbikeshedについて。JSON-SEQが何かというとRFC 7464のことらしい。今はJSON-SEQを使うこともできる、という状態(application/qlog+json-seq で返す)。他にもNDJSONやJSON linesという選択肢もある。JSON-SEQを使う場合、grep、vimとの相性が悪く、またjqで使うには --seq optionを渡す必要がある。それらを踏まえてJSON-SEQのままでいくか、他の何かを採用するか、それとも他のserialization formatを追加するか、何のstreaming serialization formatも推奨しないかのどれにするかという議論。結論は出なくて、年内のWGLCに向けて解決しないといけない、というところで終了。

Address Discovery

P2Pな状況におけるQUICにおいてpublic addressを検出、シグナリングするための拡張。そもそもquic wgとして取り組むべきかどうかについての投票が行われ、賛成多数。

Flexicast QUIC

The deployment of QUIC opens an interesting opportunity to reconsider the utilization of IP Multicast. As QUIC runs above UDP, it could easily use IP multicast to deliver information along multicast trees. Multicast extensions to QUIC have already been proposed in [I-D.pardue-quic-http-mcast] and [I-D.jholland-quic-multicast-05]. To our knowledge, these extensions have not been fully implemented and deployed.Flexicast QUIC takes a different approach. Instead of extending QUIC [QUIC-TRANSPORT], Flexicast QUIC extends Multipath QUIC [MULTIPATH-QUIC]. Multipath QUIC already includes several features that are very useful to allow a QUIC connection to use unicast and multicast simultaneously.

おお……?unicastについてはbidirectionalなpathを使い、multicastについてはshared unidirectional flowを使う?(p4の図)

フィードバック求む!状態。

httpapi

Agenda

HTTP Privacy

httpなpathにrequestをした場合、httpsへと301 redirectするというのはありふれている。このとき最初のnon-secureなrequestにapi keyなどのcredentialが含まれているとunsecureだよね、という話。このdraftはBest Current Practiceなやつ。serverおよびclientに最初からsecureな通信での開始を行うための指針を提供するもの。HSTSとかHTTPS DNS recordとか。

HTTP Signature

なぜスライドにこんなに映画ネタを……? https://httpsig.org/ を今さら見て気付いたけど、Ruby gemとして https://github.com/nomadium/linzer というのができているのか。これはRFC準拠っぽい。

Digest FIelds Problem Types

RFC 9530のDigest Fieldでdigestが不正だった場合に、RFC 9457の仕組みを用いて結果を返すためのschemaを定義するものかな?

oracle attackに注意というコメントがあった。

REST API Media Types

OpenAPIやJSON Schemaをresponseとして返せるようにするもの。レビューしてlast callの準備ができたか確認するということになった。

RateLimit header

そういえばRate limitの仕組みがRailsに入ったよな……

patition keyが入った?のかな、これは便利という意見があった。

masque

Agenda

いつ見てもなんかSEGAを彷彿とさせる。

QUIC-Aware Proxying

04での更新点は、Proxyはoriginal CIDsに限定した(as long asをこう理解していいのか?)virtual CIDsをpickしないといけない、MAX_CONNECTION_IDSをproxyに登録されるconnection idsの上限を限定するために追加した、など。スライドにある議題として、issue 113のPreferred address migrationについては追加の議論はなかった。issue 115のActive attack on scramble transformが主な議論。active attackerはiv生成のために使われるバイト列を複数のpacket間で共通になるように変更できる。packetそのものは無効または破棄されるけど、scrambled packetには一致するバイト列が含まれており、プロキシの両側のフローを対応することができる、と……結論としてはこのような攻撃手法がある、という対応のみに留まりそう。

Proxying Linstener UDP in HTTP

前回(っていうのは120のこと?)からの変更は特になく、WGLCになるまでに相互運用性があると嬉しいので、実装に意欲的な人を募集中、という段階。hackathonで1つ実装した、という話があった。Googleによるもの。それってこれのことなのかな? https://github.com/google/quiche/commit/29f785f59dfb33f4fff4c87852983c2cb7808ad0

Proxying Ethenet in HTTP

hachathonでericsson clientとgoogle serverとのinteropが行われたとのこと。もっと他の実装も募集中。輻輳制御に関して未解決の問題が残っている。これについてどうすべきかはまだまだ議論が必要という感じになっている。

DNS Configuration for Proxying IP in HTTP

dnsop wgに持っていって早期レビューを受ける流れ?

tls

Agenda

会場めっちゃ広くない?????

あとIETF 121が終わってからML-DSAめっちゃもりあがってるんだが……

Trust Tussle Interim Summary

Avoid client trust conflicts by enabling servers to reliably and efficiently support clients with diverse trust anchor lists, particularly in larger PKIs where the existing certificate_authorities extension is not viable.

たぶんinterimの議事録をもっとちゃんと読めばどういうものかわかりそうなのであとで読むかも……

https://datatracker.ietf.org/meeting/interim-2024-tls-01/session/tls

ステータスとしては、もうひとつdraftが来るという。

TLS Registries Update

TLS Registyに入った変更について。"A stunning presentation.“

ECH Discussion

issueについて議論する回。AD reviewでついたDNSの問題については、合意に至らずADからの勧告があれば従うと。他にもいくつかあるopen issueについての議論が行われた。今repoを見てる感じでは、それらに対応した変更がcommitされていそう。

FATT Updates

FATTの現状について。議論は公開されるべきだ、という意見が多い。(動画だと結構長い時間話してたけどmisnutesがアッサリめ)

DTLS Clarifications

RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3の改訂が必要だ、という1枚目から始まる。TLS 1.3とDTLS 1.3でKeyUpdatesの適用タイミングが異なるとか(マジで?)、1.3でしか対応していないACKがversionをまたいで使われる場合の挙動とか、Epoch managementが明記されていないとか、とか、とか……結構ございますわね。

repositoryを作るよ、という話になったぽい。

Abridged Certs Update

certificateの圧縮。pass 2は複雑(これ2パス圧縮のことでいいのかな?)なので辞書なしのBrotilを使おうという提案がある、と。よりシンプルになるが圧縮率は落ちる。それはそれとしてZstdとBrotilのどっちでいくかはまだ議論中かな?

Extended Key Update

ExtendedKeyUpdateRequestを受信したときにalert & terminateしていたのがExtendedKeyUpdateResponseを返すように定義されたり、ExtendedなKey Updateが実行されたときにSSLKEYLOGFILEにどう記録するか、などの更新。未解決issueはもうない!

SSLKeylog ECH

最新のWiresharkではもうサポートされている!!

まとめ

アー

2024年11月25日