要約

  • RFC 5925はTCP-AOのMAC計算・検証前に、32ビットのTCPシーケンス番号へローカルなSND.SNEとRCV.SNEを組み合わせる。
  • SNEは新しい通信フィールドではなく、受信側が番号の遷移、接続履歴、周回境界付近の並べ替えから高位値を推定する。

長寿命のルーティングセッションが大量のデータを運び、TCPシーケンス番号が一周したとする。新しいセグメントは、遠い過去のセグメントと同じ32ビット値を持ち得る。TCPの受信窓は現在のストリーム内で解釈できるが、認証には別の区別が要る。低位32ビットの値が戻っただけで、異なる二つの時点を同じMAC入力にしてはならない。

RFC 5925は32ビットのシーケンス番号拡張（SNE）を加えた。接続開始時、送信用SND.SNEと受信用RCV.SNEはいずれもゼロである。送信側はSNEをIP疑似ヘッダーとTCP材料の前に置いてMACを計算する。受信側は対応する高位値を復元してからMACを検証する。両者は認証用に64ビット相当の番号空間を作る。

SNEは線上に送られない。TCP本体と食い違い得る第二の番号欄を設けないためである。送信側は内部の64ビット番号の上半分をSND.SNEにできる。一方、受信側が見るのは低い32ビットだけで、接続の経過からRCV.SNEを推定しなければならない。

RFCは一つの実装例を示す。番号が上半分から下半分へ移ると周回としてSNEを増やす。その後に大きな番号が届けば、境界を越えて遅れてきた旧周期のセグメントとして、増加前のSNEを用いる。フラグは反対側の中間境界まで二重加算を防ぐ。要求されるのは正しい結果であり、この内部表現だけが唯一の方法ではない。

同じ見える番号は、別の認証周期に属するようになる。SNEは時刻でも世界共通IDでもない。一接続の一方向だけに意味を持ち、その正しさは端点が保持する履歴に依存する。

出典