B3. Handling Loss of Synchronization (同期損失の処理)

単一のSA上で2^32以上の連続したパケットの検出されないパケット損失がある場合, 送信者と受信者は上位ビットの同期を失います。つまり, 付録B2.2の方程式は正しい値を生成できません。この問題が検出され対処されない限り, このSA上の後続のパケットは認証チェックに失敗し, 破棄されます。次の手順は, ESNオプションをサポートするIPsec (ESPまたはAH) 実装によって実装されるべきです (SHOULD)。

この種の拡張されたトラフィック損失は, 問題のSA上のトラフィックのかなりの部分がTCPである場合には発生する可能性が低いように思われます。送信元がACKを受信できず, 2^32パケットが失われるずっと前に送信を停止するためです。また, UDPの上で動作しているものであっても, 双方向アプリケーションの場合, このような拡張された停止は, 何らかの形式のタイムアウトをトリガーする可能性があります。ただし, UDP上で動作する単方向アプリケーションは, この規模の損失の自動検出を引き起こすフィードバックを欠いている可能性があるため, このケースの回復方法を開発する動機があります。

私たちが選択したソリューションは, 次のことを選択しました:

• 通常のトラフィック処理への影響を最小限に抑えます。
• 攻撃者がリソースを再同期プロセスに転用することを強制できることによって発生する可能性のある新しいサービス拒否攻撃の機会を作成しないようにします。
• アンチリプレイは受信者のためのサービスであり, 送信者は一般に受信者がこのオプションサービスをサポートするためにシーケンス番号を使用しているかどうかを認識していないため, 回復メカニズムを受信者に限定します。回復メカニズムは受信者にローカルであることが望ましいです。これにより, 下位互換性も可能になります。

B3.1. Triggering Re-synchronization (再同期のトリガー)

各SAについて, 受信者は認証に失敗した連続したパケットの数を記録します。このカウントは, バックグラウンドまたは別のプロセッサを使用して実行されるべき再同期プロセスをトリガーするために使用されます。SA上で有効なパケットを受信すると, カウンターがゼロにリセットされます。再同期プロセスをトリガーするために使用される値は, ローカルパラメータです。実装者がそうすることを選択する場合がありますが, 異なるSAに対して異なるトリガー値をサポートする要件はありません。

B3.2. Re-synchronization Process (再同期プロセス)

上記のトリガーポイントに達すると, 「不良」パケットが選択され, シーケンス番号の上半分 (Seqh) の連続して大きくなる値を使用して認証が再試行されます。これらの値は, 各再試行ごとに1ずつインクリメントすることによって生成されます。これが「過去」からのパケットまたは偽のパケットである場合に備えて, 再試行の数を制限する必要があります。制限値はローカルパラメータです。(Seqh値はAH (またはESP) ペイロードのエンドポイントの後に暗黙的に配置されるため, ペイロードのエンドポイントまでパケットに対して完全性アルゴリズムを実行し, 次にSeqhの値を変えることによって異なる候補ICVを計算することによって, この手順を最適化できる可能性があります。) この手順によるパケットの認証の成功は, 連続失敗カウントをリセットし, Tの値を受信したパケットの値に設定します。

このソリューションは受信者側のサポートのみを必要とするため, 下位互換性が可能になります。また, 再同期の試みはバックグラウンドで発生するか, 追加のプロセッサを利用するため, このソリューションはトラフィック処理に影響を与えず, サービス拒否攻撃がトラフィック処理からリソースを転用することはできません。