Summary

  • 11月の MoQ リレー DoS 草案は、リレーが多数のクライアントへ GOAWAY を送り、第三者のホストを新しい接続先に指定できるという危険を追加した。相手は MoQT を運用していなくても接続試行を受ける。
  • MoQT トランスポート草案では、サーバーの制御ストリームから届く GOAWAY に空でない New Session URI があれば、クライアントは新しいセッションにそれを使わなければならない。接続先の指定と、その接続先の承認は別の事実だ。

視聴者の多いリレーが移行のために次の URI を配る。通常の運用では便利だ。問題は、リレーが無関係なサーバーを指したときである。接続していたクライアントが一斉にその場所へ向かう。改訂02の新しい段落は、標的が MoQT に対応する必要さえないと明記する。接続が成立しなくても、試行は相手側へ到達する。

ワーキンググループの仕様案第9.2節は、サーバーが制御ストリームの GOAWAY に新しい URI を含められると定める。空でなければクライアントは新しいセッションでその URI を使う。クライアントからサーバーへ同じ指示を出すことは役割違反だ。URI は最大8192バイトで、同じ制御ストリーム上で GOAWAY を繰り返すことも禁じられる。しかしこれらは、指定されたホストが移行を受け入れる権限を持つかを確かめない。要求ストリームの GOAWAY は特定の要求を指定 URI で出し直すことを推奨する別の規則である。大量の視聴者を動かす脅威は、サーバー側の制御ストリームにある。

7月の改訂01には、この第三者ホストの記述がなかった。11月版が加えたのは、リレーの負荷一般ではなく、移行先の指定が第三者への接続急増を作るという経路だ。草案は、クライアントが新しい URI に従う前に、その URI が正当な移行先だと確認できる仕組みを求め、具体的な規則はトランスポート仕様に委ねる。TLS が後で接続を拒んでも、最初の接続試行は既に送られている。公式資料に実際の事件や測定結果はない。IETF の記録では個人草案の段階だ。

必要な運用記録は、元のリレー、新しい URI、その URI を認めた規則、接続試行の件数と時刻、受信側の負荷をつないだものになる。「移行成功」という一行では、他人のサーバーへ請求書を送った可能性が見えない。