要約

  • 相手のアドレスを検証する前、応答する QUIC 端点はそのアドレスから受信したバイト数の3倍を超えて送信できない。
  • この台帳は特定段階での送信元偽装による増幅を制限するが、クライアントの本人確認でも包括的な DDoS 対策でもない。
  • 正当な検証待ちを損失や過負荷と区別するには、バイト計数と検証状態の遷移を残す必要がある。

サーバーが Initial データグラムを受信し、ハンドシェイク flight を作り、許された送信枠を使い切った場面を考える。残りのデータは準備済みで、経路も到達可能、CPU とメモリにも余裕があるかもしれない。それでもサーバーはクライアントから追加データを受け取るか、アドレスが検証されるまで待たなければならない。

これは RFC 9000 のセキュリティ境界である。攻撃者は被害者の送信元アドレスを偽装し、サーバーから被害者へ応答を向けさせ得る。その反射量を抑えるため、未検証アドレスに応答する端点は、そこから受信した量の3倍を超えてデータを送信してはならない。

累積する台帳として理解するのがよい。受信バイトが上限を増やし、送信バイトが予算を消費する。着信パケットごとに独立して3倍を認める規則ではなく、直近のデータグラムだけでは残額を計算できない。

8.1節 は接続確立時の計数を定める。サーバーは一つの接続に一意に帰属するデータグラムの全ペイロードバイトを数える。サーバーの Initial または Handshake が失われると予算は消費されたままで、クライアント側は送信済みデータがすべて確認済みなら追加送信の理由がない。RFC はこの条件で行き詰まり得ることを説明している。

したがって運用記録には、未検証アドレスからの受信量、そのアドレスへの送信量、現在の上限と残額、送信が止まった時刻、未送信のハンドシェイク量を含めるべきである。これがなければ、損失、予算枯渇、サーバー資源圧迫は同じタイムアウトに見える。

アドレス検証が示す範囲も限定的である。接続確立中は Handshake パケットの受信や Initial のトークン検証が状態を変え得る。Retry は、申告アドレスで受け取ったトークンを返すようクライアントに求められる。新経路では 8.2節 の PATH_CHALLENGE と一致する PATH_RESPONSE が、特定のローカル・相手アドレス間の到達性を検証する。ACK だけでは偽装可能なため不十分である。

これらはアドレスの利用者を特定しない。受信可能性やトークン規則への適合を示すだけで、人、端末、アカウント、アプリケーションを認証しない。検証後は3倍の上限を超えて送信できる。輻輳制御、フロー制御、暗号状態、アプリケーション方針は残るが、この台帳は恒久的なレート制限ではない。

完全な DDoS 対策と呼ぶのも誤りである。RFC 9000 の21.2節 はハンドシェイク時のサービス拒否を扱い、21.9節 は処理能力や接続状態を消費させる悪用を扱う。別の 21.3節 が、検証トークンとアドレス再割り当てに伴う残余の増幅リスクを説明する。検証前の帯域上限だけでは、CPU、状態表、認証済み洪水、検証後のアプリケーション負荷を制御できない。

編集上の運用提案として、監視では三つを分離する。どの証拠がアドレスを検証するのか、バイト台帳の残額はいくらか、そしてパケット率・CPU・メモリ・接続状態に独立した圧力があるかである。この分離が、到達性を本人確認や総合的な安全保証へ膨らませるのを防ぐ。

推奨する完全な記録には、接続・経路識別子、ローカルと相手の IP/ポート組、観測時刻、検証状態・遷移・方法、未検証アドレスからの受信バイトと同アドレスへの送信バイト、現在の3倍上限と残額、未送信のハンドシェイク flight、Retry またはトークンの結果、該当時の PATH_CHALLENGE/PATH_RESPONSE 結果、損失・再送コンテキスト、制限開始と最終制限の時刻、検証後の結果、CPU・メモリ・接続状態・パケット率の個別指標を含める。