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。

我们选择的解决方案被选择的目的是:

• 最小化对正常流量处理的影响

• 避免创造新的拒绝服务攻击的机会, 例如允许攻击者强制将资源转移到重新同步过程可能发生的情况

• 将恢复机制限制在接收方 -- 因为防重放仅是接收方的服务, 并且发送方通常不知道接收方是否正在使用序列号来支持此可选服务, 因此恢复机制在接收方本地是可取的。这也允许向后兼容性。