Internet Engineering Task Force (IETF) R. Singh, Ed.
Request for Comments: 6311 G. Kalyani
Category: Standards Track Cisco
ISSN: 2070-1721 Y. Nir
Check Point
Y. Sheffer
Porticor
D. Zhang
Huawei
July 2011
Internet Engineering Task Force (IETF) R. Singh, Ed.
Request for Comments: 6311 G. Kalyani
Category: Standards Track Cisco
ISSN: 2070-1721 Y. Nir
Check Point
Y. Sheffer
Porticor
D. Zhang
Huawei
July 2011
Protocol Support for High Availability of IKEv2/IPsec
对IKEv2/IPsec高可用性的协议支持
Abstract
摘要
The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.
IPsec协议套件广泛用于业务关键型网络流量。为了使IPsec部署具有高可用性、更可扩展性和抗故障性，通常将其实现为IPsec高可用性（HA）群集。然而，IPsec HA集群中存在许多问题，特别是在Internet密钥交换协议版本2（IKEv2）集群中。前面的文档“IPsec群集问题声明”列举了在IKEv2/IPsec HA群集环境中遇到的问题。本文档通过对协议进行尽可能少的更改来解决这些问题。
This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters.
本文档定义了对IKEv2协议的扩展，以解决通常部署的热备集群中“IPsec集群问题声明”的主要问题，并为其他问题提供了实施建议。解决的主要问题是IKEv2消息ID计数器和IPsec重播计数器的同步。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6311.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6311.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Issues Resolved from IPsec Cluster Problem Statement ............7
3.1. Large Amount of State ......................................8
3.2. Multiple Members Using the Same SA .........................9
3.3. Avoiding Collisions in SPI Number Allocation ...............9
3.4. Interaction with Counter Modes .............................9
4. The IKEv2/IPsec SA Counter Synchronization Problem .............10
5. SA Counter Synchronization Solution ............................11
5.1. Processing Rules for IKE Message ID Synchronization .......13
5.2. Processing Rules for IPsec Replay Counter
Synchronization ...........................................14
6. IKEv2/IPsec Synchronization Notification Payloads ..............14
6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification ..........15
6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification ......15
6.3. The IKEV2_MESSAGE_ID_SYNC Notification ....................16
6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification ................16
7. Implementation Details .........................................17
8. IKE SA and IPsec SA Message Sequencing .........................18
8.1. Handling of Pending IKE Messages ..........................18
8.2. Handling of Pending IPsec Messages ........................18
8.3. IKE SA Inconsistencies ....................................19
9. Step-by-Step Details ...........................................19
10. Interaction with Other Specifications .........................20
11. Security Considerations .......................................21
12. IANA Considerations ...........................................21
13. Acknowledgements ..............................................22
14. References ....................................................22
14.1. Normative References .....................................22
14.2. Informative References ...................................22
Appendix A. IKEv2 Message ID Sync Examples ........................24
A.1. Normal Failover -- Example 1 ...............................24
A.2. Normal Failover -- Example 2 ...............................24
A.3. Normal Failover -- Example 3 ...............................25
A.4. Simultaneous Failover ......................................25
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Issues Resolved from IPsec Cluster Problem Statement ............7
3.1. Large Amount of State ......................................8
3.2. Multiple Members Using the Same SA .........................9
3.3. Avoiding Collisions in SPI Number Allocation ...............9
3.4. Interaction with Counter Modes .............................9
4. The IKEv2/IPsec SA Counter Synchronization Problem .............10
5. SA Counter Synchronization Solution ............................11
5.1. Processing Rules for IKE Message ID Synchronization .......13
5.2. Processing Rules for IPsec Replay Counter
Synchronization ...........................................14
6. IKEv2/IPsec Synchronization Notification Payloads ..............14
6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification ..........15
6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification ......15
6.3. The IKEV2_MESSAGE_ID_SYNC Notification ....................16
6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification ................16
7. Implementation Details .........................................17
8. IKE SA and IPsec SA Message Sequencing .........................18
8.1. Handling of Pending IKE Messages ..........................18
8.2. Handling of Pending IPsec Messages ........................18
8.3. IKE SA Inconsistencies ....................................19
9. Step-by-Step Details ...........................................19
10. Interaction with Other Specifications .........................20
11. Security Considerations .......................................21
12. IANA Considerations ...........................................21
13. Acknowledgements ..............................................22
14. References ....................................................22
14.1. Normative References .....................................22
14.2. Informative References ...................................22
Appendix A. IKEv2 Message ID Sync Examples ........................24
A.1. Normal Failover -- Example 1 ...............................24
A.2. Normal Failover -- Example 2 ...............................24
A.3. Normal Failover -- Example 3 ...............................25
A.4. Simultaneous Failover ......................................25
The IPsec protocol suite, including the Internet Key Exchange Protocol version 2 (IKEv2), is a major building block of virtual private networks (VPNs). In order to make such VPNs highly available, more scalable, and failure-resistant, these VPNs are implemented as IKEv2/IPsec Highly Available (HA) clusters. However,
IPsec协议套件，包括Internet密钥交换协议版本2（IKEv2），是虚拟专用网络（VPN）的主要构建块。为了使这些VPN具有高可用性、更可扩展性和抗故障性，这些VPN被实现为IKEv2/IPsec高可用性（HA）群集。然而
there are many issues with the IKEv2/IPsec HA cluster. Sections 3 and 4 below expand on the issues around the IKEv2/IPsec HA cluster solution, issues which were first described in the problem statement [6].
IKEv2/IPsec HA集群存在许多问题。下面的第3节和第4节详细介绍了围绕IKEv2/IPsec HA群集解决方案的问题，这些问题首先在问题陈述[6]中描述。
In the case of a hot standby cluster implementation of IKEv2/ IPsec-based VPNs, the IKEv2/IPsec session is first established between the peer and the active member of the cluster. Later, the active member continuously syncs/updates the IKE/IPsec security association (SA) state to the standby member of the cluster. This primary SA state sync-up takes place upon each SA bring-up and/or rekey. Performing the SA state synchronization/update for every single IKE and IPsec message is very costly, so normally it is done periodically. As a result, when the failover event happens, this is first detected by the standby member and, possibly after a considerable amount of time, it becomes the active member. During this failover process, the peer is unaware of the failover event, and keeps sending IKE requests and IPsec packets to the cluster, as in fact it is allowed to do because of the IKEv2 windowing feature. After the newly active member starts, it detects the mismatch in IKE Message ID values and IPsec replay counters and needs to resolve this situation. Please see Section 4 for more details of the problem.
在基于IKEv2/IPsec的VPN的热备用群集实现的情况下，首先在对等方和群集的活动成员之间建立IKEv2/IPsec会话。稍后，活动成员将持续同步/更新IKE/IPsec安全关联（SA）状态到集群的备用成员。此主SA状态同步在每次SA启动和/或重设密钥时进行。为每个IKE和IPsec消息执行SA状态同步/更新的成本非常高，因此通常会定期执行。因此，当故障转移事件发生时，备用成员会首先检测到该事件，并且可能在相当长的时间后，它会成为活动成员。在此故障转移过程中，对等方不知道故障转移事件，并不断向集群发送IKE请求和IPsec数据包，因为IKEv2窗口功能允许这样做。新活动成员启动后，它会检测到IKE消息ID值和IPsec重播计数器中的不匹配，需要解决此情况。有关该问题的更多详细信息，请参见第4节。
This document defines an extension to the IKEv2 protocol to solve the main issues of IKE Message ID synchronization and IPsec SA replay counter synchronization, and gives implementation advice to address other issues. Following is a summary of the solutions provided in this document:
本文档定义了对IKEv2协议的扩展，以解决IKE消息ID同步和IPsec SA replay计数器同步的主要问题，并给出了解决其他问题的实施建议。以下是本文件中提供的解决方案摘要：
o IKEv2 Message ID synchronization: This is done by syncing up the expected send and receive Message ID values with the peer, and updating the values at the newly active cluster member.
o IKEv2消息ID同步：这是通过将预期的发送和接收消息ID值与对等方同步，并更新新活动集群成员处的值来完成的。
o IPsec replay counter synchronization: This is done by incrementing the cluster's outgoing SA replay counter values by a "large" number; in addition, the newly active member requests the peer to increment the replay counter values it is using for the peer's outgoing traffic.
o IPsec replay计数器同步：这是通过将集群的传出SA replay计数器值增加一个“大”数来完成的；此外，新活动成员请求对等方增加其用于对等方传出流量的重播计数器值。
Although this document describes the IKEv2 Message ID and IPsec replay counter synchronization in the context of an IPsec HA cluster, the solution provided is generic and can be used in other scenarios where IKEv2 Message ID or IPsec SA replay counter synchronization may be required.
尽管本文档描述了IPsec HA群集上下文中的IKEv2消息ID和IPsec replay计数器同步，但提供的解决方案是通用的，可用于可能需要IKEv2消息ID或IPsec SA replay计数器同步的其他场景。
Implementations differ on the need to synchronize the IKEv2 Message ID and/or IPsec replay counters. Both of these problems are handled separately, using a separate notification for each capability. This provides the flexibility of implementing either or both of these solutions.
不同的实现需要同步IKEv2消息ID和/或IPsec重播计数器。这两个问题都是单独处理的，对每个功能使用单独的通知。这提供了实现这两种解决方案之一或两者的灵活性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
"SA Counter Synchronization" is the informational exchange defined in this document to synchronize the IKEv2/IPsec SA counter information between one member of the cluster and the peer.
“SA计数器同步”是本文档中定义的信息交换，用于在集群的一个成员和对等方之间同步IKEv2/IPsec SA计数器信息。
Some of the terms listed below are reused from [6] with further clarification in the context of the current document.
下面列出的一些术语是从[6]中重新使用的，并在当前文件中作了进一步澄清。
o "Hot Standby Cluster", or "HS Cluster", is a cluster where only one of the members is active at any one time. This member is also referred to as the "active" member, whereas the other(s) are referred to as "standby" members. The Virtual Router Redundancy Protocol (VRRP) [7] is one method of building such a cluster. The goal of the hot standby cluster is to create the illusion of a single virtual gateway to the peer(s).
o “热备用群集”或“HS群集”是一个在任何时间只有一个成员处于活动状态的群集。此成员也称为“活动”成员，而其他成员称为“备用”成员。虚拟路由器冗余协议（VRRP）[7]是构建此类集群的一种方法。热备用集群的目标是创建一个到对等方的单一虚拟网关的幻觉。
o "Active Member" is the primary member in the hot standby cluster. It is responsible for forwarding packets on behalf of the virtual gateway.
o “活动成员”是热备用群集中的主要成员。它负责代表虚拟网关转发数据包。
o "Standby Member" is the primary backup member. This member takes control, i.e., becomes the active member, after the failover event.
o “备用成员”是主备份成员。此成员在故障转移事件后获得控制权，即成为活动成员。
o "Peer" is an IKEv2/IPsec endpoint that maintains an IPsec connection with the hot standby cluster. The peer identifies the cluster by the cluster's (single) IP address. If a failover event occurs, the standby member of the cluster becomes active, and the peer normally doesn't notice that failover has taken place. Although we treat the peer as a single entity, it may also be a cluster.
o “对等”是一个IKEv2/IPsec端点，它与热备用群集保持IPsec连接。对等方通过集群的（单个）IP地址标识集群。如果发生故障转移事件，集群的备用成员将变为活动成员，而对等方通常不会注意到发生了故障转移。尽管我们将对等体视为单个实体，但它也可能是一个集群。
o "Multiple failover" is the situation where, in a cluster with three or more members, multiple failover events happen in rapid succession, e.g., from M1 to M2, and then to M3. It is our goal that the implementation should be able to handle this situation, i.e., to handle the new failover event even if it is still processing the old failover.
o “多故障转移”是指在具有三个或更多成员的集群中，多个故障转移事件快速连续发生，例如从M1到M2，然后到M3。我们的目标是实现应该能够处理这种情况，即即使仍在处理旧的故障转移，也要处理新的故障转移事件。
o "Simultaneous failover" is the situation where two clusters have an IPsec connection between them, and failover happens at both ends at the same time. It is our goal that implementations should be able to handle simultaneous failover.
o “同时故障转移”是指两个群集之间有IPsec连接，并且故障转移同时发生在两端的情况。我们的目标是实现应该能够处理同步故障切换。
o "IPsec replay counter" is the Encapsulating Security Payload (ESP) Sequence Number or Extended Sequence Number (Section 2.2 of [2]), or the respective field in the Authentication Header (AH) protocol (Section 2.5 of [3]).
o “IPsec重播计数器”是封装安全有效负载（ESP）序列号或扩展序列号（第2.2节，共[2]），或认证头（AH）协议（第2.5节，共[3]）中的相应字段。
The generic term "IKEv2/IPsec SA Counters" is used throughout this document. This term refers to both IKEv2 Message ID counters and IPsec replay counters. According to the IPsec standards, the IKEv2 Message ID counter is mandatory, and used to ensure reliable delivery as well as to protect against message replay in IKEv2; the IPsec SA replay counters are optional, and are used to provide the IPsec anti-replay feature.
本文档通篇使用通用术语“IKEv2/IPsec SA计数器”。此术语同时指IKEv2消息ID计数器和IPsec重播计数器。根据IPsec标准，IKEv2消息ID计数器是强制性的，用于确保可靠传递以及防止IKEv2中的消息重播；IPsec SA重播计数器是可选的，用于提供IPsec反重播功能。
Some of these terms are used in the following architectural diagram.
以下架构图中使用了其中一些术语。
+---------------+
| |
| Hot Standby |
| Cluster |
| |
| +---------+ |
| | | |
| | Active | |
| | | |
| | Member | |
| | | |
| +---------+ |
| ^ |
+---------+ | Synch | |
| | | Channel | |
| IPsec | IKE/IPsec Traffic | | |
| | <=============================> | | |
| Peer | | | |
| | | | |
+---------+ | | |
| v |
| +---------+ |
| | | |
| | Standby | |
| | | |
| | Member | |
| | | |
| +---------+ |
+---------------+
+---------------+
| |
| Hot Standby |
| Cluster |
| |
| +---------+ |
| | | |
| | Active | |
| | | |
| | Member | |
| | | |
| +---------+ |
| ^ |
+---------+ | Synch | |
| | | Channel | |
| IPsec | IKE/IPsec Traffic | | |
| | <=============================> | | |
| Peer | | | |
| | | | |
+---------+ | | |
| v |
| +---------+ |
| | | |
| | Standby | |
| | | |
| | Member | |
| | | |
| +---------+ |
+---------------+
An IPsec Hot Standby Cluster
IPsec热备用集群
"IPsec Cluster Problem Statement" [6] enumerates the problems raised by IPsec clusters. The following table lists the problem statement's sections that are resolved by this document.
“IPsec群集问题声明”[6]列举了IPsec群集引发的问题。下表列出了本文档解决的问题说明部分。
o 3.2. A Lot of Long-Lived State
o 3.3. IKE Counters
o 3.4. Outbound SA Counters
o 3.5. Inbound SA Counters
o 3.6. Missing Synch Messages
o 3.2. A Lot of Long-Lived State
o 3.3. IKE Counters
o 3.4. Outbound SA Counters
o 3.5. Inbound SA Counters
o 3.6. Missing Synch Messages
o 3.7. Simultaneous Use of IKE and IPsec SAs by Different Members * 3.7.1. Outbound SAs Using Counter Modes o 3.8. Different IP Addresses for IKE and IPsec o 3.9. Allocation of SPIs
o 3.7. 不同成员同时使用IKE和IPsec SAs*3.7.1。使用计数器模式o 3.8的出站SAs。IKE和IPsec o 3.9的不同IP地址。SPI的分配
The main problem areas are solved using the protocol extension defined below, starting with Section 5; additionally, this section provides implementation advice for other issues in the following subsections. Implementers should note that these subsections include a number of new security-critical requirements.
从第5节开始，使用下面定义的协议扩展解决主要问题区域；此外，本节还针对以下小节中的其他问题提供了实施建议。实现者应该注意，这些小节包括许多新的安全关键需求。
Section 3.2 of the problem statement [6] mentions that a lot of state needs to be synchronized for a cluster to be transparent. The actual volume of that data is very much implementation-dependent, and even for the same implementation, the amounts of data may vary wildly. An IPsec gateway used for inter-domain VPN with a dozen other gateways, and having SAs that are rekeyed every 8 hours, will need a lot less synchronization traffic than a similar gateway used for remote access, and supporting 10,000 clients. This is because counter synchronization is proportional to the number of SAs and requires little data, and the setting up of an SA requires a lot of data. Additionally, remote access IKE and IPsec SA setup tend to happen at a particular time of day, so the example gateway with the 10,000 clients may see 30-50 IKE SA setups per second at 9:00 AM. This would require very heavy synchronization traffic over that short period of time.
问题陈述[6]的第3.2节提到，要使集群透明，需要同步很多状态。该数据的实际量在很大程度上取决于实现，即使对于相同的实现，数据量也可能相差很大。用于域间VPN的IPsec网关与十几个其他网关一起使用，并且具有每8小时重新设置密钥的SAs，与用于远程访问的类似网关相比，需要的同步通信量要少得多，并且支持10000个客户端。这是因为计数器同步与SA的数量成正比，只需要很少的数据，而SA的设置需要大量的数据。此外，远程访问IKE和IPsec SA设置往往发生在一天中的特定时间，因此具有10000个客户端的示例网关在上午9:00时每秒可能会看到30-50个IKE SA设置。这将需要在短时间内进行非常大的同步通信量。
If a large volume of traffic is necessary, it may be advisable to use a dedicated high-speed network interface for synch traffic. When packet loss can be made extremely low, it may be advisable to use a stateless transport such as UDP, to minimize network overhead.
如果需要大量流量，建议使用专用高速网络接口来同步流量。当数据包丢失率极低时，建议使用无状态传输，如UDP，以最小化网络开销。
If these methods are insufficient, it may be prudent that for some SAs the entire state is not synchronized. Instead, only an indication of the SA's existence is synchronized. This, in combination with a sticky solution (as described in Section 3.7 of the problem statement [6]) ensures that the traffic from a particular peer does not reach a different member before an actual failover happens. When that happens, the method described in [8] can be used to quickly force the peer to set up a new SA.
如果这些方法不充分，则谨慎的做法是，对于某些SA，整个状态不同步。相反，只同步SA存在的指示。这与粘性解决方案（如问题陈述[6]第3.7节所述）相结合，可确保在实际故障切换发生之前，来自特定对等方的流量不会到达不同的成员。发生这种情况时，可以使用[8]中描述的方法快速强制对等方设置新SA。
In a load-sharing cluster of the "duplicate" variety (see Section 3.7 of the problem statement [6]), multiple members may need to send traffic with the same selectors. To actually use the same SA, the cluster would have to synchronize the replay counter after every packet, and that would impose unreasonable requirements on the synch connection.
在“重复”类型的负载共享集群中（参见问题陈述[6]的第3.7节），多个成员可能需要使用相同的选择器发送流量。要实际使用相同的SA，集群必须在每个数据包之后同步重播计数器，这将对同步连接施加不合理的要求。
A far better solution would be to not synchronize the outbound SA, and create multiple outbound SAs, one for each member. The problem with this option is that the peer might view these multiple parallel SAs as redundant, and tear down all but one of them.
更好的解决方案是不同步出站SA，创建多个出站SA，每个成员一个。此选项的问题在于，对等方可能会将这些多个并行SA视为冗余，并拆除除一个以外的所有SA。
Section 2.8 of [4] specifically allows multiple parallel SAs, but the reason given for this is to have multiple SAs with different Quality of Service (QoS) attributes. So while this is not a new requirement of IKEv2 implementations working with QoS, we re-iterate here that IPsec peers MUST accept the long-term existence of multiple parallel SAs, even when QoS mechanisms are not in use.
[4]第2.8节特别允许多个并行SA，但给出的理由是多个SA具有不同的服务质量（QoS）属性。因此，虽然这不是使用QoS的IKEv2实现的新要求，但我们在此重申，IPsec对等方必须接受多个并行SA的长期存在，即使QoS机制未使用。
Section 3.9 of the problem statement [6] describes the problem of two cluster members allocating the same Security Parameter Index (SPI) number for two different SAs. This behavior would violate Section 4.4.2.1 of [5]. There are several schemes to allow implementations to avoid such collisions, such as partitioning the SPI space, a request-response over the synch channel, and locking mechanisms. We believe that these are sufficiently robust and available so that we don't need to make an exception to the rules in Section 4.4.2.1 of RFC 4301 [5], and we can leave this problem for the implementations to solve. Cluster members must not generate multiple inbound SAs with the same SPI.
问题陈述[6]的第3.9节描述了两个集群成员为两个不同的SA分配相同的安全参数索引（SPI）号的问题。这种行为将违反[5]第4.4.2.1节。有几种方案允许实现避免此类冲突，例如划分SPI空间、通过同步通道的请求响应和锁定机制。我们认为，这些功能足够强大且可用，因此我们不需要对RFC 4301[5]第4.4.2.1节中的规则进行例外，我们可以将此问题留给实现来解决。群集成员不得生成具有相同SPI的多个入站SA。
For SAs involving counter mode ciphers such as Counter Mode (CTR) [9] or Galois/Counter Mode (GCM) [10], there is yet another complication. The initial vector for such modes MUST NOT be repeated, and senders may use methods such as counters or linear feedback shift registers (LFSRs) to ensure this property. For an SA shared between multiple active members (load-sharing cases), implementations MUST ensure that no initial vector is ever repeated. Similar concerns apply to an SA failing over from one member to another. See [11] for a discussion of this problem in another context.
对于涉及计数器模式密码的SA，如计数器模式（CTR）[9]或伽罗瓦/计数器模式（GCM）[10]，还有另一个复杂性。此类模式的初始向量不得重复，发送方可使用计数器或线性反馈移位寄存器（LFSR）等方法来确保此属性。对于在多个活动成员之间共享的SA（负载共享情况），实现必须确保不会重复初始向量。类似的担忧也适用于SA从一个成员国故障转移到另一个成员国。参见[11]以了解在另一个上下文中对该问题的讨论。
Just as in the SPI collision problem, there are ways to avoid a collision of initial vectors, and this is left up to implementations. In the context of load sharing, parallel SAs are a simple solution to this problem as well.
正如在SPI冲突问题中一样，有一些方法可以避免初始向量的冲突，这取决于实现。在负载共享的环境中，并行SA也是这个问题的简单解决方案。
The IKEv2 protocol [4] states that "An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests".
IKEv2协议[4]规定“IKE端点不得超过对等方规定的发送IKE请求的窗口大小”。
All IKEv2 messages are required to follow a request-response paradigm. The initiator of an IKEv2 request MUST retransmit the request, until it has received a response from the peer. IKEv2 introduces a windowing mechanism that allows multiple requests to be outstanding at a given point of time, but mandates that the sender's window should not move until the oldest message it has sent is acknowledged. Loss of even a single message leads to repeated retransmissions followed by an IKEv2 SA teardown if the retransmissions remain unacknowledged.
所有IKEv2消息都需要遵循请求-响应范例。IKEv2请求的发起方必须重新传输该请求，直到收到来自对等方的响应为止。IKEv2引入了一种窗口机制，允许多个请求在给定时间点处于未完成状态，但要求发送方的窗口在其发送的最旧消息得到确认之前不应移动。即使丢失一条消息，也会导致重复的重新传输，如果重新传输未被确认，则会导致IKEv2 SA断开。
An IPsec hot standby cluster is required to ensure that in the case of failover, the standby member becomes active immediately. The standby member is expected to have the exact value of the Message ID counter as the active member had before failover. Even assuming the best effort to update the Message ID values from active to standby member, the values at the standby member can still be stale due to the following reasons:
需要IPsec热备用群集以确保在故障转移的情况下，备用成员立即变为活动成员。备用成员应具有与活动成员在故障转移之前相同的消息ID计数器的精确值。即使尽最大努力将消息ID值从活动成员更新到备用成员，由于以下原因，备用成员处的值仍可能过时：
o The standby member is unaware of the last message that was received and acknowledged by the previously active member, as the failover event could have happened before the standby member could be updated.
o 备用成员不知道先前活动成员接收和确认的最后一条消息，因为故障转移事件可能发生在备用成员更新之前。
o The standby member does not have information about on-going unacknowledged requests sent by the previously active member. As a result, after the failover event, the newly active member cannot retransmit those requests.
o 备用成员没有关于先前活动成员发送的正在进行的未确认请求的信息。因此，在故障转移事件之后，新活动成员无法重新传输这些请求。
When a standby member takes over as the active member, it can only initialize the Message ID values from the previously updated values. This would make it reject requests from the peer when these values are stale. Conversely, the standby member may end up reusing a stale Message ID value, which would cause the peer to drop the request. Eventually, there is a high probability of the IKEv2 and corresponding IPsec SAs getting torn down simply because of a transitory Message ID mismatch and retransmission of requests, negating the benefits of the high-availability cluster despite the periodic update between the cluster members.
当备用成员作为活动成员接管时，它只能根据以前更新的值初始化消息ID值。这将使它在这些值过时时拒绝来自对等方的请求。相反，备用成员可能最终重用过时的消息ID值，这将导致对等方丢弃请求。最终，IKEv2和相应的IPsec SA很有可能仅仅因为暂时的消息ID不匹配和请求的重新传输而被破坏，从而否定了高可用性集群的好处，尽管集群成员之间定期更新。
A similar issue is also observed with IPsec anti-replay counters if anti-replay protection is enabled, which is commonly the case. Regardless of how well the ESP and AH SA counters are synchronized from the active to the standby member, there is a chance that the standby member would end up with stale counter values. The standby member would then use those stale counter values when sending IPsec packets. The peer would drop such packets, since when the anti-replay protection feature is enabled, duplicate use of counters is not allowed. Note that IPsec allows the sender to skip some counter values and continue sending with higher counter values.
如果启用了反重放保护（通常情况下），IPsec反重放计数器也会出现类似问题。无论ESP和AH SA计数器从活动成员同步到备用成员的情况如何，备用成员都有可能最终使用过时的计数器值。然后，备用成员在发送IPsec数据包时将使用这些过时的计数器值。对等方将丢弃此类数据包，因为当启用防重播保护功能时，不允许重复使用计数器。请注意，IPsec允许发送方跳过一些计数器值，并使用更高的计数器值继续发送。
We conclude that a mechanism is required to ensure that the standby member has correct Message ID and IPsec counter values when it becomes active, so that sessions are not torn down as a result of mismatched counters.
我们得出结论，需要一种机制来确保备用成员在变为活动状态时具有正确的消息ID和IPsec计数器值，以便会话不会因为计数器不匹配而中断。
This document defines two separate approaches to resolving the issues of mismatched IKE Message ID values and IPsec counter values.
本文档定义了两种不同的方法来解决IKE消息ID值和IPsec计数器值不匹配的问题。
o In the case of IKE Message ID values, the newly active cluster member and the peer negotiate a pair of new values so that future IKE messages will not be dropped.
o 在IKE消息ID值的情况下，新活动的集群成员和对等方协商一对新值，以便将来不会丢弃IKE消息。
o For IPsec counter values, the newly active member and the peer both increment their respective counter values, "skipping forward" by a large number, to ensure that no IPsec counters are ever reused.
o 对于IPsec计数器值，新活动成员和对等成员都会将其各自的计数器值增加一个大数字，“向前跳过”，以确保不会重用任何IPsec计数器。
Although conceptually separate, the two synchronization processes would typically take place simultaneously.
虽然在概念上是分开的，但这两个同步过程通常会同时发生。
First, the peer and the active member of the cluster negotiate their ability to support IKEv2 Message ID synchronization and/or IPsec replay counter synchronization. This is done by exchanging one or both of the IKEV2_MESSAGE_ID_SYNC_SUPPORTED and IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notifications during the IKE_AUTH exchange. When negotiating these capabilities, the responder MUST NOT assert support of a capability unless such support was asserted by the initiator. Only a capability whose support was asserted by both parties can be used during the lifetime of the SA. The peer's capabilities with regard to this extension are part of the IKEv2 SA state, and thus MUST be shared between the cluster members.
首先，对等方和集群的活动成员协商其支持IKEv2消息ID同步和/或IPsec重播计数器同步的能力。这是通过在IKE_身份验证交换期间交换IKEV2_消息_ID_SYNC_SUPPORTED和IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED通知中的一个或两个来完成的。协商这些能力时，响应者不得声明支持某项能力，除非发起人声明支持该项能力。在SA的生命周期内，只能使用双方都声明支持的功能。对等方关于此扩展的能力是IKEv2 SA状态的一部分，因此必须在集群成员之间共享。
This per-IKE SA information is shared with the other cluster members.
此每个IKE SA信息与其他集群成员共享。
Peer Active Member
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
SAi2, TSi, TSr} ---------->
Peer Active Member
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
SAi2, TSi, TSr} ---------->
<-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
SAr2, TSi, TSr}
<-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
SAr2, TSi, TSr}
After a failover event, the standby member MAY use the IKE Message ID and/or IPsec replay counter synchronization capability when it becomes the active member, and provided support for the capabilities used has been negotiated. Following that, the peer MUST respond to any synchronization message it receives from the newly active cluster member, subject to the rules noted below.
故障转移事件发生后，备用成员在成为活动成员时可以使用IKE消息ID和/或IPsec replay计数器同步功能，并且已协商对所用功能的支持。然后，对等方必须根据以下规则响应它从新活动的集群成员接收到的任何同步消息。
After the failover event, when the standby member becomes active, it has to synchronize its SA counters with the peer. There are now four possible cases:
故障转移事件发生后，当备用成员变为活动状态时，它必须将其SA计数器与对等方同步。现在有四种可能的情况：
1. The cluster member wishes to only perform IKE Message ID value synchronization. In this case, it initiates an Informational exchange, with Message ID zero and the sole notification IKEV2_MESSAGE_ID_SYNC.
1. 集群成员只希望执行IKE消息ID值同步。在这种情况下，它启动信息交换，消息ID为零，唯一的通知是IKEV2_Message_ID_SYNC。
2. If the newly active member wishes to perform only IPsec replay counter synchronization, it generates a regular IKEv2 Informational exchange using the current Message ID values, and containing the IPSEC_REPLAY_COUNTER_SYNC notification.
2. 如果新激活的成员希望仅执行IPsec replay计数器同步，则它将使用当前消息ID值生成定期的IKEv2信息交换，并包含IPsec\u replay\u计数器\u SYNC通知。
3. If synchronization of both counters is needed, the cluster member generates a zero-Message ID message as in case #1, and includes both notifications in this message.
3. 如果需要同步两个计数器，则集群成员将生成一条零消息ID消息，如案例#1所示，并在该消息中包含这两个通知。
4. Lastly, the peer may not support this extension. This is known to the newly active member (because the cluster members must share this information, as noted earlier). This case is the existing IKEv2 behavior, and the IKE and IPsec SAs may or may not survive the failover, depending on the exact state on the peer and the cluster member.
4. 最后，对等方可能不支持此扩展。这是新活动成员所知道的（因为集群成员必须共享此信息，如前所述）。这种情况是现有的IKEv2行为，IKE和IPsec SA可能在故障切换中存活，也可能无法存活，这取决于对等方和集群成员的确切状态。
This figure contains the IKE message exchange used for SA counter synchronization. The following subsections describe the details of the sender and receiver processing of each message.
此图包含用于SA计数器同步的IKE消息交换。以下小节描述了每条消息的发送方和接收方处理的详细信息。
Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {N(IKEV2_MESSAGE_ID_SYNC),
[N(IPSEC_REPLAY_COUNTER_SYNC)]} -------->
Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {N(IKEV2_MESSAGE_ID_SYNC),
[N(IPSEC_REPLAY_COUNTER_SYNC)]} -------->
<--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC)}
<--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC)}
Alternatively, if only IPsec replay counter synchronization is desired, a normal Informational exchange is used, where the Message ID is non-zero:
或者，如果只需要IPsec replay计数器同步，则使用正常的信息交换，其中消息ID为非零：
Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} -------->
Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} -------->
<--------- HDR
<--------- HDR
The newly active member sends a request containing two counter values, one for the member (itself) and another for the peer, as well as a random nonce. We denote the values M1 and P1. The peer responds with a message containing two counter values, M2 and P2 (note that the values appear in the opposite order in the notification's payload). The goal of the rules below is to prevent an attacker from replaying a synchronization message and thereby invalidating IKE messages that are currently in process.
新激活的成员发送一个包含两个计数器值的请求，一个用于成员（自身），另一个用于对等方，以及一个随机的nonce。我们表示值M1和P1。对等方响应一条消息，其中包含两个计数器值M2和P2（请注意，这些值在通知的有效负载中以相反的顺序出现）。以下规则的目标是防止攻击者重播同步消息，从而使当前正在处理的IKE消息无效。
o M1 is the next sender's Message ID to be used by the member. M1 MUST be chosen so that it is larger than any value known to have been used. It is RECOMMENDED to increment the known value at least by the size of the IKE sender window.
o M1是成员要使用的下一个发件人的邮件ID。必须选择M1，使其大于已知已使用的任何值。建议将已知值至少增加IKE发送器窗口的大小。
o P1 SHOULD be 1 more than the last Message ID value received from the peer, but may be any higher value.
o P1应该比从对等方接收的最后一个消息ID值多1，但可以是任何更高的值。
o The member SHOULD communicate the sent values to the other cluster members, so that if a second failover event takes place, the synchronization message is not replayed. Such a replay would result in the eventual deletion of the IKE SA (see below).
o 该成员应将发送的值传递给其他集群成员，以便在发生第二个故障切换事件时不会重播同步消息。这样的重播将导致最终删除IKE SA（见下文）。
o The peer MUST silently drop any received synchronization message if M1 is lower than or equal to the highest value it has seen from the cluster. This includes any previous received synchronization messages.
o 如果M1小于或等于从集群中看到的最高值，则对等方必须静默删除任何接收到的同步消息。这包括以前收到的任何同步消息。
o M2 MUST be at least the higher of the received M1, and one more than the highest sender value received from the cluster. This includes any previous received synchronization messages.
o M2必须至少是接收到的M1中较高的一个，并且比从集群接收到的最高发送方值多出一个。这包括以前收到的任何同步消息。
o P2 MUST be the higher of the received P1 value, and one more than the highest sender value used by the peer.
o P2必须是接收到的P1值中较高的一个，并且比对等方使用的最高发送方值多出一个。
o The request contains a Nonce field. This field MUST be returned in the response, unchanged. A response MUST be silently dropped if the received nonce does not match the one that was sent.
o 请求包含一个Nonce字段。此字段必须在响应中返回，保持不变。如果收到的nonce与发送的nonce不匹配，则必须静默删除响应。
o Both the request and the response MUST NOT contain any additional payloads, other than an optional IPSEC_REPLAY_COUNTER_SYNC notification in the request.
o 除了请求中可选的IPSEC\u REPLAY\u COUNTER\u SYNC通知之外，请求和响应都不得包含任何其他有效负载。
o The request and the response MUST both be sent with a Message ID value of zero.
o 请求和响应都必须以消息ID值为零的方式发送。
Upon failover, the newly active member MUST increment its own replay counter (the counter used for outgoing traffic), so as to prevent the case of its traffic being dropped by the peer as replay. We note that IPsec allows the replay counter to skip forward by any amount. The estimate is based on the outgoing IPsec bandwidth and the frequency of synchronization between cluster members. In those implementations where it is difficult to estimate this value, the counter can be incremented by a very large number, e.g., 2**30. In the latter case, a rekey SHOULD follow shortly afterwards, to ensure that the counter never wraps around.
故障转移时，新活动成员必须增加其自己的replay计数器（用于传出流量的计数器），以防止对等方丢弃其流量作为replay。我们注意到IPsec允许重播计数器向前跳任意数量。该估计基于传出IPsec带宽和集群成员之间的同步频率。在难以估计该值的那些实现中，计数器可以增加非常大的数字，例如2**30。在后一种情况下，随后应立即重新输入，以确保计数器不会缠绕。
Next, the cluster member estimates the number of incoming messages it might have missed, using similar logic. The member sends out an IPSEC_REPLAY_COUNTER_SYNC notification, either stand-alone or together with an IKEV2_MESSAGE_ID_SYNC notification.
接下来，集群成员使用类似的逻辑估计可能错过的传入消息的数量。成员发送IPSEC_REPLAY_COUNTER_SYNC通知，单独发送或与IKEV2_MESSAGE_ID_SYNC通知一起发送。
If the IPSEC_REPLAY_COUNTER_SYNC is included in the same message as IKEV2_MESSAGE_ID_SYNC, the peer MUST process the Message ID notification first (which might cause the entire message to be dropped as a replay). Then, it MUST increment the replay counters for all Child SAs associated with the current IKE SA by the amount requested by the cluster member.
如果IPSEC_REPLAY_计数器_SYNC包含在与IKEV2_message_ID_SYNC相同的消息中，则对等方必须首先处理消息ID通知（这可能导致整个消息作为REPLAY被丢弃）。然后，它必须将与当前IKE SA关联的所有子SA的重播计数器增加集群成员请求的数量。
This section lists the new notification payload types defined by this extension.
本节列出了此扩展定义的新通知有效负载类型。
All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first", or "network byte order").
所有表示整数的多个八位字节字段均按大端顺序排列（也称为“最高有效字节优先”或“网络字节顺序”）。
This notification payload is included in the IKE_AUTH request/ response to indicate support of the IKEv2 Message ID synchronization mechanism described in this document.
此通知有效负载包含在IKE_AUTH请求/响应中，以表示支持本文档中描述的IKEv2消息ID同步机制。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3 of [4]. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate IKEV2_MESSAGE_ID_SYNC_SUPPORTED (16420). There is no data associated with this notification.
“下一个有效负载”、“有效负载长度”、“协议ID”、“SPI大小”和“通知消息类型”字段与[4]第3节中描述的相同。“SPI大小”字段必须设置为0，以指示此消息中不存在SPI。“协议ID”必须设置为0，因为通知不是特定于特定安全关联的。“有效负载长度”字段设置为整个有效负载（包括通用有效负载标头）的长度（以八位字节为单位）。“通知消息类型”字段设置为指示支持的IKEV2_消息ID_同步（16420）。没有与此通知关联的数据。
This notification payload is included in the IKE_AUTH request/ response to indicate support for the IPsec SA replay counter synchronization mechanism described in this document.
此通知有效负载包含在IKE_AUTH请求/响应中，以表示支持本文档中描述的IPsec SA replay计数器同步机制。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3 of [4] . The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security
“下一个有效负载”、“有效负载长度”、“协议ID”、“SPI大小”和“通知消息类型”字段与[4]第3节中描述的相同。“SPI大小”字段必须设置为0，以指示此消息中不存在SPI。“协议ID”必须设置为0，因为通知不是特定于特定安全性的
association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED (16421). There is no data associated with this notification.
协会“有效负载长度”字段设置为整个有效负载（包括通用有效负载标头）的长度（以八位字节为单位）。“通知消息类型”字段设置为指示支持IPSEC\u REPLAY\u计数器\u SYNC\u（16421）。没有与此通知关联的数据。
This notification payload type (16422) is defined to synchronize the IKEv2 Message ID values between the newly active (formerly standby) cluster member and the peer.
此通知有效负载类型（16422）被定义为在新活动（以前是备用）集群成员和对等方之间同步IKEv2消息ID值。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_SEND_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_RECV_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_SEND_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_RECV_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It contains the following data.
它包含以下数据。
o Nonce Data (4 octets): The random nonce data. The data should be identical in the synchronization request and response.
o Nonce数据（4个八位字节）：随机的Nonce数据。同步请求和响应中的数据应该相同。
o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets): This field is used by the sender of this notification payload to indicate the Message ID it will use in the next request that it will send to the other protocol peer.
o 预期的_SEND_REQ_MESSAGE_ID（4个八位字节）：此通知有效负载的发送方使用此字段指示其将在下一个发送给其他协议对等方的请求中使用的消息ID。
o EXPECTED_RECV_REQ_MESSAGE_ID (4 octets): This field is used by the sender of this notification payload to indicate the Message ID it is expecting in the next request to be received from the other protocol peer.
o EXPECTED_RECV_REQ_MESSAGE_ID（4个八位字节）：此通知有效负载的发送方使用此字段指示其在下一个请求中预期从其他协议对等方接收的消息ID。
This notification payload type (16423) is defined to synchronize the IPsec SA replay counters between the newly active (formerly standby) cluster member and the peer. Since there may be numerous IPsec SAs
此通知有效负载类型（16423）定义为在新活动（以前为备用）群集成员和对等方之间同步IPsec SA replay计数器。因为可能有许多IPsec SA
established under a single IKE SA, we do not directly synchronize the value of each one. Instead, a delta value is sent, and all replay counters for Child SAs of this IKE SA are incremented by the same value. Note that this solution requires that either all Child SAs use Extended Sequence Numbers (ESNs) or else that no Child SA uses ESNs. This notification is only sent by the cluster.
在单个IKE SA下建立，我们不直接同步每个SA的值。相反，将发送一个增量值，并且此IKE SA的子SA的所有replay计数器将以相同的值递增。请注意，此解决方案要求所有子SA使用扩展序列号（ESN），或者没有子SA使用ESN。此通知仅由群集发送。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming IPsec SA delta value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming IPsec SA delta value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The notification payload contains the following data.
通知有效负载包含以下数据。
o Incoming IPsec SA delta value (4 or 8 octets): The sender requests that the peer should increment all the Child SA replay counters for the sender's incoming (the peer's outgoing) traffic by this value. The size of this field depends on the ESN bit associated with the Child SAs: if the ESN bit is 1, the field's size is 8 octets; otherwise, it is 4 octets. We note that this constrains the Child SAs of each IKE SA to either all have the ESN bit on or off.
o 传入IPsec SA增量值（4或8个八位字节）：发送方请求对等方将发送方的传入（对等方的传出）通信量的所有子SA replay计数器增加此值。此字段的大小取决于与子SAs关联的ESN位：如果ESN位为1，则字段大小为8个八位字节；否则，它是4个八位组。我们注意到，这将每个IKE SA的子SA约束为全部ESN位为on或off。
This protocol does not change any of the existing IKEv2 rules regarding Message ID values.
此协议不会更改任何有关消息ID值的现有IKEv2规则。
The standby member can initiate the synchronization of IKEv2 Message IDs under different circumstances.
备用成员可以在不同情况下启动IKEv2消息ID的同步。
o When it receives a problematic IKEv2/IPsec packet, i.e., a packet outside its expected receive window.
o 当它接收到有问题的IKEv2/IPsec数据包时，即在其预期接收窗口之外的数据包。
o When it has to send the first IKEv2/IPsec packet after a failover event.
o 在故障转移事件之后，它必须发送第一个IKEv2/IPsec数据包。
o When it has just received control from the active member and wishes to update the values proactively, so that it need not start this exchange later, when sending or receiving the request.
o 当它刚从活动成员接收到控制并希望主动更新值时，以便在发送或接收请求时不必稍后启动此交换。
To clarify the first alternative: the normal IKE behavior of rejecting out-of-window messages is not changed, but such messages can still be a valid trigger for the exchange defined in this document. To avoid denial-of-service (DoS) attacks resulting from replayed messages, the peer MUST NOT initiate counter synchronization for any particular IKE SA more than once per failover event.
澄清第一种选择：拒绝窗口外消息的正常IKE行为没有改变，但此类消息仍然可以是本文档中定义的交换的有效触发器。为了避免由于重播消息而导致的拒绝服务（DoS）攻击，对等方不得在每个故障转移事件中多次为任何特定IKE SA启动计数器同步。
The standby member can initiate the synchronization of IPsec SA replay counters:
备用成员可以启动IPsec SA replay计数器的同步：
o If there has been traffic using the IPsec SA in the recent past and the standby member suspects that its replay counter may be stale.
o 如果最近有使用IPsec SA的流量，并且备用成员怀疑其重播计数器可能过时。
Since there can be a large number of sessions at the standby member, and sending synchronization exchanges for all of them may result in overload, the standby member can choose to initiate the exchange in a "lazy" fashion: only when it has to send or expects to receive traffic from each peer. In general, the standby member is free to initiate this exchange at its discretion. Implementation considerations include the ability to survive a certain amount of traffic loss, and the capacity of a cluster member to initiate counter synchronization simultaneously with a large number of peers.
由于备用成员处可能存在大量会话，并且为所有会话发送同步交换可能会导致过载，因此备用成员可以选择以“延迟”方式启动交换：仅当它必须发送或期望接收来自每个对等方的流量时。一般而言，备用会员机构可自行决定发起本次交易。实现方面的考虑因素包括能够承受一定数量的通信量损失，以及集群成员与大量对等方同时启动计数器同步的能力。
The straightforward definitions of message sequence numbers, retransmissions, and replay protection in IPsec and IKEv2 are strained by the failover scenarios described in this document. This section describes some policy choices that need to be made by implementations in this setting.
IPsec和IKEv2中对消息序列号、重传和重播保护的直接定义因本文档中描述的故障切换场景而受到限制。本节介绍在此设置中实现需要做出的一些策略选择。
After sending its "receive" counter, the cluster member MUST reject (silently drop) any incoming IKE messages that are outside its declared window. A similar rule applies to the peer. Local policies vary, and strict implementations will reject any incoming IKE message arriving before Message ID synchronization is complete.
在发送其“receive”计数器后，集群成员必须拒绝（静默删除）任何在其声明窗口之外的传入IKE消息。类似的规则也适用于对等方。本地策略各不相同，严格的实现将拒绝在消息ID同步完成之前到达的任何传入IKE消息。
For IPsec, there is often a trade-off between security and reliability of the protected protocols. Here again, there is some leeway for local policy. Some implementations might accept incoming
对于IPsec，通常需要在受保护协议的安全性和可靠性之间进行权衡。在这方面，地方政策也有一定的回旋余地。一些实现可能接受传入的
traffic that is outside the replay window for some time after the failover event, and until the counters had been synchronized. Strict implementations will only accept traffic that's inside the "safe" window.
故障转移事件发生后一段时间内，直到计数器同步之前，在replay窗口之外的通信量。严格的实现只接受“安全”窗口内的流量。
IKEv2 is normally a reliable protocol. As long as an IKE SA is valid, both peers share a single, consistent view of the IKE SA and all associated Child SAs. Failover situations as described in this document may involve forced deletion of IKE messages, resulting in inconsistencies, such as Child SAs that exist on only one of the peers. Such SAs might cause an INVALID_SPI to be returned when used by that peer. Note that Section 1.5 of [4] allows but does not mandate sending an INVALID_SPI notification in this case.
IKEv2通常是一个可靠的协议。只要IKE SA有效，两个对等方共享IKE SA和所有关联子SA的单一一致视图。本文档中描述的故障转移情况可能涉及强制删除IKE消息，从而导致不一致，例如仅存在于一个对等方上的子SA。当该对等方使用此类SA时，可能会导致返回无效的_SPI。请注意，在这种情况下，[4]的第1.5节允许但不强制发送无效的_SPI通知。
The IPsecME Working Group discussed at some point a proposed set of rules for dealing with such situations. However, we believe that these situations should be rare in practice; as a result, the "default" behavior of tearing down the entire IKE SA is to be preferred over the complexity of dealing with a multitude of edge cases.
IPSECM工作组在某个时候讨论了一套处理此类情况的拟议规则。然而，我们认为这些情况在实践中应该是罕见的；因此，与处理大量边缘情况的复杂性相比，拆除整个IKE SA的“默认”行为更为可取。
This section goes through the sequence of steps of a typical failover event, looking at a case where the IKEv2 Message ID values are synchronized.
本节将介绍典型故障切换事件的步骤序列，查看同步IKEv2消息ID值的情况。
o The active cluster member and the peer device establish the session. They both announce the capability to synchronize counter information by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED notification in the IKE_AUTH exchange.
o 活动群集成员和对等设备建立会话。它们都通过在IKE_身份验证交换中发送IKEV2_消息_ID_SYNC_支持的通知来宣布同步计数器信息的功能。
o Some time later, the active member dies, and a standby member takes over. The standby member sends its own idea of the IKE Message IDs (both incoming and outgoing) to the peer in an Informational message exchange with Message ID zero.
o 一段时间后，活动成员死亡，备用成员接管。在消息ID为零的信息性消息交换中，备用成员将其自己的IKE消息ID（传入和传出）发送给对等方。
o The peer first authenticates the message. The peer compares the received values with the values available locally and picks the higher value. It then updates its Message IDs with the higher values and also proposes the same values in its response.
o 对等方首先对消息进行身份验证。对等方将接收到的值与本地可用的值进行比较，并选择较高的值。然后，它用更高的值更新消息ID，并在响应中提出相同的值。
o The peer should not wait for any pending responses while responding with the new Message ID values. For example, if the window size is 5 and the peer's window is 3-7, and if the peer has sent requests 3, 4, 5, 6, and 7 and received responses only for 4,
o 当使用新的消息ID值进行响应时，对等方不应等待任何挂起的响应。例如，如果窗口大小为5，对等方的窗口为3-7，并且对等方发送了请求3、4、5、6和7，并且仅收到了4个响应，
5, 6, and 7 but not for 3, then it should include the value 8 in its EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a response to message 3 any more.
5、6和7，但不适用于3，则应在其预期的_SEND_REQ_MESSAGE_ID有效负载中包含值8，并且不应再等待对消息3的响应。
o Similarly, the peer should also not wait for pending (incoming) requests. For example, if the window size is 5 and the peer's window is 3-7, and if the peer has received requests 4, 5, 6, and 7 but not 3, then it should send the value 8 in the EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to receive message 3 any more.
o 同样，对等方也不应等待挂起（传入）请求。例如，如果窗口大小为5，对等方的窗口为3-7，并且对等方已接收到请求4、5、6和7，但未接收到3，则它应发送预期的_RECV_REQ_MESSAGE_ID有效负载中的值8，并且不应再期望接收消息3。
The usage scenario of this IKEv2/IPsec SA counter synchronization solution is that an IKEv2 SA has been established between the active member of a hot standby cluster and a peer, followed by a failover event occurring and the standby member becoming active. The solution further assumes that the IKEv2 SA state was continuously synchronized between the active and standby members of the cluster before the failover event.
此IKEv2/IPsec SA计数器同步解决方案的使用场景是，在热备用群集的活动成员和对等方之间建立了IKEv2 SA，随后发生故障转移事件，备用成员变为活动状态。该解决方案还假设在故障转移事件发生之前，IKEv2 SA状态在集群的活动和备用成员之间持续同步。
o Session resumption [12] assumes that a peer (client or initiator) detects the need to re-establish the session. In IKEv2/IPsec SA counter synchronization, it is the newly active member (a gateway or responder) that detects the need to synchronize the SA counter after the failover event. Also, in a hot standby cluster, the peer establishes the IKEv2/IPsec session with a single IP address that represents the whole cluster, so the peer normally does not detect the event of failover in the cluster unless the standby member takes too long to become active and the IKEv2 SA times out by use of the IKEv2 liveness check mechanism. To conclude, session resumption and SA counter synchronization after failover are mutually exclusive: they are not expected to be used together, and both features can coexist within the same implementation without affecting each other.
o 会话恢复[12]假设对等方（客户端或启动器）检测到需要重新建立会话。在IKEv2/IPsec SA计数器同步中，是新活动的成员（网关或响应程序）在故障转移事件后检测到需要同步SA计数器。此外，在热备用集群中，对等方使用代表整个集群的单个IP地址建立IKEv2/IPsec会话，因此对等方通常不会检测集群中的故障转移事件，除非备用成员花费太长时间变为活动状态，并且IKEv2 SA通过使用IKEv2活动性检查机制超时。总之，故障转移后的会话恢复和SA计数器同步是互斥的：它们不应该一起使用，而且这两个功能可以在同一个实现中共存，而不会相互影响。
o The IKEv2 Redirect mechanism for load balancing [13] can be used either during the initial stages of SA setup (the IKE_SA_INIT and IKE_AUTH exchanges) or after session establishment. SA counter synchronization is only useful after the IKE SA has been established and a failover event has occurred. So, unlike Redirect, it is irrelevant during the first two exchanges. Redirect after the session has been established is mostly useful
o IKEv2负载平衡重定向机制[13]可以在SA设置的初始阶段（IKE_SA_INIT和IKE_AUTH交换）或会话建立后使用。SA计数器同步仅在建立IKE SA并发生故障转移事件后有用。因此，与重定向不同，它在前两次交换中是不相关的。会话建立后重定向最有用
for timed or planned shutdown/maintenance. A real failover event cannot be detected by the active member ahead of time, and so using Redirect after session establishment is not possible in the case of failover. So, Redirect and SA counter synchronization after failover are mutually exclusive, in the sense described above.
用于定时或计划停机/维护。活动成员无法提前检测到真正的故障转移事件，因此在故障转移的情况下，无法在会话建立后使用重定向。因此，在上述意义上，故障转移后的重定向和SA计数器同步是互斥的。
o IKEv2 Failure Detection [8] solves a similar problem where the peer can rapidly detect that a cluster member has crashed based on a token. It is unrelated to the current scenario, because the goal in failover is for the peer not to notice that a failure has occurred.
o IKEv2 Failure Detection[8]解决了一个类似的问题，即对等方可以基于令牌快速检测到集群成员崩溃。这与当前场景无关，因为故障转移的目标是让对等方不会注意到发生了故障。
Since Message ID synchronization messages need to be sent with Message ID zero, they are potentially vulnerable to replay attacks. Because of the semantics of this protocol, these can only be denial-of-service (DoS) attacks, and we are aware of two variants.
由于消息ID同步消息需要在消息ID为零的情况下发送，因此它们可能容易受到重播攻击。由于该协议的语义，这些攻击只能是拒绝服务（DoS）攻击，我们知道有两种变体。
o Replay of Message ID synchronization request: This is countered by the requirement that the Send counter sent by the cluster member should always be monotonically increasing, a rule that the peer enforces by silently dropping messages that contradict it.
o 消息ID同步请求的重播：集群成员发送的发送计数器应始终单调递增的要求抵消了这一点，对等方通过静默删除与之矛盾的消息来强制执行这一规则。
o Replay of the Message ID synchronization response: This is countered by sending the nonce data along with the synchronization payload. The same nonce data has to be returned in the response. Thus, the standby member will accept a reply only for the current request. After it receives a valid response, it MUST NOT process the same response again and MUST discard any additional responses.
o 消息ID同步响应的重播：通过发送nonce数据和同步负载来应对。响应中必须返回相同的nonce数据。因此，备用成员将只接受当前请求的回复。收到有效响应后，它不得再次处理相同的响应，并且必须放弃任何其他响应。
As mentioned in Section 7, triggering counter synchronization by out-of-window, potentially replayed messages could open a DoS vulnerability. This risk is mitigated by the solution described in that section.
如第7节所述，通过窗口外触发计数器同步，可能重播的消息可能会打开DoS漏洞。该部分描述的解决方案缓解了该风险。
This document introduces four new IKEv2 Notification Message types as described in Section 6. The new Notify Message Types have been assigned values as follows.
本文档介绍了四种新的IKEv2通知消息类型，如第6节所述。新的通知消息类型已分配如下值。
+-------------------------------------+-------+
| Name | Value |
+-------------------------------------+-------+
| IKEV2_MESSAGE_ID_SYNC_SUPPORTED | 16420 |
| IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED | 16421 |
| IKEV2_MESSAGE_ID_SYNC | 16422 |
| IPSEC_REPLAY_COUNTER_SYNC | 16423 |
+-------------------------------------+-------+
+-------------------------------------+-------+
| Name | Value |
+-------------------------------------+-------+
| IKEV2_MESSAGE_ID_SYNC_SUPPORTED | 16420 |
| IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED | 16421 |
| IKEV2_MESSAGE_ID_SYNC | 16422 |
| IPSEC_REPLAY_COUNTER_SYNC | 16423 |
+-------------------------------------+-------+
We would like to thank Pratima Sethi and Frederic Detienne for their review comments and valuable suggestions for the initial version of the document.
我们要感谢Pratima Sethi和Frederic Detienne对文件初始版本的审查意见和宝贵建议。
We would also like to thank the following people (in alphabetical order) for their review comments and valuable suggestions: Dan Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and Pekka Riikonen.
我们还要感谢以下人士（按字母顺序）的评论和宝贵建议：Dan Harkins、Paul Hoffman、Steve Kent、Tero Kivinen、David McGrew和Pekka Riikonen。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[2] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[3] Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[4] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[4] Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Erenen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[5] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[6] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
[6] Nir，Y.，“IPsec集群问题声明”，RFC 6027，2010年10月。
[7] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[7] Nadas，S.，编辑，“IPv4和IPv6的虚拟路由器冗余协议（VRRP）第3版”，RFC 5798，2010年3月。
[8] Nir, Y., Ed., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)", RFC 6290, June 2011.
[8] Nir，Y.，Ed.，Wierbowski，D.，Detiene，F.，和P.Sethi，“互联网密钥交换协议（IKE）的快速崩溃检测方法”，RFC 62902011年6月。
[9] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[9] Housley，R.，“将高级加密标准（AES）计数器模式与IPsec封装安全有效载荷（ESP）结合使用”，RFC 3686，2004年1月。
[10] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[10] Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[11] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", RFC 6054, November 2010.
[11] McGrew，D.和B.Weis，“使用带有封装安全有效负载（ESP）和身份验证头（AH）的计数器模式来保护组流量”，RFC 60542010年11月。
[12] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[12] Sheffer，Y.和H.Tschofenig，“互联网密钥交换协议第2版（IKEv2）会话恢复”，RFC 57232010年1月。
[13] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009.
[13] Devarapalli，V.和K.Weniger，“互联网密钥交换协议版本2（IKEv2）的重定向机制”，RFC 5685，2009年11月。
This (non-normative) section presents some examples that illustrate how the IKEv2 Message ID values are synchronized. We use a tuple notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and EXPECTED_RECV_REQ_MESSAGE_ID on each protocol party as (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).
本节（非规范性）给出了一些示例，说明了IKEv2消息ID值是如何同步的。我们使用元组表示法，将每个协议方上的两个计数器预期的发送请求消息ID和预期的接收请求消息ID表示为（预期的发送请求消息ID，预期的接收请求消息ID）。
Note that if the IKE message counters are already synchronized (as in the first example), we expect the numbers to be reversed between the two sides. If one protocol party intends to send the next request as 4, then the other expects the next received request to be 4.
请注意，如果IKE消息计数器已经同步（如第一个示例中所示），则我们希望两侧的数字是相反的。如果一个协议方打算将下一个请求作为4发送，那么另一个协议方希望下一个接收到的请求为4。
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (0, 5) -------->
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (0, 5) -------->
Peer has the values (5, 0), so it sends
<------------- (5, 0) as the Sync Response
Peer has the values (5, 0), so it sends
<------------- (5, 0) as the Sync Response
In this example, the peer has most recently sent an IKE request with Message ID 4, and has never received a request. So the peer's expected values for the next pair of messages are (5, 0). These are the same values as received from the member, and therefore they are sent as-is.
在此示例中，对等方最近发送了消息ID为4的IKE请求，但从未收到请求。因此，对等方对下一对消息的期望值为（5，0）。这些值与从成员接收到的值相同，因此它们按原样发送。
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (2, 3) -------->
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (2, 3) -------->
Peer has the values (4, 5), so it sends
<------------- (4, 5) as the Sync Response
Peer has the values (4, 5), so it sends
<------------- (4, 5) as the Sync Response
In this example, the peer has most recently sent an IKE message with the Message ID 3, and received one with ID 4. So the peer's expected values for the next pair of messages are (4, 5). These are both higher than the corresponding values just received from the member (the order of tuple members is reversed when doing this comparison!), and therefore they are sent as-is.
在该示例中，对等方最近发送了一个具有消息ID 3的IKE消息，并接收到一个具有ID 4的IKE消息。因此，对等方对下一对消息的期望值为（4，5）。这两个值都高于刚刚从成员接收到的相应值（在进行比较时元组成员的顺序是相反的！），因此它们按原样发送。
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (2, 5) -------->
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (2, 5) -------->
Peer has the values (2, 4), so it sends
<-------------(5, 4) as the Sync Response
Peer has the values (2, 4), so it sends
<-------------(5, 4) as the Sync Response
In this example, the newly active member expects to send the next IKE
message with ID 2. It sends an expected receive value of 5, which is
higher than the last ID value it has seen from the peer, because it
believes some incoming messages may have been lost. The peer has
last sent a message with ID 1, and received one with ID 3, indicating
that a couple of messages sent by the previously active member had
not been synchronized into the other member. So the peer's next
expected (send, receive) values are (2, 4). The peer replies with
the maximum of the received and the expected value for both send and
receive counters: (max(2, 5), max(4, 2)) = (5, 4).
In this example, the newly active member expects to send the next IKE
message with ID 2. It sends an expected receive value of 5, which is
higher than the last ID value it has seen from the peer, because it
believes some incoming messages may have been lost. The peer has
last sent a message with ID 1, and received one with ID 3, indicating
that a couple of messages sent by the previously active member had
not been synchronized into the other member. So the peer's next
expected (send, receive) values are (2, 4). The peer replies with
the maximum of the received and the expected value for both send and
receive counters: (max(2, 5), max(4, 2)) = (5, 4).
In the case of simultaneous failover, both sides send their synchronization requests simultaneously. The eventual outcome of synchronization consists of the higher counter values. This is demonstrated in the following figure.
在同时故障切换的情况下，双方同时发送同步请求。同步的最终结果包括更高的计数器值。下图显示了这一点。
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (4,4) ----->
Sync Request (4,4) ----->
<-------------- Sync Request (5,5)
<-------------- Sync Request (5,5)
Sync Response (5,5) ---->
Sync Response (5,5) ---->
<-------- Sync Response (5,5)
<-------- Sync Response (5,5)
Authors' Addresses
作者地址
Raj Singh (editor) Cisco Systems, Inc. Divyashree Chambers, B Wing, O'Shaugnessy Road Bangalore, Karnataka 560025 India
拉吉·辛格（编辑）思科系统公司，印度卡纳塔克邦班加罗尔O'Shaugnessy路B翼Divyashree Chambers 560025
Phone: +91 80 4301 3320
EMail: rsj@cisco.com
Phone: +91 80 4301 3320
EMail: rsj@cisco.com
Kalyani Garigipati Cisco Systems, Inc. Divyashree Chambers, B Wing, O'Shaugnessy Road Bangalore, Karnataka 560025 India
印度卡纳塔克邦班加罗尔O'Shaugnessy路B栋Kalyani Garigipati Cisco Systems，Inc.Divyashree Chambers，邮编560025
Phone: +91 80 4426 4831
EMail: kagarigi@cisco.com
Phone: +91 80 4426 4831
EMail: kagarigi@cisco.com
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim St. Tel Aviv 67897 Israel
以色列特拉维夫Hasolelim街5号Yoav Nir Check Point软件技术有限公司67897
EMail: ynir@checkpoint.com
EMail: ynir@checkpoint.com
Yaron Sheffer Porticor Cloud Security
Yaron Sheffer Porticor云安全
EMail: yaronf.ietf@gmail.com
EMail: yaronf.ietf@gmail.com
Dacheng Zhang Huawei Technologies Ltd.
张大成华为技术有限公司。
EMail: zhangdacheng@huawei.com
EMail: zhangdacheng@huawei.com