HTTP/2のDDoS攻撃手法として『HTTP/2 Rapid Reset』(CVE-2023-44487)が世間を賑わせています。
各ベンダーから情報が出ています
- AWS 『How AWS protects customers from DDoS events』
- GCP『The attack used a novel technique, HTTP/2 Rapid Reset, based on stream multiplexing』
- Cloudflare『HTTP/2 Rapid Reset: deconstructing the record-breaking attack』
このDDoS攻撃はストリームのオープン(HTTPリクエスト)とストリームのキャンセルを繰り返すことで行われます。HTTP/2では、ピアが同時に開くストリーム数を制限する事ができますが、それではオープン/クローズを繰り返す行為を制限することはできません。
（実際にはストリームのオープン/クローズは瞬時に行われる）
このHTTP/2 Rapid Reset攻撃に対して、仕様上制限することができないか？という議論がIETFのHTTP WGで開始しています。すでに「Using HTTP/3 Stream Limits in HTTP/2」がひとつの案として投げかけられています。
来月行われる IETF 118でサイドミーティングが行われるようですが、ひとまずこの提案に目を通しておく。
Using HTTP/3 Stream Limits in HTTP/2
「Using HTTP/3 Stream Limits in HTTP/2」はHTTP/3で行われるストリームオープン制限方式をHTTP/2に適応することを提案しています。
HTTP/3が使うQUICでは、"同時にストリームがオープンしてる数"で制限をするのではなく、"ストリームをオープンする回数"で制限をかけます。
実際にはストリームIDの上限値をピアに通達します。MAX_STREAMSフレームを送ることで、上限値をあげることができます。通常の利用では次のようになると思います。
ストリームIDは再利用できないので、消費された分必要に応じてMAX_STREAMSフレームを送信し、ピアが利用できるストリーム上限を上げていきますわ
ピアが高速でストリームオープン/クローズされたとしても、上限に達した場合はピアはMAX_STREAMSフレームを受け取るまでストリームをオープンすることができなくなります。
この仕組みをHTTP/2に組み込みます
MAX_STREAMSフレーム
HTTP/2のMAX_STREAMSフレームは次の形式です。
Maximum Stream Identifierによって、上限となるストリームID値を指定します。このフレームをストリーム0で送信します。
有効性について
もちろん、実世界ではこの拡張仕様 (MAX_STREAMSフレーム)をサポートしてない実装も引き続き利用されつづけるでしょう。そのような実装は変わらず 同時オープン数(SETTINGS_MAX_CONCURRENT_STREAMS) に従って振る舞うことができます。
MAX_STREAMSフレームを解釈できるピアと、できないピアにたいしてヒューリスティックに異なる制約を実装上かけることはできるかもしれない。という形にはなるのかなと思っています。ストリームの並列数はパフォーマンスにも関わるのでそちらとの兼ね合いもトレードオフが有ると思います。
DDoSは正規の処理を大量に行う行為なため制限は悩ましいですね...
なんにせよこれから議論がされていくと思うので、全く別の手法も提案されるかもしれません。引き続き議論を追っていこうと思います
