要約

  • draft-ietf-scone-protocol-09 は、同じUDPデータグラムに入ったQUICパケットが有効だと認証され、実際に処理されることを助言採用の最低条件として明記した。後続パケットが破棄・無視された場合、重複の疑いがある場合も、SCONEの値は採用しない。
  • 送信側は、別の理由でQUICパケットを送る必要がない限りSCONEを送ってはならない。接続が静かなときには助言の期限切れを許す。いずれも審査中の草案の規定であり、実装普及やRFC化を示すものではない。

動画配信の受信側が速度助言を二度観測したとする。二度目のデータグラムに入った暗号化済みQUICパケットが、すでに受け取ったものの複製ならどうなるか。第09版の答えは明確だ。複製として無視されたパケットに付き添う助言を、新しい助言として扱ってはならない。受信ログの「到着」は、アプリが利用できる「受理」ではない。

SCONEは、経路上の装置が持続可能なスループットについての見方をQUICの両端に示す仕組みとして提案されている。助言は通常のQUICパケットと同じデータグラムに入る。ただしこの同梱条件そのものは新しくない。第07版と第08版も、同じデータグラムの別パケットが正常に処理されない限り値を無視するよう求めていた。第09版が加えたのは「正常」の最低限の意味と、破棄されたパケット、とりわけ重複候補に便乗する値の扱いである。更新日だけを見て仕組み全体を新発明のように伝えるのは誤りだ。

ここには重要な非対称性がある。認証されるのは同伴するQUICパケットであり、ネットワーク装置が書き換えた速度助言の発信者ではない。草案のセキュリティー節は助言自体が認証されないと明記し、正当なパケットの複製を先回りさせる攻撃の可能性も論じる。重複として処理された後の助言を退けられるとしても、先着した偽の値まで必ず防げるとは言えない。まして数字を設定した事業者の契約上の権限を証明しない。既存のDaniel Kadeの記事はその政策の出所を扱った。今回のニュースは、出所の前段にある受理条件の改訂だ。

送信機会についても同じく、旧稿と新稿を切り分ける必要がある。67秒の監視期間や、助言を求める端末が期間内に少なくとも二度SCONEを送る規定は以前からあった。第09版はさらに、SCONEのためだけにQUICの送信を作ってはならないと定める。通常の通信が続けば同乗の機会がある。通信が止まれば以前の助言が失効してもよい。これはQUICの接続状態が必ず終了するという意味でも、別途設定された事業者の速度制限が消えるという意味でもない。別の目的で必要なQUICの生存確認まで禁止したと読む根拠もない。

運用上は、四つの時刻を一つにまとめない方がよい。値がデータグラムに現れた時刻、同伴パケットが受理された時刻、アプリにその期間の最低値が渡された時刻、助言が期限切れになった時刻だ。第09版はアプリへ報告する場合、直前の監視期間に受け取った最低の助言を端末が報告する、と表現を改めた。単一の「最終受信値」だけでは、重複排除と期間の切り替えを検証できない。

IETF Datatrackerでは本稿はまだ活動中のInternet-Draftで、IESG評価のADフォローアップ段階にあり、DISCUSSの立場が残る。IANA欄も改訂版の再確認を要すると示す。承認済み標準でも障害の記録でもない。現時点で確かに言えるのは、受信と送信の境界が、以前よりもテスト可能な文章になったということだ。

出典