要約

  • RFC 793は同期済み状態で受信ウィンドウ内のRSTを有効としたが、RFC 5961は即時リセットをRCV.NXTとの完全一致に絞った。
  • ウィンドウ内でも完全一致しないRSTにはchallenge ACKを返して破棄する。正規の相手は状態に基づき確認できるが、通信を見られない送信者には難しい。

弱点は、ひとつの判定に二つの役割を持たせたことから生まれた。受信ウィンドウは、本来なら「このバイト列がストリームに属し得るか」を決める。しかしRFC 793の規則では、RSTが同じ条件を満たすと「接続状態をすべて捨ててよい」という権限まで得た。経路外の攻撃者は通信を観測できなくても、番号を変えながら試し、広いウィンドウのどこかに当てればよかった。

2010年のRFC 5961は、この判断を三つに分けた。ウィンドウ外のRSTは黙って破棄する。番号が次に期待するRCV.NXTと完全に一致すれば接続をリセットする。そして、ウィンドウ内だが一致しないRSTには、SEQ=SND.NXT、ACK=RCV.NXTのACKを返し、疑わしいセグメント自体は破棄する。

これがchallenge ACKと呼ばれるのは、主張を相手の状態への質問に変えるからだ。通信相手が本当に終了または再起動し、古い伝送制御ブロックを持たないなら、受け取ったACKから新しいRSTを組み立てられる。その二度目のRSTは、生き残った側が期待する番号と完全一致し得る。盲目的な注入者は通常、この問いを見られず、おおまかな推測を正確な答えに変えられない。

重要なのは、受理可能性と権限を切り離した点である。ウィンドウ内という事実は、返答する理由にはなるが、不可逆な状態遷移を許す証明ではない。「無視する」と「破壊する」の間に、状態を温存したまま確認する選択肢が置かれた。

RFC 5961は、同期済み接続に突然届くSYNにも同じ発想を使う。SYNの番号にかかわらずchallenge ACKを送り、そのセグメントの処理を止める。偽装SYNなら、確立済みの相手は余分なACKを重複として扱うだけである。本当に再起動した相手は古い状態を失っているため、旧接続の終了を確認する別の反応が可能になる。

ただし、これは本人確認ではない。現在の番号を観測できる経路上の攻撃者を防ぐものでもない。RFC 5961は、同じアドレスとポートを再利用し、特定の初期番号を偶然選ぶ再起動時の例外も記す。盲目的攻撃の難度を上げる修正であり、TCPを暗号化する修正ではない。

規範の強さにも差がある。RSTとSYNへの緩和は推奨される一方、データ注入に対するACK範囲の厳格化は任意である。現在の基本仕様RFC 9293は一般的なRST処理を残し、RFC 5961を堅牢化策として参照する。標準の歴史は置換ではなく、旧い基盤の上に修正を重ねた記録として読める。

一次資料