A3. Handling Loss of Synchronization due to Significant Packet Loss (大量のパケット損失による同期喪失の処理)

A3. Handling Loss of Synchronization due to Significant Packet Loss (大量のパケット損失による同期喪失の処理)

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

この種の拡張されたトラフィック損失は, ほとんどの場合, IPsec が A3.1 と A3.2 で説明されている種類の再同期メカニズムを呼び出す必要がある前に, 上位層で検出される可能性が高いことに注意してください。問題の SA のトラフィックの重要な部分が TCP である場合, 送信元は ACK を受信できず, 2^32 個のパケットが失われるずっと前に送信を停止します。また, UDP 上で動作するアプリケーションであっても, 双方向アプリケーションの場合, このような拡張された停止は何らかの形のタイムアウトをトリガーする可能性があります。ただし, UDP 上で動作する単方向アプリケーションは, この規模の損失の自動検出を引き起こすフィードバックを欠いている可能性があるため, このケースの回復方法を開発する動機があります。上記の観察は, セキュリティゲートウェイ間, ホスト間, またはホストとセキュリティゲートウェイ間の SA に適用されることに注意してください。

私たちが選択したソリューションは, 以下のために選択されました:

• 通常のトラフィック処理への影響を最小限に抑える

• 攻撃者がリソースを再同期プロセスに転用させることを許可することによって発生する可能性のある新しいサービス拒否攻撃の機会を作らない

• 回復メカニズムを受信者に制限する -- リプレイ防止は受信者のみのサービスであり, 送信者は通常, 受信者がこのオプションのサービスをサポートするためにシーケンス番号を使用しているかどうかを認識していないため, 回復メカニズムは受信者にローカルであることが望ましいです。これにより, 下位互換性も可能になります。