跳到主要内容

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 的值设置为接收数据包的值。

此解决方案仅需要接收方的支持, 从而允许向后兼容。此外, 由于重新同步工作将在后台进行或使用额外的处理器, 因此此解决方案不会影响流量处理, 并且拒绝服务攻击无法将资源从流量处理中转移出去。

最后于 更新