2022-11-24

IETF116 Yokohamaをもっと楽しむために (その1) ~参加申し込み~

雑イベントレポート

IETFではインターネットで使用されているプロトコルの標準化を行っています。TCPやHTTPの仕様がRFCという文書として公開されているのをご存知の方も多いでしょう。

そのIETFは、年3回オフラインのミーティングを実施しており、次回(2023年3月25日~) の開催地は横浜(Yokohama)となっております。

前回日本で開催されたのは2015年ですので、8年ぶりということになります。プロトコルの標準化の会議を実際に見る貴重な機会になるかとおもいますので、これを機会に参加しようと思われる方もいるでしょう。

そんな方のために、よりIETFを楽しむための幾つか記事を書いていこうかと思います。

1.「参加申し込み」
2.「予習/事前の議論のキャッチアップ」
3.「WG紹介, ホットトピック紹介」
4.「当日の流れ/会議の流れ」

特にIETFのミーティングは、メーリングリストや前回の会議の続きでディスカッションされることが多いですし、Draftの細部のディスカッションが多いため個人的には予習していったほうが良いかと思います。

何はともあれ、まずは参加申込みが必要です。今回は参加申し込みについて書いていきます。

その他ご質問あればお気軽にどうぞー

申込み

IETF 116の申込みは https://registration.ietf.org/116/ からすでに行うことが出来ます

2月6日までは Earliy Bird期間であり、お安く申し込みすることが出来ます(Week Passで700$)。期限が過ぎても割高ではありますが3月13日まで参加申し込みは出来ます。

IETFは1週間かけて行われ、チケットによって参加形態が異なります。

Week Pass: 1週間の参加券
One Day Pass: 1日参加券
Studnet Pass: 学生用参加券
Hackathon: 土日行われるハッカソン

申込みフォームの入力

申込みフォームについては、英語ですが悩むところは無いと思います。まずは、IETF用アカウントを作成して、個人情報の入力が必要です。

"T-shirt"
- 現地で貰えるTシャツです。サイズを申告しとくと良いでしょう。
"How many IETF meetings have you attended?"
- 初参加の場合は"this is my first"を選択すると良いでしょう。名札にNew Commerシールが付いてきます。これがあるとNew Comer限定の懇親会/ディナー会に参加できます。WGチェアなどとも話せる貴重な機会だと思います。
attendees mailing list
- 参加者向けのメーリングリストに登録されます。アジェンダ情報のアップデート、海外の方向けの旅行情報、遺失物の連絡などのやりとりがされます。また、全体懇親会 Social Event(有料) のチケット情報などが流れます。
Policies
- IETFの参加ポリシーになります。目を通していただくことになりますが... 特に大きく気をつけることはないかと思います

なお、支払いは基本的にはクレジットカードかPaypalとなってます。支払いが完了するとレシートが発行されます。

ハッカソン

IETF期間中(土日)にハッカソンが開催されます。参加には無料の申込みが必要です
(Week Passを購入しててもHackathon申込みをしてないと開催部屋に入れてくれません)

雰囲気としては、こんな感じで有志で集まってプロトコルの開発をしたりします。

(画像引用: https://www.ietf.org/blog/ietf114-hackathon/)

参考までに前回のIETF115の資料はここらへんです

開発テーマ一覧: IETF 115 Hackathon | IETF Community Wiki
発表スライド: https://github.com/IETF-Hackathon/ietf115-project-presentations

社会人向け

イベント参加フローが各社あると思いますので、それに準じて進める必要があります。

参加の社内申請 (参加目的の説明 + 予算確保)
参加費用 (+ 遠方の方は旅費) の稟議
- 初参加者ディナー、全体懇親会は有料ですので、必要があれば合わせて費用申請する。
開催後にレポートの作成

参加については、ハッカソンに参加しない場合は月曜からで問題ないと思います。また、金曜はお昼でセッションが終わるので夕方の時間で移動は可能かと思います。

つづき

その2はこちら
asnokaze.hatenablog.com

2022-11-07

Media over QUICの base draft について

HTTP QUIC internet-draft

IETFではQUICを使ってライブ映像などのメディアを転送するためのプロトコルの標準化を進めています。

MoQ (Media over QUIC) WGでは、今までユースケースや要件の整理を行ってきました。そうして、配信者からのアップロード(ingest) + 視聴者への配信 (distribution)をユースケースとして、メディアをQUIC上で配送するプロトコルの標準化を目指しています。

議論の中では、各社が独自に開発してきたプロトコルの紹介も行われました。

Facebook: RUSH - Reliable (unreliable) streaming protocol
Twitch: Warp - Segmented Live Media Transport (draft 01)
Cisco: QuicR - Media Delivery Protocol over QUIC

先月行われたMoQ WGの中間会議では、各社の提案をもとに、メディアを転送するためのコモンプロトコルの設計について発表がありました。
(スライドpdf)

それが今回取り上げる、base draftと呼ばれるものです。

Base Draft

中間会議のあと、実際に提案仕様として提出されたのが「Warp - Segmented Live Media Transport (draft02)」です。プロトコルの名称は、Warpの名前を冠していますが中身はメディア転送用のcommon protocolになっています(参照: MLでの投稿)。先に上げたTwitch, Facebook(Meta), Ciscoの方の共著になっています。

ingestやdistributionなどの用途まではまだ設計されていませんが、その用途でもcommon protocolがベースになるものと思われます。

まだ、メディアを転送するための必要最低限を定義しただけで、設計のたたき台という意味が強そうです。

ざっくり次のような感じです

WebTransportを用いた、一方向ストリーム
- 拡張で双方向ストリームもサポート
CDNなどのリレーサーバを意識した設計
- 明示的な順序付け
- 優先度
セグメントとしてfragmented MP4を利用 (その他も使えるようにする)
(HTTP DATAGRAMは拡張でサポート?)

( メディアエンコーディングする都合、ソフトウェアエンコーディング/ハードウェアエンコーディングを色々考慮されてそうだが、僕個人が詳しくないのでよく分からず... )

Base Draftのメッセージ

「Warp - Segmented Live Media Transport (draft02)」はまだたたき台で、必要最低限の部分しか定義されていませんが、ストリームの様子を見ていきます。

現在仕様では、ストリーム上でやり取りされるメッセージは次のようになっています。

各ストリームでは次のメッセージが送信されます

HEADERS: セグメントを配送するためのメタデータ。優先度や依存関係を指定できる
SEGMENT: fragmented MP4 (初期化フラグメントを持つか、それを持つ他のストリームに依存する必要がある)
APP: 任意のデータ
GOAWAY: 接続のGracefullシャットダウンを要求する (クライアントに接続し直させる)

HTTPではストリーム上でやり取りされるデータをフレームと読んでいましたが、メディアの用語との混乱を避けるため、ストリーム上でやり取りされるデータをメッセージと呼びます。

HEADERSメッセージ

セグメントを配送するためにHEADERSメッセージを送ります。これらの情報はリレーする際にも利用されます。

HEADERSは次のフィールドを持ちます。

id: HEADERSメッセージの一意な識別子
order: 配送順序を指定する整数値。この順番に配送されるように優先制御される。
depends: セグメントのデコーディングに必要な依存関係を配列値として指定する。

2022-11-05

HTTP Alternative Services, Plan B のメモ

HTTP internet-draft

IETFのHTTP WGで『HTTP Alternative Services, Plan B』という仕様の議論されている。

これは、RFC 7838 『HTTP Alternative Services』の課題を改善するための取り組みです。

ざっと読んでメモ

RFC 7838 HTTP Alternative Services

HTTP Alternative Services (代替サービス)は、サーバが提供するWebサービスの代替をクライアントに通知する仕組みです。

代替通知により、ことなるサーバからそのWebサービスを提供できるようになります。

よく使われているのは、HTTP/3 のサポートをクライアントに通知するのに使われています。下記のようにalt-svcヘッダをレスポンスで返すことで、クライアントにHTTP/3で接続するように通知できます。

alt-svc: h3=":443"; ma=2592000

なお、代替サービスは別のドメイン名も指定できます。次の例は、alt.example.comの8000版ポートでこのWebサービスを提供していることを通知できます。クライアントはそちらのサーバに繋ぎにいきます。

alt-svc: h2="alt.example.com:8000", h2=":443"

まとめると、alt-svcのユースケースは主に次のとおりです

クライアントに合わせて、適切な場所のサーバに誘導する
負荷分散やシャットダウンの都合のために別のサーバに誘導する
HTTP/3で接続できることをクライアントに通知する

HTTP Alternative Services の課題

既存のHTTP Alternative Servicesは、レスポンスヘッダで次のように通知されます。このとき、maで指定された秒数クライアント側でキャッシュされます。

alt-svc: h3=":443"; ma=2592000

このmaが長く設定されるとクライアントは長くそのAlternative Servicesを使いますし、短すぎると再確認の発生が増えます

また、クライアント側で長くキャッシュしてると、サーバ側のインフラ環境が変わった場合に追随できません。

さらに、HTTP/3のアドバタイズはDNS HTTPS レコードを用いており HTTP Alternative Servicesのキャッシュ期間とは異なるメカニズムを持っています。
asnokaze.hatenablog.com

このようにAlternative Servicesを一貫して管理/提供が課題として上げられています。

HTTP Alternative Services, Plan B

説明したHTTP Alternative Services課題にたいして、IETF HTTP WGではDesign Teamを結成し課題の整理と解決策の議論をしていました。

そのDesign Teamの最初のアウトプットとして出てきたのが『HTTP Alternative Services, Plan B』です。

このPlan Bでは、一貫してDNSからAlternative Services情報を提供するように設計されています。

今までのユースケースに対して次のようなアプローチです

HTTP/3などの別プロトコルのアドバタイズ => DNS HTTPS レコードを使用
別サーバに接続を誘導 => 一旦クライアントにDNSを引かせ、再接続させる

特に2点目の接続の誘導のために、alt-svcbヘッダを導入しています。

こんな感じでレスポンスを返すと、クライアントはalt-svcbで指定されたドメインにHTTPSレコードを引いた上で、代替サービスとして使用します。

200 OK HTTP/1.1
date: Mon, 24 Oct 2022 02:58:31 GMT
alt-svcb: "instance31.example.com"
content-length: 0

HTTP/2やHTTP/3では専用フレームも使うことが出来ます。ALTSVCフレームのようにALTSVCBフレームが定義されています（説明割愛）

2022-10-27

DNS HTTPSレコードで別ドメインにpreconnectさせる提案仕様

HTTP internet-draft

「A Preconnect Hint for SVCB/HTTPS RR」という提案仕様がIETFに提出されています

これは、DNS HTTPSレコードを用いて、クライアントに別ドメインに対して事前接続(preconnect)させることを可能にします。

DNS HTTPS レコード

今回使う DNS HTTPSレコード自体はすでに使われてる仕組みです。

やや古い記事ですが、DNSのHTTPSレコードについては以前書いたとおりです。
ブラウザがhttpsでサーバに通信する際に有用な情報を名前解決時に提供できるようになります。

asnokaze.hatenablog.com

A Preconnect Hint for SVCB/HTTPS RR

「A Preconnect Hint for SVCB/HTTPS RR」の仕組みは具体例があると分かりやすいかと思います。

例えば、https://example.com はページのサブリソースとしてwww.example.comやscripts.example.orgを含むとします。

通常ブラウザは、https://example.com にアクセスしてHTMLをパースしてサブリソースを取得するために、scripts.example.orgに接続しに行きます。

preconnectHint

今回の提案では、HTTPS レコードにpreconnectHintといパラメータを追加します。

example.org IN HTTPS 1 . alpn=h2,h3 preconnectHint=www.example.com,scripts.example.org

クライアントは、example.orgの名前解決する際に合わせてこのレコードを取得し、preconnectHintで指定されたドメインに事前に接続を確立しておきます。

具体的には名前解決とTCP, TLS, QUICなどのハンドシェイクなどまで終わらせておきます(W3C Resource Hints)。そして、将来のHTTPリクエストに備える事ができます。

これにより、サブリソースを取得する際に発生するコネクション確立の待ち時間を減らすことが出来ます。

2022-10-26

TLSの復号に用いる SSLKEYLOGFILE のフォーマット提案仕様

TLS internet-draft

QUICやTLS通信のデバッグを行うために、TLS実装が通信に用いたシークレットをファイルに出力することがあります。多くの実装は SSLKEYLOGFILE という形式で出力することが一般的になっています。このファイルをWiresharkなどに食べさせることで該当通信の復号が行なえます。

たとえば、QUICは以前書いた手順で復号できます。
asnokaze.hatenablog.com

SSLKEYLOGFILE のファイル形式は、NSSのドキュメント(URL)で見ることが出来ますが

ちゃんと SSLKEYLOGFILE を仕様化するために「The SSLKEYLOGFILE Format for TLS」という提案がIETFに提出されています。

SSLKEYLOGFILEの中身

例えば OpenSSLでSSLKEYLOGFILE を出力すると次のとおりになる

# SSL/TLS secrets log file, generated by OpenSSL
SERVER_HANDSHAKE_TRAFFIC_SECRET 24878b76381f03203d3c4772bf51c49c5786c7adcf7d8fdd644460d5deafd6d5 b48d1fdc6b10b6f4765456e8407649b25971f3384e63461bdacab59c2488cacb8bb7dcde0aa1e2c6ede9390b568624f4
EXPORTER_SECRET 24878b76381f03203d3c4772bf51c49c5786c7adcf7d8fdd644460d5deafd6d5 b56d696bd2fc3ef533dea35a6f907586cbbd7d049fd027d9964d3b924435ea157bfc955a55ef1d6ea7d5012ea906dee3
SERVER_TRAFFIC_SECRET_0 24878b76381f03203d3c4772bf51c49c5786c7adcf7d8fdd644460d5deafd6d5 4676aa104c6ac82822f4450c5a8d3990f70b64005bed05e50a9586e4cd2a6c0187fec0220a83ed21e69eb61fd9e9cfaf
CLIENT_HANDSHAKE_TRAFFIC_SECRET 24878b76381f03203d3c4772bf51c49c5786c7adcf7d8fdd644460d5deafd6d5 6ef4d40e4103a2aa00c985a5287314048fdaddd781f7ee90a2b98513efef6fde04a00950721660ba9e5afb184fbafc70
CLIENT_TRAFFIC_SECRET_0 24878b76381f03203d3c4772bf51c49c5786c7adcf7d8fdd644460d5deafd6d5 8408e4b76dfcb3850eea590c8be1a0fb42a5c63f85246b1b6b16661241670f19c0a511b3d683d5bafc650e89efc04890

#で始まる行はコメント行である。

各行の意味

各行は、スペース区切りで「label」「client_random」「secret」の3つが記述される。

label: シークレットのタイプを示す識別子
client_random: ClientHelloのランダムの値。これによりどのコネクションのシークレットかわかるようになっている。
secret: シークレット値

ラベルの種類

TLS1.3で使うlabelは次の種類がある

CLIENT_EARLY_TRAFFIC_SECRET: early dataに用いたシークレット
EARLY_EXPORTER_MASTER_SECRET: early exportersに用いたシークレット
CLIENT_HANDSHAKE_TRAFFIC_SECRET: クライアントが送った handshake レコードに用いたシークレット
SERVER_HANDSHAKE_TRAFFIC_SECRET: サーバが送った handshake レコードに用いたシークレット
CLIENT_TRAFFIC_SECRET_0: クライアントがapplication_data レコードに用いたシークレット。(数字はKey Updateにより増える)
SERVER_TRAFFIC_SECRET_0: サーバがapplication_data レコードに用いたシークレット。(数字はKey Updateにより増える)
EXPORTER_SECRET: exportersに用いたシークレット

2022-10-20

CookieのPartitioned属性 (CHIPS) の標準化はじまる

雑 internet-draft

サードパーティ Cookieをトラッキングに使用できないようにする「Cookies Having Independent Partitioned State (CHIPS)」という仕組みが議論されています。

現在は、その仕組はW3CのPrivacy CGで議論されています。細かい仕組みは以前書いたとおりです。

( トラッキングに利用できない3rdパーティクッキー「CHIPS」の仕組み (partitioned属性) - ASnoKaze blog )

このCHIPSは、Cookieに新しいPartitioned属性を利用します。Cookie自体の仕様は、IETFが発行するRFC 6265で定義されており、そこにPartitioned属性を追加してやる必要があります。

そのためIETF側にも「Cookies Having Independent Partitioned State specification」というdraftが提出されています。

CHIPSのdraft

「Cookies Having Independent Partitioned State specification」のdraftは割りとシンプルです。rfc6265bisで定義されているCookie処理の手順にPartitioned属性周りの処理を追加するだけです。

ユーザエージェントがcookieの保存時

set-cookieヘッダを受け取った際に、Secure属性 (secure-only-flagがon) があり、Partitioned属性を処理する
保存時のcookieの"cookie-partition-key"として、ドキュメントの最上位のブラウジングコンテキストのsiteに設定する

ユーザエージェントがcookieを送信するとき

cookie-partition-key が設定されている場合は、cookie-partition-keyが一致する場合のHTTPリクエストにcookieを添付する

2022-10-19

UUIDv6~UUIDv8と uuidrev の動向

雑 internet-draft

UUIDの新しいフォーマットとしてversion6~version8を追加する提案がIETFで行われていることは、以前記事で取り上げたとおりです。
asnokaze.hatenablog.com

その後、IETFでRevise UUID WGが立ち上がるなど、標準化に向けて動きがあったので簡単に紹介する
（今回は、具体的なUUIDv6~UUIDv8 の紹介は割愛する）

uuidrev

今年の8月、Revise UUID WG (uuidrev) が立ち上がりました。このWGの主な作業領域は次のとおりです。

UUIDを定義した RFC4122 を改訂し、既存のエラッタを治す
改訂版仕様にUUIDv6~UUIDv8 を組み込む

なお、これらの作業のマイルストーンとして2023年3月にIESGに提出することが掲げられています。

WG設立の流れは、7月に行われたIETF114の議事録に議論の様子が残っています(議事録URL)。Dispatch WGのミーティングで新しいUUIDの発表があり、この提案仕様の標準化の進め方を議論していました。そこでは、この取組をおこなうためのWG設立が好ましい旨発言されています。

rfc4122bis

uuidrev WGの取り組みとして RFC4122の改訂版となる「rfc4122bis」のdraftが公開されました。

内容は

UUIDの基本フォーマット
version1~version8までの定義
UUIDのベストプラクティス
- タイムスタンプの精度
- 分散システムでの生成
- ソート
- 衝突性
- などなど

目次としても、UUIDv6~UUIDv8の仕様が組み込まれたことが伺えます

詳しいエラッタ修正内容はdraft内に説明せれてるのでそちらをご参照ください。

なんにせよ、今後はこのdraftの動向をウォッチしておけば良さそうです。