IETFでeBPFの標準化の議論

先月行われたIETF 115において、eBPFの一部ドキュメントをIETFからRFCとして出すか?という議論が行われました。

まだ議論の段階で結論は出ていないが、簡単にメモとして残しておく。

なお、僕自身はKernel, eBPF方面に明るいわけではない...

eBPF サイドミーティング

IETFでは会期中に特定トピックについて議論するサイドミーティングが行われます。IETF 115において「eBPF standardization side meeting」が開催されました。

eBPF Foundationのほうからは、Dave Thaler氏らを中心にeBPF Steering Committeeから数名と、IETF参加者がサイドミーティングに出席したようです。

概要

eBPF Foundation は、eBPF クロスプラットフォーム ドキュメントをどこで公開するかについて検討しています。主な候補は次の4つです:

  1. eBPF Foundation で発行
  2. eBPF Foundation によって公開され、ISO 番号が割り当てられるように ISO へ提出
  3. Independent Stream RFC として公開
  4. IETF RFC として公開

特に4点目をメインにディスカッションされました。技術的な部分はIETFでは関与しない想定だが、標準化のフローなどが適合するかなどが議論されました。一方でIETF内ではどのエリアで取り扱うかについて意見が出ましたが、INTやROUTINGが候補として上がっていました。

また標準化団体からの公開する必要性については、特にハードウェアベンダーが実装のために標準化仕様を望んでることが話されていました。

現在のeBPFドキュメントの管理

議論の中では現在のドキュメント管理状況についても説明されまいた。

現在、eBPFドキュメントは、Kernelのツリーに配置されています。

eBPF FoudationのGithubミラーリポジトリもあるようです (URL)。

パッチとしてebpf MLに投げられて、そこからリポジトリにマージされます。


(引用: eBPF side meeting @ IETF 115 - YouTube )

標準化候補のドキュメント

eBPFのうち次のドキュメントがIETFでの標準化候補としてあげられていました。

  • ISA
  • ELF file format
  • BPF type format
  • Compiler expectations
  • Verifier expectations
  • Cross-platform map types
  • Cross-platform program types
今後

引き続きさらなる議論が必要ということで、IETFにこの議論をするMLが出来ました。

subscribeはこちらから
Bpf Info Page

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の資料はここらへんです

社会人向け

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

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

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

Media over QUICの base draft について

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

MoQ (Media over QUIC) WGでは、今までユースケースや要件の整理を行ってきました。そうして、配信者からのアップロード(ingest) + 視聴者への配信 (distribution)をユースケースとして、メディアを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: セグメントのデコーディングに必要な依存関係を配列値として指定する。

HTTP Alternative Services, Plan B のメモ

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フレームが定義されています(説明割愛)

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

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

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

DNS HTTPS レコード

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

やや古い記事ですが、DNSHTTPSレコードについては以前書いたとおりです。
ブラウザが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リクエストに備える事ができます。

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

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

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に用いたシークレット

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

サードパーティ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を添付する