偽造 RST による TCP 切断
A 社は，本社とデータセンタの間で，TLS で保護した長時間持続する TCP 接続を使ってデータを同期している。第三者が送信元を詐称した RST セグメント（以下，偽造 RST という）を送り付けて，この接続を切断する攻撃が懸念されている。偽造 RST による切断の成立条件や対策に関する記述として，適切なものはどれか。
- ア通信を TLS で保護しているので，偽造 RST は TLS のレコードの MAC の検証によって破棄され，TCP 接続は切断されない。
- イRST セグメントはシーケンス番号を検査されないので，攻撃者は送信元・宛先の IP アドレスとポート番号が分かれば，1 個の偽造 RST で確実に切断できる。
- ウ攻撃者は，送信元・宛先の IP アドレスとポート番号を接続に合わせたうえで，受信側の受信ウィンドウ内に収まるシーケンス番号を偽造 RST に設定する必要がある。
- エ拠点間を認証付きの IPsec ESP で保護しても，RST は TCP 層で処理されるので，偽造 RST による切断は防げない。
正解と解説を見る
正解 ウ
この問題の基礎知識
- TCP の接続は，送信元・宛先の IP アドレスとポート番号の 4 つ組で識別される。RST は，受け入れられると接続を直ちに中断させる制御フラグである。
- 受信ウィンドウは，受信側が次に受信を期待するシーケンス番号から始まる，受け付けるシーケンス番号の範囲である。経路外の攻撃者は通信を観測できないので，シーケンス番号を推測するしかない。
- TLS は TCP の上位で，IPsec は IP 層で動作する。認証や暗号化は，それを行う層が運ぶ上位の層のヘッダとデータを保護し，それより下位の層のヘッダは保護しない。
TLS は TCP の上位で動作し，TCP のヘッダや RST を保護しない。RST は TCP 層で処理され，TLS が検証する前に接続がリセットされる。アプリケーション層の認証は，トランスポート層への偽装攻撃を防げない。
接続の確立後は，RST もシーケンス番号で検証され，受信ウィンドウ内にない RST は無効として扱われる。経路外の攻撃者は，アドレスとポート番号に加えてシーケンス番号を推測する必要があり，多数の RST を送ることになる。
アドレスとポート番号の組が接続と合わない RST や，シーケンス番号が受信ウィンドウ外の RST は破棄されるので，両方がそろうことが切断の必要条件である。RFC 5961 を実装した TCP では，さらに次に期待する番号（RCV.NXT）との一致を求め，ウィンドウ内でも一致しなければチャレンジ ACK を返すだけである。
IPsec はネットワーク層でパケットの送信元と内容を認証する。鍵を持たない攻撃者が作った偽造 RST は認証に失敗し，TCP に渡される前に破棄されるので，TCP-AO などのトランスポート層の認証と同様に偽造 RST 対策として有効である。
照合の根拠（6 件）
- ウ（正解）・イ（誤り）: 確立後の RST はシーケンス番号で検証され，ウィンドウ内の番号でなければ有効にならない。シーケンス番号を検査しないとするイは誤り
In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ fields. A reset is valid if its sequence number is in the window.
RFC 9293 · Section 3.5.3（新しいタブで開きます） - ウ（正解）: 偽造 RST の攻撃者が持つ（推測する）必要がある情報として，両端の IP アドレスとポート番号の 4 つ組が挙げられている（2) としてシーケンス番号が続く）
1) The 4-tuple value containing the IP address and TCP port number of both ends of the connection.
RFC 5961 · Section 1.2（新しいタブで開きます） - ウ（解説の補足）: RFC 5961 を実装した TCP では RCV.NXT と一致する RST だけで切断し，ウィンドウ内で一致しなければチャレンジ ACK を返す（同節 3)）。ウィンドウ内であることは引き続き必要条件であり，正解の記述と矛盾しない
If the RST bit is set and the sequence number exactly matches the next expected sequence number (RCV.NXT), then TCP MUST reset the connection.
RFC 5961 · Section 3.2（新しいタブで開きます） - イ（誤り）: アドレスとポート番号が分かっていても，経路外の攻撃者はシーケンス番号を推測して多数の RST を送る必要があり，1 個で確実に切断できるわけではない
Put differently, a blind (i.e., off-path) attacker would need to send 57,000 RSTs with suitably spaced sequence number guesses within one round-trip time to successfully reset a connection.
RFC 4953 · Section 2.4（新しいタブで開きます） - ア（誤り）: TLS などアプリケーション層の認証はトランスポート層への偽装を防げず，偽造パケットはアプリケーションが検証する前に接続をリセットする
Application authentication cannot protect either the network or transport protocols from spoofing attacks, however. Spoofed packets interfere with network processing or reset transport connections before the application checks the data.
RFC 4953 · Section 5.3（新しいタブで開きます） - エ（誤り）: IPsec の認証は経路上・経路外の第三者による偽装攻撃を防ぐのに十分であり，同節で ESP は IP データ（トランスポートヘッダとペイロード）を認証するとされる。偽造 RST を防げないとするエは誤り
IPsec already provides authentication of an IP header and its data contents sufficient to defeat both on-path and off-path third-party spoofing attacks.
RFC 4953 · Section 5.2（新しいタブで開きます）
RFC 9293 の基本処理（ウィンドウ内なら有効）と RFC 5961 の厳格化（RCV.NXT と一致で切断，ウィンドウ内不一致はチャレンジ ACK）のどちらでも，4 つ組の一致とウィンドウ内のシーケンス番号は必要条件であり，正解ウの記述と矛盾しない。解説中の TCP-AO は RFC 4953 には出てこない（同文書はトランスポート層の認証として TCP/MD5 を挙げる）。