摘要
本文档定义了IKEv2协议的扩展，解决了部署高可用集群时“IPsec集群问题陈述”中常见的主要问题 。解决的主要问题是同步IKEv2消息ID计数器和IPsec重放计数器。
2. 术语
本文通篇使用通用术语IKEv2/IPsec SA Counters。该术语指IKEv2消息ID计数器和IPsec重播计数器。根据IPsec标准，IKEv2消息ID计数器是必需的，并用于确保可靠的传输以及防止IKEv2中的消息重放。IPsec SA重播计数器是可选的，用于提供IPsec抗重放功能。
IPsec高可用群集架构图：
3. IPsec群集问题声明中解决的问题
“IPsec群集问题陈述”[6]列举了 通过IPsec群集引发的问题。下表列出了问题陈述中本文档解决的部分。
3.2 大量长期存在的状态
3.3 IKE计数器
3.4 出站SA计数器
3.5 入站SA计数器
3.6 缺少同步消息
3.7 不同成员同时使用IKE和IPsec SA
3.7.1 使用计数器模式的出站SA
3.8 IKE和IPsec的不同IP地址
3. 9 SPI的分配
使用协议扩展解决了主要问题，其定义从第5节开始，另外，这一节为后续小节的其他问题提供了实施建议。实施者应注意这些小节包括一些新的安全关键要求。
3.1. 大量的状态
第3.2节的问题陈述[6]提到，群集的很多状态需要同步，这些同步对集群是透明的。实际的数据量依赖于实现，即使对于相同的实现，数据量可能会有很大差异。一个 IPsec网关用于关联了其他十几个网关的域间VPN，并且每8小时更新一次SA的密钥，比用于支持10000个客户端的远程接入的类似网关需要更少的流量同步。这是因为计数器的同步与SA的数量成正比，且需要数据很少，而建立SA需要大量数据。此外，远程访问IKE和IPsec SA的建立往往发生在一天的特定时间，所以拥有10,000的客户示例网关可能会在上午9:00每秒建立30-50个IKE SA。这需要在短时间内承受非常繁重的流量同步工作。
如果需要大量流量，建议使用用于同步流量的专用高速网络接口。如果丢包率能控制在极小的范围内，建议使用无状态传输（如UDP），以最大限度地减少网络开销。
如果这些方法不够用，可以谨慎的考虑不同步某些SA的整个状态，而只对SA存在的标识进行同步。这样，与sticky方案相结合（如第3.7节所述问题陈述[6]），确保来自特定 peer的流量在实际故障转移之前未到达其他成员。当发生这种情况时，可以使用[8]中描述的方法快速强制对等体建立新的SA。
3.2 多个成员使用相同的SA
问题陈述[6]的第3.9节描述了一个问题，即两个集群成员的不同SAs分配了相同的安全参数索引（SPI）编号。这种行为会违反[5]的4.4.2.1节。这里有几个允许的实现方案可以避免这种冲突。比如分隔SPI空间，同步通道上的请求-响应和锁定机制。我们相信这些足够健壮可用，这样我们就不需要对RFC 4301 [5]的4.4.2.1节规则做额外处理了，这个问题可以留给实现去解决。群集成员不得生成具有相同SPI的多个入站SA。