Internet Engineering Task Force (IETF) D. Migault, Ed.
Request for Comments: 7791 Ericsson
Category: Standards Track V. Smyslov
ISSN: 2070-1721 ELVIS-PLUS
March 2016
Internet Engineering Task Force (IETF) D. Migault, Ed.
Request for Comments: 7791 Ericsson
Category: Standards Track V. Smyslov
ISSN: 2070-1721 ELVIS-PLUS
March 2016
Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)
在Internet密钥交换协议版本2（IKEv2）中克隆IKE安全关联
Abstract
摘要
This document considers a VPN end user establishing an IPsec Security Association (SA) with a Security Gateway using the Internet Key Exchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.
本文档考虑VPN最终用户使用Internet密钥交换协议版本2（IKEv2）与安全网关建立IPsec安全关联（SA），其中至少一个对等方具有多个接口，或者安全网关是一个群集，每个节点都有自己的IP地址。
The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKE SA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node.
所述协议允许对等方克隆IKEv2 SA，其中从现有SA派生出附加SA。新创建的IKE SA未设置IKEv2身份验证交换。此IKE SA稍后可以分配给另一个接口或移动到另一个群集节点。
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/rfc7791.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7791.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Support Negotiation . . . . . . . . . . . . . . . . . . . 6
5.2. Cloning the IKE SA . . . . . . . . . . . . . . . . . . . 7
5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 7
6. Payload Description . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Setting a VPN on Multiple Interfaces . . . . . . . . 11
A.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 11
A.2. Creating an Additional IKE SA . . . . . . . . . . . . . . 12
A.3. Creating the Child SA for VPN_1 . . . . . . . . . . . . . 12
A.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Support Negotiation . . . . . . . . . . . . . . . . . . . 6
5.2. Cloning the IKE SA . . . . . . . . . . . . . . . . . . . 7
5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 7
6. Payload Description . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Setting a VPN on Multiple Interfaces . . . . . . . . 11
A.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 11
A.2. Creating an Additional IKE SA . . . . . . . . . . . . . . 12
A.3. Creating the Child SA for VPN_1 . . . . . . . . . . . . . 12
A.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
The main scenario that motivated this document is a VPN end user establishing a VPN with a Security Gateway when at least one of the peers has multiple interfaces. Figure 1 represents the case when the VPN end user has multiple interfaces, Figure 2 represents the case when the Security Gateway has multiple interfaces, and Figure 3 represents the case when both the VPN end user and the Security Gateway have multiple interfaces. With Figure 1 and Figure 2, one of the peers has n = 2 interfaces and the other has a single interface. This results in the creation of up to n = 2 VPNs. With Figure 3, the VPN end user has n = 2 interfaces and the Security Gateway has m = 2 interfaces. This may lead to up to m x n VPNs.
激发本文档的主要场景是当至少一个对等方具有多个接口时，VPN最终用户使用安全网关建立VPN。图1表示VPN最终用户具有多个接口的情况，图2表示安全网关具有多个接口的情况，图3表示VPN最终用户和安全网关都具有多个接口的情况。在图1和图2中，一个对等点有n=2个接口，另一个有一个接口。这将导致创建多达n=2个VPN。在图3中，VPN最终用户有n=2个接口，安全网关有m=2个接口。这可能导致多达m x n个VPN。
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================= | |
| VPN | v | Security |
| End User | ================== Gateway |
| ================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================= | |
| VPN | v | Security |
| End User | ================== Gateway |
| ================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 1: VPN End User with Multiple Interfaces
图1：具有多个接口的VPN最终用户
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| | ================== |
| VPN | v | Security |
| End User ================= | Gateway |
| | ^================= |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| | ================== |
| VPN | v | Security |
| End User ================= | Gateway |
| | ^================= |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 2: Security Gateway with Multiple Interfaces
图2：具有多个接口的安全网关
+------------+ +------------+
| | Interface_0 Interface_0' | |
| ================================== |
| VPN | \\ // | Security |
| End User | // \\ | Gateway |
| ================================== |
| | Interface_1 Interface_1' | |
+------------+ +------------+
+------------+ +------------+
| | Interface_0 Interface_0' | |
| ================================== |
| VPN | \\ // | Security |
| End User | // \\ | Gateway |
| ================================== |
| | Interface_1 Interface_1' | |
+------------+ +------------+
Figure 3: VPN End User and Security Gateway with Multiple Interfaces
图3：具有多个接口的VPN最终用户和安全网关
With the current IKEv2 protocol [RFC7296], each VPN requires an IKE SA, and setting an IKE SA requires an authentication. Authentication might require multiple round trips and an activity from the end user (like EAP-SIM [RFC4186] or EAP-TLS [RFC5216]) as well as crypto operations that would introduce an additional delay.
使用当前的IKEv2协议[RFC7296]，每个VPN都需要IKE SA，设置IKE SA需要身份验证。身份验证可能需要多次往返和来自最终用户的活动（如EAP-SIM[RFC4186]或EAP-TLS[RFC5216]）以及可能引入额外延迟的加密操作。
Another scenario is a load-balancing solution. Load-sharing clusters are often built to be transparent for VPN end users. In the case of IPsec, this means that IKE and IPsec SA states are duplicated on every cluster node where the load balancer can redirect packets. The drawback of such an approach is that anti-replay related data (in particular, Sequence Number) must be reliably synchronized between participating nodes per every outgoing Authentication Header (AH) or Encapsulating Security Payload (ESP) packet, which makes building high-speed systems problematic. Another approach for building load-balancing systems is to make VPN end users aware of them, which allows for having two or more Security Gateways sharing the same ID, but each having its own IP address. In this case, the VPN end user first establishes an IKE SA with one of these gateways. Then, at some point of time the gateway makes a decision to move the client to a different cluster node. This can be done with Redirect Mechanism for IKEv2 [RFC5685]. The drawback of such an approach is that it requires a new IKE SA to be established from scratch, including full authentication. In some cases, this could be avoided by using IKEv2 Session Resumption [RFC5723] with a new gateway. However, this requires the VPN end user to know beforehand which new gateway to connect to. So, it is desirable to be able to clone the existing IKE SA, move it to a different Security Gateway, and then indicate to the VPN end user to use this new SA. This would allow participating Security Gateways to share the load between them.
另一个场景是负载平衡解决方案。负载共享集群通常构建为对VPN最终用户透明。在IPsec的情况下，这意味着IKE和IPsec SA状态在负载平衡器可以重定向数据包的每个群集节点上都是重复的。这种方法的缺点是，每个传出认证报头（AH）或封装安全有效载荷（ESP）数据包的参与节点之间必须可靠地同步与反重放相关的数据（特别是序列号），这使得构建高速系统成为问题。构建负载平衡系统的另一种方法是让VPN最终用户知道它们，这允许两个或多个安全网关共享相同的ID，但每个都有自己的IP地址。在这种情况下，VPN最终用户首先使用这些网关之一建立IKE SA。然后，网关在某个时间点决定将客户端移动到不同的集群节点。这可以通过IKEv2[RFC5685]的重定向机制实现。这种方法的缺点是需要从头建立新的IKE SA，包括完全认证。在某些情况下，可以通过使用带有新网关的IKEv2会话恢复[RFC5723]来避免这种情况。但是，这需要VPN最终用户事先知道要连接到哪个新网关。因此，希望能够克隆现有IKE SA，将其移动到不同的安全网关，然后向VPN最终用户指示使用此新SA。这将允许参与的安全网关在它们之间共享负载。
This document introduces the possibility of cloning the IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2). The main idea is that the peer with multiple interfaces sets the first IKE SA as usual. Then it takes advantage of the fact that this SA is completed and derives as many new parallel IKE SAs from it as the desired number of VPNs. On each IKE SA a VPN is negotiated by creating one or more IPsec SAs. This results in coexisting parallel VPNs. Then the VPN end user moves each IPsec SA to its proper location using the IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555]. Alternatively, the VPN end user may first move the IKE SAs and then create the IPsec SAs.
本文档介绍了在Internet密钥交换协议版本2（IKEv2）中克隆IKE SA的可能性。其主要思想是，具有多个接口的对等方像往常一样设置第一个IKE SA。然后，它利用此SA已完成的事实，并从中派生出与所需VPN数量相同的新并行IKE SA。在每个IKE SA上，通过创建一个或多个IPsec SA协商VPN。这导致并行VPN共存。然后，VPN最终用户使用IKEv2移动和多址协议（MOBIKE）[RFC4555]将每个IPsec SA移动到其适当的位置。或者，VPN最终用户可以首先移动IKE SAs，然后创建IPsec SAs。
Note that it is up to the host's local policy to decide which additional VPNs to create and when to do it. The process of selecting address pairs for migration is a local matter.
请注意，由主机的本地策略决定创建哪些附加VPN以及何时创建。为迁移选择地址对的过程是本地事务。
Furthermore, in the case of multiple interfaces on both ends, care should be taken to avoid the VPNs being duplicated by both ends or moved to both interfaces.
此外，如果两端都有多个接口，应注意避免VPN被两端复制或移动到两个接口。
In addition, multiple MOBIKE operations may be involved from the Security Gateway or the VPN end user. Suppose, as depicted in Figure 3 for example, that the cloned VPN is between Interface _0 and Interface_0', and the VPN end user and the Security Gateway want to move it to Interface_1 and Interface_1'. The VPN end user may initiate a MOBIKE exchange in order to move it to Interface_1, in which case the cloned VPN is now between Interface_1 and Interface_0'. Then the Security Gateway may also initiate a MOBIKE exchange in order to move the VPN to Interface_1', in which case the VPN has reached its final destination.
此外，安全网关或VPN最终用户可能涉及多个MOBIKE操作。例如，如图3所示，假设克隆的VPN位于接口_0和接口_0'之间，VPN最终用户和安全网关希望将其移动到接口_1和接口_1'。VPN最终用户可以发起MOBIKE交换，以便将其移动到接口_1，在这种情况下，克隆的VPN现在位于接口_1和接口_0'之间。然后，安全网关还可以发起MOBIKE交换，以便将VPN移动到接口_1'，在这种情况下，VPN已经到达其最终目的地。
The combination of the IKE SA cloning with MOBIKE protocol provides IPsec communications with multiple interfaces the following advantages. First, cloning the IKE SA requires very few modifications to already existing IKEv2 implementations. Then, it takes advantage of the already existing and widely deployed MOBIKE protocol. Finally, it keeps a dedicated IKE SA for each VPN, which simplifies reachability tests and VPN maintenance.
IKE SA克隆与MOBIKE协议的结合为具有多个接口的IPsec通信提供了以下优势。首先，克隆IKE SA只需对现有的IKEv2实现进行很少的修改。然后，它利用了已经存在并广泛部署的MOBIKE协议。最后，它为每个VPN保留一个专用IKE SA，这简化了可达性测试和VPN维护。
Note also that the cloning of the IKE SA is independent from MOBIKE and can also address other future scenarios not described in the current document.
还请注意，IKE SA的克隆独立于MOBIKE，还可以解决当前文档中未描述的其他未来场景。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section defines terms and acronyms used in this document.
本节定义了本文件中使用的术语和首字母缩略词。
- VPN: Virtual Private Network -- one or more Child (IPsec) SAs created in tunnel mode between two peers.
- VPN：虚拟专用网络——在两个对等方之间以隧道模式创建的一个或多个子（IPsec）SA。
- VPN End User: designates the end user that initiates the VPN with a Security Gateway. This end user may be mobile and move its VPN from one Security Gateway to another.
- VPN最终用户：指定使用安全网关启动VPN的最终用户。该最终用户可能是移动的，并将其VPN从一个安全网关移动到另一个安全网关。
- Security Gateway: designates a point of attachment for the VPN service. In this document, the VPN service is provided by multiple Security Gateways. Each Security Gateway may be considered as a specific hardware.
- 安全网关：为VPN服务指定连接点。在本文档中，VPN服务由多个安全网关提供。每个安全网关可被视为一个特定的硬件。
- IKE SA: IKE Security Association as defined in [RFC7296].
- IKE SA:IKE安全关联，定义见[RFC7296]。
This document specifies how to clone existing IKE SAs without performing new authentication. In order to achieve this goal, this document proposes that the two peers agree upon their ability to clone the IKE SA. This is done during the IKE_AUTH exchange by exchanging the CLONE_IKE_SA_SUPPORTED notifications. To create a new parallel IKE SA, one of the peers initiates a CREATE_CHILD_SA exchange as if it would rekey the existing IKE SA. In order to indicate that the current IKE SA must not be deleted, the initiator includes the CLONE_IKE_SA notification in the CREATE_CHILD_SA exchange. This results in two parallel IKE SAs.
本文档指定如何在不执行新身份验证的情况下克隆现有IKE SA。为了实现这一目标，本文档建议两个对等方就克隆IKE SA的能力达成一致。这是在IKE_身份验证交换期间通过交换克隆IKE_SA_支持的通知来完成的。为了创建一个新的并行IKE SA，其中一个对等方启动一个create_CHILD_SA交换，就好像它将为现有IKE SA重新设置密钥一样。为了指示当前IKE SA不能被删除，发起方在CREATE_CHILD_SA交换中包含克隆IKE_SA通知。这将导致两个并行IKE SA。
Note that without the CLONE_IKE_SA notification, the old IKE SA would be deleted after the rekey is successfully completed (as specified in Section 2.8 of [RFC7296].
请注意，在没有克隆IKE SA通知的情况下，旧IKE SA将在重新密钥成功完成后删除（如[RFC7296]第2.8节所述）。
The initiator and the responder indicate their support for cloning IKE SA by exchanging the CLONE_IKE SA_SUPPORTED notifications. This notification MUST be sent in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges -- in the first IKE_AUTH message from initiator and in the last IKE_AUTH message from responder). If both initiator and responder send this notification during the IKE_AUTH exchange, peers may clone this IKE SA. In the other case, the IKE SA MUST NOT be cloned.
发起方和响应方通过交换克隆IKE SA受支持的通知来表示支持克隆IKE SA。此通知必须在IKE_身份验证交换中发送（在多个IKE_身份验证交换的情况下——在来自发起方的第一条IKE_身份验证消息和来自响应方的最后一条IKE_身份验证消息中）。如果发起方和响应方在IKE_身份验证交换期间发送此通知，则对等方可以克隆此IKE SA。在另一种情况下，不得克隆IKE SA。
Initiator Responder
-------------------------------------------------------------------
HDR, SA, KEi, Ni -->
<-- HDR, SA, KEr, Nr
HDR, SK {IDi, AUTH,
SA, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)} -->
<-- HDR, SK {IDr, AUTH,
SA, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)}
Initiator Responder
-------------------------------------------------------------------
HDR, SA, KEi, Ni -->
<-- HDR, SA, KEr, Nr
HDR, SK {IDi, AUTH,
SA, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)} -->
<-- HDR, SK {IDr, AUTH,
SA, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)}
The initiator of the rekey exchange includes the CLONE_IKE_SA notification in a CREATE_CHILD_SA request for rekeying the IKE SA. The CLONE_IKE_SA notification indicates that the current IKE SA will not be immediately deleted once the new IKE SA is created. Instead, two parallel IKE SAs are expected to coexist. The current IKE SA becomes the old IKE SA and the newly negotiated IKE SA becomes the new IKE SA. The CLONE_IKE_SA notification MUST appear only in the request message of the CREATE_CHILD_SA exchange concerning the IKE SA rekey. If the CLONE_IKE_SA notification appears in any other message, it MUST be ignored.
密钥交换的发起人将克隆IKE SA通知包含在用于密钥交换IKE SA的创建子SA请求中。克隆IKE SA通知表示，在创建新IKE SA后，不会立即删除当前IKE SA。相反，两个并行IKE SA预计将共存。当前IKE SA变为旧IKE SA，新协商的IKE SA变为新IKE SA。克隆IKE SA通知必须仅出现在有关IKE SA密钥的CREATE CHILD SA交换的请求消息中。如果克隆IKE SA通知出现在任何其他消息中，则必须将其忽略。
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(CLONE_IKE_SA), SA, Ni, KEi} -->
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(CLONE_IKE_SA), SA, Ni, KEi} -->
If the CREATE_CHILD_SA request is concerned with an IKE SA rekey and contains the CLONE_IKE_SA notification, the responder proceeds to the IKE SA rekey, creates the new IKE SA, and keeps the old IKE SA. No additional Notify Payloads are included in the CREATE_CHILD_SA response as represented below:
如果CREATE_CHILD_SA请求与IKE SA密钥有关，并且包含克隆IKE_SA通知，则响应者继续执行IKE SA密钥，创建新的IKE SA，并保留旧的IKE SA。CREATE_CHILD_SA响应中不包括其他Notify有效载荷，如下所示：
<-- HDR, SK {SA, Nr, KEr}
<-- HDR, SK {SA, Nr, KEr}
When the IKE SA is cloned, peers MUST NOT transfer existing Child SAs that were created by the old IKE SA to the newly created IKE SA. So, all signaling messages concerning those Child SAs would continue to be sent over the old IKE SA. This is different from the regular IKE SA rekey in IKEv2.
克隆IKE SA时，对等方不得将旧IKE SA创建的现有子SA传输到新创建的IKE SA。因此，所有关于这些子SA的信令消息将继续通过旧IKE SA发送。这与IKEv2中的常规IKE SA密钥不同。
There may be conditions when the responder for some reason is unable or unwilling to clone the IKE SA. This inability may be temporary or permanent.
当响应者出于某种原因无法或不愿意克隆IKE SA时，可能存在一些情况。这种能力可能是暂时的，也可能是永久的。
Temporary inability occurs when the responder doesn't have enough resources at the moment to clone an IKE SA or when the IKE SA is being deleted by the responder. In this case, the responder SHOULD reject the request to clone the IKE SA with the TEMPORARY_FAILURE notification.
当响应程序此时没有足够的资源克隆IKE SA或当响应程序正在删除IKE SA时，会发生暂时的无法。在这种情况下，响应者应拒绝克隆IKE SA的请求，并发出临时_失败通知。
<-- HDR, SK {N(TEMPORARY_FAILURE)}
<-- HDR, SK {N(TEMPORARY_FAILURE)}
After receiving this notification, the initiator MAY retry its request after waiting some period of time. See Section 2.25 of [RFC7296] for details.
收到此通知后，启动器可能会在等待一段时间后重试其请求。详见[RFC7296]第2.25节。
In some cases, the responder may have restrictions on the number of coexisting IKE SAs with one peer. These restrictions may be either implicit (some devices may have enough resources to handle only a few IKE SAs) or explicit (provided by some configuration parameter). If the initiator wants to clone more IKE SAs than the responder is able or is configured to handle, the responder SHOULD reject the request with the NO_ADDITIONAL_SAS notification.
在某些情况下，响应者可能对与一个对等方共存的IKE sa的数量有限制。这些限制可能是隐式的（某些设备可能有足够的资源来处理少数IKE SA），也可能是显式的（由某些配置参数提供）。如果发起方希望克隆的IKE SA数量超过响应方所能克隆的数量或配置为可处理的数量，则响应方应拒绝该请求，并发出“无额外的”SAs通知。
<-- HDR, SK {N(NO_ADDITIONAL_SAS)}
<-- HDR, SK {N(NO_ADDITIONAL_SAS)}
This condition is considered permanent and the initiator SHOULD NOT retry cloning an IKE SA until some of the existing SAs with the responder are deleted.
这种情况被认为是永久性的，在删除带有响应程序的某些现有SA之前，发起方不应重试克隆IKE SA。
Figure 4 illustrates the Notify Payload packet format as described in Section 3.10 of [RFC7296]. This format is used for both the CLONE_IKE_SA and the CLONE_IKE_SA_SUPPORTED notifications.
图4说明了[RFC7296]第3.10节所述的Notify Payload数据包格式。此格式用于CLONE_IKE_SA和CLONE_IKE_SA_支持的通知。
The CLONE_IKE_SA_SUPPORTED notification is used in an IKEv2 exchange of type IKE_AUTH and the CLONE_IKE_SA is used in an IKEv2 exchange of type CREATE_CHILD_SA.
支持的克隆IKE SA用于IKE AUTH类型的IKEv2交换，克隆IKE SA用于CREATE CHILD SA类型的IKEv2交换。
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 | SPI Size | 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 | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Notify Payload
图4：通知有效负载
The fields Next Payload, Critical Bit, RESERVED, and Payload Length are defined in [RFC7296]. Specific fields defined in this document are:
[RFC7296]中定义了下一个有效载荷、关键位、保留和有效载荷长度字段。本文档中定义的特定字段包括：
- Protocol ID (1 octet): Set to zero.
- 协议ID（1个八位组）：设置为零。
- Security Parameter Index (SPI) Size (1 octet): Set to zero.
- 安全参数索引（SPI）大小（1个八位字节）：设置为零。
- Notify Message Type (2 octets): Specifies the type of notification message. It is set to 16432 for the CLONE_IKE_SA_SUPPORTED notification or 16433 for the CLONE_IKE_SA notification.
- 通知消息类型（2个八位字节）：指定通知消息的类型。支持克隆的通知设置为16432，支持克隆的通知设置为16433。
IANA has allocated two values in the "IKEv2 Notify Message Types - Status Types" registry:
IANA在“IKEv2通知消息类型-状态类型”注册表中分配了两个值：
Value Notify Messages - Status Types
-----------------------------------------
16432 CLONE_IKE_SA_SUPPORTED
16433 CLONE_IKE_SA
Value Notify Messages - Status Types
-----------------------------------------
16432 CLONE_IKE_SA_SUPPORTED
16433 CLONE_IKE_SA
The protocol defined in this document does not modify IKEv2. Security considerations for cloning an IKE SA are mostly the same as those for the base IKEv2 protocol described in [RFC7296].
本文件中定义的协议不修改IKEv2。克隆IKE SA的安全注意事项与[RFC7296]中描述的基本IKEv2协议的安全注意事项基本相同。
Cloning an IKE SA allows an initiator to duplicate existing SAs. As a result, it may influence any accounting or control mechanisms based on a single IKE SA per authentication.
克隆IKE SA允许启动器复制现有SA。因此，它可能会影响基于每个身份验证的单个IKE SA的任何记帐或控制机制。
Suppose a system has a limit on the number of IKE SAs it can handle. In this case, cloning an IKE SA may provide a way for resource exhaustion, as a single end user may populate multiple IKE SAs.
假设系统可以处理的IKE SA数量有限。在这种情况下，克隆IKE SA可能会导致资源耗尽，因为单个最终用户可能会填充多个IKE SA。
Suppose a system shares the IPsec resources by limiting the number of Child SAs per IKE SA. With a single IKE SA per end user, this provides an equal resource sharing. In this case, cloning the IKE SA provides the means for an end user to overpass this limit. Such a system should evaluate the number of Child SAs over the number of all IKE SAs associated to an end user.
假设系统通过限制每个IKE SA的子SA数量来共享IPsec资源。对于每个最终用户一个IKE SA，这提供了平等的资源共享。在这种情况下，克隆IKE SA为最终用户提供了超越此限制的方法。这样的系统应该评估子SA的数量，而不是与最终用户相关联的所有IKE SA的数量。
Note that these issues are not unique to the ability of cloning the IKE SA, as multiple IKE SAs between two peers may be created without involving a cloning method. Note also that implementation can always limit the number of cloned IKE SAs.
请注意，这些问题并非克隆IKE SA的能力所独有，因为可以在两个对等方之间创建多个IKE SA而不涉及克隆方法。还请注意，实现始终可以限制克隆IKE SA的数量。
Suppose the VPN or any other IPsec-based service monitoring is based on the liveliness of the first IKE SA. Such a system considers a service is accessed or used from the time IKE performs an authentication to the time the IKE SA is deleted. Such accounting methods were fine as any IKE SA required an authentication exchange. As cloning the IKE SA skips the authentication phase, it may make it possible to delete the initial IKE SA while the service is being used on the cloned IKE SA. Such accounting methods should consider that the service is being used from the first IKE SA establishment to until the last IKE SA is removed.
假设VPN或任何其他基于IPsec的服务监控基于第一个IKE SA的活跃度。这样的系统认为从IKE执行身份验证到删除ikesa，服务被访问或使用。这种记帐方法很好，因为任何IKE SA都需要身份验证交换。由于克隆IKE SA跳过了身份验证阶段，因此在克隆的IKE SA上使用服务时，可以删除初始IKE SA。这种会计方法应该考虑到服务是从第一个IKSA SA建立到最后一个IKE SA被移除。
When this solution is used to build load-balancing systems, then there is a necessity to transfer IKE SA states between nodes of a load-sharing cluster. Since IKE SA state contains sensitive information, such as session keys, implementations must take all due precautions. Such precautions might include using technical and/or administrative means to protect IKE SA state data. The details of what is transferred and how it is protected are out of scope of this document.
当此解决方案用于构建负载平衡系统时，就需要在负载共享集群的节点之间传输IKE SA状态。由于IKE SA状态包含敏感信息，如会话密钥，因此实现必须采取所有适当的预防措施。此类预防措施可能包括使用技术和/或管理手段保护IKE SA状态数据。传输内容和保护方式的详细信息不在本文件范围内。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, <http://www.rfc-editor.org/info/rfc4555>.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC 4555，DOI 10.17487/RFC4555，2006年6月<http://www.rfc-editor.org/info/rfc4555>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, <http://www.rfc-editor.org/info/rfc4186>.
[RFC4186]Haverinen，H.，Ed.和J.Salowey，Ed.，“全球移动通信系统（GSM）用户身份模块（EAP-SIM）的可扩展认证协议方法”，RFC 4186，DOI 10.17487/RFC4186，2006年1月<http://www.rfc-editor.org/info/rfc4186>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，DOI 10.17487/RFC5216，2008年3月<http://www.rfc-editor.org/info/rfc5216>.
[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, DOI 10.17487/RFC5685, November 2009, <http://www.rfc-editor.org/info/rfc5685>.
[RFC5685]Devarapalli，V.和K.Weniger，“互联网密钥交换协议版本2（IKEv2）的重定向机制”，RFC 5685，DOI 10.17487/RFC5685，2009年11月<http://www.rfc-editor.org/info/rfc5685>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <http://www.rfc-editor.org/info/rfc5723>.
[RFC5723]Sheffer，Y.和H.Tschofenig，“互联网密钥交换协议版本2（IKEv2）会话恢复”，RFC 5723，DOI 10.17487/RFC5723，2010年1月<http://www.rfc-editor.org/info/rfc5723>.
This section is informational and exposes how a VPN end user, as illustrated in Figure 1, can build two VPNs on its two interfaces without multiple authentications. Other cases represented in Figure 2 and Figure 3 are similar and can be easily derived from this case. The mechanism is based on cloning the IKE SA and the MOBIKE extension [RFC4555].
本节是信息性的，介绍了VPN最终用户（如图1所示）如何在两个接口上构建两个VPN，而无需多次身份验证。图2和图3中所示的其他情况类似，可以很容易地从该情况中派生出来。该机制基于克隆IKE SA和MOBIKE扩展[RFC4555]。
First, the VPN end user negotiates a VPN using one interface. This involves regular IKEv2 exchanges. In addition, the VPN end user and the Security Gateway advertise their support for MOBIKE. At the end of the IKE_AUTH exchange, VPN_0 is set as represented in Figure 5.
首先，VPN最终用户使用一个接口协商VPN。这涉及定期的IKEv2交换。此外，VPN最终用户和安全网关宣传他们对MOBIKE的支持。在IKE_身份验证交换结束时，设置了VPN_0，如图5所示。
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================= | |
| VPN | v | Security |
| End User | ================== Gateway |
| = | |
| | Interface_1 | |
+------------+ +------------+
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================= | |
| VPN | v | Security |
| End User | ================== Gateway |
| = | |
| | Interface_1 | |
+------------+ +------------+
Figure 5: VPN End User Establishing VPN_0
图5:VPN最终用户建立VPN\u 0
The exchanges are completely described in [RFC7296] and [RFC4555]. First, peers negotiate IKE SA parameters and exchange nonces and public keys in the IKE_SA_INIT exchange. In the figure below, they also proceed to NAT detection because of the use of MOBIKE.
[RFC7296]和[RFC4555]中对交换进行了完整描述。首先，对等方协商IKE SA参数，并在IKE_SA_INIT交换中交换nonce和公钥。在下图中，由于使用MOBIKE，他们还继续进行NAT检测。
Initiator Responder
-------------------------------------------------------------------
(IP_I0:500 -> IP_R:500)
HDR, SA, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
Initiator Responder
-------------------------------------------------------------------
(IP_I0:500 -> IP_R:500)
HDR, SA, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R:500 -> IP_I0:500)
HDR, SA, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
<-- (IP_R:500 -> IP_I0:500)
HDR, SA, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
Then the initiator and the responder proceed to the IKE_AUTH exchange, advertise their support for MOBIKE and their ability to clone the IKE SA -- with the MOBIKE_SUPPORTED and the CLONE_IKE_SA_SUPPORTED notifications -- and negotiate the Child SA
然后，发起方和响应方继续进行IKE_身份验证交换，宣传他们对MOBIKE的支持以及克隆IKE SA的能力（支持MOBIKE_和克隆IKE_SA_支持的通知），并协商子SA
for VPN_0. Optionally, the initiator and the responder can advertise their multiple interfaces using the ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications.
对于VPN_0。可选地，发起方和响应方可以使用附加的_-IP4_地址和/或附加的_-IP6_地址通知来公布其多个接口。
(IP_I0:4500 -> IP_R:4500)
HDR, SK {IDi, AUTH,
SA, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_IP*_ADDRESS)+,]
N(CLONE_IKE_SA_SUPPORTED)} -->
(IP_I0:4500 -> IP_R:4500)
HDR, SK {IDi, AUTH,
SA, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_IP*_ADDRESS)+,]
N(CLONE_IKE_SA_SUPPORTED)} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK {IDr, AUTH,
SA, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_IP*_ADDRESS)+,]
N(CLONE_IKE_SA_SUPPORTED)}
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK {IDr, AUTH,
SA, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_IP*_ADDRESS)+,]
N(CLONE_IKE_SA_SUPPORTED)}
In this case, the VPN end user wants to establish an additional VPN with its Interface_1. The VPN end user will first establish a parallel IKE SA using a CREATE_CHILD_SA that concerns an IKE SA rekey associated with a CLONE_IKE_SA notification. This results in two separate IKE SAs between the VPN end user and the Security Gateway. Currently both IKE SAs are set using Interface_0 of the VPN end user.
在这种情况下，VPN最终用户希望通过其接口_1建立额外的VPN。VPN最终用户将首先使用与克隆IKE SA通知相关联的IKE SA密钥相关的CREATE_CHILD_SA建立并行IKE SA。这将导致VPN最终用户和安全网关之间出现两个独立的IKE SA。目前，两个IKE SA都是使用VPN最终用户的接口_0设置的。
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR, SK {N(CLONE_IKE_SA),
SA, Ni, KEi} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK {SA, Nr, KEr}
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR, SK {N(CLONE_IKE_SA),
SA, Ni, KEi} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK {SA, Nr, KEr}
Once the new IKE SA has been created, the VPN end user can initiate a CREATE_CHILD_SA exchange that concerns the creation of a Child SA for VPN_1. The newly created VPN_1 will use Interface_0 of the VPN end user.
一旦创建了新的IKE SA，VPN最终用户就可以启动一个CREATE_CHILD_SA交换，该交换涉及为VPN_1创建子SA。新创建的VPN_1将使用VPN最终用户的接口_0。
It is out of scope for this document to define how the VPN end user handles traffic with multiple interfaces. The VPN end user can use the same inner IP address on its multiple interfaces. In this case, the same Traffic Selectors (that is, the IP address used for VPN_0 and VPN_1) can match for both VPNs VPN_0 and VPN_1. The VPN end user must be aware of such a match and be able to manage it. It can, for
定义VPN最终用户如何使用多个接口处理流量超出了本文档的范围。VPN最终用户可以在其多个接口上使用相同的内部IP地址。在这种情况下，相同的流量选择器（即用于VPN_0和VPN_1的IP地址）可以同时匹配VPN VPN_0和VPN_1。VPN最终用户必须知道这种匹配并能够管理它。它可以，因为
example, use distinct Traffic Selectors on both VPNs using different ports, manage the order of its Security Policy Database (SPD), or have SPD defined per interfaces. Defining these mechanisms is out of scope for this document. Alternatively, the VPN end user can use a different inner IP address for each interface.
例如，在使用不同端口的两个VPN上使用不同的流量选择器，管理其安全策略数据库（SPD）的顺序，或为每个接口定义SPD。定义这些机制超出了本文档的范围。或者，VPN最终用户可以为每个接口使用不同的内部IP地址。
The creation of VPN_1 is performed via the newly created IKE SA as follows:
VPN_1的创建通过新创建的IKE SA执行，如下所示：
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR(new), SK(new) {SA, TSi, TSr} -->
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR(new), SK(new) {SA, TSi, TSr} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR(new), SK(new) {SA, TSi, TSr}
<-- (IP_R:4500 -> IP_I0:4500)
HDR(new), SK(new) {SA, TSi, TSr}
The resulting configuration is depicted in Figure 6. VPN_0 and VPN_1 have been created, but both are using the same Interface: Interface_0.
结果配置如图6所示。已创建VPN_0和VPN_1，但两者使用相同的接口：接口_0。
+------------+ +------------+
| | Interface_0 : VPN_0, VPN_1 | |
| ==================== | |
| VPN ================= v | Security |
| End User | v =============== Gateway |
| | ================== |
| | Interface_1 | |
+------------+ +------------+
+------------+ +------------+
| | Interface_0 : VPN_0, VPN_1 | |
| ==================== | |
| VPN ================= v | Security |
| End User | v =============== Gateway |
| | ================== |
| | Interface_1 | |
+------------+ +------------+
Figure 6: VPN End User Establishing VPN_0 and VPN_1
图6：建立VPN_0和VPN_1的VPN最终用户
In this section, MOBIKE is used to move VPN_1 on Interface_1. The exchange is described in [RFC4555].
在本节中，MOBIKE用于在接口_1上移动VPN_1。[RFC4555]中描述了交换。
(IP_I1:4500 -> IP_R:4500)
HDR(new), SK(new) {N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2)} -->
(IP_I1:4500 -> IP_R:4500)
HDR(new), SK(new) {N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2)} -->
<-- (IP_R:4500 -> IP_I1:4500)
HDR(new), SK(new) {
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2)}
<-- (IP_R:4500 -> IP_I1:4500)
HDR(new), SK(new) {
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2)}
This results in the situation as described in Figure 7.
这将导致图7所示的情况。
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================== | |
| VPN | v | Security |
| End User | ================= Gateway |
| =================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================== | |
| VPN | v | Security |
| End User | ================= Gateway |
| =================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 7: VPN End User with Multiple Interfaces
图7：具有多个接口的VPN最终用户
Acknowledgments
致谢
The ideas for this document came from various input from the IP Security Maintenance and Extensions (ipsecme) Working Group and from discussions with Tero Kivinen and Michael Richardson. Yaron Sheffer and Tero Kivinen provided significant input to set the current design of the protocol, as well as its designation.
本文档的想法来自IP安全维护和扩展（ipsecme）工作组的各种输入以及与Tero Kivinen和Michael Richardson的讨论。Yaron Sheffer和Tero Kivinen为制定当前的协议设计及其命名提供了重要的投入。
Authors' Addresses
作者地址
Daniel Migault (editor) Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada
Daniel Migault（编辑）加拿大QC H4P 2N2蒙特利尔德卡里大道8400号爱立信
Email: daniel.migault@ericsson.com
Email: daniel.migault@ericsson.com
Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation
Valery Smyslov ELVIS-PLUS邮政信箱81莫斯科（Zelenograd）124460俄罗斯联邦
Phone: +7 495 276 0211
Email: svan@elvis.ru
Phone: +7 495 276 0211
Email: svan@elvis.ru