要約

  • 両端が TCP-AO の接続状態とトラフィック鍵を保持していれば、リセットを認証できる。
  • 再起動後に検証できないリセットは破棄され、古い接続は生存確認やアプリケーションの復旧処理で整理される。

再起動で状態の非対称が生じる

障害前は、両端が TCP 接続、初期シーケンス番号、その接続用に導出された鍵を知っている。この共有された文脈なら、リセットにも有効な認証を付けられる。

しかし、ルーターが再起動すると、TCP-AO を使う設定を覚えていても、個別の接続状態を失うことがある。RFC 5925 は、初期シーケンス番号の組が分からない場合、たとえば再起動後のリセットでは、認証なしで送るべきだとしている。TCP-AO を要求する相手はそのセグメントを検証できず、破棄する。

再起動した側には接続がない。生き残った側にはまだ古い接続がある。しかし、後者には信頼できる終了通知が届かない。

正しいリセットも受け入れられない理由

未認証リセットを例外として受け入れれば、攻撃者も同じ形式の偽造パケットで保護された接続を切断できる。受信側は、パケットだけから送信者の意図を区別できない。

そのため、通常の TCP よりクリーンアップが遅くなる。生き残った側は、接続が進展しないと判断するまで古い状態を保持する。RFC 5925 は TCP またはアプリケーションの keepalive を推奨し、接続状態の過剰な蓄積を検出して整理できる実装を求めている。

参考資料