Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 7815 INSIDE Secure
Category: Informational March 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 7815 INSIDE Secure
Category: Informational March 2016
ISSN: 2070-1721
Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
最小Internet密钥交换版本2（IKEv2）启动器实现
Abstract
摘要
This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.
本文档描述了用于受约束节点的Internet密钥交换版本2（IKEv2）协议的最低启动器版本。IKEv2是IPsec的一个组件，用于执行相互身份验证以及建立和维护安全关联（SA）。IKEv2包括几个可选特性，在最小的实现中不需要这些特性。本文档描述了最小实现所需的内容，还描述了可以进行的各种优化。这里描述的协议可以与使用共享秘密身份验证的完整IKEv2实现进行互操作（IKEv2不需要使用证书身份验证）。这个最小的启动器实现只能与作为响应者的完整IKEv2实现对话；因此，两个最小启动器实现不能相互通信。
This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.
本文档不更新或修改RFC 7296，但对协议的最低版本提供了更简洁的描述。如果本文件与RFC 7296冲突，则RFC 7296为权威性说明。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7815.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7815.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 5
2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 12
2.3. Generating Keying Material . . . . . . . . . . . . . . . 12
3. Conformance Requirements . . . . . . . . . . . . . . . . . . 13
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Header and Payload Formats . . . . . . . . . . . . . 17
A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 17
A.2. Generic Payload Header . . . . . . . . . . . . . . . . . 19
A.3. Security Association Payload . . . . . . . . . . . . . . 21
A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 23
A.3.2. Transform Substructure . . . . . . . . . . . . . . . 24
A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 26
A.3.4. Transform Attributes . . . . . . . . . . . . . . . . 26
A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 27
A.5. Identification Payloads . . . . . . . . . . . . . . . . . 27
A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 29
A.7. Certificate Request Payload . . . . . . . . . . . . . . . 30
A.8. Authentication Payload . . . . . . . . . . . . . . . . . 31
A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 31
A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 32
A.10.1. Notify Message Types . . . . . . . . . . . . . . . . 33
A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . 34
A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . 36
A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Useful Optional Features . . . . . . . . . . . . . . 39
B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . 39
B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 40
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 5
2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 12
2.3. Generating Keying Material . . . . . . . . . . . . . . . 12
3. Conformance Requirements . . . . . . . . . . . . . . . . . . 13
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Header and Payload Formats . . . . . . . . . . . . . 17
A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 17
A.2. Generic Payload Header . . . . . . . . . . . . . . . . . 19
A.3. Security Association Payload . . . . . . . . . . . . . . 21
A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 23
A.3.2. Transform Substructure . . . . . . . . . . . . . . . 24
A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 26
A.3.4. Transform Attributes . . . . . . . . . . . . . . . . 26
A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 27
A.5. Identification Payloads . . . . . . . . . . . . . . . . . 27
A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 29
A.7. Certificate Request Payload . . . . . . . . . . . . . . . 30
A.8. Authentication Payload . . . . . . . . . . . . . . . . . 31
A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 31
A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 32
A.10.1. Notify Message Types . . . . . . . . . . . . . . . . 33
A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . 34
A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . 36
A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Useful Optional Features . . . . . . . . . . . . . . 39
B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . 39
B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 40
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources. This document describes a minimal IKEv2 implementation designed for use on such constrained nodes that is interoperable with "Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC7296].
Internet协议套件越来越多地用于电源、内存和处理资源受到严重限制的小型设备上。本文档描述了一个最小的IKEv2实现，该实现设计用于可与“Internet密钥交换协议版本2（IKEv2）”[RFC7296]互操作的受约束节点。
A minimal IKEv2 implementation only supports the initiator end of the protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH exchanges and does not initiate any other exchanges. It also replies with an empty (or error) message to all incoming requests.
最小的IKEv2实现只支持协议的发起端。它只支持初始IKE_SA_INIT和IKE_AUTH交换，不启动任何其他交换。它还会向所有传入的请求回复一条空（或错误）消息。
This means that most of the optional features of IKEv2 are left out: NAT traversal, IKE SA rekey, Child SA rekey, multiple Child SAs, deleting Child / IKE SAs, Configuration payloads, Extensible Authentication Protocol (EAP) authentication, COOKIEs, etc.
这意味着IKEv2的大多数可选功能被忽略了：NAT遍历、IKE SA重新密钥、子SA重新密钥、多个子SA、删除子/IKE SA、配置有效负载、可扩展身份验证协议（EAP）身份验证、cookie等。
Some optimizations can be done because of the limited set of supported features, and this text should not be considered for generic IKEv2 implementations (for example, Message IDs can be done as specified because minimal implementation is only sending out an IKE_SA_INIT and IKE_AUTH request and not any other request).
由于受支持的功能集有限，因此可以进行一些优化，对于一般的IKEv2实现，不应考虑此文本（例如，消息ID可以按指定进行，因为最小实现只发送IKE_SA_INIT和IKE_AUTH请求，而不发送任何其他请求）。
This document is intended to be standalone, meaning everything needed to implement IKEv2 is copied here except the description of the cryptographic algorithms. The IKEv2 specification has lots of background information and rationale that has been omitted from this document.
本文档是独立的，这意味着实现IKEv2所需的一切都复制到这里，除了加密算法的描述。IKEv2规范有大量的背景信息和基本原理，本文件中省略了这些信息。
Numerous additional numeric values from IANA registries have been omitted from this document; only those which are of interest for a minimal implementation are listed.
本文件中省略了IANA注册处的许多附加数值；只列出那些对最小实现感兴趣的内容。
The main body of this document describes how to use the shared secret authentication in IKEv2, as it is easiest to implement. In some cases, that is not enough, and Appendix B.2 describes how to use raw public keys instead of shared secret authentication.
本文的主体部分描述了如何在IKEv2中使用共享秘密身份验证，因为它最容易实现。在某些情况下，这还不够，附录B.2描述了如何使用原始公钥而不是共享秘密身份验证。
For more information, check the full IKEv2 specification in [RFC7296] and [IKEV2IANA].
有关更多信息，请查看[RFC7296]和[IKEV2IANA]中的完整IKEv2规范。
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]. The term "Constrained Node" is defined in "Terminology for Constrained-Node Networks" [RFC7228].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。术语“受限节点”在“受限节点网络术语”[RFC7228]中定义。
One use case for this kind of minimal implementation is in small devices doing machine-to-machine communication. In such environments, the node initiating connections can be very small, and the other end of the communication channel is some kind of larger device.
这种最小实现的一个用例是在进行机器对机器通信的小型设备中。在这种环境中，发起连接的节点可能非常小，而通信信道的另一端是某种较大的设备。
An example of the small initiating node could be a remote garage door opener device, i.e., a device having buttons that open and close a garage door and that connects to the home area network server over a wireless link.
小型发起节点的示例可以是远程车库门开启器设备，即，具有打开和关闭车库门的按钮并且通过无线链路连接到家庭区域网络服务器的设备。
Another example of such a device is some kind of sensor device, for example, a room temperature sensor, which sends periodic temperature data to some centralized node.
此类设备的另一个示例是某种传感器设备，例如，室温传感器，其向某个集中节点发送周期性温度数据。
Those devices usually sleep for a long time and only wake up periodically or because of user interaction. The data transfer is always initiated from that sleeping node when they wake up; after they send packets, there might be ACKs or other packets coming back before they go back to sleep. If some data needs to be transferred from a server node to the small device, it can be implemented by polling, i.e., the small node periodically polls for the server to see if it, for example, has some configuration changes or similar. While the device is sleeping, it will not maintain the IKEv2 SA. That is, it will always create the IKEv2 SA again when it wakes up. This means there is no need to do liveness checks for the server, as after the device wakes up again, the minimal implementation will start from the beginning again.
这些设备通常会长时间睡眠，并且只会周期性地或由于用户交互而醒来。数据传输总是在睡眠节点醒来时从该节点启动；在他们发送数据包之后，可能会有ACK或其他数据包在他们返回睡眠之前返回。如果一些数据需要从服务器节点传输到小型设备，则可以通过轮询来实现，即，小型节点定期轮询服务器，以查看其是否（例如）有一些配置更改或类似更改。当设备处于睡眠状态时，它将不会维护IKEv2 SA。也就是说，它总是在醒来时再次创建IKEv2 SA。这意味着不需要对服务器进行活动性检查，因为在设备再次唤醒后，最小实现将从头开始。
All IKEv2 communications consist of pairs of messages: a request and a response. The pair is called an "exchange" and is sometimes called a "request/response pair". Every request requires a response.
所有IKEv2通信都由成对的消息组成：一个请求和一个响应。该对称为“交换”，有时称为“请求/响应对”。每个请求都需要响应。
For every pair of IKEv2 messages, the initiator is responsible for retransmission in the event of a timeout. The responder MUST never retransmit a response unless it receives a retransmission of the request.
对于每对IKEv2消息，发起方负责在超时情况下重新传输。响应者不得重新传输响应，除非它收到请求的重新传输。
IKEv2 is a reliable protocol: the initiator MUST retransmit a request until it either receives a corresponding response or deems the IKE SA to have failed. A retransmission from the initiator MUST be bitwise
IKEv2是一个可靠的协议：发起方必须重新传输请求，直到收到相应的响应或认为IKE SA失败为止。发起者的重传必须按位进行
identical to the original request. Retransmission times MUST increase exponentially.
与原始请求相同。重传时间必须成倍增加。
IKEv2 is run over UDP port 500. All IKEv2 implementations MUST be able to send, receive, and process IKEv2 messages that are up to 1280 octets long. An implementation MUST accept incoming requests even if the source port is not 500 and MUST respond to the address and port from which the request was received.
IKEv2通过UDP端口500运行。所有IKEv2实现必须能够发送、接收和处理长达1280个八位字节的IKEv2消息。即使源端口不是500，实现也必须接受传入请求，并且必须响应接收请求的地址和端口。
The minimal implementation of IKEv2 only uses the first two exchanges, called IKE_SA_INIT and IKE_AUTH. These are used to create the IKE SA and the first Child SA. In addition to those messages, a minimal IKEv2 implementation needs to understand the CREATE_CHILD_SA request enough to generate a CREATE_CHILD_SA response containing the NO_ADDITIONAL_SAS error notify. It needs to understand the INFORMATIONAL request enough to generate an empty INFORMATIONAL response to it. There is no requirement to be able to respond to any other requests.
IKEv2的最小实现仅使用前两个交换，即IKE_SA_INIT和IKE_AUTH。这些用于创建IKE SA和第一个子SA。除了这些消息之外，最小的IKEv2实现需要充分理解CREATE_CHILD_SA请求，以生成包含NO_附加_SAS错误通知的CREATE_CHILD_SA响应。它需要充分理解信息请求，以生成一个空的信息响应。没有要求能够响应任何其他请求。
All messages following the IKE_SA_INIT exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange.
IKE_SA_INIT交换之后的所有消息都使用IKE_SA_INIT交换中协商的加密算法和密钥进行加密保护。
Every IKEv2 message contains a Message ID as part of its fixed header. This Message ID is used to match up requests and responses and to identify retransmissions of messages.
每个IKEv2消息都包含一个消息ID作为其固定头的一部分。此消息ID用于匹配请求和响应，并标识消息的重新传输。
Minimal implementations only need to support the role of initiator, so it typically only sends an IKE_SA_INIT request that, when answered, is followed by an IKE_AUTH. As those messages have fixed Message IDs (0 and 1), it does not need to keep track of its own Message IDs for outgoing requests after that.
最低限度的实现只需要支持发起方的角色，因此它通常只发送IKE_SA_INIT请求，当该请求得到响应时，后面跟着IKE_AUTH。由于这些消息具有固定的消息ID（0和1），因此它不需要为之后的传出请求跟踪自己的消息ID。
Minimal implementations can also optimize Message ID handling of the incoming requests, as they do not need to protect incoming requests against replays. This is possible because minimal implementations will only return error or empty notification replies to incoming requests. This means that any of those incoming requests do not have any effect on the minimal implementation, thus processing them again does not cause any harm. Because of this, a minimal implementation can always answer a request coming in, with the same Message ID than what the request had, and then forget the request/response pair immediately. This means there is no need to keep track of Message IDs of the incoming requests.
最小的实现还可以优化传入请求的消息ID处理，因为它们不需要保护传入请求不受重播的影响。这是可能的，因为最低限度的实现只会对传入请求返回错误或空通知答复。这意味着这些传入请求中的任何一个都不会对最小实现产生任何影响，因此再次处理它们不会造成任何伤害。因此，一个最小的实现总是可以使用与请求相同的消息ID来回答传入的请求，然后立即忘记请求/响应对。这意味着不需要跟踪传入请求的消息ID。
In the following descriptions, the payloads contained in the message are indicated by the names listed below.
在下面的描述中，消息中包含的有效载荷由下面列出的名称表示。
Notation Payload
-----------------------------------------
AUTH Authentication
CERTREQ Certificate Request
D Delete
HDR IKE header (not a payload)
IDi Identification - Initiator
IDr Identification - Responder
KE Key Exchange
Ni, Nr Nonce
N Notify
SA Security Association
SK Encrypted and Authenticated
TSi Traffic Selector - Initiator
TSr Traffic Selector - Responder
Notation Payload
-----------------------------------------
AUTH Authentication
CERTREQ Certificate Request
D Delete
HDR IKE header (not a payload)
IDi Identification - Initiator
IDr Identification - Responder
KE Key Exchange
Ni, Nr Nonce
N Notify
SA Security Association
SK Encrypted and Authenticated
TSi Traffic Selector - Initiator
TSr Traffic Selector - Responder
The initial exchanges are as follows:
初步交流如下：
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
Flags: Initiator, Message ID=0),
SAi1, KEi, Ni -->
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
Flags: Initiator, Message ID=0),
SAi1, KEi, Ni -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ]
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ]
HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. Each endpoint chooses one of the two SPIs and MUST choose them so as to be unique identifiers of an IKE SA. An SPI value of zero is special: it indicates that the remote SPI value is not yet known by the sender.
HDR包含各种安全参数索引（SPI）、版本号和标志。每个端点选择两个SPI中的一个，并且必须选择它们，以便成为IKE SA的唯一标识符。SPI值为零是特殊的：它表示发送方尚未知道远程SPI值。
Incoming IKEv2 packets are mapped to an IKE SA using only the packet's SPI, not using (for example) the source IP address of the packet.
传入的IKEv2数据包仅使用数据包的SPI映射到IKE SA，而不使用（例如）数据包的源IP地址。
The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE SA. The KEi and KEr payloads contain Diffie-Hellman values, and Ni and Nr are the nonces. The SAr1 contains the chosen cryptographic suite from the initiator's offered choices. A minimal implementation using shared secrets will ignore the CERTREQ payload.
SAi1有效负载说明了启动器支持的IKE SA加密算法。KEi和KEr有效载荷包含Diffie-Hellman值，Ni和Nr为nonce。SAr1包含从启动器提供的选项中选择的加密套件。使用共享机密的最小实现将忽略CERTREQ负载。
Minimal implementation will most likely support exactly one set of cryptographic algorithms, meaning the SAi1 payload will be static. It needs to check that the SAr1 received matches the proposal it sent.
最小实现很可能只支持一组加密算法，这意味着SAi1负载将是静态的。它需要检查收到的SAr1与发送的提案是否匹配。
At this point in the negotiation, each party can generate SKEYSEED, from which all keys are derived for that IKE SA.
在协商的这一点上，每一方都可以生成skeysed，从中派生出该IKE SA的所有密钥。
SKEYSEED = prf(Ni | Nr, g^ir)
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
prf+ (K,S) = T1 | T2 | T3 | T4 | ...
prf+（K，S）=T1 | T2 | T3 | T4 |。。。
where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) ...
式中：T1=prf（K，S | 0x01）T2=prf（K，T1 | S | 0x02）T3=prf（K，T2 | S | 0x03）T4=prf（K，T3 | S | 0x04）。。。
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr are taken in order from the generated bits of the prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman exchange. g^ir is represented as a string of octets in big endian order padded with zeros if necessary to make it the length of the modulus. Ni and Nr are the nonces, stripped of any headers.
（指示量SK_d、SK_ai、SK_ar、SK_ei、SK_er、SK_pi和SK_pr是按顺序从prf+的生成位获取的）。g^ir是短暂的Diffie-Hellman交换的共享秘密。g^ir表示为一个以大端顺序排列的八位字节串，如果需要，用零填充，以使其成为模的长度。Ni和Nr是无任何标题的nonce。
The SK_d is used for deriving new keys for the Child SAs. The SK_ai and SK_ar are used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges. The SK_ei and SK_er are used for encrypting (and of course decrypting) all subsequent exchanges. The SK_pi and SK_pr are used when generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr MUST be the preferred key length of the Pseudorandom Function (PRF) agreed upon.
SK_d用于派生子sa的新密钥。SK_ai和SK_ar用作完整性保护算法的密钥，用于验证后续交换的组件消息。SK_ei和SK_er用于加密（当然还有解密）所有后续交换。生成验证有效负载时使用SK_pi和SK_pr。SK_d、SK_pi和SK_pr的长度必须是商定的伪随机函数（PRF）的首选密钥长度。
A separate SK_e and SK_a is computed for each direction. The keys used to protect messages from the original initiator are SK_ai and SK_ei. The keys used to protect messages in the other direction are SK_ar and SK_er. The notation SK { ... } indicates that these payloads are encrypted and integrity protected using that direction's SK_e and SK_a.
为每个方向计算单独的SK_e和SK_A。用于保护来自原始启动器的消息的密钥是sku ai和sku ei。用于保护另一个方向的消息的键是SK_-ar和SK_-er。符号SK{…}表示使用该方向的SK_e和SK_a对这些有效载荷进行加密和完整性保护。
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, AUTH, SAr2, TSi, TSr}
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, AUTH, SAr2, TSi, TSr}
The initiator asserts its identity with the IDi payload, proves knowledge of the secret corresponding to IDi, and integrity protects the contents of the first message using the AUTH payload. The responder asserts its identity with the IDr payload, authenticates its identity, and protects the integrity of the second message with the AUTH payload.
发起者使用IDi有效载荷声明其身份，证明知道与IDi对应的秘密，并且完整性使用AUTH有效载荷保护第一条消息的内容。响应程序使用IDr有效负载声明其身份，验证其身份，并使用AUTH有效负载保护第二条消息的完整性。
As minimal implementation usually has only one host where it connects, that means it has only one shared secret. This means it does not need to care about the IDr payload that much. If the other end sends an AUTH payload that the initiator can verify using the shared secret it has, then it knows the other end is the peer it was configured to talk to.
由于最小实现通常只有一个连接的主机，这意味着它只有一个共享秘密。这意味着它不需要太在意IDr有效负载。如果另一端发送启动器可以使用其拥有的共享机密验证的身份验证有效负载，则它知道另一端是配置为与之对话的对等方。
In the IKE_AUTH request, the initiator sends the SA offer(s) in the SAi2 payload and the proposed Traffic Selectors (TSs) for the Child SA in the TSi and TSr payloads. The responder replies with the accepted offer in an SAr2 payload and with the selected Traffic Selectors. The selected Traffic Selectors may be a subset of what the initiator proposed.
在IKE_身份验证请求中，发起方发送SAi2有效负载中的SA提供以及TSi和TSr有效负载中的子SA的建议流量选择器（TSs）。响应者使用SAr2有效负载中的已接受报价和所选流量选择器进行回复。所选的业务选择器可以是发起方提议的业务选择器的子集。
In the minimal implementation, both SA payloads and TS payloads are going to be mostly static. The SA payload will have the SPI value used in the Encapsulating Security Payload (ESP), but the algorithms are most likely going to be the one and only supported set. The TS payloads on the initiator end will most likely say from any to any, i.e., full wildcard ranges, or from the local IP to the remote IP. In the wildcard case, the responder quite often narrows the range down to the one IP address pair. Using a single IP address pair as the Traffic Selectors when sending the IKE_AUTH request will simplify processing as the responder will either accept the IP address pair or return an error. If wildcard ranges are used, there is a possibility that the responder will narrow the Traffic Selector range to range that is not acceptable by the initiator.
在最小的实现中，SA有效负载和TS有效负载大部分都是静态的。SA有效负载将具有封装安全有效负载（ESP）中使用的SPI值，但算法很可能是唯一受支持的集。启动器端的TS有效负载很可能是从任意到任意，即，完整的通配符范围，或从本地IP到远程IP。在通配符情况下，响应程序通常会将范围缩小到一个IP地址对。在发送IKE_AUTH请求时使用单个IP地址对作为流量选择器将简化处理，因为响应者将接受IP地址对或返回错误。如果使用通配符范围，则响应者可能会将流量选择器范围缩小到启动器不可接受的范围。
The IKE_AUTH (and IKE_SA_INIT) response may contain multiple status notification payloads that can be ignored by minimal implementations.
IKE_AUTH（和IKE_SA_INIT）响应可能包含多个状态通知有效载荷，这些载荷可以被最小的实现忽略。
There can also be Vendor ID, Certificate, Certificate Request, or Configuration payloads, but any payload unknown to minimal implementations can simply be skipped over (response messages cannot have critical unsupported payloads).
也可以有供应商ID、证书、证书请求或配置有效负载，但可以跳过对最小实现未知的任何有效负载（响应消息不能有关键的不受支持的有效负载）。
The exchange above includes N(INITIAL_CONTACT) notification in the request as that is quite commonly sent by a minimal implementation. It indicates to the other end that the initiator does not have any other IKE SAs between it and the responder, and if there is any left from previous runs, those can be deleted by the responder. As minimal implementations delete IKE SAs without sending IKE SA delete requests, this will help the responder to clean up leftover state.
上面的交换在请求中包括N（初始联系人）通知，因为这通常由最小的实现发送。它向另一端指出，发起程序与响应程序之间没有任何其他IKE SA，如果以前的运行还剩下任何IKE SA，则响应程序可以删除这些IKE SA。由于最小实现在不发送IKE SA delete请求的情况下删除IKE SA，这将有助于响应者清除剩余状态。
When using shared secret authentication, the peers are authenticated by having each calculating a Message Authentication Code (MAC) over a block of data:
使用共享秘密身份验证时，通过让每个对等方在数据块上计算消息身份验证码（MAC）来对对等方进行身份验证：
For the initiator:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<InitiatorSignedOctets>)
For the responder:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<ResponderSignedOctets>)
For the initiator:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<InitiatorSignedOctets>)
For the responder:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<ResponderSignedOctets>)
The string "Key Pad for IKEv2" is 17 ASCII characters without null termination. The implementation can precalculate the inner prf and only store the output of it. This is possible because a minimal IKEv2 implementation usually only supports one PRF.
字符串“IKEv2的键盘”为17个ASCII字符，无空终止。该实现可以预先计算内部prf，并且只存储其输出。这是可能的，因为最小的IKEv2实现通常只支持一个PRF。
In the following calculations, IDi' and IDr' are the entire ID payloads excluding the fixed header, and the Ni and Nr are only the values, not the payloads containing it. Note that neither the nonce Ni/Nr nor the value prf(SK_pr, IDr')/prf(SK_pi, IDi') are transmitted.
在以下计算中，IDi'和IDr'是不包括固定标头的整个ID有效载荷，Ni和Nr只是值，而不是包含它的有效载荷。注意，当前Ni/Nr和值prf（SK_pr，IDr'）/prf（SK_pi，IDi'）都不被传输。
The initiator signs the first message (IKE_SA_INIT request), starting with the first octet of the first SPI in the header and ending with the last octet of the last payload in that first message. Appended to this (for purposes of computing the signature) are the responder's nonce Nr and the value prf(SK_pi, IDi').
发起者对第一条消息（IKE_SA_INIT request）进行签名，从报头中第一个SPI的第一个八位组开始，以该第一条消息中最后一个有效负载的最后一个八位组结束。在此之后（为了计算签名的目的）附加了响应者的nonce Nr和值prf（SK_pi，IDi'）。
For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message (IKE_SA_INIT response) and end with the last octet of the last payload in that second message. Appended to this are the initiator's nonce Ni and the value prf(SK_pr, IDr').
对于响应者，要签名的八位字节以第二条消息（IKE_SA_INIT response）头部中第一个SPI的第一个八位字节开始，并以该第二条消息中最后一个有效负载的最后一个八位字节结束。在此之后附加了启动器的nonce Ni和值prf（SK_pr，IDr'）。
The initiator's signed octets can be described as:
启动器的签名八位字节可以描述为：
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
Initiator SignedOctets=realmessage 1 | NonceRData | MACedIDForI RealIKEHDR=SPIi | SPIr |……|长度RealMessage1=RealIKEHDR | RestOfMessage1 NONCERDAYLOAD=PayloadHeader | NonceRData INITORIDPAYLOAD=PayloadHeader | RestOfInitIDPayload=IDType | RETED | InitIDData MACedIDForI=prf（SK|pi，RestOfInitIDPayload）
The responder's signed octets can be described as:
响应者的签名八位字节可以描述为：
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfRespIDPayload RestOfRespIDPayload = IDType | RESERVED | RespIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
ResponderSignedocets=RealMessage2 | NonceIData | MACedIDForR RealIKEHDR=SPIi | SPIr |……|长度RealMessage2=RealIKEHDR | RestOfMessage2 NonceIPayload=PayloadHeader | NonceIData ResponderIDPayload=PayloadHeader | restofRestofRepedPayload=IDType | restofRepedPayload=prf（SK|pr，restofRepedPayload）
Note that all of the payloads inside the RestOfMessageX are included under the signature, including any payload types not listed in this document.
请注意，RestOfMessageX中的所有有效负载都包含在签名下，包括本文档中未列出的任何有效负载类型。
The initiator might also get an unauthenticated response back that has a notification payload with an error code inside. As that error code will be unauthenticated and may be faked, there is no need to do anything for those. A minimal implementation can simply ignore those errors and retransmit its request until it times out, and if that happens, then the IKE SA (and Child SA) creation failed.
发起方还可能获得未经验证的响应，该响应包含一个包含错误代码的通知负载。由于该错误代码将是未经验证的，并且可能是伪造的，因此无需对这些错误代码执行任何操作。一个最小的实现可以简单地忽略这些错误并重新传输其请求，直到超时为止，如果超时，那么IKE SA（和子SA）创建失败。
The responder might also reply with an IKE_AUTH response packet that does not contain the payloads needed to set up a Child SA (SAr2, TSi, and TSr) but instead contain AUTH payload and an error. Minimal implementation that does not support the CREATE_CHILD_SA exchange cannot recover from this scenario. It can delete the IKE SA and start over from the beginning (which might fail again if this is a configuration error, or it might succeed if this was temporal failure).
响应者还可以使用IKE_AUTH响应数据包进行响应，该数据包不包含设置子SA（SAr2、TSi和TSr）所需的有效负载，而是包含AUTH有效负载和错误。不支持CREATE_CHILD_SA交换的最小实现无法从此场景中恢复。它可以删除IKE SA并从头开始（如果这是配置错误，则可能再次失败；如果这是暂时失败，则可能成功）。
Minimal implementations MUST be able to reply to INFORMATIONAL requests by sending back an empty INFORMATIONAL response:
最低限度的实现必须能够通过发送回空的信息性响应来回复信息性请求：
Minimal implementation Other end
-------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: none, Message ID=m),
SK {...}
Minimal implementation Other end
-------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: none, Message ID=m),
SK {...}
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator | Response,
Message ID=m),
SK {} -->
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator | Response,
Message ID=m),
SK {} -->
Minimal implementations MUST be able to reply to incoming CREATE_CHILD_SA requests. A typical implementation will reject the CREATE_CHILD_SA exchanges by sending a NO_ADDITIONAL_SAS error notify back:
最低限度的实现必须能够响应传入的CREATE_CHILD_SA请求。一个典型的实现将通过发送一个NO_ADDITIONAL_SAS错误通知来拒绝CREATE_CHILD_SA交换：
Minimal implementation Other end
-------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA,
Flags: none, Message ID=m),
SK {...}
Minimal implementation Other end
-------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA,
Flags: none, Message ID=m),
SK {...}
HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA,
Flags: Initiator | Response, Message ID=m),
SK {N(NO_ADDITIONAL_SAS)} -->
HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA,
Flags: Initiator | Response, Message ID=m),
SK {N(NO_ADDITIONAL_SAS)} -->
Note that INFORMATIONAL and CREATE_CHILD_SA requests might contain unsupported critical payloads, in which case a compliant implementation MUST ignore the request and send a response message back that has the UNSUPPORTED_CRITICAL_PAYLOAD notification. That notification payload data contains a 1-octet payload type of the unsupported critical payload.
请注意，信息性和CREATE_CHILD_SA请求可能包含不受支持的关键有效负载，在这种情况下，兼容的实现必须忽略该请求，并发送一条包含不受支持的关键有效负载通知的响应消息。该通知有效负载数据包含不受支持的关键有效负载的1-octet有效负载类型。
The keying material for the Child SA created by the IKE_AUTH exchange is generated as follows:
IKE_AUTH exchange创建的子SA的键控材质生成如下：
KEYMAT = prf+(SK_d, Ni | Nr)
KEYMAT=prf+（SK|d，Ni|Nr）
Where Ni and Nr are the nonces from the IKE_SA_INIT exchange.
其中Ni和Nr是来自IKE_SA_INIT交换的nonce。
A single CHILD_SA negotiation may result in multiple Security Associations. ESP and Authentication Header (AH) SAs exist in pairs (one in each direction), so two SAs are created in a single Child SA negotiation for them. The keying material for each Child SA MUST be taken from the expanded KEYMAT using the following rules:
单个子_SA协商可能导致多个安全关联。ESP和身份验证头（AH）SA成对存在（每个方向一个），因此在一个子SA协商中为它们创建两个SA。每个子SA的键控材料必须使用以下规则从扩展的键盘垫中获取：
o All keys for SAs carrying data from the initiator to the responder are taken before SAs going from the responder to the initiator.
o 将数据从发起方传送到响应方的SAs的所有密钥在SAs从响应方传送到发起方之前获取。
o If an IPsec protocol requires multiple keys, the order in which they are taken from the SA's keying material needs to be described in the protocol's specification. For ESP and AH, [IPSECARCH] defines the order, namely: the encryption key (if any) MUST be taken from the first bits, and the integrity key (if any) MUST be taken from the remaining bits.
o 如果IPsec协议需要多个密钥，则需要在协议规范中描述从SA的密钥材料中获取密钥的顺序。对于ESP和AH，[IPSECARCH]定义了顺序，即：加密密钥（如果有）必须从第一位获取，完整性密钥（如果有）必须从其余位获取。
Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm or negotiated in SA payloads.
每个加密算法都采用固定数量的密钥材料位，这些密钥材料被指定为算法的一部分或在SA有效负载中协商。
For an implementation to be called conforming to the RFC 7296 specification, it MUST be possible to configure it to accept the following:
要调用符合RFC 7296规范的实现，必须能够将其配置为接受以下内容：
o Public Key Infrastructure using X.509 (PKIX) Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN.
o 使用X.509（PKIX）证书的公钥基础设施，该证书包含大小为1024或2048位的RSA密钥并由其签名，其中传递的ID为ID_Key_ID、ID_FQDN、ID_RFC822_ADDR或ID_DER_ASN1_DN中的任意一个。
o Shared key authentication where the ID passed is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR.
o 共享密钥身份验证，其中传递的ID是ID_key_ID、ID_FQDN或ID_RFC822_ADDR中的任意一个。
o Authentication where the responder is authenticated using PKIX Certificates, and the initiator is authenticated using shared key authentication.
o 身份验证，其中使用PKIX证书对响应者进行身份验证，使用共享密钥身份验证对启动器进行身份验证。
This document only supports the second bullet; it does not support PKIX Certificates at all. As full RFC 7296 responders must also support that shared key authentication, this allows a minimal implementation to be able to interoperate with all implementations that are compliant with RFC 7296.
本文件仅支持第二个项目符号；它根本不支持PKIX证书。由于完整的RFC 7296响应程序还必须支持共享密钥身份验证，这使得最小的实现能够与符合RFC 7296的所有实现进行互操作。
PKIX Certificates are left out from the minimal implementation as those would add quite a lot of complexity to the implementation. The actual code changes needed in the IKEv2 protocol are small, but the certificate validation code would be more complex than the whole
PKIX证书被排除在最小实现之外，因为这些证书会给实现增加相当多的复杂性。IKEv2协议中需要的实际代码更改很小，但是证书验证代码比整个协议更复杂
minimal IKEv2 implementation itself. If public-key-based authentication is needed for scalability reasons, then raw public keys would probably be the best compromise (see Appendix B.2).
最小的IKEv2实现本身。如果出于可伸缩性的原因需要基于公钥的身份验证，那么原始公钥可能是最佳折衷方案（见附录B.2）。
This document describes a minimal implementation written by the author of this document. The minimal implementation supported the base IKE_SA_INIT and IKE_AUTH exchanges and successfully interoperated with a full IKEv2 server. This minimal implementation was presented in the Interconnecting Smart Objects with Internet Workshop in Prague in March 2011 [Kiv11]. This implementation was written as proof of concept in perl.
本文档描述了本文档作者编写的一个最小实现。最小的实现支持基本IKE_SA_INIT和IKE_AUTH交换，并成功地与完整的IKEv2服务器互操作。2011年3月在布拉格举行的智能对象与互联网互联研讨会上介绍了这一最低限度的实现[Kiv11]。这个实现是用perl编写的概念证明。
There was another proof-of-concept implementation written in python, which also interoperated with a full IKEv2 server.
还有另一个用python编写的概念验证实现，它也可以与完整的IKEv2服务器进行互操作。
Both implementations were written just for demonstration purposes and included fixed configuration built into the code, and both also implemented ESP, ICMP, and IP layers to the level that was needed to send and receive one ICMP echo packet. Both implementations were about 1000 lines of code excluding cryptographic libraries but including ESP, ICMP, and IP layers.
这两个实现都是为了演示而编写的，并且在代码中包含了固定的配置，并且都实现了ESP、ICMP和IP层，达到了发送和接收一个ICMP回显数据包所需的级别。这两种实现大约有1000行代码，不包括加密库，但包括ESP、ICMP和IP层。
As this implements the same protocol as RFC 7296, this means all security considerations from it also apply to this document.
由于它实现了与RFC 7296相同的协议，这意味着它的所有安全注意事项也适用于本文档。
[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>.
[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>.
[EAI] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <http://www.rfc-editor.org/info/rfc6532>.
[EAI]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件标题”，RFC 6532，DOI 10.17487/RFC6532，2012年2月<http://www.rfc-editor.org/info/rfc6532>.
[IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[IDNA]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<http://www.rfc-editor.org/info/rfc5890>.
[IKEV2IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters>.
[IKEV2IANA]IANA，“互联网密钥交换版本2（IKEv2）参数”<http://www.iana.org/assignments/ikev2-parameters>.
[IPSEARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[IPSEARCH]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[Kiv11] Kivinen, T., "Interconnecting Smart Objects with Internet Workshop 2011-03025; IKEv2 and Smart Objects", March 2011, <https://www.iab.org/wp-content/IAB-uploads/2011/04/ Kivinen.pdf>.
[Kiv11]Kivinen，T.“智能对象与互联网互联研讨会2011-03025；IKEv2与智能对象”，2011年3月<https://www.iab.org/wp-content/IAB-uploads/2011/04/ Kivinen.pdf>。
[MODES] National Institute of Standards and Technology, U.S. Department of Commerce, "Recommendation for Block Cipher Modes of Operation", SP 800-38A, 2001.
[模式]美国商务部国家标准与技术研究所，“分组密码操作模式建议”，SP 800-38A，2001年。
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[PKCS1]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，DOI 10.17487/RFC3447，2003年2月<http://www.rfc-editor.org/info/rfc3447>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <http://www.rfc-editor.org/info/rfc7619>.
[RFC7619]Smyslov，V.和P.Wouters，“互联网密钥交换协议版本2（IKEv2）中的空身份验证方法”，RFC 7619，DOI 10.17487/RFC7619，2015年8月<http://www.rfc-editor.org/info/rfc7619>.
[RFC7670] Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw Public-Key Support for IKEv2", RFC 7670, DOI 10.17487/RFC7670, January 2016, <http://www.rfc-editor.org/info/rfc7670>.
[RFC7670]Kivinen，T.，Wouters，P.，和H.Tschofenig，“IKEv2的通用原始公钥支持”，RFC 7670，DOI 10.17487/RFC7670，2016年1月<http://www.rfc-editor.org/info/rfc7670>.
This appendix describes actual packet payload formats. This is required to make the document self-contained. The descriptions are mostly copied from RFC 7296, and more information can be found from there.
本附录描述了实际的数据包有效负载格式。这是使文档自包含所必需的。这些描述大部分是从RFC 7296复制的，更多信息可以从那里找到。
Various payloads contain RESERVED fields, and those MUST be sent as zero and MUST be ignored on receipt.
各种有效载荷包含保留字段，这些字段必须作为零发送，并且在收到时必须忽略。
All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first" or "network byte order").
所有表示整数的多个八位字节字段均按大端顺序排列（也称为“最高有效字节优先”或“网络字节顺序”）。
Each IKEv2 message begins with the IKE header, denoted HDR in this document. Following the header are one or more IKE payloads each identified by a Next Payload field in the preceding payload. Payloads are identified in the order in which they appear in an IKE message by looking in the Next Payload field in the IKE header and, subsequently, according to the Next Payload field in the IKE payload itself until a Next Payload field of zero indicates that no payloads follow. If a payload of type "Encrypted" is found, that payload is decrypted and its contents parsed as additional payloads. An Encrypted payload MUST be the last payload in a packet, and an Encrypted payload MUST NOT contain another Encrypted payload.
每个IKEv2消息都以IKE头开始，在本文档中表示为HDR。在报头之后是一个或多个IKE有效载荷，每个有效载荷由前一有效载荷中的下一有效载荷字段标识。通过查看IKE报头中的下一个有效载荷字段，然后根据IKE有效载荷本身中的下一个有效载荷字段，按照它们在IKE消息中出现的顺序来识别有效载荷，直到下一个有效载荷字段为零表示没有有效载荷跟随。如果找到“加密”类型的有效负载，则该有效负载将被解密，其内容将被解析为附加有效负载。加密的有效负载必须是数据包中的最后一个有效负载，并且加密的有效负载不得包含另一个加密的有效负载。
The format of the IKE header is shown in Figure 1.
IKE头的格式如图1所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Initiator's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Responder's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | MjVer | MnVer | Exchange Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Initiator's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Responder's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | MjVer | MnVer | Exchange Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IKE Header Format
图1:IKE头格式
o Initiator's SPI (8 octets) - A value chosen by the initiator to identify a unique IKE Security Association. This value MUST NOT be zero.
o 发起者的SPI（8个八位字节）-发起者选择用于标识唯一IKE安全关联的值。此值不能为零。
o Responder's SPI (8 octets) - A value chosen by the responder to identify a unique IKE Security Association. This value MUST be zero in the first message of an IKE initial exchange.
o 响应者的SPI（8个八位字节）-响应者选择的一个值，用于标识唯一的IKE安全关联。在IKE初始交换的第一条消息中，此值必须为零。
o Next Payload (1 octet) - Indicates the type of payload that immediately follows the header. The format and value of each payload are defined below.
o 下一个有效负载（1个八位字节）-指示紧跟在报头之后的有效负载类型。每个有效载荷的格式和值定义如下。
o Major Version (4 bits) - Indicates the major version of the IKE protocol in use. Implementations based on this version of IKE MUST set the major version to 2 and MUST drop the messages with a higher major version number.
o 主要版本（4位）-表示正在使用的IKE协议的主要版本。基于此版本的IKE的实现必须将主版本设置为2，并且必须删除具有更高主版本号的消息。
o Minor Version (4 bits) - Indicates the minor version of the IKE protocol in use. Implementations based on this version of IKE MUST set the minor version to zero. They MUST ignore the minor version number of received messages.
o 次要版本（4位）-表示正在使用的IKE协议的次要版本。基于此版本的IKE的实现必须将次要版本设置为零。他们必须忽略收到的消息的次要版本号。
o Exchange Type (1 octet) - Indicates the type of exchange being used. This constrains the payloads sent in each message in an exchange.
o 交换类型（1个八位字节）-表示正在使用的交换类型。这将限制在exchange中的每条消息中发送的有效负载。
Exchange Type Value
----------------------------------
IKE_SA_INIT 34
IKE_AUTH 35
CREATE_CHILD_SA 36
INFORMATIONAL 37
Exchange Type Value
----------------------------------
IKE_SA_INIT 34
IKE_AUTH 35
CREATE_CHILD_SA 36
INFORMATIONAL 37
o Flags (1 octet) - Indicates specific options that are set for the message. Presence of options is indicated by the appropriate bit in the flags field being set. The bits are as follows:
o 标志（1个八位字节）-表示为消息设置的特定选项。选项的存在由正在设置的标志字段中的相应位表示。位如下所示：
+-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+
In the description below, a bit being 'set' means its value is '1', while 'cleared' means its value is '0'. 'X' bits MUST be cleared when sending and MUST be ignored on receipt.
在下面的描述中，“设置”表示其值为“1”，而“清除”表示其值为“0”发送时必须清除X'位，接收时必须忽略X'位。
* R (Response) - This bit indicates that this message is a response to a message containing the same Message ID. This bit MUST be cleared in all request messages and MUST be set in all responses. An IKEv2 endpoint MUST NOT generate a response to a message that is marked as being a response.
* R（响应）-此位表示此消息是对包含相同消息ID的消息的响应。此位必须在所有请求消息中清除，并且必须在所有响应中设置。IKEv2端点不得对标记为响应的消息生成响应。
* V (Version) - This bit indicates that the transmitter is capable of speaking a higher major version number of the protocol than the one indicated in the Major Version field. Implementations of IKEv2 MUST clear this bit when sending and MUST ignore it in incoming messages.
* V（版本）-此位表示变送器能够说出比主版本字段中指示的更高的协议主版本号。IKEv2的实现在发送时必须清除该位，并且在传入消息中必须忽略该位。
* I (Initiator) - This bit MUST be set in messages sent by the original initiator of the IKE SA and MUST be cleared in messages sent by the original responder. It is used by the recipient to determine which 8 octets of the SPI were generated by the recipient. This bit changes to reflect who initiated the last rekey of the IKE SA.
* I（发起方）-此位必须在IKE SA的原始发起方发送的消息中设置，并且必须在原始响应方发送的消息中清除。接收方使用它来确定接收方生成的SPI的8个八位字节。此位更改以反映谁发起了IKE SA的最后一次重新密钥。
o Message ID (4 octets, unsigned integer) - Message identifier used to control retransmission of lost packets and matching of requests and responses. It is essential to the security of the protocol because it is used to prevent message replay attacks.
o 消息ID（4个八位字节，无符号整数）—用于控制丢失数据包的重新传输以及请求和响应的匹配的消息标识符。它对协议的安全性至关重要，因为它用于防止消息重放攻击。
o Length (4 octets, unsigned integer) - Length of the total message (header + payloads) in octets.
o 长度（4个八位字节，无符号整数）-以八位字节为单位的总消息长度（头+有效负载）。
Each IKE payload begins with a generic payload header, as shown in Figure 2. Figures for each payload below will include the generic payload header, but for brevity, the description of each field will be omitted.
每个IKE负载都以一个通用负载头开始，如图2所示。下面每个有效载荷的图将包括通用有效载荷标题，但为简洁起见，将省略每个字段的描述。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generic Payload Header
图2：通用有效负载头
The Generic Payload Header fields are defined as follows:
通用有效负载标头字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. This field provides a "chaining" capability whereby additional payloads can be added to a message by appending each one to the end of the message and setting the Next Payload field of the preceding payload to indicate the new payload's type. An Encrypted payload, which must always be the last payload of a message, is an exception. It contains data structures in the format of additional payloads. In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload (instead of zero); conversely, the Next Payload field of the last contained payload is set to zero). The payload type values needed for minimal implementations are listed here.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为零。此字段提供“链接”功能，通过将每个有效负载追加到消息末尾，并设置前一有效负载的下一个有效负载字段以指示新有效负载的类型，可以向消息添加其他有效负载。加密的有效负载（必须始终是消息的最后一个有效负载）是一个例外。它包含附加有效载荷格式的数据结构。在加密有效载荷的报头中，下一有效载荷字段被设置为第一个包含的有效载荷的有效载荷类型（而不是零）；相反，最后包含的有效负载的下一个有效负载字段设置为零）。这里列出了最小实现所需的有效负载类型值。
Next Payload Type Notation Value
--------------------------------------------------
No Next Payload 0
Security Association SA 33
Key Exchange KE 34
Identification - Initiator IDi 35
Identification - Responder IDr 36
Certificate CERT 37
Certificate Request CERTREQ 38
Authentication AUTH 39
Nonce Ni, Nr 40
Notify N 41
Delete D 42
Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45
Encrypted and Authenticated SK 46
Next Payload Type Notation Value
--------------------------------------------------
No Next Payload 0
Security Association SA 33
Key Exchange KE 34
Identification - Initiator IDi 35
Identification - Responder IDr 36
Certificate CERT 37
Certificate Request CERTREQ 38
Authentication AUTH 39
Nonce Ni, Nr 40
Notify N 41
Delete D 42
Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45
Encrypted and Authenticated SK 46
o Critical (1 bit) - MUST be set to zero if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. MUST be set to 1 if the sender wants the recipient to reject this entire message if it does not understand the payload type. MUST be ignored by the recipient if the recipient understands the payload type code. MUST be set to zero for payload types defined in this document. Note that the critical bit applies to the current payload rather than the "next" payload whose type code appears in the first octet.
o 临界（1位）-如果发送方不理解上一个有效负载的下一个有效负载字段中的有效负载类型代码，则发送方希望接收方跳过此有效负载，则必须将临界（1位）设置为零。如果发件人希望收件人在不了解有效负载类型的情况下拒绝整个邮件，则必须将设置为1。如果收件人理解有效负载类型代码，则收件人必须忽略此项。对于本文档中定义的有效负载类型，必须将设置为零。请注意，关键位适用于当前有效负载，而不是类型代码出现在第一个八位字节中的“下一个”有效负载。
o Payload Length (2 octets, unsigned integer) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节，无符号整数）—当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
The Security Association payload, denoted SA in this document, is used to negotiate attributes of a Security Association.
安全关联有效负载（在本文档中表示为SA）用于协商安全关联的属性。
An SA payload consists of one or more proposals. Each proposal includes one protocol. Each protocol contains one or more transforms -- each specifying a cryptographic algorithm. Each transform contains zero or more attributes (attributes are needed only if the Transform ID does not completely specify the cryptographic algorithm; currently, the only attribute is the Key Length attribute for variable-length ciphers, meaning there is exactly zero or one attribute).
SA有效负载由一个或多个方案组成。每项提案包括一项议定书。每个协议都包含一个或多个转换——每个转换指定一个加密算法。每个转换包含零个或多个属性（仅当转换ID未完全指定加密算法时才需要属性；当前，唯一的属性是可变长度密码的密钥长度属性，这意味着只有零个或一个属性）。
The responder MUST choose a single suite, which may be any subset of the SA proposal following the rules below.
响应者必须选择单个套件，可以是SA提案的任何子集，遵循以下规则。
Each proposal contains one protocol. If a proposal is accepted, the SA response MUST contain the same protocol. Each IPsec protocol proposal contains one or more transforms. Each transform contains a Transform Type. The accepted cryptographic suite MUST contain exactly one transform of each type included in the proposal. For example: if an ESP proposal includes transforms ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six combinations are acceptable.
每项提案包含一项议定书。如果提案被接受，SA响应必须包含相同的协议。每个IPsec协议提案都包含一个或多个转换。每个变换都包含一个变换类型。接受的加密套件必须仅包含提案中包含的每种类型的一个转换。例如：如果ESP方案包括转换ENCR_3DES、ENCR_AES w/keysize 128、ENCR_AES w/keysize 256、AUTH_HMAC_MD5和AUTH_HMAC_SHA，则接受的套件必须包含一个ENCR_转换和一个AUTH_转换。因此，可以接受六种组合。
Minimal implementation can create very simple SA proposal, i.e., include one proposal, which contains exactly one transform for each Transform Type. It is important to only include one Diffie-Hellman group in the proposal, so there is no need to do INVALID_KE_PAYLOAD processing in responses.
最小的实现可以创建非常简单的SA方案，即包括一个方案，其中每个变换类型只包含一个变换。建议中只包含一个Diffie-Hellman组很重要，因此无需在响应中执行无效的负载处理。
When parsing an SA, an implementation MUST check that the total Payload Length is consistent with the payload's internal lengths and counts. Proposals, Transforms, and Attributes each have their own variable-length encodings. They are nested such that the Payload Length of an SA includes the combined contents of the SA, Proposal, Transform, and Attribute information. The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains.
解析SA时，实现必须检查总负载长度是否与负载的内部长度和计数一致。建议、转换和属性都有自己的可变长度编码。它们是嵌套的，因此SA的有效负载长度包括SA、建议、转换和属性信息的组合内容。提案的长度包括其包含的所有变换和属性的长度。变换的长度包括其包含的所有属性的长度。
Each Proposal/Protocol structure is followed by one or more transform structures. The number of different transforms is generally determined by the Protocol. AH generally has two transforms: Extended Sequence Numbers (ESNs) and an integrity check algorithm.
每个提案/协议结构后面都有一个或多个转换结构。不同转换的数量通常由协议决定。AH通常有两种转换：扩展序列号（ESN）和完整性检查算法。
ESP generally has three: ESN, an encryption algorithm, and an integrity check algorithm. IKEv2 generally has four transforms: a Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, and an encryption algorithm. For each Protocol, the set of permissible transforms is assigned Transform ID numbers, which appear in the header of each transform.
ESP通常有三种：ESN、加密算法和完整性检查算法。IKEv2通常有四种转换：Diffie-Hellman组、完整性检查算法、PRF算法和加密算法。对于每个协议，为允许的转换集分配转换ID号，该编号显示在每个转换的标题中。
If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple transforms with different Transform Types, the proposal is an AND of the different groups.
如果有多个变换具有相同的变换类型，则建议是这些变换的OR。如果存在具有不同变换类型的多个变换，则建议是不同组的AND。
A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm, and the attribute would specify the key size. To propose alternate values for an attribute (for example, multiple key sizes for the AES encryption algorithm), an implementation MUST include multiple transforms with the same Transform Type each with a single Attribute.
给定的变换可能有一个或多个属性。当转换可以以多种方式使用时，属性是必需的，例如当加密算法具有可变密钥大小时。转换将指定算法，属性将指定密钥大小。要为属性提出备选值（例如，AES加密算法的多个密钥大小），实现必须包括具有相同变换类型的多个变换，每个变换具有单个属性。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Proposals> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Proposals> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Security Association Payload
图3：安全关联负载
o Proposals (variable) - One or more proposal substructures.
o 方案（可变）-一个或多个方案子结构。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 2 | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Transforms> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 2 | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Transforms> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proposal Substructure
图4：提案子结构
o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the last Proposal Substructure in the SA.
o 0（最后一个）或2（更多）（1个八位组）-指定这是否是SA中的最后一个提案子结构。
o Proposal Length (2 octets, unsigned integer) - Length of this proposal, including all transforms and attributes that follow.
o 建议长度（2个八位字节，无符号整数）-此建议的长度，包括所有后续转换和属性。
o Proposal Num (1 octet) - When a proposal is made, the first proposal in an SA payload MUST be 1, and subsequent proposals MUST be one more than the previous proposal. When a proposal is accepted, the proposal number in the SA payload MUST match the number on the proposal sent that was accepted.
o 提案编号（1个八位字节）-提出提案时，SA有效负载中的第一个提案必须为1，后续提案必须比前一个提案多一个。接受提案时，SA有效负载中的提案编号必须与已接受的已发送提案上的编号相匹配。
o Protocol ID (1 octet) - Specifies the IPsec protocol identifier for the current negotiation.
o 协议ID（1个八位字节）-指定当前协商的IPsec协议标识符。
Protocol Protocol ID
-----------------------------------
IKE 1
AH 2
ESP 3
Protocol Protocol ID
-----------------------------------
IKE 1
AH 2
ESP 3
o SPI Size (1 octet) - For an initial IKE SA negotiation, this field MUST be zero; the SPI is obtained from the outer header. During subsequent negotiations, it is equal to the size, in octets, of the SPI of the corresponding protocol (8 for IKE and 4 for ESP and AH).
o SPI大小（1个八位字节）-对于初始IKE SA协商，此字段必须为零；SPI从外部收割台获取。在随后的协商过程中，它等于相应协议的SPI的大小（八位字节）（8表示IKE，4表示ESP和AH）。
o Num Transforms (1 octet) - Specifies the number of transforms in this proposal.
o Num Transforms（1个八位字节）-指定此方案中的转换数。
o SPI (variable) - The sending entity's SPI. When the SPI Size field is zero, this field is not present in the Security Association payload.
o SPI（变量）-发送实体的SPI。当SPI大小字段为零时，安全关联有效负载中不存在此字段。
o Transforms (variable) - One or more transform substructures.
o 变换（变量）-一个或多个变换子结构。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Transform Substructure
图5：变换子结构
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal.
o 0（最后一个）或3（更多）（1个八位组）-指定这是否是提案中的最后一个变换子结构。
o Transform Length - The length (in octets) of the Transform Substructure including Header and Attributes.
o 变换长度-变换子结构的长度（以八位字节为单位），包括标题和属性。
o Transform Type (1 octet) - The type of transform being specified in this transform. Different protocols support different Transform Types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. If the initiator wishes to make use of the transform optional to the responder, it includes a transform substructure with Transform ID = 0 as one of the options.
o 变换类型（1个八位字节）-在此变换中指定的变换类型。不同的协议支持不同的转换类型。对于某些协议，某些转换可能是可选的。如果转换是可选的，并且发起人希望建议省略该转换，则建议中不包括给定类型的转换。如果发起者希望使用响应者可选的转换，它将包含一个转换子结构，其中转换ID=0作为选项之一。
o Transform ID (2 octets) - The specific instance of the Transform Type being proposed.
o Transform ID（2个八位字节）-提出的转换类型的特定实例。
The relevant Transform Type values are listed below. For more information see [RFC7296].
下面列出了相关的变换类型值。有关更多信息，请参阅[RFC7296]。
Description Trans. Used In
Type
------------------------------------------------------------------
Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudorandom Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP
Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP
Description Trans. Used In
Type
------------------------------------------------------------------
Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudorandom Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP
Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP
For Transform Type 1 (Encryption Algorithm), the relevant Transform IDs are listed below.
对于转换类型1（加密算法），下面列出了相关的转换ID。
Name Number
---------------------------
ENCR_AES_CBC 12
ENCR_AES-CCM_8 14
Name Number
---------------------------
ENCR_AES_CBC 12
ENCR_AES-CCM_8 14
For Transform Type 2 (Pseudorandom Function), the relevant Transform IDs are listed below.
对于变换类型2（伪随机函数），下面列出了相关的变换ID。
Name Number
----------------------------------
PRF_HMAC_SHA1 2
Name Number
----------------------------------
PRF_HMAC_SHA1 2
For Transform Type 3 (Integrity Algorithm), the relevant Transform IDs are listed below.
对于转换类型3（完整性算法），下面列出了相关的转换ID。
Name Number
---------------------------
AUTH_HMAC_SHA1_96 2
AUTH_AES_XCBC_96 5
Name Number
---------------------------
AUTH_HMAC_SHA1_96 2
AUTH_AES_XCBC_96 5
For Transform Type 4 (Diffie-Hellman group), the relevant Transform IDs are listed below.
对于转换类型4（Diffie-Hellman组），下面列出了相关的转换ID。
Name Number
-------------------------
1536-bit MODP 5
2048-bit MODP 14
Name Number
-------------------------
1536-bit MODP 5
2048-bit MODP 14
For Transform Type 5 (Extended Sequence Numbers), the relevant Transform IDs are listed below.
对于转换类型5（扩展序列号），下面列出了相关的转换ID。
Name Number
--------------------------------------------
No Extended Sequence Numbers 0
Extended Sequence Numbers 1
Name Number
--------------------------------------------
No Extended Sequence Numbers 0
Extended Sequence Numbers 1
Note that an initiator who supports ESNs will usually include two ESN transforms, with values "0" and "1", in its proposals. A proposal containing a single ESN transform with value "1" means that using normal (non-extended) sequence numbers is not acceptable.
请注意，支持ESN的发起人通常会在其提案中包含两个ESN转换，其值为“0”和“1”。包含值为“1”的单个ESN转换的提案意味着使用正常（非扩展）序列号是不可接受的。
The number and type of transforms that accompany an SA payload are dependent on the protocol in the SA itself. An SA payload proposing the establishment of an SA has the following mandatory and optional Transform Types. A compliant implementation MUST understand all mandatory and optional types for each protocol it supports (though it need not accept proposals with unacceptable suites). A proposal MAY omit the optional types if the only value for them it will accept is NONE.
SA有效负载附带的转换的数量和类型取决于SA本身中的协议。建议建立SA的SA有效负载具有以下强制和可选转换类型。兼容实现必须了解其支持的每个协议的所有强制和可选类型（尽管它不需要接受带有不可接受套件的提案）。如果建议书接受的唯一值为“无”，则建议书可能会忽略可选类型。
Protocol Mandatory Types Optional Types
---------------------------------------------------
IKE ENCR, PRF, INTEG, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H
Protocol Mandatory Types Optional Types
---------------------------------------------------
IKE ENCR, PRF, INTEG, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H
Transform Type 1 (Encryption Algorithm) transforms might include one transform attribute: Key Length.
转换类型1（加密算法）转换可能包括一个转换属性：密钥长度。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Attribute Type | Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Attribute Type | Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Data Attributes
图6：数据属性
o Attribute Type (15 bits) - Unique identifier for each type of attribute (see below).
o 属性类型（15位）-每种类型属性的唯一标识符（见下文）。
o Attribute Value - Value of the attribute associated with the attribute type.
o Attribute Value—与属性类型关联的属性的值。
Attribute Type Value
----------------------------
Key Length (in bits) 14
Attribute Type Value
----------------------------
Key Length (in bits) 14
The Key Length attribute specifies the key length in bits (MUST use network byte order) for certain transforms as follows:
Key Length属性指定某些转换的密钥长度（以位为单位）（必须使用网络字节顺序），如下所示：
o The Key Length attribute MUST NOT be used with transforms that use a fixed-length key.
o “关键点长度”属性不得与使用固定长度关键点的变换一起使用。
o Some transforms specify that the Key Length attribute MUST be always included. For example, ENCR_AES_CBC.
o 某些转换指定必须始终包含“键长度”属性。例如，ENCR_AES_CBC。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Key Exchange Payload Format
图7：密钥交换有效负载格式
A Key Exchange payload is constructed by copying one's Diffie-Hellman public value into the "Key Exchange Data" portion of the payload. The length of the Diffie-Hellman public value for modular exponentiation groups (MODPs) MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary.
密钥交换有效负载是通过将Diffie-Hellman公共值复制到有效负载的“密钥交换数据”部分来构建的。模幂运算组（MODP）的Diffie-Hellman公共值的长度必须等于在其上执行幂运算的素数模的长度，如有必要，将零位前置到该值。
The Diffie-Hellman Group Num identifies the Diffie-Hellman group in which the Key Exchange Data was computed. This Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified in a proposal in the SA payload that is sent in the same message.
Diffie-Hellman组Num标识在其中计算密钥交换数据的Diffie-Hellman组。此Diffie-Hellman组编号必须与在同一消息中发送的SA有效负载中的提案中指定的Diffie-Hellman组匹配。
The Identification payloads, denoted IDi and IDr in this document, allow peers to assert an identity to one another. When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets or anything in the TSi/TSr payloads. The contents
标识有效载荷（在本文档中表示为IDi和IDr）允许对等方彼此声明身份。在IDi/IDr有效载荷中使用ID_IPV4_ADDR/ID_IPV6_ADDR标识类型时，IKEv2不要求此地址与IKEv2数据包的IP头中的地址或TSi/TSr有效载荷中的任何内容匹配。内容
of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. In minimal implementation, it might be easiest to always use KEY_ID type. This allows the ID payload to be static. Using an IP address has problems in environments where IP addresses are dynamically allocated.
IDi/IDr的属性仅用于获取与另一方相关的策略和身份验证数据。在最小的实现中，可能最容易始终使用KEY_ID类型。这允许ID有效负载是静态的。在动态分配IP地址的环境中，使用IP地址会出现问题。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Identification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Identification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Identification Payload Format
图8：识别有效载荷格式
o ID Type (1 octet) - Specifies the type of Identification being used.
o ID类型（1个八位字节）-指定正在使用的标识类型。
o Identification Data (variable length) - Value, as indicated by the Identification Type. The length of the Identification Data is computed from the size in the ID payload header.
o 标识数据（可变长度）-由标识类型指示的值。识别数据的长度是根据ID有效负载报头中的大小计算的。
The following table lists the assigned semantics for the Identification Type field.
下表列出了标识类型字段的指定语义。
ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.
ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.
ID_FQDN 2 A fully qualified domain name string. An example of an ID_FQDN is "example.com". The string MUST NOT contain any terminators (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an "internationalized domain name", the syntax is as defined in [IDNA], for example, "xn--tmonesimerkki-bfbb.example.net".
ID_FQDN 2是完全限定的域名字符串。ID_FQDN的一个示例是“example.com”。字符串不得包含任何终止符（例如NULL、CR等）。ID_FQDN中的所有字符均为ASCII；对于“国际化域名”，语法如[IDNA]中所定义，例如，“xn--tmonesimerkki bfbb.example.net”。
ID_RFC822_ADDR 3 A fully qualified RFC 822 email address string based [RFC5322]. An example of an ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT contain any terminators. Because of [EAI], implementations would be wise to treat this field as UTF-8-encoded text, not as pure ASCII.
ID \u RFC822 \u ADDR 3基于[RFC5322]的完全限定的RFC 822电子邮件地址字符串。ID_RFC822_ADDR的一个示例是“jsmith@example.com". 字符串不能包含任何终止符。由于[EAI]，实现将明智地将此字段视为UTF-8编码的文本，而不是纯ASCII。
ID_IPV6_ADDR 5 A single sixteen (16) octet IPv6 address.
ID_IPV6_ADDR 5单个十六（16）个八位字节的IPV6地址。
ID_KEY_ID 11 An opaque octet stream that may be used to pass vendor-specific information necessary to do certain proprietary types of identification. Minimal implementation might use this type to send out a serial number or similar device-specific unique static Identification Data for the device.
ID_KEY_ID 11一种不透明的八位字节流，可用于传递进行某些专有类型识别所需的供应商特定信息。最小实现可能使用此类型为设备发送序列号或类似特定于设备的唯一静态标识数据。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certificate Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certificate Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Certificate Payload Format
图9：证书有效负载格式
o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field.
o 证书编码（1个八位字节）-此字段指示证书数据字段中包含的证书类型或证书相关信息。
Certificate Encoding Value
----------------------------------------------------
X.509 Certificate - Signature 4
Raw Public Key 15
Certificate Encoding Value
----------------------------------------------------
X.509 Certificate - Signature 4
Raw Public Key 15
o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field.
o 证书数据（可变长度）-证书数据的实际编码。证书的类型由证书编码字段指示。
The syntax of the types above are:
上述类型的语法为：
o "X.509 Certificate - Signature" contains a DER-encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload.
o “X.509证书-签名”包含DER编码的X.509证书，其公钥用于验证发送方的身份验证有效负载。请注意，使用这种编码，如果需要发送证书链，则会使用多个证书有效载荷，其中只有第一个证书有效载荷保存用于验证发送者的身份验证有效载荷的公钥。
o "Raw Public Key" contains a raw public key. In essence, the Certificate Payload contains the SubjectPublicKeyInfo part of the PKIX Certificate (see Section 4.1.2.7 of [RFC5280]). This is a quite simple ASN.1 object that contains mostly static parts before the actual public key values. See [RFC7670] for more information.
o “原始公钥”包含原始公钥。本质上，证书有效负载包含PKIX证书的SubjectPublicKeyInfo部分（参见[RFC5280]第4.1.2.7节）。这是一个非常简单的ASN.1对象，它包含实际公钥值之前的大部分静态部分。有关更多信息，请参阅[RFC7670]。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certification Authority (CA) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certification Authority (CA) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Certificate Request Payload Format
图10：证书请求有效负载格式
o Certificate Encoding (1 octet) - Contains an encoding of the type or format of certificate requested.
o 证书编码（1个八位字节）-包含请求的证书类型或格式的编码。
o Certification Authority (variable length) - Contains an encoding of an acceptable certification authority for the type of certificate requested.
o 证书颁发机构（可变长度）-包含所请求证书类型的可接受证书颁发机构的编码。
The Certificate Encoding field has the same values as those defined by the certificate payload. The Certification Authority field contains an indicator of trusted authorities for this certificate type. The Certification Authority value is a concatenated list of SHA-1 hashes of the public keys of trusted Certification Authorities. Each is encoded as the SHA-1 hash of the Subject Public Key Info element (see Section 4.1.2.7 of [RFC5280]) from each Trust Anchor certificate. The 20-octet hashes are concatenated and included with no other formatting.
证书编码字段的值与证书有效负载定义的值相同。证书颁发机构字段包含此证书类型的受信任机构的指示器。证书颁发机构值是可信证书颁发机构公钥的SHA-1哈希的串联列表。每个都被编码为来自每个信任锚证书的主题公钥信息元素（参见[RFC5280]第4.1.2.7节）的SHA-1散列。20个八位字节的散列是串联的，不包含其他格式。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Authentication Payload Format
图11：验证有效负载格式
o Auth Method (1 octet) - Specifies the method of authentication used.
o Auth Method（1个八位字节）-指定使用的身份验证方法。
Mechanism Value
-----------------------------------------------------------------
RSA Digital Signature 1
Using an RSA private key with an RSASSA-PKCS1-v1_5 signature
scheme specified in [PKCS1]; see Section 2.15 of [RFC7296] for
details.
Mechanism Value
-----------------------------------------------------------------
RSA Digital Signature 1
Using an RSA private key with an RSASSA-PKCS1-v1_5 signature
scheme specified in [PKCS1]; see Section 2.15 of [RFC7296] for
details.
Shared Key Message Integrity Code 2 Computed as specified earlier using the shared key associated with the identity in the ID payload and the negotiated PRF.
共享密钥消息完整性代码2，使用与ID有效负载和协商PRF中的标识相关联的共享密钥，按照前面的指定计算。
o Authentication Data (variable length) - see Section 2.1.
o 认证数据（可变长度）-见第2.1节。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Nonce Payload Format
图12:Nonce有效负载格式
o Nonce Data (variable length) - Contains the random data generated by the transmitting entity.
o Nonce数据（可变长度）-包含传输实体生成的随机数据。
The size of the Nonce Data MUST be between 16 and 256 octets, inclusive. Nonce values MUST NOT be reused.
Nonce数据的大小必须介于16到256个八位字节之间（包括16到256个八位字节）。不得重复使用Nonce值。
The Notify payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request.
通知有效负载（在本文档中表示为N）用于向IKE对等方传输信息数据，如错误条件和状态转换。通知有效负载可能出现在响应消息（通常指定拒绝请求的原因）、信息交换（报告错误而不是IKE请求）或任何其他消息中，以指示发送方的能力或修改请求的含义。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Notify Payload Format
图13：通知有效负载格式
o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt.
o 协议ID（1个八位字节）-如果此通知涉及SPI字段中给出SPI的现有SA，则此字段指示该SA的类型。如果SPI字段为空，则此字段必须作为零发送，并且在收到时必须忽略。
o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the SPI field must be empty.
o SPI大小（1个八位字节）-由IPsec协议ID定义的SPI的八位字节长度，如果没有适用的SPI，则为零。对于有关IKE SA的通知，SPI大小必须为零，SPI字段必须为空。
o Notify Message Type (2 octets) - Specifies the type of notification message.
o 通知消息类型（2个八位字节）-指定通知消息的类型。
o SPI (variable length) - Security Parameter Index.
o SPI（可变长度）-安全参数索引。
o Notification Data (variable length) - Status or error data transmitted in addition to the Notify Message Type. Values for this field are type specific.
o 通知数据（可变长度）-除通知消息类型外发送的状态或错误数据。此字段的值是特定于类型的。
Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process.
通知信息可以是错误消息，指定无法建立SA的原因。它也可以是管理SA数据库的进程希望与对等进程通信的状态数据。
Types in the range 0 - 16383 are intended for reporting errors. An implementation receiving a Notify payload with one of these types that it does not recognize in a response MUST assume that the corresponding request has failed entirely. Unrecognized error types in a request and status types in a request or response MUST be ignored, and they should be logged.
范围为0-16383的类型用于报告错误。接收到Notify有效负载的实现在响应中无法识别其中一种类型的有效负载时，必须假定相应的请求已完全失败。必须忽略请求中无法识别的错误类型以及请求或响应中的状态类型，并记录它们。
Notify payloads with status types MAY be added to any message and MUST be ignored if not recognized. They are intended to indicate capabilities and, as part of SA negotiation, are used to negotiate non-cryptographic parameters.
具有状态类型的Notify payloads可添加到任何消息中，如果无法识别，则必须忽略。它们用于指示功能，并且作为SA协商的一部分，用于协商非加密参数。
NOTIFY messages: error types Value
-------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1
Indicates that the 1-octet payload type included in the
Notification Data field is unknown.
NOTIFY messages: error types Value
-------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1
Indicates that the 1-octet payload type included in the
Notification Data field is unknown.
INVALID_SYNTAX 7 Indicates the IKE message that was received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons. To avoid a Denial-of-Service (DoS) attack using forged messages, this status may only be returned for and in an encrypted packet if the Message ID and cryptographic checksum were valid. To avoid leaking information to someone probing a node, this status MUST be sent in response to any error not covered by one of the other status types. To aid debugging, more detailed error information should be written to a console or log.
INVALID_SYNTAX 7表示接收到的IKE消息无效，因为某些类型、长度或值超出范围，或者由于策略原因请求被拒绝。为了避免使用伪造消息的拒绝服务（DoS）攻击，只有在消息ID和加密校验和有效的情况下，才能在加密数据包中返回此状态。为了避免向探测节点的人泄漏信息，必须发送此状态以响应其他状态类型之一未包含的任何错误。为了帮助调试，应将更详细的错误信息写入控制台或日志。
NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. This can be sent in any case where the offered proposals are not acceptable for the responder.
没有选择任何方案14提议的加密套件都不可接受。如果响应者不接受所提供的建议书，则可以发送此信息。
NO_ADDITIONAL_SAS 35 Specifies that the node is unwilling to accept any more Child SAs.
NO_ADDITIONAL_SAS 35指定节点不愿意接受更多子SA。
NOTIFY messages: status types Value
-------------------------------------------------------------------
INITIAL_CONTACT 16384
Asserts that this IKE SA is the only IKE SA currently active
between the authenticated identities.
NOTIFY messages: status types Value
-------------------------------------------------------------------
INITIAL_CONTACT 16384
Asserts that this IKE SA is the only IKE SA currently active
between the authenticated identities.
Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their Security Policy Database (SPD) to their peers. TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA.
流量选择器（TS）有效负载允许端点将一些信息从其安全策略数据库（SPD）传递给其对等方。TS有效负载指定将通过新设置的SA转发的数据包的选择标准。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Traffic Selectors> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Traffic Selectors> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Traffic Selectors Payload Format
图14：流量选择器有效负载格式
o Number of TSs (1 octet) - Number of Traffic Selectors being provided.
o TSs数量（1个八位字节）-提供的流量选择器数量。
o Traffic Selectors (variable length) - One or more individual Traffic Selectors.
o 流量选择器（可变长度）-一个或多个单独的流量选择器。
The length of the Traffic Selector payload includes the TS header and all the Traffic Selectors.
流量选择器有效负载的长度包括TS报头和所有流量选择器。
There is no requirement that TSi and TSr contain the same number of individual Traffic Selectors. Thus, they are interpreted as follows: a packet matches a given TSi/TSr if it matches at least one of the individual selectors in TSi and at least one of the individual selectors in TSr.
没有要求TSi和TSr包含相同数量的单个流量选择器。因此，它们被解释为：如果数据包匹配TSi中的至少一个单独选择器和TSr中的至少一个单独选择器，则它匹配给定TSi/TSr。
Two TS payloads appear in each of the messages in the exchange that creates a Child SA pair. Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID.
两个TS有效负载出现在创建子SA对的exchange中的每条消息中。每个TS有效负载包含一个或多个流量选择器。每个流量选择器由地址范围（IPv4或IPv6）、端口范围和IP协议ID组成。
The first of the two TS payloads is known as TSi (Traffic Selector - initiator). The second is known as TSr (Traffic Selector - responder). TSi specifies the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the Child SA pair. TSr specifies the destination address of the traffic forwarded to (or the source address of the traffic forwarded from) the responder of the Child SA pair.
两个TS有效负载中的第一个称为TSi（流量选择器-启动器）。第二种称为TSr（流量选择器-响应器）。TSi指定从子SA对的启动器转发的流量的源地址（或转发到子SA对的流量的目标地址）。TSr指定转发到子SA对的响应者的通信量的目标地址（或转发自子SA对的通信量的源地址）。
IKEv2 allows the responder to choose a subset of the traffic proposed by the initiator.
IKEv2允许响应者选择发起者提议的通信量的子集。
When the responder chooses a subset of the traffic proposed by the initiator, it narrows the Traffic Selectors to some subset of the initiator's proposal (provided the set does not become the null set). If the type of Traffic Selector proposed is unknown, the responder ignores that Traffic Selector, so that the unknown type is not returned in the narrowed set.
当响应者选择发起者建议的流量子集时，它会将流量选择器缩小到发起者建议的某个子集（前提是该集合不会变为空集合）。如果建议的流量选择器类型未知，响应者将忽略该流量选择器，以便在缩小的集合中不返回未知类型。
To enable the responder to choose the appropriate range, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request. If the initiator creates the Child SA pair not in response to an arriving packet, but rather, say, upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr can be ranges rather than specific values.
为了使响应者能够选择适当的范围，如果启动器由于数据包而请求SA，则启动器应在每个TSi和TSr中包括一个非常特定的流量选择器，作为第一个流量选择器，该流量选择器包括触发请求的包中的地址。如果启动器创建子SA对不是响应到达的数据包，而是（比如）在启动时创建，则启动器可能不喜欢初始隧道的特定地址。在这种情况下，TSi和TSr中的第一个值可以是范围，而不是特定值。
As minimal implementations might only support one SA, the Traffic Selectors will usually be from the initiator's IP address to the responder's IP address (i.e., no port or protocol selectors and only one range).
由于最低限度的实现可能只支持一个SA，流量选择器通常从启动器的IP地址到响应者的IP地址（即，没有端口或协议选择器，只有一个范围）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type |IP Protocol ID | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port | End Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Starting Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ending Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type |IP Protocol ID | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port | End Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Starting Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ending Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Traffic Selector
图15：流量选择器
o TS Type (1 octet) - Specifies the type of Traffic Selector.
o TS类型（1个八位字节）-指定流量选择器的类型。
o IP protocol ID (1 octet) - Value specifying an associated IP protocol ID (such as UDP, TCP, and ICMP). A value of zero means that the protocol ID is not relevant to this Traffic Selector -- the SA can carry all protocols.
o IP协议ID（1个八位字节）-指定关联IP协议ID（如UDP、TCP和ICMP）的值。值为零表示协议ID与此流量选择器无关——SA可以承载所有协议。
o Selector Length - Specifies the length of this Traffic Selector substructure including the header.
o 选择器长度-指定此流量选择器子结构（包括标题）的长度。
o Start Port (2 octets, unsigned integer) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be zero.
o 起始端口（2个八位字节，无符号整数）—指定此流量选择器允许的最小端口号的值。对于端口未定义的协议（包括协议0），或者如果允许所有端口，则此字段必须为零。
o End Port (2 octets, unsigned integer) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be 65535.
o End Port（2个八位字节，无符号整数）—指定此流量选择器允许的最大端口号的值。对于端口未定义的协议（包括协议0），或者如果允许所有端口，则此字段必须为65535。
o Starting Address - The smallest address included in this Traffic Selector (length determined by TS Type).
o 起始地址-此流量选择器中包含的最小地址（长度由TS类型决定）。
o Ending Address - The largest address included in this Traffic Selector (length determined by TS Type).
o 结束地址-此流量选择器中包含的最大地址（长度由TS类型决定）。
The following table lists values for the Traffic Selector Type field and the corresponding Address Selector Data.
下表列出了“交通选择器类型”字段的值和相应的地址选择器数据。
TS Type Value
-------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two 4-octet
values. The first value is the beginning IPv4 address
(inclusive), and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.
TS Type Value
-------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two 4-octet
values. The first value is the beginning IPv4 address
(inclusive), and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.
TS_IPV6_ADDR_RANGE 8 A range of IPv6 addresses, represented by two 16-octet values. The first value is the beginning IPv6 address (inclusive), and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.
TS_IPV6_ADDR_RANGE 8一个IPV6地址范围，由两个16八位字节值表示。第一个值是起始IPv6地址（含），第二个值是结束IPv6地址（含）。两个指定地址之间的所有地址都被视为在列表中。
The Encrypted payload, denoted as SK{...} in this document, contains other payloads in encrypted form.
加密的有效载荷，在本文档中表示为SK{…}，包含其他加密形式的有效载荷。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (length is block size for the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (length is block size for the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Encrypted Payload Format
图16：加密有效负载格式
o Next Payload - The payload type of the first embedded payload. Note that this is an exception in the standard header format, since the Encrypted payload is the last payload in the message; therefore, the Next Payload field would normally be zero. But because the content of this payload is embedded payloads and there was no natural place to put the type of the first one, that type is placed here.
o 下一个有效负载-第一个嵌入有效负载的有效负载类型。注意，这是标准报头格式中的一个例外，因为加密的有效负载是消息中的最后一个有效负载；因此，下一个有效载荷字段通常为零。但是因为这个有效载荷的内容是嵌入的有效载荷，并且没有放置第一个有效载荷类型的自然位置，所以这个类型被放置在这里。
o Payload Length - Includes the lengths of the header, initialization vector (IV), Encrypted IKE payloads, Padding, Pad Length, and Integrity Checksum Data.
o 有效负载长度-包括标头的长度、初始化向量（IV）、加密的IKE有效负载、填充、焊盘长度和完整性校验和数据。
o Initialization Vector - For Cipher Block Chaining (CBC) mode ciphers, the length of the initialization vector (IV) is equal to the block length of the underlying encryption algorithm. Senders MUST select a new unpredictable IV for every message; recipients MUST accept any value. The reader is encouraged to consult [MODES] for advice on IV generation. In particular, using the final ciphertext block of the previous message is not considered unpredictable. For modes other than CBC, the IV format and processing is specified in the document specifying the encryption algorithm and mode.
o 初始化向量-对于密码块链接（CBC）模式密码，初始化向量（IV）的长度等于基础加密算法的块长度。发件人必须为每封邮件选择一个新邮件；收件人必须接受任何值。鼓励读者参考[MODES]以获得有关IV生成的建议。特别是，使用前一条消息的最后一个密文块并不被认为是不可预测的。对于CBC以外的模式，IV格式和处理在指定加密算法和模式的文档中指定。
o IKE payloads are as specified earlier in this section. This field is encrypted with the negotiated cipher.
o IKE有效载荷如本节前面所述。此字段使用协商密码加密。
o Padding MAY contain any value chosen by the sender and MUST have a length that makes the combination of the payloads, the Padding, and the Pad Length to be a multiple of the encryption block size. This field is encrypted with the negotiated cipher.
o 填充可以包含发送方选择的任何值，并且必须具有使有效负载、填充和填充长度的组合为加密块大小的倍数的长度。此字段使用协商密码加密。
o Pad Length is the length of the Padding field. The sender SHOULD set the Pad Length to the minimum value that makes the combination of the payloads, the Padding, and the Pad Length a multiple of the block size, but the recipient MUST accept any length that results in proper alignment. This field is encrypted with the negotiated cipher.
o Pad Length是填充字段的长度。发送方应将焊盘长度设置为使有效载荷、焊盘和焊盘长度的组合为块大小的倍数的最小值，但接收方必须接受导致正确对齐的任何长度。此字段使用协商密码加密。
o Integrity Checksum Data is the cryptographic checksum of the entire message starting with the Fixed IKE header through the Pad Length. The checksum MUST be computed over the encrypted message. Its length is determined by the integrity algorithm negotiated.
o 完整性校验和数据是整个消息的加密校验和，从固定IKE头开始，一直到Pad长度。必须对加密消息计算校验和。其长度由协商的完整性算法决定。
There are some optional features of IKEv2, which might be useful for minimal implementations in some scenarios. Such features include raw public keys authentication and sending an IKE SA delete notification.
IKEv2有一些可选的特性，在某些场景中，这些特性对于最小的实现可能很有用。这些特性包括原始公钥身份验证和发送IKE SA删除通知。
In some scenarios, a minimal implementation device creates an IKE SA, sends one or few packets, perhaps gets some packets back, and then the device goes back to sleep, forgetting the IKE SA. In such scenarios, it would be nice for the minimal implementation to send the IKE SA delete notification to tell the other end that the IKE SA is going away, so it can free the resources.
在某些场景中，一个最小实现设备创建一个IKE SA，发送一个或几个数据包，可能返回一些数据包，然后设备返回睡眠状态，忘记IKE SA。在这种情况下，最好让最小的实现发送IKE SA delete通知，告诉另一端IKE SA正在离开，这样它就可以释放资源。
Deleting the IKE SA can be done by sending one packet with a fixed Message ID and with only one payload inside the Encrypted payload. The other end will send back an empty response:
删除IKE SA可以通过发送一个具有固定消息ID且在加密有效负载内只有一个有效负载的数据包来完成。另一端将发回一个空响应：
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator, Message ID=2),
SK {D} -->
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator, Message ID=2),
SK {D} -->
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Response, Message ID=2),
SK {}
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Response, Message ID=2),
SK {}
The Delete payload format is:
删除有效负载格式为：
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 | Num of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index(es) (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Num of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index(es) (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Delete Payload Format
图17：删除有效负载格式
o Protocol ID (1 octet) - Must be 1 for an IKE SA.
o 协议ID（1个八位组）-对于IKE SA必须为1。
o SPI Size (1 octet) - Length in octets of the SPI as defined by the protocol ID. It MUST be zero for IKE (SPI is in the message header).
o SPI大小（1个八位字节）-协议ID定义的SPI的八位字节长度。IKE的长度必须为零（SPI在消息头中）。
o Num of SPIs (2 octets, unsigned integer) - The number of SPIs contained in the Delete payload. This MUST be zero for IKE.
o SPI数（2个八位字节，无符号整数）—删除有效负载中包含的SPI数。对于IKE，该值必须为零。
o Security Parameter Index(es) (variable length) - Identifies the specific Security Association(s) to delete. The length of this field is determined by the SPI Size and Num of SPIs fields. This field is empty for the IKE SA delete.
o 安全参数索引（可变长度）-标识要删除的特定安全关联。此字段的长度由SPI大小和SPI字段数决定。对于IKE SA delete，此字段为空。
In some scenarios, the shared secret authentication is not safe enough, as anybody who knows the secret can impersonate the server. If the shared secret is printed on the side of the device, then anybody who gets physical access to the device can read it. In such environments, public key authentication allows stronger authentication with minimal operational overhead. Certificate support is quite complex, and minimal implementations do not usually have need for them. Using Raw Public Keys is much simpler, and it scales similar to certificates. The fingerprint of the raw public key can still be distributed by, for example, printing it on the side of the device allowing setup similar to using a shared secret.
在某些情况下，共享秘密身份验证不够安全，因为任何知道该秘密的人都可以模拟服务器。如果共享机密打印在设备的侧面，那么任何物理访问设备的人都可以读取它。在这样的环境中，公钥身份验证允许以最小的操作开销进行更强的身份验证。证书支持是相当复杂的，最小的实现通常不需要它们。使用原始公钥要简单得多，而且它的伸缩性类似于证书。原始公钥的指纹仍然可以通过（例如）在允许类似于使用共享密钥的设置的设备一侧打印来分发。
Raw public keys can also be used in a "leap of faith" or baby duck style initial setup, where the device imprints itself to the first device it sees when it boots up the first time. After that initial connection, it stores the fingerprint of the Raw Public Key of the server in its own configuration and verifies that it never changes (unless a "reset to factory settings" or similar command is issued).
原始公钥也可用于“信仰的飞跃”或雏鸭式初始设置，即设备在第一次启动时会将自身印在第一台设备上。在初始连接之后，它将服务器的原始公钥指纹存储在自己的配置中，并验证它不会更改（除非发出“重置为出厂设置”或类似命令）。
This changes the initial IKE_AUTH payloads as follows:
这将更改初始IKE_AUTH有效载荷，如下所示：
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, CERT, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, CERT, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, CERT, AUTH, SAr2, TSi, TSr}
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, CERT, AUTH, SAr2, TSi, TSr}
The CERT payloads contain the raw public keys used to sign the hash of the InitiatorSignedOctects/ResponderSignedOctects when generating an AUTH payload. Minimal implementations should use SHA-1 as the hash function as that is the "SHOULD" support algorithm specified in RFC 7296, so it is the most likely one that is supported by all devices.
证书有效载荷包含原始公钥，用于在生成AUTH有效载荷时对Initiator SignedActs/ResponderSignedActs的哈希进行签名。最小的实现应该使用SHA-1作为散列函数，因为这是RFC 7296中指定的“应该”支持算法，所以它很可能是所有设备都支持的算法。
Note that RFC 7296 already obsoleted the old Raw RSA Key method, and "Generic Raw Public-Key Support for IKEv2" [RFC7670] adds a new format to allow using any types of raw public keys with IKEv2. This document only specifies how to use the new format.
请注意，RFC 7296已经淘汰了旧的原始RSA密钥方法，“IKEv2的通用原始公钥支持”[RFC7670]添加了一种新格式，允许在IKEv2中使用任何类型的原始公钥。本文档仅指定如何使用新格式。
In these setups, it might be possible that authenticating the server is not needed at all. If a minimal device is sending, for example, sensor information to the server, the server wants to verify that the sensor is who it claims to be using raw public keys, but the sensor does not really care who the server is. In such cases, the NULL authentication method [RFC7619] would be useful, as it allows devices to do one-way authentication.
在这些设置中，可能根本不需要对服务器进行身份验证。例如，如果最小设备正在向服务器发送传感器信息，则服务器希望验证传感器是否为其声称使用原始公钥的传感器，但传感器并不真正关心服务器是谁。在这种情况下，空身份验证方法[RFC7619]将非常有用，因为它允许设备进行单向身份验证。
Acknowledgements
致谢
Most of the content of this document is copied from RFC 7296.
本文件的大部分内容是从RFC 7296复制的。
Author's Address
作者地址
Tero Kivinen INSIDE Secure Eerikinkatu 28 HELSINKI FI-00180 FINLAND
Tero Kivinen INSIDE Kinkatu 28赫尔辛基FI-00180芬兰
Email: kivinen@iki.fi
Email: kivinen@iki.fi