はい。今回はTZ的にはいわゆる仕事が終わった後に開始、というセッションが多く日本からのリモート参加も比較的しやすい回ではありましたが、Kaigi on Rails 2024のアフターイベントとか何やらとかでリアルタイム参加はひとつもできませんでした……
それでは例によって以下は個人的な感想を無責任に書き散らかしたものです。
minutesがいつものHedgeDocじゃなくて https://httpwg.org/wg-materials/ietf121/minutes.html になっているのはなにゆえ……?
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が割り当てられるかもしれない?
120からの主要なupdateとして、Content-Location ヘッダと Location ヘッダの用途についてとそれに設定するURIのガイダンス、Accept-QueryヘッダのIANAへの登録が挙げられている。議事録にはAccept-Queryの値に対してStructued Field Valuesは使わないでくれ、くらいしか記載がない。
スライドがない。とはいえIn WG Last Callだし、もう特に議論すべきこともない段階?
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が多めで前向きな感じがする。
“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
を送信することを可能にするか?という議題がある。前進しそう。
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は含まれるのか、とか。
結論としてはもうすこし議論しようということっぽい。
Delete-Cookie
ヘッダーで明示的にCookieを削除できるようにする?
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ がちゃんとRFCになってから取り掛かるのでいいのでは?という意見があった。
YANG(ヤン、英: Yet Another Next Generation)は、データモデル言語の一種である。NETCONF や RESTCONF などのネットワーク管理用プロトコルによりアクセスされるネットワーク機器の設定や状態、遠隔手続き呼出し (RPC)、通知をモデル化するために開発された。 https://ja.wikipedia.org/wiki/YANG
netconf wgのdraftについてhttpbis wgからのフィードバックはあるか、というやつかな。肯定的ではあるものの、もっと議論が必要という感じ。
MASQUE for TCPってスライドには書いてるし、そういうものを実現するためのもの?
HTTPの拡張CONNECTメソッド について復習する - ASnoKaze blog で connect-upd
を使うという解説があるけど、こっちは TCPの上に載せるのでconnect-tcp
を新しく定義して使うとある。
Capsuleを使うべきでは?という意見がいくつか。賛否両論で、さらに議論しようという結論。
もともと “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 というヘッダーで、URLのparamsに入っているものがレスポンスに影響するかどうかを知らせることができるようになる。なのでparamsのバリエーションによるキャッシュのうんぬんを制御できるってことだろうか。既にChromeにはサポートが入っているっぽい?call for adoptionされそう。
上記は前回の自分のblogより。
スライドで「CG Draft」にsuspendedとなっているのは、WICGでの策定?はやめて、httpbis wgでの作業に一本化したということ?なのか?
いわゆるGeoIPの話。間に中間者を挟むなどで自分のIP addrは知られたくないが、地理情報は伝えたい(?)ケースがある。そのときに Sec-CH-IP-Geo
で地理情報をサーバーに送信できるようにする提案。目的としてはIP addrによる地理情報の推測をやめていきたい、というものだとか。問題意識はわかるような……とりあえず継続して議論しようというステータス。
この章を書いている途中で 第2回 Media over QUIC とか勉強会 - moq-wasm 開発秘話!!【Media over QUIC とか勉強会】 | 高田馬場 Live Cafe mono に参加し、nttcom/moq-wasmを実装している方々とお話しすることができました。なので色々なワケワカラナイだった部分がだいぶわかるようになりました。やっぱ実装してるとより理解が進むし、実装しなければわからないこともあるということで。
IETF 120からinterim meetingsが12も実施されている。やば。そしてこの記事を書いてる間にもどんどんinterimが予定されていって、今ではこうなっている。
https://quic.video/blog/transfork/ が気になってるけど、議題にはないのかな?まあないか……
一番実装が進んでいるものでも 6 (unsubscribe) までで、7 (goaway) を実装できているものはない。そもそもinteropの内容が120から変わっていなかった、という話も(前述のスライドで)ありましたね。
IETF 120以降でMoQ Transportに入った変更まとめ。超interimがあったので、こういうのがあるのが本当に助かる……そしてまあ、いっぱいありますね。
複数のgroupにobjectが配置されている場合においてRTTを削減できるってことか?beneftとしてスライド内で説明されているのが以下。例えば解像度の切り替えなんかで嬉しいというように読める。議事録によると、スライドにあるproposal #2が賛成多数ということでその方向で進むらしい。
スライド読んで!
priorityについての記述のあいまいさがあるみたいで、そのための議論のよう。複数のgroup間でのpriorityの順序がどうなるか、ということっぽい。これもproposalが2つ挙げられており、決を取ったところproposal 2が賛成多数となった。proposal 2はsubgroup内でuniqueなpriority値をつける方式。見た感じgroupにもまたがっていそうだけど……?
スライド読んで!!
moq wgのプロセス及びワークフローについて。chairがコンセンサスを確認できていない、virtual interimで物事が進んでいて参加できない人がおいていかれる、運営が難しいという問題が挙げられている。いくつかの解決策が挙げられていて、議事録を見た感じではそれで合意した……?
なんか色々ある……まず、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として最低限どこまでサポートするべきか、みたいなところが今後のワークで明確になる?
スライド読んで!!!
解像度を変えるなどしたい場合に、新しいgroupを受信しても今ある解像度から新しい解像度とのgroupの間のobject(?)をもらわないといけないとき、SUBSCRIBE+UNSUBSCRIBEか、それにFETCHもまざってくるかというケースの複雑さを解決するために導入する仕組みがSWITCH。具体的にどうするかについてはこれからっぽい。
スライド読んで!!!!
Delivery TimeoutとMax Cache Durationが相対的でありベストエフォートである。もしパケロスや順序の入れ替わりがある場合にskewedとなる。エンコードに時間がかかるケースにおいてはcaches upできない??optionalな"timestamp"を導入することで解決するということらしいが。わかりません!
latencyの計測のためにmoqt上で時刻のmetadataを交換できるようにするっぽい。地理情報も含められるようになっている。しかし事情によりskipとなった。
recharterするっぽい?その兼ね合いでテストスイートがあると嬉しい、古くならないよう長期的にメンテされているべきだ、みたいな話がされていた。これ、Hackathonと関係していそうだけど。ns-3っていうやつが便利なツールっぽい。
なんか日本の大学の名前が見える……
なんかあったらしい。"Design a suite of test cases based on 5033bis, the proposed new BCP on Specifying New Congestion Control Algorithms" は超ステキだと思うが。成果は……どこにまとまってるんだろう???
変更点としては、wg draftになっているとか、元文書がXMLからMarkdownになっているとか、明確化したとかとか。軽微なアルゴリズムの変更をするpull reqが2つopenになっていて、TCPでないtransport(主にQUICのことを指してる)に対する一般化についてのissueがopenになっている。
現実世界でのdeployに協力してくれるボランティアを募集している段階?ccwgのワークとして取り組むことに賛成の意見が多いので、引き続きなにかしら行われそう。
送信者のデータ送信がrate limitedな場合における輻輳ウィンドウの増加について……?この挙動について、十分な送信が行われていない場合には輻輳ウィンドウの増加に制限をかけるようにする提案。"Who thinks we should not do work on this topic" が0 votesなので、肯定的な反応。
が、前回。これも投票の結果、ccwgのワークとして取り組むことに前向き。
スライドの最後がオシャレ。ccwgのワークとして取り組むことの賛成は反対より多かったけど、no opinionを含めてあまり差がない感じ。どうなるんだろう?
他のものについては時間切れ。
こんなwgありましたっけ……?って思ったけどpast meetingsは110からあって完全に節穴でしたね。
WebRTC Ingest Signaling over HTTPSなのでWHIP/WHEPのwg。
WebRTC のシグナリング規格 WHIP と WHEP について が概要をつかむのにはわかりやすいかも。
agendaはこれだけ。そしてin WG Last Call状態。行われた議論自体はGitHubで未解決のissueについてとWHEPについて。WHEPはURLをどうするかについてどうしようか状態なのと、失敗(何に?)した場合の振る舞いについて定義しないといけない、ということについての議論があった。minutesを読むと議論があったことはわかるけど結論は書かれていなくて、合意に至らなかったのかな。
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_INTERFACE
やNO_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になるかどうかについては、もう一回改訂を重ねるということになった。そもそもやろうとしてることが多くて大変とも。
なんだこの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に向けて解決しないといけない、というところで終了。
P2Pな状況におけるQUICにおいてpublic addressを検出、シグナリングするための拡張。そもそもquic wgとして取り組むべきかどうかについての投票が行われ、賛成多数。
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の図)
フィードバック求む!状態。
httpなpathにrequestをした場合、httpsへと301 redirectするというのはありふれている。このとき最初のnon-secureなrequestにapi keyなどのcredentialが含まれているとunsecureだよね、という話。このdraftはBest Current Practiceなやつ。serverおよびclientに最初からsecureな通信での開始を行うための指針を提供するもの。HSTSとかHTTPS DNS recordとか。
なぜスライドにこんなに映画ネタを……? https://httpsig.org/ を今さら見て気付いたけど、Ruby gemとして https://github.com/nomadium/linzer というのができているのか。これはRFC準拠っぽい。
RFC 9530のDigest Fieldでdigestが不正だった場合に、RFC 9457の仕組みを用いて結果を返すためのschemaを定義するものかな?
oracle attackに注意というコメントがあった。
OpenAPIやJSON Schemaをresponseとして返せるようにするもの。レビューしてlast callの準備ができたか確認するということになった。
そういえばRate limitの仕組みがRailsに入ったよな……
patition keyが入った?のかな、これは便利という意見があった。
いつ見てもなんかSEGAを彷彿とさせる。
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には一致するバイト列が含まれており、プロキシの両側のフローを対応することができる、と……結論としてはこのような攻撃手法がある、という対応のみに留まりそう。
前回(っていうのは120のこと?)からの変更は特になく、WGLCになるまでに相互運用性があると嬉しいので、実装に意欲的な人を募集中、という段階。hackathonで1つ実装した、という話があった。Googleによるもの。それってこれのことなのかな? https://github.com/google/quiche/commit/29f785f59dfb33f4fff4c87852983c2cb7808ad0
hachathonでericsson clientとgoogle serverとのinteropが行われたとのこと。もっと他の実装も募集中。輻輳制御に関して未解決の問題が残っている。これについてどうすべきかはまだまだ議論が必要という感じになっている。
dnsop wgに持っていって早期レビューを受ける流れ?
会場めっちゃ広くない?????
あとIETF 121が終わってからML-DSAがめっちゃもりあがってるんだが……
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 Registyに入った変更について。"A stunning presentation.“
issueについて議論する回。AD reviewでついたDNSの問題については、合意に至らずADからの勧告があれば従うと。他にもいくつかあるopen issueについての議論が行われた。今repoを見てる感じでは、それらに対応した変更がcommitされていそう。
FATTの現状について。議論は公開されるべきだ、という意見が多い。(動画だと結構長い時間話してたけどmisnutesがアッサリめ)
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を作るよ、という話になったぽい。
certificateの圧縮。pass 2は複雑(これ2パス圧縮のことでいいのかな?)なので辞書なしのBrotilを使おうという提案がある、と。よりシンプルになるが圧縮率は落ちる。それはそれとしてZstdとBrotilのどっちでいくかはまだ議論中かな?
ExtendedKeyUpdateRequestを受信したときにalert & terminateしていたのがExtendedKeyUpdateResponseを返すように定義されたり、ExtendedなKey Updateが実行されたときにSSLKEYLOGFILEにどう記録するか、などの更新。未解決issueはもうない!
最新のWiresharkではもうサポートされている!!
アー