Network Working Group C. Kaufman, Ed.
Request for Comments: 4306 Microsoft
Obsoletes: 2407, 2408, 2409 December 2005
Category: Standards Track
Network Working Group C. Kaufman, Ed.
Request for Comments: 4306 Microsoft
Obsoletes: 2407, 2408, 2409 December 2005
Category: Standards Track
Internet Key Exchange (IKEv2) Protocol
因特网密钥交换（IKEv2）协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).
本文档描述了Internet密钥交换（IKE）协议的版本2。IKE是IPsec的一个组件，用于执行相互身份验证以及建立和维护安全关联（SA）。
This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.
此版本的IKE规范结合了以前单独文档的内容，包括Internet安全关联和密钥管理协议（ISAKMP，RFC 2408）、IKE（RFC 2409）、Internet解释域（DOI，RFC 2407）、网络地址转换（NAT）遍历、传统身份验证、，远程地址获取。
Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port.
IKE的版本2不能与版本1互操作，但它有足够多的共同头格式，这两个版本可以明确地在同一UDP端口上运行。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Usage Scenarios ............................................5
1.2. The Initial Exchanges ......................................7
1.3. The CREATE_CHILD_SA Exchange ...............................9
1.4. The INFORMATIONAL Exchange ................................11
1.5. Informational Messages outside of an IKE_SA ...............12
2. IKE Protocol Details and Variations ............................12
2.1. Use of Retransmission Timers ..............................13
2.2. Use of Sequence Numbers for Message ID ....................14
2.3. Window Size for Overlapping Requests ......................14
2.4. State Synchronization and Connection Timeouts .............15
2.5. Version Numbers and Forward Compatibility .................17
2.6. Cookies ...................................................18
2.7. Cryptographic Algorithm Negotiation .......................21
2.8. Rekeying ..................................................22
2.9. Traffic Selector Negotiation ..............................24
2.10. Nonces ...................................................26
2.11. Address and Port Agility .................................26
2.12. Reuse of Diffie-Hellman Exponentials .....................27
2.13. Generating Keying Material ...............................27
2.14. Generating Keying Material for the IKE_SA ................28
2.15. Authentication of the IKE_SA .............................29
2.16. Extensible Authentication Protocol Methods ...............31
2.17. Generating Keying Material for CHILD_SAs .................33
2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34
2.19. Requesting an Internal Address on a Remote Network .......34
2.20. Requesting the Peer's Version ............................35
2.21. Error Handling ...........................................36
2.22. IPComp ...................................................37
2.23. NAT Traversal ............................................38
2.24. Explicit Congestion Notification (ECN) ...................40
3. Header and Payload Formats .....................................41
3.1. The IKE Header ............................................41
3.2. Generic Payload Header ....................................44
3.3. Security Association Payload ..............................46
3.4. Key Exchange Payload ......................................56
3.5. Identification Payloads ...................................56
3.6. Certificate Payload .......................................59
3.7. Certificate Request Payload ...............................61
3.8. Authentication Payload ....................................63
3.9. Nonce Payload .............................................64
3.10. Notify Payload ...........................................64
3.11. Delete Payload ...........................................72
3.12. Vendor ID Payload ........................................73
3.13. Traffic Selector Payload .................................74
3.14. Encrypted Payload ........................................77
1. Introduction ....................................................3
1.1. Usage Scenarios ............................................5
1.2. The Initial Exchanges ......................................7
1.3. The CREATE_CHILD_SA Exchange ...............................9
1.4. The INFORMATIONAL Exchange ................................11
1.5. Informational Messages outside of an IKE_SA ...............12
2. IKE Protocol Details and Variations ............................12
2.1. Use of Retransmission Timers ..............................13
2.2. Use of Sequence Numbers for Message ID ....................14
2.3. Window Size for Overlapping Requests ......................14
2.4. State Synchronization and Connection Timeouts .............15
2.5. Version Numbers and Forward Compatibility .................17
2.6. Cookies ...................................................18
2.7. Cryptographic Algorithm Negotiation .......................21
2.8. Rekeying ..................................................22
2.9. Traffic Selector Negotiation ..............................24
2.10. Nonces ...................................................26
2.11. Address and Port Agility .................................26
2.12. Reuse of Diffie-Hellman Exponentials .....................27
2.13. Generating Keying Material ...............................27
2.14. Generating Keying Material for the IKE_SA ................28
2.15. Authentication of the IKE_SA .............................29
2.16. Extensible Authentication Protocol Methods ...............31
2.17. Generating Keying Material for CHILD_SAs .................33
2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34
2.19. Requesting an Internal Address on a Remote Network .......34
2.20. Requesting the Peer's Version ............................35
2.21. Error Handling ...........................................36
2.22. IPComp ...................................................37
2.23. NAT Traversal ............................................38
2.24. Explicit Congestion Notification (ECN) ...................40
3. Header and Payload Formats .....................................41
3.1. The IKE Header ............................................41
3.2. Generic Payload Header ....................................44
3.3. Security Association Payload ..............................46
3.4. Key Exchange Payload ......................................56
3.5. Identification Payloads ...................................56
3.6. Certificate Payload .......................................59
3.7. Certificate Request Payload ...............................61
3.8. Authentication Payload ....................................63
3.9. Nonce Payload .............................................64
3.10. Notify Payload ...........................................64
3.11. Delete Payload ...........................................72
3.12. Vendor ID Payload ........................................73
3.13. Traffic Selector Payload .................................74
3.14. Encrypted Payload ........................................77
3.15. Configuration Payload ....................................79
3.16. Extensible Authentication Protocol (EAP) Payload .........84
4. Conformance Requirements .......................................85
5. Security Considerations ........................................88
6. IANA Considerations ............................................90
7. Acknowledgements ...............................................91
8. References .....................................................91
8.1. Normative References ......................................91
8.2. Informative References ....................................92
Appendix A: Summary of Changes from IKEv1 .........................96
Appendix B: Diffie-Hellman Groups .................................97
B.1. Group 1 - 768 Bit MODP ....................................97
B.2. Group 2 - 1024 Bit MODP ...................................97
3.15. Configuration Payload ....................................79
3.16. Extensible Authentication Protocol (EAP) Payload .........84
4. Conformance Requirements .......................................85
5. Security Considerations ........................................88
6. IANA Considerations ............................................90
7. Acknowledgements ...............................................91
8. References .....................................................91
8.1. Normative References ......................................91
8.2. Informative References ....................................92
Appendix A: Summary of Changes from IKEv1 .........................96
Appendix B: Diffie-Hellman Groups .................................97
B.1. Group 1 - 768 Bit MODP ....................................97
B.2. Group 2 - 1024 Bit MODP ...................................97
IP Security (IPsec) provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. These services are provided by maintaining shared state between the source and the sink of an IP datagram. This state defines, among other things, the specific services provided to the datagram, which cryptographic algorithms will be used to provide the services, and the keys used as input to the cryptographic algorithms.
IP安全（IPsec）为IP数据报提供机密性、数据完整性、访问控制和数据源身份验证。这些服务是通过维护IP数据报的源和接收器之间的共享状态来提供的。除其他外，该状态定义提供给数据报的特定服务、将使用哪些加密算法提供服务以及用作加密算法输入的密钥。
Establishing this shared state in a manual fashion does not scale well. Therefore, a protocol to establish this state dynamically is needed. This memo describes such a protocol -- the Internet Key Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98]. This single document is intended to replace all three of those RFCs.
以手动方式建立此共享状态无法很好地扩展。因此，需要一个协议来动态地建立这种状态。这份备忘录描述了这样一种协议——因特网密钥交换（IKE）。这是IKE的第2版。IKE的版本1在RFCs 2407、2408和2409[Pip98、MSST98、HC98]中定义。本文件旨在取代所有三个RFC。
Definitions of the primitive terms in this document (such as Security Association or SA) can be found in [RFC4301].
本文档中基本术语（如安全关联或SA）的定义见[RFC4301]。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97].
本文件中出现的关键词“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”应按照[Bra97]中所述进行解释。
The term "Expert Review" is to be interpreted as defined in [RFC2434].
术语“专家评审”应按照[RFC2434]中的定义进行解释。
IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication Header (AH) [RFC4302] and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry. In this document, the term "suite" or "cryptographic suite" refers to a
IKE在双方之间执行相互身份验证，并建立IKE安全关联（SA），该关联包括可用于有效建立SA以封装安全有效负载（ESP）[RFC4303]和/或身份验证头（AH）[RFC4302]的共享机密信息以及SAs使用的一组加密算法，以保护其承载的流量。在本文件中，术语“套件”或“加密套件”指
complete set of algorithms used to protect an SA. An initiator proposes one or more suites by listing supported algorithms that can be combined into suites in a mix-and-match fashion. IKE can also negotiate use of IP Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get set up through that IKE_SA we call "CHILD_SAs".
用于保护SA的完整算法集。发起者通过列出支持的算法来提出一个或多个套件，这些算法可以以混合匹配的方式组合成套件。IKE还可以就ESP和/或AH SA协商IP压缩（IPComp）[IPComp]的使用。我们称艾克萨为“艾克萨”。ESP和/或AH的SAs通过IKE_SA设置，我们称之为“CHILD_SAs”。
All IKE communications consist of pairs of messages: a request and a response. The pair is called an "exchange". We call the first messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL exchanges. In the common case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to establish the IKE_SA and the first CHILD_SA. In exceptional cases, there may be more than one of each of these exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete, and following that any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order. In some scenarios, only a single CHILD_SA is needed between the IPsec endpoints, and therefore there would be no additional exchanges. Subsequent exchanges MAY be used to establish additional CHILD_SAs between the same authenticated pair of endpoints and to perform housekeeping functions.
所有IKE通信都由成对的消息组成：一个请求和一个响应。这对被称为“交换”。我们将建立IKE_SA IKE_SA_INIT和IKE_AUTH交换的第一条消息称为IKE_SA IKE_SA INIT和IKE_AUTH交换，随后的IKE交换创建了IKE CHILD_SA或信息交换。在常见情况下，有一个IKE_SA_INIT交换和一个IKE_AUTH交换（总共四条消息）来建立IKE_SA和第一个子_SA。在特殊情况下，每个交易所可能不止一个。在所有情况下，所有IKE_SA_INIT交换必须在任何其他交换类型之前完成，然后所有IKE_AUTH交换必须完成，然后任何数量的CREATE_CHILD_SA和信息交换可能以任何顺序发生。在某些场景中，IPsec端点之间只需要一个子节点，因此不会有额外的交换。随后的交换可用于在同一对经过身份验证的端点之间建立额外的子节点，并执行内务管理功能。
IKE message flow always consists of a request followed by a response. It is the responsibility of the requester to ensure reliability. If the response is not received within a timeout interval, the requester needs to retransmit the request (or abandon the connection).
IKE消息流始终由请求和响应组成。请求者有责任确保可靠性。如果在超时时间间隔内未收到响应，请求者需要重新传输请求（或放弃连接）。
The first request/response of an IKE session (IKE_SA_INIT) negotiates security parameters for the IKE_SA, sends nonces, and sends Diffie-Hellman values.
IKE会话的第一个请求/响应（IKE_SA_INIT）协商IKE_SA的安全参数，发送nonce，并发送Diffie-Hellman值。
The second request/response (IKE_AUTH) transmits identities, proves knowledge of the secrets corresponding to the two identities, and sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.
第二个请求/响应（IKE_AUTH）传输身份，证明与两个身份相对应的机密知识，并为第一个（通常仅）AH和/或ESP子_SA设置SA。
The types of subsequent exchanges are CREATE_CHILD_SA (which creates a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error conditions, or does other housekeeping). Every request requires a response. An INFORMATIONAL request with no payloads (other than the empty Encrypted payload required by the syntax) is commonly used as a check for liveness. These subsequent exchanges cannot be used until the initial exchanges have completed.
后续交换的类型包括创建子SA（创建子SA）和信息交换（删除SA、报告错误情况或执行其他内务管理）。每个请求都需要响应。没有有效负载的信息性请求（语法要求的空加密有效负载除外）通常用作活动性检查。在初始交换完成之前，不能使用这些后续交换。
In the description that follows, we assume that no errors occur. Modifications to the flow should errors occur are described in section 2.21.
在下面的描述中，我们假设没有错误发生。第2.21节描述了出现错误时对流程的修改。
IKE is expected to be used to negotiate ESP and/or AH SAs in a number of different scenarios, each with its own special requirements.
IKE预计将用于在许多不同的场景中协商ESP和/或AH SA，每个场景都有自己的特殊要求。
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec ! !
Protected !Tunnel ! tunnel !Tunnel ! Protected
Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet
! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec ! !
Protected !Tunnel ! tunnel !Tunnel ! Protected
Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet
! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+
Figure 1: Security Gateway to Security Gateway Tunnel
图1：安全网关到安全网关隧道
In this scenario, neither endpoint of the IP connection implements IPsec, but network nodes between them protect traffic for part of the way. Protection is transparent to the endpoints, and depends on ordinary routing to send packets through the tunnel endpoints for processing. Each endpoint would announce the set of addresses "behind" it, and packets would be sent in tunnel mode where the inner IP header would contain the IP addresses of the actual endpoints.
在这种情况下，IP连接的两个端点都没有实现IPsec，但它们之间的网络节点在某种程度上保护了通信量。保护对端点是透明的，并且依赖于通过隧道端点发送数据包进行处理的普通路由。每一个端点都会宣布它后面的一组地址，数据包将以隧道模式发送，其中内部IP报头将包含实际端点的IP地址。
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec transport ! !
!Protected! or tunnel mode SA !Protected!
!Endpoint !<---------------------------------------->!Endpoint !
! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec transport ! !
!Protected! or tunnel mode SA !Protected!
!Endpoint !<---------------------------------------->!Endpoint !
! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+
Figure 2: Endpoint to Endpoint
图2：端点到端点
In this scenario, both endpoints of the IP connection implement IPsec, as required of hosts in [RFC4301]. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. These endpoints MAY implement application layer access controls based on the IPsec authenticated identities of the participants. This scenario enables the end-to-end security that has been a guiding principle for the Internet since [RFC1958],
在这种情况下，IP连接的两个端点都按照[RFC4301]中主机的要求实现IPsec。传输模式通常在没有内部IP报头的情况下使用。如果存在内部IP头，则内部地址将与外部地址相同。将为此SA保护的数据包协商一对地址。这些端点可以基于参与者的IPsec认证身份实现应用层访问控制。该方案实现了自[RFC1958]以来一直作为互联网指导原则的端到端安全，
[RFC2775], and a method of limiting the inherent problems with complexity in networks noted by [RFC3439]. Although this scenario may not be fully applicable to the IPv4 Internet, it has been deployed successfully in specific scenarios within intranets using IKEv1. It should be more broadly enabled during the transition to IPv6 and with the adoption of IKEv2.
[RFC2775]，以及一种限制[RFC3439]所述网络复杂性固有问题的方法。尽管此场景可能不完全适用于IPv4 Internet，但已使用IKEv1在内部网内的特定场景中成功部署。在过渡到IPv6和采用IKEv2的过程中，应该更广泛地启用它。
It is possible in this scenario that one or both of the protected endpoints will be behind a network address translation (NAT) node, in which case the tunneled packets will have to be UDP encapsulated so that port numbers in the UDP headers can be used to identify individual endpoints "behind" the NAT (see section 2.23).
在这种情况下，一个或两个受保护的端点可能位于网络地址转换（NAT）节点后面，在这种情况下，隧道数据包必须采用UDP封装，以便UDP报头中的端口号可用于标识“在”NAT后面的各个端点（见第2.23节）。
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec ! ! Protected
!Protected! tunnel !Tunnel ! Subnet
!Endpoint !<------------------------>!Endpoint !<--- and/or
! ! ! ! Internet
+-+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec ! ! Protected
!Protected! tunnel !Tunnel ! Subnet
!Endpoint !<------------------------>!Endpoint !<--- and/or
! ! ! ! Internet
+-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Endpoint to Security Gateway Tunnel
图3：端点到安全网关隧道
In this scenario, a protected endpoint (typically a portable roaming computer) connects back to its corporate network through an IPsec-protected tunnel. It might use this tunnel only to access information on the corporate network, or it might tunnel all of its traffic back through the corporate network in order to take advantage of protection provided by a corporate firewall against Internet-based attacks. In either case, the protected endpoint will want an IP address associated with the security gateway so that packets returned to it will go to the security gateway and be tunneled back. This IP address may be static or may be dynamically allocated by the security gateway. In support of the latter case, IKEv2 includes a mechanism for the initiator to request an IP address owned by the security gateway for use for the duration of its SA.
在此场景中，受保护的端点（通常是便携式漫游计算机）通过受IPsec保护的隧道连接回其公司网络。它可能仅使用此隧道访问公司网络上的信息，也可能通过公司网络将其所有通信量隧道返回，以利用公司防火墙提供的保护，抵御基于Internet的攻击。在任何一种情况下，受保护的端点都需要一个与安全网关关联的IP地址，以便返回给它的数据包将进入安全网关并通过隧道返回。该IP地址可以是静态的，也可以由安全网关动态分配。为了支持后一种情况，IKEv2包括一种机制，用于启动器请求安全网关拥有的IP地址，以便在其SA期间使用。
In this scenario, packets will use tunnel mode. On each packet from the protected endpoint, the outer IP header will contain the source IP address associated with its current location (i.e., the address that will get traffic routed to the endpoint directly), while the inner IP header will contain the source IP address assigned by the security gateway (i.e., the address that will get traffic routed to the security gateway for forwarding to the endpoint). The outer destination address will always be that of the security gateway, while the inner destination address will be the ultimate destination for the packet.
在这种情况下，数据包将使用隧道模式。在来自受保护端点的每个数据包上，外部IP报头将包含与其当前位置关联的源IP地址（即，将流量直接路由到端点的地址），而内部IP报头将包含由安全网关分配的源IP地址（即，将流量路由到安全网关以转发到端点的地址）。外部目的地地址将始终是安全网关的地址，而内部目的地地址将是数据包的最终目的地。
In this scenario, it is possible that the protected endpoint will be behind a NAT. In that case, the IP address as seen by the security gateway will not be the same as the IP address sent by the protected endpoint, and packets will have to be UDP encapsulated in order to be routed properly.
在这种情况下，受保护的端点可能位于NAT后面。在这种情况下，安全网关看到的IP地址将与受保护端点发送的IP地址不同，数据包必须经过UDP封装才能正确路由。
Other scenarios are possible, as are nested combinations of the above. One notable example combines aspects of 1.1.1 and 1.1.3. A subnet may make all external accesses through a remote security gateway using an IPsec tunnel, where the addresses on the subnet are routed to the security gateway by the rest of the Internet. An example would be someone's home network being virtually on the Internet with static IP addresses even though connectivity is provided by an ISP that assigns a single dynamically assigned IP address to the user's security gateway (where the static IP addresses and an IPsec relay are provided by a third party located elsewhere).
其他场景也是可能的，上面的嵌套组合也是如此。一个值得注意的例子结合了1.1.1和1.1.3的各个方面。子网可以使用IPsec隧道通过远程安全网关进行所有外部访问，其中子网上的地址由Internet的其余部分路由到安全网关。例如，即使ISP为用户的安全网关分配一个动态分配的IP地址（其中静态IP地址和IPsec中继由位于别处的第三方提供），但某人的家庭网络实际上位于具有静态IP地址的Internet上。
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as Phase 1). These initial exchanges normally consist of four messages, though in some scenarios that number can grow. All communications using IKE consist of request/response pairs. We'll describe the base exchange first, followed by variations. The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange [DH].
使用IKE的通信总是从IKE_SA_INIT和IKE_AUTH交换开始（在IKEv1中称为阶段1）。这些初始交换通常由四条消息组成，但在某些情况下，这一数字可能会增加。使用IKE的所有通信都由请求/响应对组成。我们将首先描述基本交换，然后是变体。第一对消息（IKE_SA_INIT）协商加密算法，交换nonce，并执行Diffie-Hellman交换[DH]。
The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first CHILD_SA. Parts of these messages are encrypted and integrity protected with keys established through the IKE_SA_INIT exchange, so the identities are hidden from eavesdroppers and all fields in all the messages are authenticated.
第二对消息（IKE_AUTH）对以前的消息进行身份验证，交换身份和证书，并建立第一个子消息。这些消息的一部分通过IKE_SA_INIT交换建立的密钥进行加密和完整性保护，因此身份对窃听者隐藏，所有消息中的所有字段都经过身份验证。
In the following descriptions, the payloads contained in the message are indicated by names as listed below.
在下面的描述中，消息中包含的有效载荷由下面列出的名称表示。
Notation Payload
符号有效载荷
AUTH Authentication CERT Certificate CERTREQ Certificate Request CP Configuration D Delete E Encrypted
身份验证证书证书证书请求证书配置D删除E加密
EAP Extensible Authentication HDR IKE Header IDi Identification - Initiator IDr Identification - Responder KE Key Exchange Ni, Nr Nonce N Notify SA Security Association TSi Traffic Selector - Initiator TSr Traffic Selector - Responder V Vendor ID
EAP可扩展身份验证HDR IKE头IDi标识-发起方IDr标识-响应方KE密钥交换Ni，Nr Nonce N Notify SA安全关联TSi流量选择器-发起方TSr流量选择器-响应方V供应商ID
The details of the contents of each payload are described in section 3. Payloads that may optionally appear will be shown in brackets, such as [CERTREQ], indicate that optionally a certificate request payload can be included.
第3节详细介绍了每个有效载荷的内容。可以选择显示的有效负载将显示在括号中，例如[CERTREQ]，表示可以选择包括证书请求有效负载。
The initial exchanges are as follows:
初步交流如下：
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE_SA. The KE payload sends the initiator's Diffie-Hellman value. Ni is the initiator's nonce.
HDR包含各种安全参数索引（SPI）、版本号和标志。SAi1有效负载说明了启动器支持的IKE_SA加密算法。KE有效负载发送启动器的Diffie-Hellman值。Ni是发起者的nonce。
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<--HDR、SAr1、KEr、Nr、[CERTREQ]
The responder chooses a cryptographic suite from the initiator's offered choices and expresses that choice in the SAr1 payload, completes the Diffie-Hellman exchange with the KEr payload, and sends its nonce in the Nr payload.
响应者从发起者提供的选项中选择一个加密套件，并在SAr1负载中表示该选项，完成与KEr负载的Diffie-Hellman交换，并在Nr负载中发送其nonce。
At this point in the negotiation, each party can generate SKEYSEED, from which all keys are derived for that IKE_SA. All but the headers of all the messages that follow are encrypted and integrity protected. The keys used for the encryption and integrity protection are derived from SKEYSEED and are known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity protection). A separate SK_e and SK_a is computed for each direction. In addition to the keys SK_e and SK_a derived from the DH value for protection of the IKE_SA, another quantity SK_d is derived and used for derivation of further keying material for CHILD_SAs. The notation SK { ... } indicates that these payloads are encrypted and integrity protected using that direction's SK_e and SK_a.
在协商的这一点上，各方都可以生成skeysed，从该skeysed派生出该IKE_SA的所有密钥。除了下面所有消息的头之外，其他所有消息都是加密的，并受完整性保护。用于加密和完整性保护的密钥源自SKEYSEED，称为sku_e（加密）和SK_a（身份验证，也称为完整性保护）。为每个方向计算单独的SK_e和SK_A。除了从DH值导出的密钥SK_e和SK_a用于保护IKE_SA之外，还导出了另一个量SK_d，并用于导出用于儿童SA的进一步键控材料。符号SK{…}表示使用该方向的SK_e和SK_a对这些有效载荷进行加密和完整性保护。
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, 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 (see section 2.15). It might also send its certificate(s) in CERT payload(s) and a list of its trust anchors in CERTREQ payload(s). If any CERT payloads are included, the first certificate provided MUST contain the public key used to verify the AUTH field. The optional payload IDr enables the initiator to specify which of the responder's identities it wants to talk to. This is useful when the machine on which the responder is running is hosting multiple identities at the same IP address. The initiator begins negotiation of a CHILD_SA using the SAi2 payload. The final fields (starting with SAi2) are described in the description of the CREATE_CHILD_SA exchange.
发起者使用IDi有效载荷声明其身份，证明其知道与IDi相对应的秘密，并且完整性使用认证有效载荷保护第一条消息的内容（参见第2.15节）。它还可以在CERT有效负载中发送其证书，并在CERTREQ有效负载中发送其信任锚的列表。如果包含任何证书有效载荷，则提供的第一个证书必须包含用于验证AUTH字段的公钥。可选的有效负载IDr使启动器能够指定要与哪个响应者的身份进行对话。当响应程序运行的计算机在同一IP地址上承载多个标识时，这非常有用。发起方开始使用SAi2有效负载协商子_SA。最后的字段（从SAi2开始）在CREATE_CHILD_SA交换的描述中描述。
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}
<--HDR，SK{IDr，[CERT，]AUTH，SAr2，TSi，TSr}
The responder asserts its identity with the IDr payload, optionally sends one or more certificates (again with the certificate containing the public key used to verify AUTH listed first), authenticates its identity and protects the integrity of the second message with the AUTH payload, and completes negotiation of a CHILD_SA with the additional fields described below in the CREATE_CHILD_SA exchange.
响应者用IDr有效载荷声明其身份，选择性地发送一个或多个证书（同样，证书包含用于验证首先列出的身份验证的公钥），用身份验证有效载荷验证其身份并保护第二条消息的完整性，并使用下面在CREATE_CHILD_SA交换中描述的其他字段完成子_SA的协商。
The recipients of messages 3 and 4 MUST verify that all signatures and MACs are computed correctly and that the names in the ID payloads correspond to the keys used to generate the AUTH payload.
消息3和消息4的收件人必须验证所有签名和MAC的计算是否正确，以及ID有效负载中的名称是否对应于用于生成验证有效负载的密钥。
This exchange consists of a single request/response pair, and was referred to as a phase 2 exchange in IKEv1. It MAY be initiated by either end of the IKE_SA after the initial exchanges are completed.
此交换由单个请求/响应对组成，在IKEv1中称为阶段2交换。初始交换完成后，可由IKE_SA的任何一端启动。
All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKE exchange. These subsequent messages use the syntax of the Encrypted Payload described in section 3.14. All subsequent messages included an Encrypted Payload, even if they are referred to in the text as "empty".
初始交换之后的所有消息都使用在IKE交换的前两条消息中协商的加密算法和密钥进行加密保护。这些后续消息使用第3.14节中描述的加密有效负载的语法。所有后续消息都包含一个加密的有效负载，即使它们在文本中被称为“空”。
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this section the term "initiator" refers to the endpoint initiating this exchange.
任何一个端点都可以启动CREATE_CHILD_SA交换，因此在本节中，术语“启动器”指启动此交换的端点。
A CHILD_SA is created by sending a CREATE_CHILD_SA request. The CREATE_CHILD_SA request MAY optionally contain a KE payload for an additional Diffie-Hellman exchange to enable stronger guarantees of forward secrecy for the CHILD_SA. The keying material for the CHILD_SA is a function of SK_d established during the establishment of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA exchange, and the Diffie-Hellman value (if KE payloads are included in the CREATE_CHILD_SA exchange).
通过发送创建子SA请求来创建子SA。CREATE_CHILD_SA请求可以选择性地包含用于额外Diffie-Hellman交换的KE有效载荷，以实现对CHILD_SA的前向保密性的更有力保证。子项SA的键控材料是在IKE SA建立期间建立的SK_d、在创建子项SA交换期间交换的nonce和Diffie Hellman值（如果创建子项SA交换中包含KE有效载荷）的函数。
In the CHILD_SA created as part of the initial exchange, a second KE payload and nonce MUST NOT be sent. The nonces from the initial exchange are used in computing the keys for the CHILD_SA.
在作为初始交换的一部分创建的子_SA中，不得发送第二个KE有效负载和nonce。初始交换的nonce用于计算子_SA的密钥。
The CREATE_CHILD_SA request contains:
“创建子项”SA请求包含：
Initiator Responder
----------- -----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
Initiator Responder
----------- -----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, optionally a Diffie-Hellman value in the KEi payload, and the proposed traffic selectors in the TSi and TSr payloads. If this CREATE_CHILD_SA exchange is rekeying an existing SA other than the IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an existing SA, the N payload MUST be omitted. If the SA offers include different Diffie-Hellman groups, KEi MUST be an element of the group the initiator expects the responder to accept. If it guesses wrong, the CREATE_CHILD_SA exchange will fail, and it will have to retry with a different KEi.
发起方发送SA有效负载中的SA offer、Ni有效负载中的nonce、KEi有效负载中的Diffie-Hellman值以及TSi和TSr有效负载中的建议流量选择器。如果此CREATE_CHILD_SA交换正在为IKE_SA以外的现有SA重新设置密钥，则REKEY_SA类型的前导N有效负载必须标识正在重新设置密钥的SA。如果此CREATE_CHILD_SA交换没有为现有SA重新设置密钥，则必须忽略N有效负载。如果SA报价包含不同的Diffie-Hellman组，则KEi必须是发起方希望响应方接受的组的一个元素。如果猜错了，CREATE_CHILD_SA交换将失败，并且必须使用不同的KEi重试。
The message following the header is encrypted and the message including the header is integrity protected using the cryptographic algorithms negotiated for the IKE_SA.
使用为IKE_SA协商的加密算法对标头后面的消息进行加密，并对包含标头的消息进行完整性保护。
The CREATE_CHILD_SA response contains:
CREATE_CHILD_SA响应包含：
<-- HDR, SK {SA, Nr, [KEr], [TSi, TSr]}
<--HDR，SK{SA，Nr，[KEr]，[TSi，TSr]}
The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group. If the responder chooses a cryptographic suite with a different group, it MUST reject the request. The initiator SHOULD repeat the request, but now with a KEi payload from the group the responder selected.
如果请求中包含KEi且所选加密套件包括该组，则响应者使用SA有效负载中的已接受要约和KEr有效负载中的Diffie Hellman值进行响应（使用相同的消息ID进行响应）。如果响应者选择具有不同组的加密套件，则必须拒绝该请求。发起者应该重复该请求，但现在使用来自响应者选择的组的KEi有效负载。
The traffic selectors for traffic to be sent on that SA are specified in the TS payloads, which may be a subset of what the initiator of the CHILD_SA proposed. Traffic selectors are omitted if this CREATE_CHILD_SA request is being used to change the key of the IKE_SA.
要在该SA上发送的流量的流量选择器在TS有效负载中指定，TS有效负载可能是子SA的发起人提议的子集。如果此CREATE_CHILD_SA请求用于更改IKE_SA的密钥，则忽略流量选择器。
At various points during the operation of an IKE_SA, peers may desire to convey control messages to each other regarding errors or notifications of certain events. To accomplish this, IKE defines an INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with the negotiated keys.
在IKE_SA操作期间的不同时刻，对等方可能希望相互传递关于错误或特定事件通知的控制消息。为了实现这一点，IKE定义了一个信息交换。信息交换必须在初始交换之后进行，并使用协商密钥进行加密保护。
Control messages that pertain to an IKE_SA MUST be sent under that IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under the protection of the IKE_SA which generated them (or its successor if the IKE_SA was replaced for the purpose of rekeying).
与IKE_SA相关的控制消息必须在该IKE_SA下发送。与子_SA相关的控制消息必须在生成它们的IKE_SA的保护下发送（如果为了重新键入而替换了IKE_SA，则为其后续消息）。
Messages in an INFORMATIONAL exchange contain zero or more Notification, Delete, and Configuration payloads. The Recipient of an INFORMATIONAL exchange request MUST send some response (else the Sender will assume the message was lost in the network and will retransmit it). That response MAY be a message with no payloads. The request message in an INFORMATIONAL exchange MAY also contain no payloads. This is the expected way an endpoint can ask the other endpoint to verify that it is alive.
信息交换中的消息包含零个或多个通知、删除和配置有效负载。信息交换请求的接收者必须发送一些响应（否则发送者将假定消息在网络中丢失并将重新传输）。该响应可能是没有有效负载的消息。信息交换中的请求消息也可能不包含有效负载。这是端点要求另一个端点验证其是否处于活动状态的预期方式。
ESP and AH SAs always exist in pairs, with one SA in each direction. When an SA is closed, both members of the pair MUST be closed. When SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPComp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be deleted together. Each endpoint MUST close its incoming SAs and allow the other endpoint to close the other SA in each pair. To delete an SA, an INFORMATIONAL exchange with one or more delete payloads is sent listing the SPIs (as they would be expected in the headers of inbound packets) of the SAs to be deleted. The recipient MUST close the designated SAs. Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction. There is one exception. If by chance both ends of a set of SAs independently decide to close them, each may send a delete payload and the two requests may cross in the network. If a node receives a delete request for SAs for which it has already issued a delete request, it MUST delete the outgoing SAs while processing the request and the incoming SAs while processing the response. In that
ESP和AH SA始终成对存在，每个方向有一个SA。当SA关闭时，该对的两个成员都必须关闭。当SA嵌套时，如数据（如果处于隧道模式，则为IP头）首先用IPComp封装，然后用ESP封装，最后在同一对端点之间用AH封装时，所有SA必须一起删除。每个端点必须关闭其传入SA，并允许另一个端点关闭每对中的另一个SA。要删除SA，将发送一个具有一个或多个删除有效载荷的信息交换，其中列出要删除的SA的SPI（正如入站数据包的报头中所期望的那样）。收件人必须关闭指定的SA。通常，信息交换中的回复将包含反向配对SA的删除有效载荷。有一个例外。如果碰巧一组SA的两端独立决定关闭它们，则每个SA都可能发送一个删除有效负载，并且两个请求可能在网络中交叉。如果节点收到已发出删除请求的SAs的删除请求，则必须在处理请求时删除传出SAs，在处理响应时删除传入SAs。因为
case, the responses MUST NOT include delete payloads for the deleted SAs, since that would result in duplicate deletion and could in theory delete the wrong SA.
在这种情况下，响应不得包括已删除SA的删除有效载荷，因为这将导致重复删除，并且理论上可能删除错误的SA。
A node SHOULD regard half-closed connections as anomalous and audit their existence should they persist. Note that this specification nowhere specifies time periods, so it is up to individual endpoints to decide how long to wait. A node MAY refuse to accept incoming data on half-closed connections but MUST NOT unilaterally close them and reuse the SPIs. If connection state becomes sufficiently messed up, a node MAY close the IKE_SA; doing so will implicitly close all SAs negotiated under it. It can then rebuild the SAs it needs on a clean base under a new IKE_SA.
节点应将半封闭连接视为异常连接，并在它们持续存在时审核它们的存在。请注意，此规范没有指定时间段，因此由各个端点决定等待多长时间。节点可以拒绝接受半关闭连接上的传入数据，但不能单方面关闭它们并重用SPI。如果连接状态变得足够混乱，则节点可以关闭IKE_SA；这样做将隐式关闭根据其协商的所有SA。然后，它可以在新IKE_SA的干净基础上重建所需的SAs。
The INFORMATIONAL exchange is defined as:
信息交换定义为：
Initiator Responder
----------- -----------
HDR, SK {[N,] [D,] [CP,] ...} -->
<-- HDR, SK {[N,] [D,] [CP], ...}
Initiator Responder
----------- -----------
HDR, SK {[N,] [D,] [CP,] ...} -->
<-- HDR, SK {[N,] [D,] [CP], ...}
The processing of an INFORMATIONAL exchange is determined by its component payloads.
信息交换的处理由其组件有效负载决定。
If an encrypted IKE packet arrives on port 500 or 4500 with an unrecognized SPI, it could be because the receiving node has recently crashed and lost state or because of some other system malfunction or attack. If the receiving node has an active IKE_SA to the IP address from whence the packet came, it MAY send a notification of the wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it does not have such an IKE_SA, it MAY send an Informational message without cryptographic protection to the source IP address. Such a message is not part of an informational exchange, and the receiving node MUST NOT respond to it. Doing so could cause a message loop.
如果加密的IKE数据包到达端口500或4500时带有无法识别的SPI，则可能是因为接收节点最近崩溃并失去状态，或者是因为某些其他系统故障或攻击。如果接收节点向数据包来自的IP地址发送活动IKE_SA，则它可以在信息交换中通过该IKE_SA发送任意数据包的通知。如果它没有这样的IKE_SA，它可能会向源IP地址发送一条没有加密保护的信息性消息。这样的消息不是信息交换的一部分，接收节点不得对其作出响应。这样做可能会导致消息循环。
IKE normally listens and sends on UDP port 500, though IKE messages may also be received on UDP port 4500 with a slightly different format (see section 2.23). Since UDP is a datagram (unreliable) protocol, IKE includes in its definition recovery from transmission errors, including packet loss, packet replay, and packet forgery. IKE is designed to function so long as (1) at least one of a series of retransmitted packets reaches its destination before timing out; and (2) the channel is not so full of forged and replayed packets so
IKE通常在UDP端口500上侦听和发送，但IKE消息也可能在UDP端口4500上以稍微不同的格式接收（参见第2.23节）。由于UDP是一种数据报（不可靠）协议，IKE在其定义中包括从传输错误中恢复，包括数据包丢失、数据包重放和数据包伪造。IKE被设计为在（1）一系列重传分组中的至少一个在超时之前到达其目的地时起作用；和（2）信道中没有那么多伪造和重放的数据包
as to exhaust the network or CPU capacities of either endpoint. Even in the absence of those minimum performance requirements, IKE is designed to fail cleanly (as though the network were broken).
以耗尽任一端点的网络或CPU容量。即使在没有这些最低性能要求的情况下，IKE也被设计为完全失败（就像网络断开一样）。
Although IKEv2 messages are intended to be short, they contain structures with no hard upper bound on size (in particular, X.509 certificates), and IKEv2 itself does not have a mechanism for fragmenting large messages. IP defines a mechanism for fragmentation of oversize UDP messages, but implementations vary in the maximum message size supported. Furthermore, use of IP fragmentation opens an implementation to denial of service attacks [KPS03]. Finally, some NAT and/or firewall implementations may block IP fragments.
尽管IKEv2消息的目的是简短的，但它们包含的结构在大小上没有硬上限（特别是X.509证书），并且IKEv2本身没有分割大型消息的机制。IP定义了一种用于分割超大UDP消息的机制，但实现在支持的最大消息大小方面有所不同。此外，IP碎片的使用为拒绝服务攻击打开了一个实现[KPS03]。最后，一些NAT和/或防火墙实现可能会阻止IP片段。
All IKEv2 implementations MUST be able to send, receive, and process IKE messages that are up to 1280 bytes long, and they SHOULD be able to send, receive, and process messages that are up to 3000 bytes long. IKEv2 implementations SHOULD be aware of the maximum UDP message size supported and MAY shorten messages by leaving out some certificates or cryptographic suite proposals if that will keep messages below the maximum. Use of the "Hash and URL" formats rather than including certificates in exchanges where possible can avoid most problems. Implementations and configuration should keep in mind, however, that if the URL lookups are possible only after the IPsec SA is established, recursion issues could prevent this technique from working.
所有IKEv2实现必须能够发送、接收和处理长达1280字节的IKE消息，并且应该能够发送、接收和处理长达3000字节的消息。IKEv2实现应该知道所支持的最大UDP消息大小，并且可能会通过省略一些证书或加密套件建议来缩短消息，如果这样会使消息低于最大值。使用“哈希和URL”格式，而不是尽可能在交换中包含证书，可以避免大多数问题。但是，实现和配置应记住，如果URL查找仅在IPsec SA建立后才可能进行，则递归问题可能会阻止此技术工作。
All messages in IKE exist in pairs: a request and a response. The setup of an IKE_SA normally consists of two request/response pairs. Once the IKE_SA is set up, either end of the security association may initiate requests at any time, and there can be many requests and responses "in flight" at any given moment. But each message is labeled as either a request or a response, and for each request/response pair one end of the security association is the initiator and the other is the responder.
IKE中的所有消息成对存在：请求和响应。IKE_SA的设置通常由两个请求/响应对组成。一旦IKE_SA建立，安全关联的任何一端都可以在任何时候发起请求，并且在任何给定时刻都可能有许多请求和响应处于“飞行”状态。但每个消息都标记为请求或响应，对于每个请求/响应对，安全关联的一端是启动器，另一端是响应者。
For every pair of IKE 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. In that event, the responder MUST ignore the retransmitted request except insofar as it triggers a retransmission of the response. The initiator MUST remember each request until it receives the corresponding response. The responder MUST remember each response until it receives a request whose sequence number is larger than the sequence number in the response plus its window size (see section 2.3).
对于每对IKE消息，发起方负责在超时情况下重新传输。响应者不得重新传输响应，除非它收到请求的重新传输。在这种情况下，响应者必须忽略重新传输的请求，除非它触发了响应的重新传输。启动器必须记住每个请求，直到收到相应的响应。响应者必须记住每个响应，直到它收到一个序列号大于响应中的序列号加上其窗口大小的请求为止（参见第2.3节）。
IKE is a reliable protocol, in the sense that the initiator MUST retransmit a request until either it receives a corresponding reply OR it deems the IKE security association to have failed and it discards all state associated with the IKE_SA and any CHILD_SAs negotiated using that IKE_SA.
IKE是一种可靠的协议，从这个意义上说，发起方必须重新传输请求，直到它收到相应的回复，或者它认为IKE安全关联失败，并且它丢弃与IKE_SA关联的所有状态以及使用该IKE_SA协商的任何子SA。
Every IKE 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.
每个IKE消息都包含一个消息ID作为其固定头的一部分。此消息ID用于匹配请求和响应，并标识消息的重新传输。
The Message ID is a 32-bit quantity, which is zero for the first IKE request in each direction. The IKE_SA initial setup messages will always be numbered 0 and 1. Each endpoint in the IKE Security Association maintains two "current" Message IDs: the next one to be used for a request it initiates and the next one it expects to see in a request from the other end. These counters increment as requests are generated and received. Responses always contain the same message ID as the corresponding request. That means that after the initial exchange, each integer n may appear as the message ID in four distinct messages: the nth request from the original IKE initiator, the corresponding response, the nth request from the original IKE responder, and the corresponding response. If the two ends make very different numbers of requests, the Message IDs in the two directions can be very different. There is no ambiguity in the messages, however, because the (I)nitiator and (R)esponse bits in the message header specify which of the four messages a particular one is.
消息ID是一个32位的数量，对于每个方向上的第一个IKE请求，该数量为零。IKE_SA初始设置消息将始终编号为0和1。IKE安全关联中的每个端点维护两个“当前”消息ID：下一个用于它发起的请求，下一个用于它期望在另一端的请求中看到的。这些计数器随着请求的生成和接收而增加。响应始终包含与相应请求相同的消息ID。这意味着在初始交换之后，每个整数n可以作为消息ID出现在四个不同的消息中：来自原始IKE发起方的第n个请求、相应的响应、来自原始IKE响应方的第n个请求以及相应的响应。如果两端发出的请求数量非常不同，则两个方向上的消息ID可能会非常不同。但是，消息中没有歧义，因为消息头中的（I）initiator和（R）response位指定了四条消息中的哪一条是特定消息。
Note that Message IDs are cryptographically protected and provide protection against message replays. In the unlikely event that Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be closed. Rekeying an IKE_SA resets the sequence numbers.
请注意，消息ID受到加密保护，并提供防止消息重播的保护。如果消息ID变得太大而无法容纳32位，则必须关闭IKE_SA。对IKE_SA重新设置密钥将重置序列号。
In order to maximize IKE throughput, an IKE endpoint MAY issue multiple requests before getting a response to any of them if the other endpoint has indicated its ability to handle such requests. For simplicity, an IKE implementation MAY choose to process requests strictly in order and/or wait for a response to one request before issuing another. Certain rules must be followed to ensure interoperability between implementations using different strategies.
为了最大限度地提高IKE吞吐量，如果另一个端点已指示其处理此类请求的能力，则IKE端点可以在获得对其中任何一个请求的响应之前发出多个请求。为简单起见，IKE实现可以选择严格按顺序处理请求和/或在发出另一个请求之前等待对一个请求的响应。必须遵循某些规则，以确保使用不同策略的实现之间的互操作性。
After an IKE_SA is set up, either end can initiate one or more requests. These requests may pass one another over the network. An IKE endpoint MUST be prepared to accept and process a request while
设置IKE_SA后，任何一端都可以发起一个或多个请求。这些请求可以通过网络相互传递。IKE端点必须准备好接受和处理请求
it has a request outstanding in order to avoid a deadlock in this situation. An IKE endpoint SHOULD be prepared to accept and process multiple requests while it has a request outstanding.
它有一个未完成的请求，以避免在这种情况下出现僵局。IKE端点应该准备好接受和处理多个请求，同时它有一个未完成的请求。
An IKE endpoint MUST wait for a response to each of its messages before sending a subsequent message unless it has received a SET_WINDOW_SIZE Notify message from its peer informing it that the peer is prepared to maintain state for multiple outstanding messages in order to allow greater throughput.
IKE端点在发送后续消息之前必须等待对其每条消息的响应，除非它已从其对等方接收到一条SET_WINDOW_SIZE Notify消息，通知其对等方已准备好维护多条未完成消息的状态，以便允许更大的吞吐量。
An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests. In other words, if the responder stated its window size is N, then when the initiator needs to make a request X, it MUST wait until it has received responses to all requests up through request X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate exactly) each request it has sent until it receives the corresponding response. An IKE endpoint MUST keep a copy of (or be able to regenerate exactly) the number of previous responses equal to its declared window size in case its response was lost and the initiator requests its retransmission by retransmitting the request.
IKE端点对于传输的IKE请求不得超过对等方规定的窗口大小。换句话说，如果响应者声明其窗口大小为N，则当发起方需要发出请求X时，它必须等待直到通过请求X-N收到所有请求的响应。IKE端点必须保留其发送的每个请求的副本（或能够准确地重新生成），直到收到相应的响应。IKE端点必须保留（或能够准确地重新生成）先前响应数量的副本，该数量等于其声明的窗口大小，以防其响应丢失，并且启动器通过重新传输请求来请求其重新传输。
An IKE endpoint supporting a window size greater than one SHOULD be capable of processing incoming requests out of order to maximize performance in the event of network failures or packet reordering.
支持大于1的窗口大小的IKE端点应该能够处理无序的传入请求，以便在发生网络故障或数据包重新排序时最大限度地提高性能。
An IKE endpoint is allowed to forget all of its state associated with an IKE_SA and the collection of corresponding CHILD_SAs at any time. This is the anticipated behavior in the event of an endpoint crash and restart. It is important when an endpoint either fails or reinitializes its state that the other endpoint detect those conditions and not continue to waste network bandwidth by sending packets over discarded SAs and having them fall into a black hole.
允许IKE端点在任何时候忘记与IKE_SA和相应子SA集合关联的所有状态。这是端点崩溃和重新启动时的预期行为。当一个端点出现故障或重新初始化其状态时，另一个端点必须检测到这些情况，并且不要通过在丢弃的SA上发送数据包并使其落入黑洞而继续浪费网络带宽，这一点很重要。
Since IKE is designed to operate in spite of Denial of Service (DoS) attacks from the network, an endpoint MUST NOT conclude that the other endpoint has failed based on any routing information (e.g., ICMP messages) or IKE messages that arrive without cryptographic protection (e.g., Notify messages complaining about unknown SPIs). An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE_SA to the same authenticated identity. An endpoint SHOULD suspect that the other endpoint has failed based on routing information and initiate a request to see whether the other endpoint is alive. To check whether the other side is alive, IKE specifies an empty INFORMATIONAL message
由于IKE被设计为在网络拒绝服务（DoS）攻击的情况下运行，因此端点不得基于任何路由信息（例如ICMP消息）或到达时没有加密保护的IKE消息（例如，通知消息抱怨未知SPI）断定另一个端点失败。一个端点必须得出结论，只有在重复尝试联系另一个端点的超时时间内未得到响应，或者在不同IKE_SA上接收到受密码保护的初始_联系人通知时，另一个端点才会失败。端点应根据路由信息怀疑另一个端点已失败，并启动请求以查看另一个端点是否处于活动状态。为了检查另一端是否处于活动状态，IKE指定一条空的信息消息
that (like all IKE requests) requires an acknowledgement (note that within the context of an IKE_SA, an "empty" message consists of an IKE header followed by an Encrypted payload that contains no payloads). If a cryptographically protected message has been received from the other side recently, unprotected notifications MAY be ignored. Implementations MUST limit the rate at which they take actions based on unprotected messages.
这（与所有IKE请求一样）需要确认（注意，在IKE_SA的上下文中，“空”消息由IKE头和不包含有效负载的加密有效负载组成）。如果最近从另一方接收到受加密保护的消息，则可能会忽略未受保护的通知。实现必须限制基于未受保护的消息采取操作的速率。
Numbers of retries and lengths of timeouts are not covered in this specification because they do not affect interoperability. It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules. To be a good network citizen, retranmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse. If there has only been outgoing traffic on all of the SAs associated with an IKE_SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE_SA or any of its CHILD_SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. Receipt of a fresh cryptographically protected message on an IKE_SA or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its CHILD_SAs. Note that this places requirements on the failure modes of an IKE endpoint. An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all of the associated SAs. If CHILD_SAs can fail independently from one another without the associated IKE_SA being able to send a delete message, then they MUST be negotiated by separate IKE_SAs.
本规范不包括重试次数和超时长度，因为它们不影响互操作性。建议在放弃SA之前，在至少几分钟的时间内至少重新传输十几次消息，但不同的环境可能需要不同的规则。要成为一个好的网络公民，重传时间必须成倍增加，以避免网络泛滥，并使现有的拥塞情况恶化。如果与IKE_SA相关的所有SA上只有传出流量，则必须确认另一个端点的活动性以避免黑洞。如果IKE_SA或其任何子SA最近未收到任何受加密保护的消息，则系统需要执行活动性检查，以防止向死对等方发送消息。在IKE_SA或其任何子_SA上接收新的加密保护消息可确保IKE_SA及其所有子_SA的活跃性。请注意，这对IKE端点的故障模式提出了要求。如果某个故障阻止实现在所有相关SA上接收，则实现不得在任何SA上继续发送。如果子级SA彼此独立失败，而关联的IKE SA无法发送删除消息，则必须由单独的IKE SA协商。
There is a Denial of Service attack on the initiator of an IKE_SA that can be avoided if the initiator takes the proper care. Since the first two messages of an SA setup are not cryptographically protected, an attacker could respond to the initiator's message before the genuine responder and poison the connection setup attempt. To prevent this, the initiator MAY be willing to accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptographically valid.
IKE_SA的启动器上存在拒绝服务攻击，如果启动器采取适当的措施，可以避免这种攻击。由于SA设置的前两条消息没有加密保护，攻击者可能会在真正的响应者之前响应启动器的消息，并毒害连接设置尝试。为了防止这种情况，发起方可能愿意接受对其第一条消息的多个响应，将每个响应视为可能合法的，对其进行响应，然后在接收到对其任何一个请求的有效加密保护响应时丢弃所有无效的半开连接。一旦接收到加密有效的响应，则应忽略所有后续响应，无论它们是否加密有效。
Note that with these rules, there is no reason to negotiate and agree upon an SA lifetime. If IKE presumes the partner is dead, based on repeated lack of acknowledgement to an IKE message, then the IKE SA and all CHILD_SAs set up through that IKE_SA are deleted.
请注意，根据这些规则，没有理由就SA生命周期进行协商和达成一致。如果IKE基于反复缺少对IKE消息的确认而假定合作伙伴已死亡，则IKE SA和通过该IKE SA设置的所有子SA将被删除。
An IKE endpoint may at any time delete inactive CHILD_SAs to recover resources used to hold their state. If an IKE endpoint chooses to delete CHILD_SAs, it MUST send Delete payloads to the other end notifying it of the deletion. It MAY similarly time out the IKE_SA. Closing the IKE_SA implicitly closes all associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a Delete payload indicating that it has closed the IKE_SA.
IKE端点可以随时删除非活动子节点，以恢复用于保持其状态的资源。如果IKE端点选择删除子节点，则它必须向另一端发送删除有效负载，通知其删除。同样，它可能会暂停IKE_SA。关闭IKE_SA会隐式关闭所有关联的子SA。在这种情况下，IKE端点应发送一个删除有效负载，指示它已关闭IKE_SA。
This document describes version 2.0 of IKE, meaning the major version number is 2 and the minor version number is zero. It is likely that some implementations will want to support both version 1.0 and version 2.0, and in the future, other versions.
本文档描述了IKE的2.0版，即主版本号为2，次版本号为零。一些实现可能希望同时支持版本1.0和版本2.0，并且在将来支持其他版本。
The major version number should be incremented only if the packet formats or required actions have changed so dramatically that an older version node would not be able to interoperate with a newer version node if it simply ignored the fields it did not understand and took the actions specified in the older specification. The minor version number indicates new capabilities, and MUST be ignored by a node with a smaller minor version number, but used for informational purposes by the node with the larger minor version number. For example, it might indicate the ability to process a newly defined notification message. The node with the larger minor version number would simply note that its correspondent would not be able to understand that message and therefore would not send it.
只有当数据包格式或所需操作发生了巨大变化，以至于旧版本节点无法与新版本节点进行互操作时（如果它忽略了不理解的字段并采取了旧规范中指定的操作），主版本号才应增加。次要版本号表示新功能，次要版本号较小的节点必须忽略该功能，但次要版本号较大的节点用于提供信息。例如，它可能指示处理新定义的通知消息的能力。较小版本号较大的节点只会注意到其对应者无法理解该消息，因此不会发送该消息。
If an endpoint receives a message with a higher major version number, it MUST drop the message and SHOULD send an unauthenticated notification message containing the highest version number it supports. If an endpoint supports major version n, and major version m, it MUST support all versions between n and m. If it receives a message with a major version that it supports, it MUST respond with that version number. In order to prevent two nodes from being tricked into corresponding with a lower major version number than the maximum that they both support, IKE has a flag that indicates that the node is capable of speaking a higher major version number.
如果端点接收到具有更高主版本号的消息，则必须删除该消息，并应发送包含其支持的最高版本号的未经验证的通知消息。如果端点支持主版本n和主版本m，则它必须支持n和m之间的所有版本。如果它收到一条包含其支持的主要版本的消息，则必须使用该版本号进行响应。为了防止两个节点被欺骗，使其对应的主版本号低于它们都支持的最大值，IKE有一个标志，指示该节点能够说出更高的主版本号。
Thus, the major version number in the IKE header indicates the version number of the message, not the highest version number that the transmitter supports. If the initiator is capable of speaking versions n, n+1, and n+2, and the responder is capable of speaking versions n and n+1, then they will negotiate speaking n+1, where the initiator will set the flag indicating its ability to speak a higher version. If they mistakenly (perhaps through an active attacker
因此，IKE头中的主版本号表示消息的版本号，而不是发送器支持的最高版本号。如果发起者能够讲n、n+1和n+2版本，而响应者能够讲n和n+1版本，则他们将协商讲n+1版本，发起者将设置标志，指示其讲更高版本的能力。如果他们错误地（可能是通过一个活跃的攻击者
sending error messages) negotiate to version n, then both will notice that the other side can support a higher version number, and they MUST break the connection and reconnect using version n+1.
发送错误消息）协商到版本n，然后双方都会注意到对方可以支持更高的版本号，并且他们必须断开连接并使用版本n+1重新连接。
Note that IKEv1 does not follow these rules, because there is no way in v1 of noting that you are capable of speaking a higher version number. So an active attacker can trick two v2-capable nodes into speaking v1. When a v2-capable node negotiates down to v1, it SHOULD note that fact in its logs.
请注意，IKEv1不遵循这些规则，因为在v1中无法注意到您能够说出更高的版本号。因此，主动攻击者可以诱使两个支持v2的节点说出v1。当一个支持v2的节点向下协商到v1时，它应该在其日志中注意这一事实。
Also for forward compatibility, all fields marked RESERVED MUST be set to zero by a version 2.0 implementation and their content MUST be ignored by a version 2.0 implementation ("Be conservative in what you send and liberal in what you receive"). In this way, future versions of the protocol can use those fields in a way that is guaranteed to be ignored by implementations that do not understand them. Similarly, payload types that are not defined are reserved for future use; implementations of version 2.0 MUST skip over those payloads and ignore their contents.
此外，为了向前兼容，所有标记为保留的字段必须由版本2.0实现设置为零，并且其内容必须由版本2.0实现忽略（“发送内容要保守，接收内容要自由”）。通过这种方式，协议的未来版本可以使用这些字段，而不理解这些字段的实现将保证忽略这些字段。类似地，未定义的有效载荷类型保留供将来使用；版本2.0的实现必须跳过这些有效负载并忽略其内容。
IKEv2 adds a "critical" flag to each payload header for further flexibility for forward compatibility. If the critical flag is set and the payload type is unrecognized, the message MUST be rejected and the response to the IKE request containing that payload MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an unsupported critical payload was included. If the critical flag is not set and the payload type is unsupported, that payload MUST be ignored.
IKEv2为每个有效负载头添加了一个“关键”标志，以进一步提高向前兼容性的灵活性。如果设置了critical（关键）标志且无法识别有效负载类型，则必须拒绝该消息，并且对包含该有效负载的IKE请求的响应必须包括Notify payload UNSUPPORTED_critical_有效负载，指示包含了不受支持的关键有效负载。如果未设置临界标志且有效负载类型不受支持，则必须忽略该有效负载。
Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in section 2 and implementations SHOULD reject as invalid a message with those payloads in any other order.
尽管将来可能会添加新的有效负载类型，并且可能与本规范中定义的字段交叉出现，但实现必须按照第2节图中所示的顺序发送本规范中定义的有效负载，并且实现应以任何其他顺序拒绝带有这些有效负载的消息。
The term "cookies" originates with Karn and Simpson [RFC2522] in Photuris, an early proposal for key management with IPsec, and it has persisted. The Internet Security Association and Key Management Protocol (ISAKMP) [MSST98] fixed message header includes two eight-octet fields titled "cookies", and that syntax is used by both IKEv1 and IKEv2 though in IKEv2 they are referred to as the IKE SPI and there is a new separate field in a Notify payload holding the cookie. The initial two eight-octet fields in the header are used as a connection identifier at the beginning of IKE packets. Each endpoint
“cookies”一词起源于Photuris中的Karn和Simpson[RFC2522]，这是一个关于IPsec密钥管理的早期建议，并且一直存在。Internet安全关联和密钥管理协议（ISAKMP）[MSST98]固定消息头包括两个名为“cookies”的八位字节字段，该语法由IKEv1和IKEv2使用，尽管在IKEv2中它们被称为IKE SPI，并且在保存cookie的通知有效载荷中有一个新的单独字段。头中最初的两个八位字节字段用作IKE数据包开头的连接标识符。每个端点
chooses one of the two SPIs and SHOULD choose them so as to be unique identifiers of an IKE_SA. An SPI value of zero is special and indicates that the remote SPI value is not yet known by the sender.
选择两个SPI中的一个，并应选择它们作为IKE_SA的唯一标识符。SPI值为零是特殊的，表示发送方尚未知道远程SPI值。
Unlike ESP and AH where only the recipient's SPI appears in the header of a message, in IKE the sender's SPI is also sent in every message. Since the SPI chosen by the original initiator of the IKE_SA is always sent first, an endpoint with multiple IKE_SAs open that wants to find the appropriate IKE_SA using the SPI it assigned must look at the I(nitiator) Flag bit in the header to determine whether it assigned the first or the second eight octets.
与ESP和AH不同，在ESP和AH中，只有收件人的SPI出现在消息头中，在IKE中，发件人的SPI也会在每条消息中发送。由于IKE_SA的原始发起方选择的SPI始终首先发送，因此，如果要使用分配的SPI查找适当的IKE_SA，则打开多个IKE_SA的端点必须查看报头中的I（启动器）标志位，以确定其分配的是第一个八位字节还是第二个八位字节。
In the first message of an initial IKE exchange, the initiator will not know the responder's SPI value and will therefore set that field to zero.
在初始IKE交换的第一条消息中，发起方将不知道响应方的SPI值，因此将该字段设置为零。
An expected attack against IKE is state and CPU exhaustion, where the target is flooded with session initiation requests from forged IP addresses. This attack can be made less effective if an implementation of a responder uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which it claims to be sending them. To accomplish this, a responder SHOULD -- when it detects a large number of half-open IKE_SAs -- reject initial IKE messages unless they contain a Notify payload of type COOKIE. It SHOULD instead send an unprotected IKE message as a response and include COOKIE Notify payload with the cookie data to be returned. Initiators who receive such responses MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE containing the responder supplied cookie data as the first payload and all other payloads unchanged. The initial exchange will then be as follows:
针对IKE的预期攻击是状态和CPU耗尽，其中来自伪造IP地址的会话启动请求充斥目标。如果响应程序的实现使用最少的CPU，并且在知道发起程序可以在其声称发送数据包的地址接收数据包之前，不向SA提交任何状态，则此攻击可能会降低效率。为了实现这一点，响应程序应该——当它检测到大量半开放IKE_SA时——拒绝初始IKE消息，除非它们包含COOKIE类型的Notify负载。相反，它应该发送一个不受保护的IKE消息作为响应，并将COOKIE Notify负载和要返回的COOKIE数据一起包括在内。接收此类响应的启动器必须重试IKE_SA_INIT，并使用COOKIE类型的Notify payload（通知有效负载），其中包含响应者提供的COOKIE数据作为第一个有效负载，所有其他有效负载保持不变。初始交换将如下所示：
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
<--HDR（A、B）、SAr1、KEr、Nr、[CERTREQ]
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The first two messages do not affect any initiator or responder state except for communicating the cookie. In particular, the message sequence numbers in the first four messages will all be zero and the message sequence numbers in the last two messages will be one. 'A' is the SPI assigned by the initiator, while 'B' is the SPI assigned by the responder.
前两条消息不影响任何发起方或响应方的状态，但与cookie通信除外。特别是，前四条消息中的消息序列号将全部为零，最后两条消息中的消息序列号将为一。”“A”是发起者分配的SPI，“B”是响应者分配的SPI。
An IKE implementation SHOULD implement its responder cookie generation in such a way as to not require any saved state to recognize its valid cookie when the second IKE_SA_INIT message arrives. The exact algorithms and syntax they use to generate cookies do not affect interoperability and hence are not specified here. The following is an example of how an endpoint could use cookies to implement limited DOS protection.
IKE实现应以这样的方式实现其响应器cookie生成，即当第二条IKE_SA_INIT消息到达时，不需要任何保存的状态来识别其有效cookie。它们用于生成cookie的确切算法和语法不会影响互操作性，因此此处未指定。以下是端点如何使用cookie实现有限的DOS保护的示例。
A good way to do this is to set the responder cookie to be:
执行此操作的一个好方法是将响应者cookie设置为：
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
where <secret> is a randomly generated secret known only to the responder and periodically changed and | indicates concatenation. <VersionIDofSecret> should be changed whenever <secret> is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to <secret> and that IPi must be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE_SAs are being set up in parallel they will all get different cookies (assuming the initiator chooses unique SPIi's). Incorporating Ni into the hash ensures that an attacker who sees only message 2 can't successfully forge a message 3.
其中，<secret>是一个随机生成的秘密，只有响应者知道，并定期更改，|表示串联<只要重新生成<secret>，就应该更改VersionIDofSecret>。当IKE_SA_INIT第二次到达并与接收到的消息中的cookie进行比较时，可以重新计算cookie。如果匹配，响应者知道cookie是在上次更改为<secret>后生成的，并且IPi必须与第一次看到的源地址相同。将SPIi合并到计算中可确保，如果并行设置多个IKE_SA，它们将获得不同的cookie（假设启动器选择唯一的SPIi）。将Ni合并到哈希中可确保仅看到消息2的攻击者无法成功伪造消息3。
If a new value for <secret> is chosen while there are connections in the process of being initialized, an IKE_SA_INIT might be returned with other than the current <VersionIDofSecret>. The responder in that case MAY reject the message by sending another response with a new cookie or it MAY keep the old value of <secret> around for a short time and accept cookies computed from either one. The responder SHOULD NOT accept cookies indefinitely after <secret> is changed, since that would defeat part of the denial of service protection. The responder SHOULD change the value of <secret> frequently, especially if under attack.
如果在初始化过程中存在连接时为<secret>选择了一个新值，则IKE_SA_INIT可能会返回当前<VersionIDofSecret>以外的值。在这种情况下，响应者可以通过发送另一个带有新cookie的响应来拒绝消息，或者它可以在短时间内保留<secret>的旧值，并接受从其中任何一个计算出的cookie。响应者不应在<secret>更改后无限期地接受cookie，因为这将破坏部分拒绝服务保护。响应者应经常更改<secret>的值，尤其是在受到攻击时。
The payload type known as "SA" indicates a proposal for a set of choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well as cryptographic algorithms associated with each protocol.
称为“SA”的有效负载类型表示为SA选择一组IPsec协议（IKE、ESP和/或AH）以及与每个协议相关联的加密算法的建议。
An SA payload consists of one or more proposals. Each proposal includes one or more protocols (usually one). 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 identifier does not completely specify the cryptographic algorithm).
SA有效负载由一个或多个方案组成。每个提案包括一个或多个协议（通常为一个）。每个协议都包含一个或多个转换——每个转换指定一个加密算法。每个转换包含零个或多个属性（仅当转换标识符未完全指定加密算法时才需要属性）。
This hierarchical structure was designed to efficiently encode proposals for cryptographic suites when the number of supported suites is large because multiple values are acceptable for multiple transforms. 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 or more protocols. If a proposal is accepted, the SA response MUST contain the same protocols in the same order as the proposal. The responder MUST accept a single proposal or reject them all and return an error. (Example: if a single proposal contains ESP and AH and that proposal is accepted, both ESP and AH MUST be accepted. If ESP and AH are included in separate proposals, the responder MUST accept only one of them).
每个提案包含一个或多个协议。如果提案被接受，SA响应必须包含与提案顺序相同的协议。响应者必须接受单个提议或拒绝所有提议并返回错误。（例如：如果单个提案包含ESP和AH，并且该提案被接受，则ESP和AH都必须被接受。如果ESP和AH包含在单独的提案中，则响应者只能接受其中一个）。
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.
每个IPsec协议提案都包含一个或多个转换。每个变换都包含一个变换类型。接受的加密套件必须仅包含提案中包含的每种类型的一个转换。例如：如果ESP方案包括转换ENCR_3DES、ENCR_AES w/keysize 128、ENCR_AES w/keysize 256、AUTH_HMAC_MD5和AUTH_HMAC_SHA，则接受的套件必须包含一个ENCR_转换和一个AUTH_转换。因此，可以接受六种组合。
Since the initiator sends its Diffie-Hellman value in the IKE_SA_INIT, it must guess the Diffie-Hellman group that the responder will select from its list of supported groups. If the initiator guesses wrong, the responder will respond with a Notify payload of type INVALID_KE_PAYLOAD indicating the selected group. In this case, the initiator MUST retry the IKE_SA_INIT with the corrected Diffie-Hellman group. The initiator MUST again propose its full set of acceptable cryptographic suites because the rejection message was unauthenticated and otherwise an active attacker could trick the endpoints into negotiating a weaker suite than a stronger one that they both prefer.
由于发起程序在IKE_SA_INIT中发送其Diffie Hellman值，因此它必须猜测响应程序将从其支持的组列表中选择的Diffie Hellman组。如果发起者猜错了，响应者将使用INVALID_KEU_payload类型的Notify有效负载进行响应，指示所选组。在这种情况下，启动器必须使用更正的Diffie-Hellman组重试IKE_SA_INIT。发起方必须再次提出其可接受的全套加密套件，因为拒绝消息未经验证，否则主动攻击者可能会诱使端点协商一个较弱的套件，而不是双方都喜欢的较强的套件。
IKE, ESP, and AH security associations use secret keys that SHOULD be used only for a limited amount of time and to protect a limited amount of data. This limits the lifetime of the entire security association. When the lifetime of a security association expires, the security association MUST NOT be used. If there is demand, new security associations MAY be established. Reestablishment of security associations to take the place of ones that expire is referred to as "rekeying".
IKE、ESP和AH安全关联使用的密钥应仅在有限的时间内使用，并保护有限的数据量。这限制了整个安全关联的生存期。当安全关联的生存期到期时，不得使用该安全关联。如果有需要，可以建立新的安全协会。重新建立安全关联以取代过期的安全关联称为“密钥更新”。
To allow for minimal IPsec implementations, the ability to rekey SAs without restarting the entire IKE_SA is optional. An implementation MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA has expired or is about to expire and rekeying attempts using the mechanisms described here fail, an implementation MUST close the IKE_SA and any associated CHILD_SAs and then MAY start new ones. Implementations SHOULD support in-place rekeying of SAs, since doing so offers better performance and is likely to reduce the number of packets lost during the transition.
为了实现最小的IPsec实现，可以选择在不重新启动整个IKE_SA的情况下重新设置SAs密钥。实现可以拒绝IKE_SA中的所有CREATE_CHILD_SA请求。如果SA已过期或即将过期，并且使用此处描述的机制重新设置密钥的尝试失败，则实现必须关闭IKE_SA和任何关联的子SA，然后可以启动新的子SA。实现应该支持SAs的就地密钥更新，因为这样做可以提供更好的性能，并且有可能减少转换过程中丢失的数据包数量。
To rekey a CHILD_SA within an existing IKE_SA, create a new, equivalent SA (see section 2.17 below), and when the new one is established, delete the old one. To rekey an IKE_SA, establish a new equivalent IKE_SA (see section 2.18 below) with the peer to whom the old IKE_SA is shared using a CREATE_CHILD_SA within the existing IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's CHILD_SAs. Use the new IKE_SA for all control messages needed to maintain the CHILD_SAs created by the old IKE_SA, and delete the old IKE_SA. The Delete payload to delete itself MUST be the last request sent over an IKE_SA.
要在现有IKE_SA中为子SA重新设置密钥，请创建一个新的等效SA（见下文第2.17节），并在建立新SA后删除旧SA。要重新设置IKE_SA的密钥，请与使用现有IKE_SA中的创建子SA共享旧IKE_SA的对等方建立新的等效IKE_SA（见下文第2.18节）。这样创建的IKE_SA继承了原始IKE_SA的所有子SA。将新IKE_SA用于维护由旧IKE_SA创建的子SA所需的所有控制消息，并删除旧IKE_SA。要删除自身的删除有效负载必须是通过IKE_SA发送的最后一个请求。
SAs SHOULD be rekeyed proactively, i.e., the new SA should be established before the old one expires and becomes unusable. Enough time should elapse between the time the new SA is established and the old one becomes unusable so that traffic can be switched over to the new SA.
应主动更新SA，即新SA应在旧SA到期且无法使用之前建立。在建立新SA和旧SA变得不可用之间应经过足够的时间，以便将流量切换到新SA。
A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. If an SA bundle has been inactive for a long time and if an endpoint would not initiate the SA in the absence of traffic, the endpoint MAY choose to close the SA instead of rekeying it when its lifetime expires. It SHOULD do so if there has been no traffic since the last time the SA was rekeyed.
IKEv1和IKEv2之间的区别在于，在IKEv1中，SA的寿命是协商的。在IKEv2中，SA的每一端都负责在SA上实施自己的生存期策略，并在必要时重新设置SA的密钥。如果两端具有不同的生存期策略，则生存期较短的一端将始终是请求密钥更新的一端。如果SA捆绑长期处于非活动状态，并且如果端点在没有流量的情况下不会启动SA，则端点可以选择关闭SA，而不是在其生存期到期时重新设置SA密钥。如果自上次重新设置SA密钥以来没有任何流量，则应该这样做。
If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered (delayed by a random amount of time after the need for rekeying is noticed).
如果两端具有相同的生存期策略，则两者可能同时启动密钥更新（这将导致冗余SA）。为了降低发生这种情况的概率，应该抖动重新键入请求的时间（在注意到需要重新键入后延迟随机时间）。
This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it.
这种形式的密钥更新可能会暂时导致同一对节点之间出现多个类似的SA。当有两个SA有资格接收数据包时，节点必须通过任一SA接收传入数据包。如果通过这种冲突创建了冗余SA，则创建该SA的端点应关闭使用两个交换中使用的四个nonce中最低的nonce创建的SA。
Note that IKEv2 deliberately allows parallel SAs with the same traffic selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [RFC2474], [RFC2475], and section 4.1 of [RFC2983]). Hence unlike IKEv1, the combination of the endpoints and the traffic selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate traffic selectors SHOULD NOT be used.
请注意，IKEv2故意允许在公共端点之间使用相同流量选择器的并行SA。其目的之一是支持SA之间的业务服务质量（QoS）差异（参见[RFC2474]、[RFC2475]和[RFC2983]第4.1节）。因此，与IKEv1不同，端点和流量选择器的组合可能不会唯一地标识那些端点之间的SA，因此不应使用基于重复流量选择器删除SA的IKEv1密钥更新启发式。
The node that initiated the surviving rekeyed SA SHOULD delete the replaced SA after the new one is established.
在建立新SA后，启动幸存的重新密钥SA的节点应删除替换的SA。
There are timing windows -- particularly in the presence of lost packets -- where endpoints may not agree on the state of an SA. The responder to a CREATE_CHILD_SA MUST be prepared to accept messages on an SA before sending its response to the creation request, so there is no ambiguity for the initiator. The initiator MAY begin sending on an SA as soon as it processes the response. The initiator, however, cannot receive on a newly created SA until it receives and processes the response to its CREATE_CHILD_SA request. How, then, is the responder to know when it is OK to send on the newly created SA?
存在定时窗口——特别是在存在丢失数据包的情况下——其中端点可能不同意SA的状态。CREATE_CHILD_SA的响应者必须准备好接受SA上的消息，然后再发送其对创建请求的响应，因此启动器没有歧义。发起方可以在处理响应后立即开始在SA上发送。但是，在启动器接收并处理对其创建子SA请求的响应之前，它无法在新创建的SA上接收。那么，响应者如何知道何时可以发送新创建的SA？
From a technical correctness and interoperability perspective, the responder MAY begin sending on an SA as soon as it sends its response to the CREATE_CHILD_SA request. In some situations, however, this could result in packets unnecessarily being dropped, so an implementation MAY want to defer such sending.
从技术正确性和互操作性的角度来看，只要响应者发送了对CREATE_CHILD_SA请求的响应，就可以开始在SA上发送。然而，在某些情况下，这可能会导致不必要地丢弃数据包，因此实现可能希望延迟此类发送。
The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA. When rekeying an SA, the responder SHOULD continue to send messages on the old SA until one of those events occurs. When establishing a new SA, the responder MAY defer sending messages on a
如果（1）启动器已在新SA上接收到加密有效的消息，或者（2）新SA对现有SA重新加密，并接收到关闭替换SA的IKE请求，则可以确保响应者准备在SA上接收消息。在为SA重新键入密钥时，响应者应继续在旧SA上发送消息，直到其中一个事件发生。当建立新SA时，响应者可以延迟在网络上发送消息
new SA until either it receives one or a timeout has occurred. If an initiator receives a message on an SA for which it has not received a response to its CREATE_CHILD_SA request, it SHOULD interpret that as a likely packet loss and retransmit the CREATE_CHILD_SA request. An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages.
新建SA，直到收到一个SA或发生超时为止。如果启动器在SA上接收到一条消息，但尚未收到对其CREATE_CHILD_SA请求的响应，则应将其解释为可能的数据包丢失，并重新传输CREATE_CHILD_SA请求。如果新创建的SA没有消息排队，则启动器可以在其上发送虚拟消息，以确保响应者启动器已准备好接收消息。
When an IP packet is received by an RFC4301-compliant IPsec subsystem and matches a "protect" selector in its Security Policy Database (SPD), the subsystem MUST protect that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system's SPD is outside the scope of IKE (see [PFKEY] for an example protocol), though some implementations might update their SPD in connection with the running of IKE (for an example scenario, see section 1.1.3).
当符合RFC4301的IPsec子系统接收到IP数据包并匹配其安全策略数据库（SPD）中的“保护”选择器时，子系统必须使用IPsec保护该数据包。当尚不存在SA时，IKE的任务是创建SA。系统SPD的维护不在IKE的范围内（参见[PFKEY]了解示例协议），尽管一些实现可能会结合IKE的运行更新其SPD（参见第1.1.3节了解示例场景）。
Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their SPD to their peers. TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA. This can serve as a consistency check in some scenarios to assure that the SPDs are consistent. In others, it guides the dynamic update of the SPD.
流量选择器（TS）有效负载允许端点将一些信息从其SPD传输到其对等方。TS有效负载指定将通过新设置的SA转发的数据包的选择标准。在某些情况下，这可以作为一致性检查，以确保SPD的一致性。在其他情况下，它指导SPD的动态更新。
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. In support of the scenario described in section 1.1.3, an initiator may request that the responder assign an IP address and tell the initiator what it is.
两个TS有效负载出现在创建子_SA对的exchange中的每条消息中。每个TS有效负载包含一个或多个流量选择器。每个流量选择器由一个地址范围（IPv4或IPv6）、一个端口范围和一个IP协议ID组成。为了支持第1.1.3节中描述的场景，发起方可以请求响应方分配一个IP地址，并告诉发起方它是什么。
IKEv2 allows the responder to choose a subset of the traffic proposed by the initiator. This could happen when the configurations of the two endpoints are being updated but only one end has received the new information. Since the two endpoints may be configured by different people, the incompatibility may persist for an extended period even in the absence of errors. It also allows for intentionally different configurations, as when one end is configured to tunnel all addresses and depends on the other end to have the up-to-date list.
IKEv2允许响应者选择发起者提议的通信量的子集。当两个端点的配置正在更新，但只有一端接收到新信息时，可能会发生这种情况。由于两个端点可能由不同的人配置，因此即使在没有错误的情况下，不兼容性也可能持续很长一段时间。它还允许有意不同的配置，例如一端配置为隧道所有地址，并依赖另一端拥有最新列表。
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
两个TS有效负载中的第一个称为TSi（流量选择器启动器）。第二种称为TSr（流量选择器响应器）。TSi指定从子_SA对的启动器转发的流量的源地址（或转发到的流量的目标地址）。TSr指定通信量的目标地址
forwarded to (or the source address of the traffic forwarded from) the responder of the CHILD_SA pair. For example, if the original initiator request the creation of a CHILD_SA pair, and wishes to tunnel all traffic from subnet 192.0.1.* on the initiator's side to subnet 192.0.2.* on the responder's side, the initiator would include a single traffic selector in each TS payload. TSi would specify the address range (192.0.1.0 - 192.0.1.255) and TSr would specify the address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was acceptable to the responder, it would send identical TS payloads back. (Note: The IP address range 192.0.2.* has been reserved for use in examples in RFCs and similar documents. This document needed two such ranges, and so also used 192.0.1.*. This should not be confused with any actual address.)
转发至子_SA对的响应者（或转发自该子_SA对的流量的源地址）。例如，如果原始启动器请求创建子_SA对，并希望通过隧道将所有流量从启动器侧的子网192.0.1.*传输到响应方侧的子网192.0.2.*，则启动器将在每个TS有效负载中包含一个流量选择器。TSi将指定地址范围（192.0.1.0-192.0.1.255），TSr将指定地址范围（192.0.2.0-192.0.2.255）。假设响应者可以接受该建议，它将发送相同的TS有效负载。（注意：IP地址范围192.0.2.*已保留用于RFC和类似文档中的示例。本文档需要两个这样的范围，因此也使用了192.0.1.*。这不应与任何实际地址混淆。）
The responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating or narrowing the range of one or more members of the set of traffic selectors, provided the set does not become the NULL set.
允许响应者通过选择通信量的子集来缩小选择范围，例如，通过消除或缩小通信量选择器集合的一个或多个成员的范围，前提是该集合不成为空集合。
It is possible for the responder's policy to contain multiple smaller ranges, all encompassed by the initiator's traffic selector, and with the responder's policy being that each of those ranges should be sent over a different SA. Continuing the example above, the responder might have a policy of being willing to tunnel those addresses to and from the initiator, but might require that each address pair be on a separately negotiated CHILD_SA. If the initiator generated its request in response to an incoming packet from 192.0.1.43 to 192.0.2.123, there would be no way for the responder to determine which pair of addresses should be included in this tunnel, and it would have to make a guess or reject the request with a status of SINGLE_PAIR_REQUIRED.
响应者的策略可能包含多个较小的范围，所有范围都由启动器的流量选择器包含，并且响应者的策略是，这些范围中的每一个都应通过不同的SA发送。继续上面的示例，响应者可能有一个愿意通过隧道将这些地址传送到发起方和从发起方传送出去的策略，但可能要求每个地址对位于单独协商的子_SA上。如果发起方响应从192.0.1.43到192.0.2.123的传入数据包生成其请求，则响应方将无法确定此隧道中应包含哪对地址，并且它将不得不猜测或拒绝状态为SINGLE_pair_REQUIRED的请求。
To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first traffic selector in each of TSi and TSr a very specific traffic selector including the addresses in the packet triggering the request. In the example, the initiator would include in TSi two traffic selectors: the first containing the address range (192.0.1.43 - 192.0.1.43) and the source port and IP protocol from the packet and the second containing (192.0.1.0 - 192.0.1.255) with all ports and IP protocols. The initiator would similarly include two traffic selectors in TSr.
在这种情况下，为了使响应者能够选择适当的范围，如果发起方由于数据分组而请求SA，则发起方应在每个TSi和TSr中包括一个非常特定的流量选择器作为第一个流量选择器，该流量选择器包括触发请求的分组中的地址。在该示例中，启动器将在TSi中包括两个流量选择器：第一个包含地址范围（192.0.1.43-192.0.1.43）和来自数据包的源端口和IP协议，第二个包含所有端口和IP协议（192.0.1.0-192.0.1.255）。发起方将类似地在TSr中包括两个流量选择器。
If the responder's policy does not allow it to accept the entire set of traffic selectors in the initiator's request, but does allow him to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the
如果响应者的策略不允许它接受发起者请求中的整个流量选择器集，但允许他接受TSi和TSr的第一个选择器，则响应者必须将流量选择器缩小到包含
initiator's first choices. In this example, the responder might respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and IP protocols.
发起者的第一选择。在此示例中，响应程序可能会使用TSi（192.0.1.43-192.0.1.43）和所有端口和IP协议进行响应。
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 MAY be ranges rather than specific values, and the responder chooses a subset of the initiator's TSi and TSr that are acceptable. If more than one subset is acceptable but their union is not, the responder MUST accept some subset and MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to try again. This case will occur only when the initiator and responder are configured differently from one another. If the initiator and responder agree on the granularity of tunnels, the initiator will never request a tunnel wider than the responder will accept. Such misconfigurations SHOULD be recorded in error logs.
如果发起者创建子_SA对不是为了响应到达的数据包，而是在启动时创建，那么发起者可能不喜欢初始隧道的特定地址。在这种情况下，TSi和TSr中的第一个值可以是范围而不是特定值，并且响应者选择可接受的发起方的TSi和TSr的子集。如果多个子集是可接受的，但它们的并集不是可接受的，则响应者必须接受某个子集，并且可能包括类型为“附加”的通知有效负载，以指示启动器可能希望重试。只有当启动器和响应程序的配置不同时，才会发生这种情况。如果发起者和响应者在隧道的粒度上达成一致，发起者将永远不会请求比响应者所能接受的更宽的隧道。此类错误配置应记录在错误日志中。
The IKE_SA_INIT messages each contain a nonce. These nonces are used as inputs to cryptographic functions. The CREATE_CHILD_SA request and the CREATE_CHILD_SA response also contain nonces. These nonces are used to add freshness to the key derivation technique used to obtain keys for CHILD_SA, and to ensure creation of strong pseudo-random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated prf. ("prf" refers to "pseudo-random function", one of the cryptographic algorithms negotiated in the IKE exchange.) If the same random number source is used for both keys and nonces, care must be taken to ensure that the latter use does not compromise the former.
IKE_SA_INIT消息每个都包含一个nonce。这些nonce用作加密函数的输入。CREATE_CHILD_SA请求和CREATE_CHILD_SA响应也包含nonce。这些nonce用于为用于获取CHILD_SA密钥的密钥派生技术添加新鲜度，并确保从Diffie-Hellman密钥创建强伪随机位。IKEv2中使用的nonce必须随机选择，大小必须至少为128位，并且必须至少为协商prf的密钥大小的一半。（“prf”指的是“伪随机函数”，即IKE交换中协商的加密算法之一。）如果密钥和nonce都使用相同的随机数源，则必须注意确保后者的使用不会损害前者。
IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. The IP addresses and ports in the outer header are, however, not themselves cryptographically protected, and IKE is designed to work even through Network Address Translation (NAT) boxes. An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. IKE functions identically over IPv4 or IPv6.
IKE在UDP端口500和4500上运行，并隐式地为其运行的相同IP地址设置ESP和AH关联。然而，外部报头中的IP地址和端口本身并没有加密保护，IKE设计为即使通过网络地址转换（NAT）盒也能工作。即使源端口不是500或4500，实现也必须接受传入请求，并且必须响应接收请求的地址和端口。它必须指定接收请求的地址和端口作为响应中的源地址和端口。IKE在IPv4或IPv6上的功能相同。
IKE generates keying material using an ephemeral Diffie-Hellman exchange in order to gain the property of "perfect forward secrecy". This means that once a connection is closed and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the two endpoints cannot reconstruct the keys used to protect the conversation without doing a brute force search of the session key space.
IKE使用短暂的Diffie-Hellman交换生成密钥材料，以获得“完美前向保密”的特性。这意味着，一旦连接关闭且其对应的密钥被遗忘，即使是记录了连接中的所有数据并访问了两个端点的所有长期密钥的人，也无法在不对会话密钥空间进行强制搜索的情况下重建用于保护会话的密钥。
Achieving perfect forward secrecy requires that when a connection is closed, each endpoint MUST forget not only the keys used by the connection but also any information that could be used to recompute those keys. In particular, it MUST forget the secrets used in the Diffie-Hellman calculation and any state that may persist in the state of a pseudo-random number generator that could be used to recompute the Diffie-Hellman secrets.
要实现完美的前向保密性，需要在连接关闭时，每个端点不仅必须忘记连接使用的密钥，还必须忘记可用于重新计算这些密钥的任何信息。特别是，它必须忘记Diffie-Hellman计算中使用的秘密以及伪随机数生成器状态中可能存在的任何状态，该伪随机数生成器可用于重新计算Diffie-Hellman秘密。
Since the computing of Diffie-Hellman exponentials is computationally expensive, an endpoint may find it advantageous to reuse those exponentials for multiple connection setups. There are several reasonable strategies for doing this. An endpoint could choose a new exponential only periodically though this could result in less-than-perfect forward secrecy if some connection lasts for less than the lifetime of the exponential. Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state.
由于Diffie-Hellman指数的计算在计算上非常昂贵，端点可能会发现将这些指数用于多个连接设置是有利的。有几种合理的策略可以做到这一点。端点只能周期性地选择一个新的指数，但如果某些连接持续时间少于指数的生命周期，则这可能会导致不完美的前向保密性。或者，它可以跟踪每个连接使用的是哪个指数，并且只有在某些对应的连接关闭时才删除与指数相关的信息。这将允许在不丢失完美的前向保密性的情况下重用指数，而代价是维护更多的状态。
Decisions as to whether and when to reuse Diffie-Hellman exponentials is a private decision in the sense that it will not affect interoperability. An implementation that reuses exponentials MAY choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the calculation.
关于是否重用Diffie-Hellman指数以及何时重用Diffie-Hellman指数的决定是一个私人决定，因为它不会影响互操作性。重用指数的实现可能会选择记住另一个端点在过去的交换中使用的指数，如果重用一个端点，则可以避免计算的后半部分。
In the context of the IKE_SA, four cryptographic algorithms are negotiated: an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a pseudo-random function (prf). The pseudo-random function is used for the construction of keying material for all of the cryptographic algorithms used in both the IKE_SA and the CHILD_SAs.
在IKE_SA的上下文中，协商了四种加密算法：加密算法、完整性保护算法、Diffie-Hellman群和伪随机函数（prf）。伪随机函数用于构造IKE_SA和CHILD_SA中使用的所有加密算法的密钥材料。
We assume that each encryption algorithm and integrity protection algorithm uses a fixed-size key and that any randomly chosen value of that fixed size can serve as an appropriate key. For algorithms that accept a variable length key, a fixed key size MUST be specified as part of the cryptographic transform negotiated. For algorithms for which not all values are valid keys (such as DES or 3DES with key parity), the algorithm by which keys are derived from arbitrary values MUST be specified by the cryptographic transform. For integrity protection functions based on Hashed Message Authentication Code (HMAC), the fixed key size is the size of the output of the underlying hash function. When the prf function takes a variable length key, variable length data, and produces a fixed-length output (e.g., when using HMAC), the formulas in this document apply. When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula.
我们假设每个加密算法和完整性保护算法都使用固定大小的密钥，并且任意随机选择的固定大小的值都可以作为适当的密钥。对于接受可变长度密钥的算法，必须将固定密钥大小指定为加密转换的一部分。对于并非所有值都是有效密钥的算法（如具有密钥奇偶性的DES或3DES），密码转换必须指定从任意值派生密钥的算法。对于基于哈希消息身份验证码（HMAC）的完整性保护函数，固定密钥大小是基础哈希函数输出的大小。当prf函数采用可变长度键、可变长度数据并产生固定长度输出（例如，当使用HMAC时），本文档中的公式适用。当prf函数的键具有固定长度时，作为键提供的数据会根据需要被截断或用零填充，除非以下公式解释了异常处理。
Keying material will always be derived as the output of the negotiated prf algorithm. Since the amount of keying material needed may be greater than the size of the output of the prf algorithm, we will use the prf iteratively. We will use the terminology prf+ to describe the function that outputs a pseudo-random stream based on the inputs to a prf as follows: (where | indicates concatenation)
键控材料将始终作为协商prf算法的输出导出。由于所需的键控材料量可能大于prf算法输出的大小，因此我们将迭代使用prf。我们将使用术语prf+来描述基于prf输入输出伪随机流的函数，如下所示：（其中|表示串联）
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）
continuing as needed to compute all required keys. The keys are taken from the output string without regard to boundaries (e.g., if the required keys are a 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC key, and the prf function generates 160 bits, the AES key will come from T1 and the beginning of T2, while the HMAC key will come from the rest of T2 and the beginning of T3).
根据需要继续计算所有必需的密钥。密钥取自输出字符串而不考虑边界（例如，如果所需密钥是256位高级加密标准（AES）密钥和160位HMAC密钥，并且prf函数生成160位，则AES密钥将来自T1和T2的开头，而HMAC密钥将来自T2的其余部分和T3的开头）。
The constant concatenated to the end of each string feeding the prf is a single octet. prf+ in this document is not defined beyond 255 times the size of the prf output.
连接到提供prf的每个字符串末尾的常量是一个八位字节。本文档中prf+的定义不超过prf输出大小的255倍。
The shared keys are computed as follows. A quantity called SKEYSEED is calculated from the nonces exchanged during the IKE_SA_INIT exchange and the Diffie-Hellman shared secret established during that
共享密钥的计算如下所示。根据IKE_SA_INIT交换期间交换的nonce和在此期间建立的Diffie Hellman共享秘密计算出一个称为Skeysed的量
exchange. SKEYSEED is used to calculate seven other secrets: SK_d used for deriving new keys for the CHILD_SAs established with this IKE_SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges; SK_ei and SK_er used for encrypting (and of course decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are used when generating an AUTH payload.
交换SKEYSEED用于计算其他七个秘密：SK_d用于为使用此IKE_SA建立的子SA导出新密钥；SK_ai和SK_ar用作完整性保护算法的密钥，用于验证后续交换的组件消息；用于加密（当然还有解密）所有后续交换的SK_ei和SK_er；以及SK_pi和SK_pr，它们在生成身份验证有效负载时使用。
SKEYSEED and its derivatives are computed as follows:
SKEYSEED及其衍生物的计算如下：
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 )
(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. If the negotiated prf takes a fixed-length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each.
（指示量SK_d、SK_ai、SK_ar、SK_ei、SK_er、SK_pi和SK_pr是按顺序从prf+的生成位获取的）。g^ir是短暂的Diffie-Hellman交换的共享秘密。g^ir表示为一个以大端顺序排列的八位字节串，如果需要，用零填充，以使其成为模的长度。Ni和Nr是无任何标题的nonce。如果协商的prf采用固定长度密钥，并且Ni和Nr的长度加起来不等于该长度，则一半的位必须来自Ni，另一半来自Nr，取每个密钥的第一位。
The two directions of traffic flow use different keys. 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. Each algorithm takes a fixed number of bits of keying material, which is specified as part of the algorithm. For integrity algorithms based on a keyed hash, the key size is always equal to the length of the output of the underlying hash function.
交通流的两个方向使用不同的键。用于保护来自原始启动器的消息的密钥是sku ai和sku ei。用于保护另一个方向的消息的键是SK_-ar和SK_-er。每个算法都采用固定数量的键控材料位，这是算法的一部分。对于基于键控哈希的完整性算法，键大小始终等于基础哈希函数输出的长度。
When not using extensible authentication (see section 2.16), the peers are authenticated by having each sign (or MAC using a shared secret as the key) a block of data. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message and end with the last octet of the last payload in the second message. Appended to this (for purposes of computing the signature) are the initiator's nonce Ni (just the value, not the payload containing it), and the value prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding the fixed header. Note that neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of
当不使用可扩展身份验证（参见第2.16节）时，通过让每个签名（或使用共享密钥作为密钥的MAC）具有一个数据块来对对等方进行身份验证。对于响应者，要签名的八位字节以第二条消息的报头中第一个SPI的第一个八位字节开始，并以第二条消息中最后一个有效负载的最后一个八位字节结束。附加在这之后（为了计算签名）的是发起方的nonce Ni（只是值，而不是包含它的有效载荷），以及值prf（SK_pr，IDr'），其中IDr'是响应方的ID有效载荷，不包括固定报头。注意，既不传输nonce Ni也不传输值prf（SK_pr，IDr'）。类似地，启动器对第一条消息进行签名，从报头中第一个SPI的第一个八位字节开始，以最后一个有效负载的最后一个八位字节结束。附于本文件之后（为了
computing the signature) are the responder's nonce Nr, and the value prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the entire ID payloads excluding the fixed header. It is critical to the security of the exchange that each side sign the other side's nonce.
计算签名）是响应者的nonce Nr和值prf（SK_pi，IDi'）。在上述计算中，IDi'和IDr'是不包括固定标头的整个ID有效载荷。每一方签署另一方的临时证书对交易所的安全至关重要。
Note that all of the payloads are included under the signature, including any payload types not defined in this document. If the first message of the exchange is sent twice (the second time with a responder cookie and/or a different Diffie-Hellman group), it is the second version of the message that is signed.
请注意，所有有效载荷都包含在签名下，包括本文档中未定义的任何有效载荷类型。如果交换的第一条消息发送两次（第二次使用响应者cookie和/或不同的Diffie Hellman组），则签名的是该消息的第二个版本。
Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload. The signature or MAC will be computed using algorithms dictated by the type of key used by the signer, and specified by the Auth Method field in the Authentication payload. There is no requirement that the initiator and responder sign with the same cryptographic algorithms. The choice of cryptographic algorithms depends on the type of key each has. In particular, the initiator may be using a shared key while the responder may have a public signature key and certificate. It will commonly be the case (but it is not required) that if a shared secret is used for authentication that the same key is used in both directions. Note that it is a common but typically insecure practice to have a shared key derived solely from a user-chosen password without incorporating another source of randomness.
可选地，消息3和4可以包括证书或证书链，该证书或证书链提供用于计算数字签名的密钥属于ID有效载荷中的名称的证据。签名或MAC将使用由签名者使用的密钥类型指定的算法进行计算，并由身份验证有效负载中的Auth Method字段指定。不要求发起者和响应者使用相同的加密算法签名。加密算法的选择取决于每种算法的密钥类型。具体地，发起方可以使用共享密钥，而响应方可以具有公共签名密钥和证书。通常情况下（但不是必需的），如果共享密钥用于身份验证，则在两个方向上使用相同的密钥。请注意，一种常见但通常不安全的做法是，仅从用户选择的密码派生共享密钥，而不包含其他随机性来源。
This is typically insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method. (Applications using password-based authentication for bootstrapping and IKE_SA should use the authentication method in section 2.16, which is designed to prevent off-line dictionary attacks.) The pre-shared key SHOULD contain as much unpredictability as the strongest key being negotiated. In the case of a pre-shared key, the AUTH value is computed as:
这通常是不安全的，因为用户选择的密码不太可能具有足够的不可预测性来抵抗字典攻击，并且这种身份验证方法无法防止这些攻击。（使用基于密码的身份验证进行引导和IKE_SA的应用程序应使用第2.16节中的身份验证方法，该方法旨在防止离线字典攻击。）预共享密钥应包含与协商的最强密钥一样多的不可预测性。对于预共享密钥，AUTH值的计算如下：
AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
where the string "Key Pad for IKEv2" is 17 ASCII characters without null termination. The shared secret can be variable length. The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store the value prf(Shared Secret,"Key Pad for IKEv2"), which could not be used as a password equivalent for protocols other than IKEv2. As noted above, deriving the shared secret from a password is not secure. This construction is used because it is anticipated that people will do it anyway. The
其中字符串“IKEv2的键盘”为17个ASCII字符，无空终止。共享秘密可以是可变长度的。添加pad字符串，以便如果共享密钥来自密码，则IKE实现不需要以明文形式存储密码，而是可以存储值prf（共享密钥，“IKEv2的键盘”），该值不能用作IKEv2以外协议的等效密码。如上所述，从密码导出共享秘密是不安全的。之所以使用这种结构，是因为预计人们无论如何都会这样做。这个
management interface by which the Shared Secret is provided MUST accept ASCII strings of at least 64 octets and MUST NOT add a null terminator before using them as shared secrets. It MUST also accept a HEX encoding of the Shared Secret. The management interface MAY accept other encodings if the algorithm for translating the encoding to a binary string is specified. If the negotiated prf takes a fixed-size key, the shared secret MUST be of that fixed size.
提供共享机密的管理接口必须接受至少64个八位字节的ASCII字符串，并且在将其用作共享机密之前不得添加空终止符。它还必须接受共享秘密的十六进制编码。如果指定了将编码转换为二进制字符串的算法，则管理接口可以接受其他编码。如果协商的prf采用固定大小的密钥，则共享密钥必须具有该固定大小。
In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public key signature based authentication of the responder to the initiator. These methods are often associated with mechanisms referred to as "Legacy Authentication" mechanisms.
除了使用公钥签名和共享秘密进行身份验证外，IKE还支持使用RFC 3748[EAP]中定义的方法进行身份验证。通常，这些方法是不对称的（专为向服务器进行身份验证的用户而设计），并且它们可能不是相互的。因此，这些协议通常用于向响应者验证启动器，并且必须与基于公钥签名的响应者向启动器验证结合使用。这些方法通常与称为“遗留身份验证”机制的机制相关联。
While this memo references [EAP] with the intent that new methods can be added in the future without updating this specification, some simpler variations are documented here and in section 3.16. [EAP] defines an authentication protocol requiring a variable number of messages. Extensible Authentication is implemented in IKE as additional IKE_AUTH exchanges that MUST be completed in order to initialize the IKE_SA.
虽然本备忘录引用[EAP]的目的是在未来可以在不更新本规范的情况下添加新方法，但此处和第3.16节中记录了一些更简单的变化。[EAP]定义了需要可变数量消息的身份验证协议。可扩展身份验证作为附加的IKE_身份验证交换在IKE中实现，必须完成这些交换才能初始化IKE_SA。
An initiator indicates a desire to use extensible authentication by leaving out the AUTH payload from message 3. By including an IDi payload but not an AUTH payload, the initiator has declared an identity but has not proven it. If the responder is willing to use an extensible authentication method, it will place an Extensible Authentication Protocol (EAP) payload in message 4 and defer sending SAr2, TSi, and TSr until initiator authentication is complete in a subsequent IKE_AUTH exchange. In the case of a minimal extensible authentication, the initial SA establishment will appear as follows:
发起者通过在消息3中省略AUTH有效负载来表示希望使用可扩展身份验证。通过包含IDi有效负载而不是身份验证有效负载，发起方声明了一个身份，但没有证明它。如果响应者愿意使用可扩展身份验证方法，它将在消息4中放置可扩展身份验证协议（EAP）有效负载，并延迟发送SAr2、TSi和TSr，直到在后续IKE_身份验证交换中完成启动器身份验证。在最小可扩展身份验证的情况下，初始SA建立将如下所示：
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<--HDR、SAr1、KEr、Nr、[CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr} -->
HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, EAP }
<--HDR，SK{IDr，[CERT，]AUTH，EAP}
HDR, SK {EAP} -->
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr }
<-- HDR, SK {AUTH, SAr2, TSi, TSr }
For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the initiator and responder to generate AUTH payloads in messages 7 and 8 using the syntax for shared secrets specified in section 2.15. The shared key from EAP is the field from the EAP specification named MSK. The shared key generated during an IKE exchange MUST NOT be used for any other purpose.
对于创建共享密钥作为身份验证副作用的EAP方法，启动器和响应程序必须使用该共享密钥，以使用第2.15节中指定的共享机密语法在消息7和消息8中生成身份验证有效载荷。EAP中的共享密钥是EAP规范中名为MSK的字段。IKE交换期间生成的共享密钥不得用于任何其他目的。
EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks [EAPMITM] if these EAP methods are used in other protocols that do not use a server-authenticated tunnel. Please see the Security Considerations section for more details. If EAP methods that do not generate a shared key are used, the AUTH payloads in messages 7 and 8 MUST be generated using SK_pi and SK_pr, respectively.
不应使用未建立共享密钥的EAP方法，因为如果这些EAP方法用于不使用服务器身份验证隧道的其他协议中，它们会受到许多中间人攻击[EAPMITM]。有关更多详细信息，请参阅安全注意事项部分。如果使用不生成共享密钥的EAP方法，则必须分别使用SK_pi和SK_pr生成消息7和8中的身份验证有效负载。
The initiator of an IKE_SA using EAP SHOULD be capable of extending the initial protocol exchange to at least ten IKE_AUTH exchanges in the event the responder sends notification messages and/or retries the authentication prompt. Once the protocol exchange defined by the chosen EAP authentication method has successfully terminated, the responder MUST send an EAP payload containing the Success message. Similarly, if the authentication method has failed, the responder MUST send an EAP payload containing the Failure message. The responder MAY at any time terminate the IKE exchange by sending an EAP payload containing the Failure message.
如果响应者发送通知消息和/或重试身份验证提示，则使用EAP的IKE_SA的启动器应能够将初始协议交换扩展到至少十个IKE_认证交换。一旦所选EAP身份验证方法定义的协议交换成功终止，响应者必须发送包含成功消息的EAP有效负载。类似地，如果身份验证方法失败，响应者必须发送包含失败消息的EAP有效负载。响应者可随时通过发送包含故障消息的EAP有效载荷来终止IKE交换。
Following such an extended exchange, the EAP AUTH payloads MUST be included in the two messages following the one containing the EAP Success message.
在这种扩展交换之后，EAP AUTH有效负载必须包含在包含EAP Success消息的消息之后的两条消息中。
A single CHILD_SA is created by the IKE_AUTH exchange, and additional CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. Keying material for them is generated as follows:
IKE_AUTH交换创建了一个子SA，可以选择在CREATE_CHILD_SA交换中创建其他子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 if this request is the first CHILD_SA created or the fresh Ni and Nr from the CREATE_CHILD_SA exchange if this is a subsequent creation.
其中，Ni和Nr是来自IKE_SA_INIT交换的nonce（如果该请求是创建的第一个子项），或者是来自CREATE_CHILD_SA交换的新Ni和Nr（如果这是后续创建）。
For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman exchange, the keying material is defined as:
对于包括可选Diffie-Hellman交换的CREATE_CHILD_SA交换，键控材质定义为：
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
where g^ir (new) is the shared secret from the ephemeral Diffie-Hellman exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros in the high-order bits if necessary to make it the length of the modulus).
其中，g^ir（new）是来自此CREATE_CHILD_SA交换的短暂Diffie-Hellman交换的共享秘密（表示为一个以大端顺序排列的八位组字符串，如果需要，在高阶位中填充零以使其成为模的长度）。
A single CHILD_SA negotiation may result in multiple security associations. ESP and AH SAs exist in pairs (one in each direction), and four SAs could be created in a single CHILD_SA negotiation if a combination of ESP and AH is being negotiated.
单个子_SA协商可能导致多个安全关联。ESP和AH SA成对存在（每个方向一个），如果正在协商ESP和AH的组合，则可以在单个子_SA协商中创建四个SA。
Keying material MUST be taken from the expanded KEYMAT in the following order:
钥匙材料必须按以下顺序从扩展钥匙垫中取出：
All keys for SAs carrying data from the initiator to the responder are taken before SAs going in the reverse direction.
将数据从启动器传输到响应程序的SAs的所有键在SAs反向运行之前都会被取下。
If multiple IPsec protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet.
如果协商了多个IPsec协议，则按照协议头在封装数据包中出现的顺序获取密钥材料。
If a single protocol has both encryption and authentication keys, the encryption key is taken from the first octets of KEYMAT and the authentication key is taken from the next octets.
如果单个协议同时具有加密密钥和身份验证密钥，则加密密钥取自KEYMAT的第一个八位字节，身份验证密钥取自下一个八位字节。
Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm.
每种加密算法都采用固定数量的键控材料位，这些材料位被指定为算法的一部分。
The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA (see section 2.8). New initiator and responder SPIs are supplied in the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. SKEYSEED for the new IKE_SA is computed using SK_d from the existing IKE_SA as follows:
CREATE_CHILD_SA交换可用于为现有IKE_SA重新设置密钥（参见第2.8节）。SPI字段中提供了新的启动器和响应程序SPI。在为IKE_SA重新设置密钥时，TS有效载荷被忽略。新IKE_SA的skeysed使用现有IKE_SA的SK_d计算，如下所示：
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
where g^ir (new) is the shared secret from the ephemeral Diffie-Hellman exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros if necessary to make it the length of the modulus) and Ni and Nr are the two nonces stripped of any headers.
其中，g^ir（new）是来自此CREATE_CHILD_SA交换的短暂Diffie-Hellman交换的共享秘密（表示为一个以大端顺序填充零的八位字节字符串，如果有必要，使其成为模的长度），Ni和Nr是从任何头中剥离的两个nonce。
The new IKE_SA MUST reset its message counters to 0.
新IKE_SA必须将其消息计数器重置为0。
SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as specified in section 2.14.
sku d、sku ai、sku ar、sku ei和sku er根据第2.14节规定的skyseed进行计算。
Most commonly occurring in the endpoint-to-security-gateway scenario, an endpoint may need an IP address in the network protected by the security gateway and may need to have that address dynamically assigned. A request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload.
在端点到安全网关场景中最常见的情况是，端点可能需要安全网关保护的网络中的IP地址，并且可能需要动态分配该地址。通过包括CP有效载荷，可以在创建子_SA的任何请求（包括消息3中的隐式请求）中包括对这种临时地址的请求。
This function provides address allocation to an IPsec Remote Access Client (IRAC) trying to tunnel into a network protected by an IPsec Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled address (and optionally other information concerning the protected network) in the IKE_AUTH exchange. The IRAS may procure an address for the IRAC from any number of sources such as a DHCP/BOOTP server or its own address pool.
此函数为试图通过隧道进入受IPsec远程访问服务器（IRAS）保护的网络的IPsec远程访问客户端（IRAC）提供地址分配。由于IKE_认证交换创建IKE_SA和子SA，IRAC必须在IKE_认证交换中请求IRAS控制的地址（以及可选的其他有关受保护网络的信息）。IRA可以从任何数量的源（如DHCP/BOOTP服务器或其自己的地址池）获取IRAC的地址。
Initiator Responder
----------------------------- ---------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr} -->
Initiator Responder
----------------------------- ---------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr}
<--HDR，SK{IDr，[CERT，]AUTH，CP（CFG_回复），SAr2，TSi，TSr}
In all cases, the CP payload MUST be inserted before the SA payload. In variations of the protocol where there are multiple IKE_AUTH exchanges, the CP payloads MUST be inserted in the messages containing the SA payloads.
在所有情况下，CP有效负载必须在SA有效负载之前插入。在存在多个IKE_AUTH交换的协议变体中，必须将CP有效负载插入包含SA有效负载的消息中。
CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but MAY contain any number of additional attributes the initiator wants returned in the response.
CP（CFG_请求）必须至少包含一个内部_地址属性（IPv4或IPv6），但可以包含启动器希望在响应中返回的任何数量的附加属性。
For example, message from initiator to responder:
CP(CFG_REQUEST)=
INTERNAL_ADDRESS(0.0.0.0)
INTERNAL_NETMASK(0.0.0.0)
INTERNAL_DNS(0.0.0.0)
TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
For example, message from initiator to responder:
CP(CFG_REQUEST)=
INTERNAL_ADDRESS(0.0.0.0)
INTERNAL_NETMASK(0.0.0.0)
INTERNAL_DNS(0.0.0.0)
TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
NOTE: Traffic Selectors contain (protocol, port range, address range).
注意：流量选择器包含（协议、端口范围、地址范围）。
Message from responder to initiator:
从响应者到启动器的消息：
CP(CFG_REPLY)=
INTERNAL_ADDRESS(192.0.2.202)
INTERNAL_NETMASK(255.255.255.0)
INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
CP(CFG_REPLY)=
INTERNAL_ADDRESS(192.0.2.202)
INTERNAL_NETMASK(255.255.255.0)
INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
All returned values will be implementation dependent. As can be seen in the above example, the IRAS MAY also send other attributes that were not included in CP(CFG_REQUEST) and MAY ignore the non-mandatory attributes that it does not support.
所有返回值都将取决于实现。从上述示例中可以看出，IRA还可以发送CP（CFG_请求）中未包含的其他属性，并且可以忽略其不支持的非强制性属性。
The responder MUST NOT send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the IKE exchange with a FAILED_CP_REQUIRED error.
在未首先从发起方收到CP（CFG_请求）之前，响应方不得发送CFG_回复，因为如果IRAC无法处理回复，我们不希望IRA执行不必要的配置查找。如果IRAS的配置要求CP用于给定的标识IDi，但IRAC未能发送CP（CFG_请求），IRAS必须使请求失败，并以失败的_CP_请求错误终止IKE交换。
An IKE peer wishing to inquire about the other peer's IKE software version information MAY use the method below. This is an example of a configuration request within an INFORMATIONAL exchange, after the IKE_SA and first CHILD_SA have been created.
希望查询另一对等方的IKE软件版本信息的IKE对等方可以使用以下方法。这是创建IKE_SA和第一个子_SA后信息交换中的配置请求示例。
An IKE implementation MAY decline to give out version information prior to authentication or even after authentication to prevent trolling in case some implementation is known to have some security weakness. In that case, it MUST either return an empty string or no CP payload if CP is not supported.
IKE实现可能会拒绝在身份验证之前或甚至在身份验证之后提供版本信息，以防止在已知某些实现存在某些安全弱点的情况下出现误操作。在这种情况下，如果不支持CP，则必须返回空字符串或不返回CP有效负载。
Initiator Responder
----------------------------- --------------------------
HDR, SK{CP(CFG_REQUEST)} -->
<-- HDR, SK{CP(CFG_REPLY)}
Initiator Responder
----------------------------- --------------------------
HDR, SK{CP(CFG_REQUEST)} -->
<-- HDR, SK{CP(CFG_REPLY)}
CP(CFG_REQUEST)= APPLICATION_VERSION("")
CP（CFG_请求）=应用程序_版本（“”）
CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")
CP（CFG_回复）应用程序_版本（“foobar v1.3beta，（c）foobar Inc.））
There are many kinds of errors that can occur during IKE processing. If a request is received that is badly formatted or unacceptable for reasons of policy (e.g., no matching cryptographic algorithms), the response MUST contain a Notify payload indicating the error. If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem.
IKE处理过程中可能会发生多种错误。如果收到的请求由于策略原因（例如，没有匹配的加密算法）格式不正确或不可接受，则响应必须包含指示错误的Notify有效负载。如果在IKE请求的上下文之外发生错误（例如，节点在不存在的SPI上获取ESP消息），则节点应启动信息交换，并使用描述问题的Notify有效负载。
Errors that occur before a cryptographically protected IKE_SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service attack based on forged messages.
必须非常小心地处理在建立受加密保护的IKE_SA之前发生的错误。在希望帮助诊断和响应问题与希望避免在基于伪造消息的拒绝服务攻击中被欺骗之间存在着一种权衡。
If a node receives a message on UDP port 500 or 4500 outside the context of an IKE_SA known to it (and not a request to start one), it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI.
如果节点在其已知IKE_SA的上下文之外的UDP端口500或4500上接收到消息（而不是启动消息的请求），则可能是节点最近崩溃的结果。如果消息标记为响应，则节点可以审核可疑事件，但不得响应。如果消息被标记为请求，则节点可以审核可疑事件并发送响应。如果发送响应，则必须将响应发送到IP地址和端口，该IP地址和端口来自相同的IKE SPI和复制的消息ID。响应必须不受加密保护，并且必须包含指示无效\u IKE\u SPI的Notify有效负载。
A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response the genuine correspondent was
接收此类未受保护的Notify有效负载的节点不得响应，也不得更改任何现有SA的状态。该消息可能是伪造的，也可能是真正的通讯员的回应
tricked into sending. A node SHOULD treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and SHOULD initiate a liveness test for any such IKE_SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack.
被骗去送信。节点应将此类消息（以及类似ICMP destination unreachable的网络消息）视为指向该IP地址的SA可能存在问题的提示，并应启动任何此类IKE_SA的活动性测试。实现应限制此类测试的频率，以避免被骗参与拒绝服务攻击。
A node receiving a suspicious message from an IP address with which it has an IKE_SA MAY send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SA's as a result but SHOULD audit the event to aid in diagnosing malfunctions. A node MUST limit the rate at which it will send messages in response to unprotected messages.
从其具有IKE_SA的IP地址接收可疑消息的节点可以通过该SA在IKE信息交换中发送IKE Notify有效负载。接收者不得因此改变任何SA的状态，但应审核事件以帮助诊断故障。节点必须限制其发送消息以响应未受保护的消息的速率。
Use of IP compression [IPCOMP] can be negotiated as part of the setup of a CHILD_SA. While IP compression involves an extra header in each packet and a compression parameter index (CPI), the virtual "compression association" has no life outside the ESP or AH SA that contains it. Compression associations disappear when the corresponding ESP or AH SA goes away. It is not explicitly mentioned in any DELETE payload.
IP压缩[IPCOMP]的使用可以作为子_SA设置的一部分进行协商。虽然IP压缩涉及每个数据包中的额外报头和压缩参数索引（CPI），但虚拟“压缩关联”在包含它的ESP或AH SA之外没有生命。当相应的ESP或AH SA消失时，压缩关联消失。在任何删除有效负载中都没有明确提到它。
Negotiation of IP compression is separate from the negotiation of cryptographic parameters associated with a CHILD_SA. A node requesting a CHILD_SA MAY advertise its support for one or more compression algorithms through one or more Notify payloads of type IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT occur in messages that do not contain SA payloads.
IP压缩的协商独立于与子_SA相关的加密参数的协商。请求子_SA的节点可以通过一个或多个类型为IPCOMP_-SUPPORTED的Notify有效载荷来公布其对一个或多个压缩算法的支持。响应可能表示接受支持IPCOMP_类型的通知有效负载的单个压缩算法。这些有效负载不得出现在不包含SA有效负载的消息中。
Although there has been discussion of allowing multiple compression algorithms to be accepted and to have different compression algorithms available for the two directions of a CHILD_SA, implementations of this specification MUST NOT accept an IPComp algorithm that was not proposed, MUST NOT accept more than one, and MUST NOT compress using an algorithm other than one proposed and accepted in the setup of the CHILD_SA.
尽管已经讨论过允许接受多个压缩算法，并允许不同的压缩算法可用于一个子系统的两个方向，但本规范的实施不得接受未提出的IPComp算法，也不得接受多个IPComp算法，并且不得使用在子系统设置中提出并接受的算法以外的算法进行压缩。
A side effect of separating the negotiation of IPComp from cryptographic parameters is that it is not possible to propose multiple cryptographic suites and propose IP compression with some of them but not others.
将IPComp的协商与加密参数分离的一个副作用是，不可能提出多个加密套件，也不可能提出使用其中一些套件的IP压缩，而不是其他套件。
Network Address Translation (NAT) gateways are a controversial subject. This section briefly describes what they are and how they are likely to act on IKE traffic. Many people believe that NATs are evil and that we should not design our protocols so as to make them work better. IKEv2 does specify some unintuitive processing rules in order that NATs are more likely to work.
网络地址转换（NAT）网关是一个有争议的话题。本节简要描述了它们是什么以及它们可能如何对IKE流量起作用。许多人认为NAT是邪恶的，我们不应该设计我们的协议来让它们更好地工作。IKEv2确实指定了一些非直观的处理规则，以便NAT更容易工作。
NATs exist primarily because of the shortage of IPv4 addresses, though there are other rationales. IP nodes that are "behind" a NAT have IP addresses that are not globally unique, but rather are assigned from some space that is unique within the network behind the NAT but that are likely to be reused by nodes behind other NATs. Generally, nodes behind NATs can communicate with other nodes behind the same NAT and with nodes with globally unique addresses, but not with nodes behind other NATs. There are exceptions to that rule. When those nodes make connections to nodes on the real Internet, the NAT gateway "translates" the IP source address to an address that will be routed back to the gateway. Messages to the gateway from the Internet have their destination addresses "translated" to the internal address that will route the packet to the correct endnode.
NAT的存在主要是因为IPv4地址的短缺，尽管还有其他原因。NAT“后面”的IP节点的IP地址不是全局唯一的，而是从NAT后面的网络中唯一但可能被其他NAT后面的节点重用的某个空间分配的。通常，NAT后面的节点可以与同一NAT后面的其他节点以及具有全局唯一地址的节点通信，但不能与其他NAT后面的节点通信。这条规则也有例外。当这些节点连接到真实Internet上的节点时，NAT网关将IP源地址“转换”为将路由回网关的地址。从Internet发送到网关的消息将其目标地址“转换”为内部地址，该地址将数据包路由到正确的端节点。
NATs are designed to be "transparent" to endnodes. Neither software on the node behind the NAT nor the node on the Internet requires modification to communicate through the NAT. Achieving this transparency is more difficult with some protocols than with others. Protocols that include IP addresses of the endpoints within the payloads of the packet will fail unless the NAT gateway understands the protocol and modifies the internal references as well as those in the headers. Such knowledge is inherently unreliable, is a network layer violation, and often results in subtle problems.
NAT被设计为对端节点“透明”。NAT后面的节点上的软件和Internet上的节点都不需要修改才能通过NAT进行通信。某些协议比其他协议更难实现这种透明度。除非NAT网关理解协议并修改内部引用以及报头中的引用，否则包含数据包有效负载内端点IP地址的协议将失败。这些知识本质上是不可靠的，是违反网络层的，并且常常导致微妙的问题。
Opening an IPsec connection through a NAT introduces special problems. If the connection runs in transport mode, changing the IP addresses on packets will cause the checksums to fail and the NAT cannot correct the checksums because they are cryptographically protected. Even in tunnel mode, there are routing problems because transparently translating the addresses of AH and ESP packets requires special logic in the NAT and that logic is heuristic and unreliable in nature. For that reason, IKEv2 can negotiate UDP encapsulation of IKE and ESP packets. This encoding is slightly less efficient but is easier for NATs to process. In addition, firewalls may be configured to pass IPsec traffic over UDP but not ESP/AH or vice versa.
通过NAT打开IPsec连接会带来特殊问题。如果连接在传输模式下运行，更改数据包上的IP地址将导致校验和失败，NAT无法更正校验和，因为它们受到加密保护。即使在隧道模式下，也存在路由问题，因为透明地转换AH和ESP数据包的地址需要NAT中的特殊逻辑，并且该逻辑本质上是启发式的和不可靠的。因此，IKEv2可以协商IKE和ESP数据包的UDP封装。这种编码效率稍低，但NAT更容易处理。此外，防火墙可以配置为通过UDP传递IPsec流量，但不能通过ESP/AH，反之亦然。
It is a common practice of NATs to translate TCP and UDP port numbers as well as addresses and use the port numbers of inbound packets to decide which internal node should get a given packet. For this reason, even though IKE packets MUST be sent from and to UDP port 500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. This is because the ports may be modified as the packets pass through NATs. Similarly, IP addresses of the IKE endpoints are generally not included in the IKE payloads because the payloads are cryptographically protected and could not be transparently modified by NATs.
NAT的常见做法是转换TCP和UDP端口号以及地址，并使用入站数据包的端口号来决定哪个内部节点应获得给定数据包。因此，即使IKE数据包必须从UDP端口500发送到UDP端口500，也必须接受来自任何端口的数据包，并且必须将响应发送到它们来自的端口。这是因为当数据包通过NAT时，端口可能会被修改。类似地，IKE端点的IP地址通常不包括在IKE有效负载中，因为有效负载受到加密保护，并且不能被NAT透明地修改。
Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working through a NAT, it is generally better to pass IKE packets over port 4500 because some older NATs handle IKE traffic on port 500 cleverly in an attempt to transparently establish IPsec connections between endpoints that don't handle NAT traversal themselves. Such NATs may interfere with the straightforward NAT traversal envisioned by this document, so an IPsec endpoint that discovers a NAT between it and its correspondent MUST send all subsequent traffic to and from port 4500, which NATs should not treat specially (as they might with port 500).
端口4500保留给UDP封装的ESP和IKE。当通过NAT工作时，通常最好通过端口4500传递IKE数据包，因为一些较旧的NAT巧妙地处理端口500上的IKE流量，试图在不处理NAT遍历的端点之间透明地建立IPsec连接。此类NAT可能会干扰本文档设想的直接NAT遍历，因此，在其与对应方之间发现NAT的IPsec端点必须向端口4500发送所有后续通信量，并且从端口4500发送所有后续通信量，NAT不应特别处理这些通信量（如端口500）。
The specific requirements for supporting NAT traversal [RFC3715] are listed below. Support for NAT traversal is optional. In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal.
下面列出了支持NAT穿越[RFC3715]的具体要求。对NAT遍历的支持是可选的。仅在本节中，列出的要求必须仅适用于支持NAT遍历的实现。
IKE MUST listen on port 4500 as well as port 500. IKE MUST respond to the IP address and port from which packets arrived.
IKE必须侦听端口4500和端口500。IKE必须响应数据包到达的IP地址和端口。
Both IKE initiator and responder MUST include in their IKE_SA_INIT packets Notify payloads of type NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect if there is NAT between the hosts, and which end is behind the NAT. The location of the payloads in the IKE_SA_INIT packets are just after the Ni and Nr payloads (before the optional CERTREQ payload).
IKE启动器和响应程序都必须在其IKE_SA_INIT数据包中包含通知NAT_检测_源_IP和NAT_检测_目的地_IP类型的有效负载。这些有效负载可用于检测主机之间是否存在NAT，以及哪一端位于NAT后面。IKE_SA_INIT数据包中的有效载荷位置正好位于Ni和Nr有效载荷之后（在可选CERTREQ有效载荷之前）。
If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches the hash of the source IP and port found from the IP header of the packet containing the payload, it means that the other end is behind NAT (i.e., someone along the route changed the source address of the original packet to match the address of the NAT box). In this case, this end should allow dynamic update of the other ends IP address, as described later.
如果接收到的NAT_检测_源_IP有效载荷与从包含有效载荷的数据包的IP报头中找到的源IP和端口的哈希值均不匹配，则表示另一端在NAT后面（即，沿途有人更改原始数据包的源地址以匹配NAT盒的地址）。在这种情况下，该端应允许动态更新另一端的IP地址，如下文所述。
If the NAT_DETECTION_DESTINATION_IP payload received does not match the hash of the destination IP and port found from the IP header of the packet containing the payload, it means that this end is behind a NAT. In this case, this end SHOULD start sending keepalive packets as explained in [Hutt05].
如果接收到的NAT_检测_目的地_IP有效负载与从包含有效负载的数据包的IP报头中找到的目的地IP和端口的哈希不匹配，则表示该端位于NAT后面。在这种情况下，该端应该开始发送keepalive数据包，如[Hutt05]中所述。
The IKE initiator MUST check these payloads if present and if they do not match the addresses in the outer packet MUST tunnel all future IKE and ESP packets associated with this IKE_SA over UDP port 4500.
IKE启动器必须检查这些有效负载（如果存在），如果它们与外部数据包中的地址不匹配，则必须通过UDP端口4500对与此IKE_SA关联的所有未来IKE和ESP数据包进行隧道传输。
To tunnel IKE packets over UDP port 4500, the IKE header has four octets of zero prepended and the result immediately follows the UDP header. To tunnel ESP packets over UDP port 4500, the ESP header immediately follows the UDP header. Since the first four bytes of the ESP header contain the SPI, and the SPI cannot validly be zero, it is always possible to distinguish ESP and IKE messages.
要通过UDP端口4500对IKE数据包进行隧道传输，IKE报头有四个八位字节，前缀为零，结果紧跟在UDP报头之后。要通过UDP端口4500对ESP数据包进行隧道传输，ESP报头将紧跟在UDP报头之后。由于ESP头的前四个字节包含SPI，并且SPI不能有效地为零，因此始终可以区分ESP和IKE消息。
The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [Hutt05]) are obtained from the Traffic Selectors associated with the exchange. In the case of NAT traversal, the Traffic Selectors MUST contain exactly one IP address, which is then used as the original IP address.
传输模式TCP和UDP数据包校验和修正（参见[Hutt05]）所需的原始源和目标IP地址从与交换相关联的流量选择器获得。在NAT穿越的情况下，流量选择器必须只包含一个IP地址，然后将其用作原始IP地址。
There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retransmission packets) to the IP address and port from the last valid authenticated packet from the other end (i.e., dynamically update the address). A host behind a NAT SHOULD NOT do this because it opens a DoS attack possibility. Any authenticated IKE packet or any authenticated UDP-encapsulated ESP packet can be used to detect that the IP address or the port has changed.
有些情况下，NAT盒决定删除仍处于活动状态的映射（例如，keepalive间隔太长，或者NAT盒重新启动）。为了在这些情况下进行恢复，不在NAT后面的主机应将来自另一端的最后一个有效认证数据包的所有数据包（包括重传数据包）发送到IP地址和端口（即动态更新地址）。NAT后面的主机不应该这样做，因为这会导致DoS攻击的可能性。任何经过身份验证的IKE数据包或任何经过身份验证的UDP封装ESP数据包都可用于检测IP地址或端口是否已更改。
Note that similar but probably not identical actions will likely be needed to make IKE work with Mobile IP, but such processing is not addressed by this document.
请注意，要使IKE与移动IP协同工作，可能需要类似但可能不完全相同的操作，但本文档未涉及此类处理。
When IPsec tunnels behave as originally specified in [RFC2401], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1- based IPsec requires multiple operating modes and negotiation (see
当IPsec隧道按照[RFC2401]中最初指定的方式运行时，ECN的使用不适合外部IP头，因为隧道解除封装处理会丢弃ECN拥塞指示，从而损害网络。ECN对基于IKEv1的IPsec的IPsec隧道的支持需要多种操作模式和协商（请参阅
[RFC3168]). IKEv2 simplifies this situation by requiring that ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel-mode SAs created by IKEv2 MUST support the ECN full-functionality option for tunnels specified in [RFC3168] and MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC4301] to prevent discarding of ECN congestion indications.
[RFC3168]）。IKEv2通过要求ECN在IKEv2创建的所有隧道模式IPsec SA的外部IP头中可用，简化了这种情况。具体而言，IKEv2创建的所有隧道模式SA的隧道封装器和去封装器必须支持[RFC3168]中指定的隧道的ECN完整功能选项，并且必须实施[RFC4301]中指定的隧道封装和去封装处理，以防止丢弃ECN拥塞指示。
IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. When sent on UDP port 500, IKE messages begin immediately following the UDP header. When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zero are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. Each IKE message begins with the IKE header, denoted HDR in this memo. Following the header are one or more IKE payloads each identified by a "Next Payload" field in the preceding payload. Payloads are processed in the order in which they appear in an IKE message by invoking the appropriate processing routine according to 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.
IKE消息使用UDP端口500和/或4500，每个UDP数据报有一条IKE消息。除了来自报头的IP地址和UDP端口被反转并用于返回数据包之外，从数据包开始到UDP报头的信息基本上被忽略。当在UDP端口500上发送时，IKE消息在UDP报头之后立即开始。当在UDP端口4500上发送时，IKE消息已在四个八位字节前加上零。这四个零八位组不是IKE消息的一部分，也不包括在IKE定义的任何长度字段或校验和中。每个IKE消息都以IKE头开始，在本备忘录中表示为HDR。在报头之后是一个或多个IKE有效载荷，每个有效载荷由前一有效载荷中的“下一有效载荷”字段标识。通过根据IKE报头中的“下一个有效载荷”字段并随后根据IKE有效载荷本身中的“下一个有效载荷”字段调用适当的处理例程，按照它们在IKE消息中出现的顺序处理有效载荷，直到“下一个有效载荷”字段为零表示没有有效载荷跟随。如果找到“加密”类型的有效负载，则该有效负载将被解密，其内容将被解析为附加有效负载。加密的有效负载必须是数据包中的最后一个有效负载，并且加密的有效负载不得包含另一个加密的有效负载。
The Recipient SPI in the header identifies an instance of an IKE security association. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers.
标头中的收件人SPI标识IKE安全关联的实例。因此，IKE的单个实例可以与多个对等方多路传输不同的会话。
All multi-octet fields representing integers are laid out in big endian order (aka most significant byte first, or network byte order).
所有表示整数的多个八位字节字段都按大端顺序排列（也称为最高有效字节优先，或网络字节顺序）。
The format of the IKE header is shown in Figure 4.
IKE头的格式如图4所示。
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 4: IKE Header Format
图4: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 (including repeats of that message including a cookie) and MUST NOT be zero in any other message.
o 响应者的SPI（8个八位字节）-响应者选择的一个值，用于标识唯一的IKE安全关联。此值在IKE初始交换的第一条消息中必须为零（包括该消息的重复，包括cookie），在任何其他消息中不得为零。
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. Implementations based on previous versions of IKE and ISAKMP MUST set the Major Version to 1. Implementations based on this version of IKE MUST reject or ignore messages containing a version number greater than 2.
o 主要版本（4位）-表示正在使用的IKE协议的主要版本。基于此版本的IKE的实现必须将主版本设置为2。基于以前版本的IKE和ISAKMP的实现必须将主版本设置为1。基于此版本的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 0. They MUST ignore the minor version number of received messages.
o 次要版本（4位）-表示正在使用的IKE协议的次要版本。基于此版本的IKE的实现必须将次要版本设置为0。他们必须忽略收到的消息的次要版本号。
o Exchange Type (1 octet) - Indicates the type of exchange being used. This constrains the payloads sent in each message and orderings of messages in an exchange.
o 交换类型（1个八位字节）-表示正在使用的交换类型。这将限制在每个消息中发送的有效负载以及exchange中消息的顺序。
Exchange Type Value
交换类型值
RESERVED 0-33 IKE_SA_INIT 34 IKE_AUTH 35 CREATE_CHILD_SA 36 INFORMATIONAL 37 RESERVED TO IANA 38-239 Reserved for private use 240-255
保留0-33 IKE_SA_INIT 34 IKE_AUTH 35创建儿童_SA 36信息37保留给IANA 38-239保留给私人使用240-255
o Flags (1 octet) - Indicates specific options that are set for the message. Presence of options are indicated by the appropriate bit in the flags field being set. The bits are defined LSB first, so bit 0 would be the least significant bit of the Flags octet. In the description below, a bit being 'set' means its value is '1', while 'cleared' means its value is '0'.
o 标志（1个八位字节）-表示为消息设置的特定选项。选项的存在由正在设置的标志字段中的相应位表示。位首先定义为LSB，因此位0将是标志八位字节的最低有效位。在下面的描述中，“设置”表示其值为“1”，而“清除”表示其值为“0”。
-- X(reserved) (bits 0-2) - These bits MUST be cleared when sending and MUST be ignored on receipt.
--X（保留）（位0-2）-发送时必须清除这些位，接收时必须忽略这些位。
-- I(nitiator) (bit 3 of Flags) - 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 eight octets of the SPI were generated by the recipient.
--I（启动器）（标志位3）-此位必须在IKE_SA的原始启动器发送的消息中设置，并且必须在原始响应者发送的消息中清除。接收者使用它来确定接收者生成了哪八个SPI八位字节。
-- V(ersion) (bit 4 of Flags) - 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 number field. Implementations of IKEv2 must clear this bit when sending and MUST ignore it in incoming messages.
--V（版本）（标志的第4位）-该位表示发射机能够说出比主版本号字段中所示更高的协议主版本号。IKEv2的实现在发送时必须清除该位，并且在传入消息中必须忽略该位。
-- R(esponse) (bit 5 of Flags) - 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 IKE endpoint MUST NOT generate a response to a message that is marked as being a response.
--R（响应）（标志位5）-此位表示此消息是对包含相同消息ID的消息的响应。此位必须在所有请求消息中清除，并且必须在所有响应中设置。IKE端点不得对标记为响应的消息生成响应。
-- X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared when sending and MUST be ignored on receipt.
--X（保留）（标志位6-7）-发送时必须清除这些位，并且在接收时必须忽略这些位。
o Message ID (4 octets) - 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. See sections 2.1 and 2.2.
o 消息ID（4个八位字节）-用于控制丢失数据包的重新传输以及请求和响应的匹配的消息标识符。它对协议的安全性至关重要，因为它用于防止消息重放攻击。见第2.1节和第2.2节。
o Length (4 octets) - Length of total message (header + payloads) in octets.
o 长度（4个八位字节）-以八位字节为单位的总消息长度（报头+有效负载）。
Each IKE payload defined in sections 3.3 through 3.16 begins with a generic payload header, shown in Figure 5. Figures for each payload below will include the generic payload header, but for brevity the description of each field will be omitted.
第3.3节至第3.16节中定义的每个IKE有效负载都以通用有效负载头开始，如图5所示。下面每个有效载荷的数字将包括通用有效载荷标题，但为简洁起见，将省略每个字段的描述。
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 5: Generic Payload Header
图5：通用有效负载标题
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 0. This field provides a "chaining" capability whereby additional payloads can be added to a message by appending it 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 0).
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能，通过将附加有效负载附加到消息末尾并设置前一有效负载的“下一有效负载”字段以指示新有效负载的类型，可以将附加有效负载添加到消息中。加密的有效负载（必须始终是消息的最后一个有效负载）是一个例外。它包含附加有效载荷格式的数据结构。在加密有效负载的报头中，下一个有效负载字段设置为第一个包含的有效负载的有效负载类型（而不是0）。
Payload Type Values
有效负载类型值
Next Payload Type Notation Value
下一个有效负载类型表示值
No Next Payload 0
没有下一个有效负载0
RESERVED 1-32 Security Association SA 33 Key Exchange KE 34 Identification - Initiator IDi 35
保留的1-32安全关联SA 33密钥交换KE 34标识-启动器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 Vendor ID V 43 Traffic Selector - Initiator TSi 44 Traffic Selector - Responder TSr 45 Encrypted E 46 Configuration CP 47 Extensible Authentication EAP 48 RESERVED TO IANA 49-127 PRIVATE USE 128-255
标识-响应者IDr 36证书证书证书37证书请求证书请求证书请求38身份验证身份验证39当前Ni，Nr 40通知N 41删除D 42供应商ID V 43流量选择器-启动器TSi 44流量选择器-响应者TSr 45加密E 46配置CP 47可扩展身份验证EAP 48保留给IANA 49-127专用128-255
Payload type values 1-32 should not be used so that there is no overlap with the code assignments for IKEv1. Payload type values 49-127 are reserved to IANA for future assignment in IKEv2 (see section 6). Payload type values 128-255 are for private use among mutually consenting parties.
不应使用有效负载类型值1-32，以免与IKEv1的代码分配重叠。有效载荷类型值49-127保留给IANA，以备将来在IKEv2中分配（见第6节）。有效负载类型值128-255供双方同意的各方私人使用。
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 one 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. The reasoning behind not setting the critical bit for payloads defined in this document is that all implementations MUST understand all payload types defined in this document and therefore must ignore the Critical bit's value. Skipped payloads are expected to have valid Next Payload and Payload Length fields.
o 临界（1位）-如果发送方不理解上一个有效负载的下一个有效负载字段中的有效负载类型代码，则发送方希望接收方跳过此有效负载，则必须将临界（1位）设置为零。如果发件人希望收件人在不了解有效负载类型的情况下拒绝整个邮件，则必须将设置为1。如果收件人理解有效负载类型代码，则收件人必须忽略此项。对于本文档中定义的有效负载类型，必须将设置为零。请注意，关键位适用于当前有效负载，而不是类型代码出现在第一个八位字节中的“下一个”有效负载。没有为本文档中定义的有效负载设置关键位的原因是，所有实现必须理解本文档中定义的所有有效负载类型，因此必须忽略关键位的值。跳过的有效负载应具有有效的下一个有效负载和有效负载长度字段。
o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on receipt.
o 保留（7位）-必须作为零发送；必须在收到时忽略。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
The Security Association Payload, denoted SA in this memo, is used to negotiate attributes of a security association. Assembly of Security Association Payloads requires great peace of mind. An SA payload MAY contain multiple proposals. If there is more than one, they MUST be ordered from most preferred to least preferred. Each proposal may contain multiple IPsec protocols (where a protocol is IKE, ESP, or AH), each protocol MAY contain multiple transforms, and each transform MAY contain multiple attributes. 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有效负载可能包含多个方案。如果有多个，则必须从最优先到最不优先顺序排列。每个方案可能包含多个IPsec协议（其中一个协议是IKE、ESP或AH），每个协议可能包含多个转换，每个转换可能包含多个属性。解析SA时，实现必须检查总负载长度是否与负载的内部长度和计数一致。建议、转换和属性都有自己的可变长度编码。它们是嵌套的，因此SA的有效负载长度包括SA、建议、转换和属性信息的组合内容。提案的长度包括其包含的所有变换和属性的长度。变换的长度包括其包含的所有属性的长度。
The syntax of Security Associations, Proposals, Transforms, and Attributes is based on ISAKMP; however, the semantics are somewhat different. The reason for the complexity and the hierarchy is to allow for multiple possible combinations of algorithms to be encoded in a single SA. Sometimes there is a choice of multiple algorithms, whereas other times there is a combination of algorithms. For example, an initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR (ESP w/MD5 and 3DES).
安全关联、建议、转换和属性的语法基于ISAKMP；但是，语义有些不同。复杂性和层次结构的原因是允许在单个SA中编码多个可能的算法组合。有时有多种算法可供选择，而有时有多种算法的组合。例如，发起人可能希望建议使用（AH w/MD5和ESP w/3DES）或（ESP w/MD5和3DES）。
One of the reasons the semantics of the SA payload has changed from ISAKMP and IKEv1 is to make the encodings more compact in common cases.
SA有效负载的语义从ISAKMP和IKEv1更改的原因之一是为了在常见情况下使编码更加紧凑。
The Proposal structure contains within it a Proposal # and an IPsec protocol ID. Each structure MUST have the same Proposal # as the previous one or be one (1) greater. The first Proposal MUST have a Proposal # of one (1). If two successive structures have the same Proposal number, it means that the proposal consists of the first structure AND the second. So a proposal of AH AND ESP would have two proposal structures, one for AH and one for ESP and both would have Proposal #1. A proposal of AH OR ESP would have two proposal structures, one for AH with Proposal #1 and one for ESP with Proposal #2.
提案结构中包含一个提案和一个IPsec协议ID。每个结构必须与前一个提案具有相同的提案，或者比前一个提案大一（1）。第一个提案必须有一（1）个提案。如果两个连续结构具有相同的提案编号，则表示提案由第一个结构和第二个结构组成。所以AH和ESP的提案有两个提案结构，一个用于AH，一个用于ESP，两个提案都有提案1。AH或ESP提案将有两个提案结构，一个用于AH提案1，一个用于ESP提案2。
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 a single transform: an integrity check algorithm. ESP generally has two: an encryption algorithm and an integrity check algorithm. IKE generally has four
每个提案/协议结构后面都有一个或多个转换结构。不同转换的数量通常由协议决定。AH通常只有一个转换：完整性检查算法。ESP通常有两种：加密算法和完整性检查算法。艾克一般有四个
transforms: a Diffie-Hellman group, an integrity check algorithm, a prf algorithm, and an encryption algorithm. If an algorithm that combines encryption and integrity protection is proposed, it MUST be proposed as an encryption algorithm and an integrity protection algorithm MUST NOT be proposed. For each Protocol, the set of permissible transforms is assigned transform ID numbers, which appear in the header of each transform.
转换：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. For example, to propose ESP with (3DES or IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for IDEA) and two Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). This effectively proposes four combinations of algorithms. If the initiator wanted to propose only a subset of those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as multiple transforms within a single Proposal. Instead, the initiator would have to construct two different Proposals, each with two transforms.
如果有多个变换具有相同的变换类型，则建议是这些变换的OR。如果存在具有不同变换类型的多个变换，则建议是不同组的AND。例如，要使用（3DES或IDEA）和（HMAC_MD5或HMAC_SHA）建议ESP，ESP建议将包含两个变换类型1候选（一个用于3DES，一个用于IDEA）和两个变换类型2候选（一个用于HMAC_MD5，一个用于HMAC_SHA）。这有效地提出了四种算法组合。如果发起人只想提出其中的一个子集，例如（3DES和HMAC_MD5）或（IDEA和HMAC_SHA），则无法将其编码为单个提案中的多个变换。相反，发起者必须构建两个不同的方案，每个方案都有两个转换。
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. Most transforms do not have attributes. A transform MUST NOT have multiple attributes of the same type. To propose alternate values for an attribute (for example, multiple key sizes for the AES encryption algorithm), and implementation MUST include multiple Transforms with the same Transform Type each with a single Attribute.
给定的变换可能有一个或多个属性。当转换可以以多种方式使用时，属性是必需的，例如当加密算法具有可变密钥大小时。转换将指定算法，属性将指定密钥大小。大多数变换没有属性。转换不能具有相同类型的多个属性。要为属性提出替代值（例如，AES加密算法的多个密钥大小），实现必须包括具有相同变换类型的多个变换，每个变换具有单个属性。
Note that the semantics of Transforms and Attributes are quite different from those in IKEv1. In IKEv1, a single Transform carried multiple algorithms for a protocol with one carried in the Transform and the others carried in the Attributes.
请注意，转换和属性的语义与IKEv1中的语义大不相同。在IKEv1中，单个转换为协议携带多个算法，其中一个在转换中携带，其他在属性中携带。
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 6: Security Association Payload
图6：安全关联负载
o Proposals (variable) - One or more proposal substructures.
o 方案（可变）-一个或多个方案子结构。
The payload type for the Security Association Payload is thirty three (33).
安全关联有效负载的有效负载类型为三十三（33）。
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 # ! Protocol ID ! SPI Size !# of 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 # ! Protocol ID ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ <Transforms> ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Proposal Substructure
图7：提案子结构
o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the last Proposal Substructure in the SA. This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA. The value (2) corresponds to a Payload Type of Proposal in IKEv1, and the first 4 octets of the Proposal structure are designed to look somewhat like the header of a Payload.
o 0（最后一个）或2（更多）（1个八位组）-指定这是否是SA中的最后一个提案子结构。此语法继承自ISAKMP，但没有必要，因为可以根据SA的长度识别最后一个提案。值（2）对应于IKEv1中提议的有效负载类型，并且提议结构的前4个八位字节被设计成看起来有点像有效负载的头部。
o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on receipt.
o 保留（1个八位字节）-必须作为零发送；必须在收到时忽略。
o Proposal Length (2 octets) - Length of this proposal, including all transforms and attributes that follow.
o 提案长度（2个八位字节）-此提案的长度，包括所有后续转换和属性。
o Proposal # (1 octet) - When a proposal is made, the first proposal in an SA payload MUST be #1, and subsequent proposals MUST either be the same as the previous proposal (indicating an AND of the two proposals) or one more than the previous proposal (indicating an OR of the two proposals). When a proposal is accepted, all of the proposal numbers in the SA payload MUST be the same and MUST match the number on the proposal sent that was accepted.
o 提案#（1个八位组）-提出提案时，SA有效载荷中的第一个提案必须为#1，后续提案必须与前一个提案相同（表示两个提案中的and）或比前一个提案多一个提案（表示两个提案中的or）。接受提案时，SA有效负载中的所有提案编号必须相同，并且必须与已接受的已发送提案上的编号相匹配。
o Protocol ID (1 octet) - Specifies the IPsec protocol identifier for the current negotiation. The defined values are:
o 协议ID（1个八位字节）-指定当前协商的IPsec协议标识符。定义的值为：
Protocol Protocol ID RESERVED 0 IKE 1 AH 2 ESP 3 RESERVED TO IANA 4-200 PRIVATE USE 201-255
协议ID保留0 IKE 1 AH 2 ESP 3保留给IANA 4-200专用201-255
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, 4 for ESP and AH).
o SPI大小（1个八位组）-对于初始IKE_SA协商，此字段必须为零；SPI从外部收割台获取。在随后的协商过程中，它等于相应协议的SPI的大小（八位字节）（8表示IKE，4表示ESP和AH）。
o # of Transforms (1 octet) - Specifies the number of transforms in this proposal.
o #变换数量（1个八位字节）-指定此方案中的变换数量。
o SPI (variable) - The sending entity's SPI. Even if the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload. When the SPI Size field is zero, this field is not present in the Security Association payload.
o SPI（变量）-发送实体的SPI。即使SPI大小不是4个八位字节的倍数，也不会对有效负载应用填充。当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 8: Transform Substructure
图8：变换子结构
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal. This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA. The
o 0（最后一个）或3（更多）（1个八位组）-指定这是否是提案中的最后一个变换子结构。此语法继承自ISAKMP，但没有必要，因为可以根据SA的长度识别最后一个提案。这个
value (3) corresponds to a Payload Type of Transform in IKEv1, and the first 4 octets of the Transform structure are designed to look somewhat like the header of a Payload.
值（3）对应于IKEv1中转换的有效负载类型，并且转换结构的前4个八位字节被设计成看起来有点像有效负载的报头。
o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o 保留-必须作为零发送；必须在收到时忽略。
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个八位字节）-提出的转换类型的特定实例。
Transform Type Values
转换类型值
Transform Used In Type RESERVED 0 Encryption Algorithm (ENCR) 1 (IKE and ESP) Pseudo-random 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) RESERVED TO IANA 6-240 PRIVATE USE 241-255
用于类型保留0加密算法（ENCR）1（IKE和ESP）伪随机函数（PRF）2（IKE）完整性算法（INTEG）3（IKE，AH，ESP中可选）Diffie Hellman组（D-H）4（IKE，AH和ESP中可选）扩展序列号（ESN）5（AH和ESP）保留给IANA 6-240专用241-255
For Transform Type 1 (Encryption Algorithm), defined Transform IDs are:
对于转换类型1（加密算法），定义的转换ID为：
Name Number Defined In RESERVED 0 ENCR_DES_IV64 1 (RFC1827) ENCR_DES 2 (RFC2405), [DES] ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_CAST 6 (RFC2451) ENCR_BLOWFISH 7 (RFC2451) ENCR_3IDEA 8 (RFC2451)
保留的0 ENCR_DES_IV64 1（RFC1827）ENCR_DES 2（RFC2405），[DES]ENCR_3DES 3（RFC2451）ENCR_RC5 4（RFC2451）ENCR_IDEA 5（RFC2451），[IDEA]ENCR_CAST 6（RFC2451）ENCR_河豚7（RFC2451）ENCR_IDEA 8（RFC2451）中定义的名称编号
ENCR_DES_IV32 9 RESERVED 10 ENCR_NULL 11 (RFC2410) ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CTR 13 (RFC3664)
电子病历IV32 9保留10电子病历NULL 11（RFC2410）电子病历CBC 12（RFC3602）电子病历13（RFC3664）
values 14-1023 are reserved to IANA. Values 1024-65535 are for private use among mutually consenting parties.
值14-1023保留给IANA。值1024-65535供双方同意的各方私用。
For Transform Type 2 (Pseudo-random Function), defined Transform IDs are:
对于变换类型2（伪随机函数），定义的变换ID为：
Name Number Defined In RESERVED 0 PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_TIGER 3 (RFC2104) PRF_AES128_XCBC 4 (RFC3664)
保留的0 PRF_HMAC_MD5 1（RFC2104）、[MD5]PRF_HMAC_SHA1 2（RFC2104）、[SHA]PRF_HMAC_TIGER 3（RFC2104）PRF_AES128_XCBC 4（RFC3664）中定义的名称编号
values 5-1023 are reserved to IANA. Values 1024-65535 are for private use among mutually consenting parties.
值5-1023保留给IANA。值1024-65535供双方同意的各方私用。
For Transform Type 3 (Integrity Algorithm), defined Transform IDs are:
对于转换类型3（完整性算法），定义的转换ID为：
Name Number Defined In NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_DES_MAC 3 AUTH_KPDK_MD5 4 (RFC1826) AUTH_AES_XCBC_96 5 (RFC3566)
无0身份验证HMAC MD5 MD96 1（RFC2403）身份验证HMAC SHA1 96 2（RFC2404）身份验证MAC 3身份验证KPDK MD5 4（RFC1826）身份验证XCBC 96 5（RFC3566）中定义的名称编号
values 6-1023 are reserved to IANA. Values 1024-65535 are for private use among mutually consenting parties.
值6-1023保留给IANA。值1024-65535供双方同意的各方私用。
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs are:
对于转换类型4（Diffie-Hellman组），定义的转换ID为：
Name Number NONE 0 Defined in Appendix B 1 - 2 RESERVED 3 - 4 Defined in [ADDGROUP] 5 RESERVED TO IANA 6 - 13 Defined in [ADDGROUP] 14 - 18 RESERVED TO IANA 19 - 1023 PRIVATE USE 1024-65535
名称编号无0在附录B中定义1-2在[ADDGROUP]5中定义保留3-4在[ADDGROUP]14-18中定义保留给IANA 19-1023专用1024-65535中定义保留给IANA 6-13
For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are:
对于变换类型5（扩展序列号），定义的变换ID为：
Name Number No Extended Sequence Numbers 0 Extended Sequence Numbers 1 RESERVED 2 - 65535
名称编号无扩展序号0扩展序号1保留2-65535
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
协议强制类型可选类型如ENCR、PRF、INTEG、D-H ESP ENCR、ESN INTEG、D-H AH INTEG、ESN D-H
The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves.
本文档中删除了互操作性必须和应该支持的套件规范，因为它们的变化可能比本文档的发展更快。
An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. For example, at the time that this document was written, many IKEv1 implementers were starting to migrate to AES in Cipher Block Chaining (CBC) mode for Virtual Private Network (VPN) applications. Many IPsec systems based on IKEv2 will implement AES, additional Diffie-Hellman groups, and additional hash algorithms, and some IPsec customers already require these algorithms in addition to the ones listed above.
从IKEv1中学到的一个重要教训是，任何系统都不应该只实现强制算法，并期望它们成为所有客户的最佳选择。例如，在编写本文档时，许多IKEv1实现者开始以密码块链接（CBC）模式迁移到AES，用于虚拟专用网络（VPN）应用程序。许多基于IKEv2的IPsec系统将实现AES、额外的Diffie-Hellman组和额外的哈希算法，除了上面列出的算法之外，一些IPsec客户已经需要这些算法。
It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits. In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie-Hellman (DH) parameters (the generator, modulus, and exponent lengths and values) for new DH groups. Implementations SHOULD provide a
IANA很可能会在将来添加额外的转换，一些用户可能希望使用私有套件，特别是对于IKE，在IKE中，实现应该能够支持不同的参数，达到一定的大小限制。为了支持这一目标，IKEv2的所有实现都应该包括一个管理设施，允许（由用户或系统管理员）为新的DH组指定Diffie-Hellman（DH）参数（生成器、模数和指数长度和值）。实现应该提供
management interface via which these parameters and the associated transform IDs may be entered (by a user or system administrator), to enable negotiating such groups.
管理界面，通过该界面（用户或系统管理员）可以输入这些参数和相关的转换ID，以便能够协商这些组。
All implementations of IKEv2 MUST include a management facility that enables a user or system administrator to specify the suites that are acceptable for use with IKE. Upon receipt of a payload with a set of transform IDs, the implementation MUST compare the transmitted transform IDs against those locally configured via the management controls, to verify that the proposed suite is acceptable based on local policy. The implementation MUST reject SA proposals that are not authorized by these IKE suite controls. Note that cryptographic suites that MUST be implemented need not be configured as acceptable to local policy.
IKEv2的所有实现必须包括一个管理工具，该工具允许用户或系统管理员指定可与IKE一起使用的套件。在收到带有一组转换ID的有效负载后，实现必须将传输的转换ID与通过管理控制在本地配置的转换ID进行比较，以验证基于本地策略提出的套件是可接受的。实施必须拒绝未经这些IKE套件控件授权的SA提案。请注意，必须实现的加密套件不需要配置为本地策略可以接受。
Each transform in a Security Association payload may include attributes that modify or complete the specification of the transform. These attributes are type/value pairs and are defined below. For example, if an encryption algorithm has a variable-length key, the key length to be used may be specified as an attribute. Attributes can have a value with a fixed two octet length or a variable-length value. For the latter, the attribute is encoded as type/length/value.
安全关联有效负载中的每个转换可以包括修改或完成转换规范的属性。这些属性是类型/值对，定义如下。例如，如果加密算法具有可变长度密钥，则可将要使用的密钥长度指定为属性。属性可以具有固定的两个八位字节长度值或可变长度值。对于后者，属性被编码为type/length/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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! Attribute Type ! AF=0 Attribute Length !
!F! ! AF=1 Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! AF=0 Attribute Value !
! AF=1 Not Transmitted !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! Attribute Type ! AF=0 Attribute Length !
!F! ! AF=1 Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! AF=0 Attribute Value !
! AF=1 Not Transmitted !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Data Attributes
图9：数据属性
o Attribute Type (2 octets) - Unique identifier for each type of attribute (see below).
o 属性类型（2个八位字节）-每种类型属性的唯一标识符（见下文）。
The most significant bit of this field is the Attribute Format bit (AF). It indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is zero (0), then the Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data Attributes are of the Type/Value form.
该字段的最高有效位是属性格式位（AF）。它指示数据属性是遵循类型/长度/值（TLV）格式还是缩短类型/值（TV）格式。如果AF位为零（0），则数据属性为类型/长度/值（TLV）形式。如果AF位为一（1），则数据属性为类型/值形式。
o Attribute Length (2 octets) - Length in octets of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute Length field is not present.
o 属性长度（2个八位字节）-属性值的八位字节长度。当AF位为1时，属性值仅为2个八位字节，且属性长度字段不存在。
o Attribute Value (variable length) - Value of the Attribute associated with the Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets.
o 属性值（可变长度）-与属性类型关联的属性的值。如果AF位为零（0），则该字段具有由属性长度字段定义的可变长度。如果AF位为1，则属性值的长度为2个八位字节。
Note that only a single attribute type (Key Length) is defined, and it is fixed length. The variable-length encoding specification is included only for future extensions. The only algorithms defined in this document that accept attributes are the AES-based encryption, integrity, and pseudo-random functions, which require a single attribute specifying key width.
请注意，只定义了一个属性类型（键长度），它是固定长度的。可变长度编码规范仅用于将来的扩展。本文档中定义的唯一接受属性的算法是基于AES的加密、完整性和伪随机函数，它们需要指定密钥宽度的单个属性。
Attributes described as basic MUST NOT be encoded using the variable-length encoding. Variable-length attributes MUST NOT be encoded as basic even if their value can fit into two octets. NOTE: This is a change from IKEv1, where increased flexibility may have simplified the composer of messages but certainly complicated the parser.
不得使用可变长度编码对描述为基本的属性进行编码。即使可变长度属性的值可以放入两个八位字节，也不能将其编码为基本属性。注意：这是IKEv1的一个变化，在IKEv1中，增加的灵活性可能简化了消息的编写器，但肯定会使解析器复杂化。
Attribute Type Value Attribute Format
--------------------------------------------------------------
RESERVED 0-13 Key Length (in bits)
14 TV RESERVED 15-17
RESERVED TO IANA 18-16383 PRIVATE USE
16384-32767
Attribute Type Value Attribute Format
--------------------------------------------------------------
RESERVED 0-13 Key Length (in bits)
14 TV RESERVED 15-17
RESERVED TO IANA 18-16383 PRIVATE USE
16384-32767
Values 0-13 and 15-17 were used in a similar context in IKEv1 and should not be assigned except to matching values. Values 18-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties.
值0-13和15-17在IKEv1的类似上下文中使用，不应分配给匹配值以外的值。值18-16383保留给IANA。价值16384-32767供双方同意的私人使用。
- Key Length
- 键长
When using an Encryption Algorithm that has a variable-length key, this attribute specifies the key length in bits (MUST use network byte order). This attribute MUST NOT be used when the specified Encryption Algorithm uses a fixed-length key.
使用具有可变长度密钥的加密算法时，此属性以位为单位指定密钥长度（必须使用网络字节顺序）。当指定的加密算法使用固定长度密钥时，不得使用此属性。
During security association negotiation, initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers (or reject all offers if none are acceptable). If there are multiple proposals, the responder MUST choose a single proposal number and return all of the Proposal substructures with that Proposal number. If there are multiple Transforms with the same type, the responder MUST choose a single one. Any attributes of a selected transform MUST be returned unmodified. The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not that response MUST be rejected.
在安全关联协商期间，发起者向响应者提供报价。响应者必须从报价中选择一组完整的参数（如果没有一个报价是可接受的，则拒绝所有报价）。如果有多个提案，响应者必须选择一个提案编号，并返回带有该提案编号的所有提案子结构。如果有多个相同类型的转换，响应者必须选择一个。所选转换的任何属性都必须未经修改地返回。交易所的发起人必须检查所接受的报价是否与其提议一致，如果不一致，则必须拒绝该回复。
Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and include a KE corresponding to that group. If the guess turns out to be wrong, the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. It SHOULD, however, continue to propose its full supported set of groups in order to prevent a man-in-the-middle downgrade attack.
谈判Diffie-Hellman集团面临一些特殊挑战。SA提供的服务包括在同一消息中建议的属性和Diffie Hellman公用号码（KE）。如果在初始交换中，发起方提出使用几个Diffie-Hellman组中的一个，那么它应该选择响应方最有可能接受的组，并包括与该组对应的KE。如果猜测结果是错误的，响应者将在响应中指示正确的组，并且发起者应在重试第一条消息时为其KE值选择该组的一个元素。然而，为了防止中间人降级攻击，它应该继续提出其完全受支持的组集。
Implementation Note:
实施说明：
Certain negotiable attributes can have ranges or could have multiple acceptable values. These include the key length of a variable key length symmetric cipher. To further interoperability and to support upgrading endpoints independently, implementers of this protocol SHOULD accept values that they deem to supply greater security. For instance, if a peer is configured to accept a variable-length cipher with a key length of X bits and is offered that cipher with a larger key length, the implementation SHOULD accept the offer if it supports use of the longer key.
某些可协商属性可以具有范围，也可以具有多个可接受的值。其中包括可变密钥长度对称密码的密钥长度。为了进一步提高互操作性并支持独立升级端点，该协议的实现者应该接受他们认为可以提供更高安全性的值。例如，如果一个对等方被配置为接受密钥长度为X位的可变长度密码，并且该密码具有更大的密钥长度，那么如果该实现支持使用更长的密钥，则该实现应该接受该密码。
Support of this capability allows an implementation to express a concept of "at least" a certain level of security -- "a key length of _at least_ X bits for cipher Y".
对该功能的支持允许实现表达“至少”某种安全级别的概念——“密码Y的密钥长度至少为X位”。
The Key Exchange Payload, denoted KE in this memo, is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange Payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself.
密钥交换有效载荷（在本备忘录中表示为KE）用于交换Diffie-Hellman公钥，作为Diffie-Hellman密钥交换的一部分。密钥交换有效负载由IKE通用有效负载头和Diffie-Hellman公共值本身组成。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DH Group # ! 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DH Group # ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Exchange Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Key Exchange Payload Format
图10：密钥交换有效负载格式
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 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公共值复制到有效负载的“密钥交换数据”部分来构建的。Diffie-Hellman公共值的长度必须等于在其上执行求幂的素数模的长度，如有必要，将零位前置到该值。
The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see section 3.3.2). If the selected proposal uses a different Diffie-Hellman group, the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD.
DH组#确定计算密钥交换数据的Diffie-Hellman组（见第3.3.2节）。如果所选方案使用不同的Diffie-Hellman组，则必须使用无效有效负载类型的Notify payload拒绝该消息。
The payload type for the Key Exchange payload is thirty four (34).
密钥交换有效负载的有效负载类型为三十四（34）。
The Identification Payloads, denoted IDi and IDr in this memo, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions.
标识有效载荷（在本备忘录中表示为IDi和IDr）允许对等方彼此声明身份。此标识可用于策略查找，但不一定必须匹配证书有效负载中的任何内容；实现可以使用这两个字段来执行访问控制决策。
NOTE: In IKEv1, two ID payloads were used in each direction to hold Traffic Selector (TS) information for data passing over the SA. In IKEv2, this information is carried in TS payloads (see section 3.13).
注意：在IKEv1中，在每个方向上使用两个ID有效载荷来保存通过SA的数据的流量选择器（TS）信息。在IKEv2中，该信息在TS有效载荷中携带（见第3.13节）。
The Identification Payload consists of the IKE generic payload header followed by identification fields as follows:
标识有效负载由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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 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 11: Identification Payload Format
图11：识别有效载荷格式
o ID Type (1 octet) - Specifies the type of Identification being used.
o ID类型（1个八位字节）-指定正在使用的标识类型。
o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o 保留-必须作为零发送；必须在收到时忽略。
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 payload types for the Identification Payload are thirty five (35) for IDi and thirty six (36) for IDr.
识别有效载荷的有效载荷类型为IDi的三十五（35）种，IDr的三十六（36）种。
The following table lists the assigned values for the Identification Type field, followed by a description of the Identification Data which follows:
下表列出了标识类型字段的指定值，然后是标识数据的说明，如下所示：
ID Type Value
------- -----
RESERVED 0
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID\u IPV4\u地址1
A single four (4) octet IPv4 address.
单个四（4）个八位IPv4地址。
ID_FQDN 2
ID_FQDN 2
A fully-qualified domain name string. An example of a ID_FQDN is, "example.com". The string MUST not contain any terminators (e.g., NULL, CR, etc.).
完全限定的域名字符串。ID_FQDN的一个示例是“example.com”。字符串不得包含任何终止符（例如NULL、CR等）。
ID_RFC822_ADDR 3
ID\u RFC822\u地址3
A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not contain any terminators.
完全限定的RFC822电子邮件地址字符串，ID_RFC822_ADDR的一个示例是，“jsmith@example.com". 字符串不能包含任何终止符。
Reserved to IANA 4
保留给IANA 4
ID_IPV6_ADDR 5
ID\u IPV6\u地址5
A single sixteen (16) octet IPv6 address.
单个十六（16）个八位组IPv6地址。
Reserved to IANA 6 - 8
保留给IANA 6-8
ID_DER_ASN1_DN 9
ID\u DER\u ASN1\u DN 9
The binary Distinguished Encoding Rules (DER) encoding of an ASN.1 X.500 Distinguished Name [X.501].
ASN.1 X.500可分辨名称[X.501]的二进制可分辨编码规则（DER）编码。
ID_DER_ASN1_GN 10
ID\u DER\u ASN1\u GN 10
The binary DER encoding of an ASN.1 X.500 GeneralName [X.509].
ASN.1 X.500通用名称[X.509]的二进制DER编码。
ID_KEY_ID 11
ID\u键\u ID 11
An opaque octet stream which may be used to pass vendor-specific information necessary to do certain proprietary types of identification.
一种不透明的八位字节流，可用于传递进行某些专有类型标识所需的供应商特定信息。
Reserved to IANA 12-200
保留给IANA 12-200
Reserved for private use 201-255
保留供私人使用201-255
Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR.
只有当两个实现都能生成另一个可以接受的ID类型时，这两个实现才能互操作。为了确保最大的互操作性，实现必须可配置为发送至少一个ID_IPV4_ADDR、ID_FQDN、ID_RFC822_ADDR或ID_KEY_ID，并且必须可配置为接受所有这些类型。实现应该能够生成和接受所有这些类型。支持IPv6的实现还必须可配置为接受ID\u IPv6\u ADDR。仅IPv6实现可以配置为仅发送ID\u IPv6\u ADDR。
The Certificate Payload, denoted CERT in this memo, provides a means to transport certificates or other authentication-related information via IKE. Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the term "Certificate Payload" is somewhat misleading, because not all authentication mechanisms use certificates and data other than certificates may be passed in this payload.
证书有效负载（在本备忘录中表示为CERT）提供了通过IKE传输证书或其他身份验证相关信息的方法。如果发送方可以使用证书，则应将证书有效负载包括在exchange中，除非对等方已指示能够使用HTTP_CERT_LOOKUP_支持的Notify有效负载从其他位置检索此信息。请注意，术语“证书有效负载”有些误导，因为并非所有身份验证机制都使用证书，并且除了证书之外的数据可能在此有效负载中传递。
The Certificate Payload is defined as follows:
证书有效负载的定义如下：
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 12: Certificate Payload Format
图12：证书有效负载格式
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
-------------------- -----
RESERVED 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate - Signature 4
Kerberos Token 6
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8
SPKI Certificate 9
X.509 Certificate - Attribute 10
Raw RSA Key 11
Hash and URL of X.509 certificate 12
Hash and URL of X.509 bundle 13
RESERVED to IANA 14 - 200
PRIVATE USE 201 - 255
Certificate Encoding Value
-------------------- -----
RESERVED 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate - Signature 4
Kerberos Token 6
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8
SPKI Certificate 9
X.509 Certificate - Attribute 10
Raw RSA Key 11
Hash and URL of X.509 certificate 12
Hash and URL of X.509 bundle 13
RESERVED to IANA 14 - 200
PRIVATE USE 201 - 255
o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field.
o 证书数据（可变长度）-证书数据的实际编码。证书的类型由证书编码字段指示。
The payload type for the Certificate Payload is thirty seven (37).
证书有效负载的有效负载类型为三十七（37）。
Specific syntax is for some of the certificate type codes above is not defined in this document. The types whose syntax is defined in this document are:
本文档中未定义上述某些证书类型代码的特定语法。本文档中定义了其语法的类型有：
X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload.
X.509证书-签名（4）包含DER编码的X.509证书，其公钥用于验证发送方的身份验证有效负载。
Certificate Revocation List (7) contains a DER encoded X.509 certificate revocation list.
证书吊销列表（7）包含DER编码的X.509证书吊销列表。
Raw RSA Key (11) contains a PKCS #1 encoded RSA key (see [RSA] and [PKCS1]).
原始RSA密钥（11）包含PKCS#1编码的RSA密钥（请参见[RSA]和[PKCS1]）。
Hash and URL encodings (12-13) allow IKE messages to remain short by replacing long data structures with a 20 octet SHA-1 hash (see [SHA]) of the replaced value followed by a variable-length URL that resolves to the DER encoded data structure itself. This improves efficiency when the endpoints have certificate data cached and makes IKE less subject to denial of service attacks that become easier to mount when IKE messages are large enough to require IP fragmentation [KPS03].
散列和URL编码（12-13）允许IKE消息保持简短，方法是将长数据结构替换为替换值的20个八位组SHA-1散列（参见[SHA]），后跟解析为DER编码数据结构本身的可变长度URL。当端点缓存了证书数据时，这提高了效率，并使IKE较少受到拒绝服务攻击的影响，当IKE消息大到需要IP碎片时，更容易装载拒绝服务攻击[KPS03]。
Use the following ASN.1 definition for an X.509 bundle:
对X.509捆绑包使用以下ASN.1定义：
CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(34) }
CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(34) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
Certificate, CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
IMPORTS
Certificate, CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
CertificateOrCRL ::= CHOICE {
cert [0] Certificate,
crl [1] CertificateList }
CertificateOrCRL ::= CHOICE {
cert [0] Certificate,
crl [1] CertificateList }
CertificateBundle ::= SEQUENCE OF CertificateOrCRL
CertificateBundle ::= SEQUENCE OF CertificateOrCRL
END
终止
Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the first two Hash and URL formats (with HTTP URLs). Implementations SHOULD be capable of being configured to send and accept Raw RSA keys. If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order.
实现必须能够配置为发送和接受最多四个X.509证书以支持身份验证，还必须能够配置为发送和接受前两种哈希和URL格式（使用HTTP URL）。实现应该能够配置为发送和接受原始RSA密钥。如果发送了多个证书，则第一个证书必须包含用于签名身份验证有效负载的公钥。其他证书可按任何顺序发送。
The Certificate Request Payload, denoted CERTREQ in this memo, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. If multiple CAs are trusted and the cert encoding does not allow a list, then multiple Certificate Request payloads SHOULD be transmitted.
证书请求有效负载（在本备忘录中表示为CERTREQ）提供了通过IKE请求首选证书的方法，并可出现在IKE_INIT_SA响应和/或IKE_AUTH请求中。当发送方需要获得接收方的证书时，证书请求有效负载可以包括在交换中。如果多个CA受信任，且证书编码不允许列表，则应传输多个证书请求有效负载。
The Certificate Request Payload is defined as follows:
证书请求有效负载定义如下：
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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Certificate Request Payload Format
图13：证书请求有效负载格式
o Certificate Encoding (1 octet) - Contains an encoding of the type or format of certificate requested. Values are listed in section 3.6.
o 证书编码（1个八位字节）-包含请求的证书类型或格式的编码。数值见第3.6节。
o Certification Authority (variable length) - Contains an encoding of an acceptable certification authority for the type of certificate requested.
o 证书颁发机构（可变长度）-包含所请求证书类型的可接受证书颁发机构的编码。
The payload type for the Certificate Request Payload is thirty eight (38).
证书请求有效负载的有效负载类型为三十八（38）。
The Certificate Encoding field has the same values as those defined in section 3.6. 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 (CAs). Each is encoded as the SHA-1 hash of the Subject Public Key Info element (see section 4.1.2.7 of [RFC3280]) from each Trust Anchor certificate. The twenty-octet hashes are concatenated and included with no other formatting.
证书编码字段的值与第3.6节中定义的值相同。证书颁发机构字段包含此证书类型的受信任机构的指示器。证书颁发机构值是可信证书颁发机构（CA）公钥的SHA-1哈希的串联列表。每个都被编码为来自每个信任锚证书的主题公钥信息元素（参见[RFC3280]第4.1.2.7节）的SHA-1散列。二十个八位组散列是串联的，不包含其他格式。
Note that the term "Certificate Request" is somewhat misleading, in that values other than certificates are defined in a "Certificate" payload and requests for those values can be present in a Certificate Request Payload. The syntax of the Certificate Request payload in such cases is not defined in this document.
请注意，术语“证书请求”有点误导，因为在“证书”有效负载中定义了证书以外的值，并且对这些值的请求可以出现在证书请求有效负载中。在这种情况下，证书请求有效负载的语法未在本文档中定义。
The Certificate Request Payload is processed by inspecting the "Cert Encoding" field to determine whether the processor has any certificates of this type. If so, the "Certification Authority" field is inspected to determine if the processor has any certificates that can be validated up to one of the specified certification authorities. This can be a chain of certificates.
通过检查“Cert Encoding”（证书编码）字段来处理证书请求有效负载，以确定处理器是否具有任何此类证书。如果是，则检查“证书颁发机构”字段，以确定处理者是否有任何证书可通过指定证书颁发机构之一的验证。这可以是一个证书链。
If an end-entity certificate exists that satisfies the criteria specified in the CERTREQ, a certificate or certificate chain SHOULD be sent back to the certificate requestor if the recipient of the CERTREQ:
如果存在满足CERTREQ中指定标准的终端实体证书，则如果CERTREQ的接收者：
- is configured to use certificate authentication,
- 配置为使用证书身份验证，
- is allowed to send a CERT payload,
- 允许发送证书有效负载，
- has matching CA trust policy governing the current negotiation, and
- 具有管理当前协商的匹配CA信任策略，以及
- has at least one time-wise and usage appropriate end-entity certificate chaining to a CA provided in the CERTREQ.
- 至少具有一个与CERTREQ中提供的CA链接的时间和使用适当的最终实体证书。
Certificate revocation checking must be considered during the chaining process used to select a certificate. Note that even if two peers are configured to use two different CAs, cross-certification relationships should be supported by appropriate selection logic.
在用于选择证书的链接过程中，必须考虑证书吊销检查。请注意，即使将两个对等方配置为使用两个不同的CA，也应通过适当的选择逻辑支持交叉认证关系。
The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out-of-band configured means. Thus, the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist, then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator).
这样做的目的不是为了通过严格遵守基于CERTREQ的证书选择来阻止通信，当发送方可以选择替代证书时，该替代证书仍然能够使接收方通过交叉认证CRLs传递的信任来成功验证和信任该证书，或其他带外配置方式。因此，CERTREQ的处理应该被视为选择证书的建议，而不是强制证书。如果不存在证书，则忽略CERTREQ。这不是协议的错误情况。在某些情况下，CERTREQ中可能发送了首选CA，但可以接受备用CA（可能是在提示人工操作员之后）。
The Authentication Payload, denoted AUTH in this memo, contains data used for authentication purposes. The syntax of the Authentication data varies according to the Auth Method as specified below.
身份验证有效负载（在本备忘录中表示为AUTH）包含用于身份验证目的的数据。身份验证数据的语法根据下面指定的身份验证方法而变化。
The Authentication Payload is defined as follows:
身份验证有效负载的定义如下：
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 14: Authentication Payload Format
图14：验证有效负载格式
o Auth Method (1 octet) - Specifies the method of authentication used. Values defined are:
o Auth Method（1个八位字节）-指定使用的身份验证方法。定义的值为：
RSA Digital Signature (1) - Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash (see [RSA] and [PKCS1]).
RSA数字签名（1）-根据第2.15节的规定，在PKCS#1填充哈希上使用RSA私钥计算（请参见[RSA]和[PKCS1]）。
Shared Key Message Integrity Code (2) - Computed as specified in section 2.15 using the shared key associated with the identity in the ID payload and the negotiated prf function
共享密钥消息完整性代码（2）-根据第2.15节的规定，使用与ID有效载荷中的身份相关联的共享密钥和协商的prf功能计算
DSS Digital Signature (3) - Computed as specified in section 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash.
DSS数字签名（3）-根据第2.15节的规定，在SHA-1散列上使用DSS私钥（见[DSS]）计算。
The values 0 and 4-200 are reserved to IANA. The values 201-255 are available for private use.
值0和4-200保留给IANA。值201-255可供私人使用。
o Authentication Data (variable length) - see section 2.15.
o 认证数据（可变长度）-见第2.15节。
The payload type for the Authentication Payload is thirty nine (39).
验证有效负载的有效负载类型为三十九（39）。
The Nonce Payload, denoted Ni and Nr in this memo for the initiator's and responder's nonce respectively, contains random data used to guarantee liveness during an exchange and protect against replay attacks.
Nonce有效负载（在本备忘录中分别表示为发起者和响应者的Nonce的Ni和Nr）包含随机数据，用于保证交换期间的活跃性并防止重播攻击。
The Nonce Payload is defined as follows:
当前有效载荷定义如下：
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 15: Nonce Payload Format
图15：Nonce有效负载格式
o Nonce Data (variable length) - Contains the random data generated by the transmitting entity.
o Nonce数据（可变长度）-包含传输实体生成的随机数据。
The payload type for the Nonce Payload is forty (40).
当前有效载荷的有效载荷类型为四十（40）。
The size of a Nonce 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请求）或任何其他消息中，以指示发送方的能力或修改请求的含义。
The Notify Payload is defined as follows:
通知有效负载的定义如下：
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 16: Notify Payload Format
图16：通知有效负载格式
o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment.
o 协议ID（1个八位字节）-如果此通知涉及现有SA，则此字段指示该SA的类型。对于IKE_SA通知，此字段必须为一（1）。对于与IPsec SA有关的通知，此字段必须包含（2）以指示AH或（3）以指示ESP。对于与现有SA无关的通知，此字段必须作为零发送，并且在收到时必须忽略。此字段的所有其他值保留给IANA以供将来分配。
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.
o SPI大小（1个八位字节）-由IPsec协议ID定义的SPI的八位字节长度，如果没有适用的SPI，则为零。对于有关IKE_SA的通知，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) - Informational or error data transmitted in addition to the Notify Message Type. Values for this field are type specific (see below).
o 通知数据（可变长度）-除了通知消息类型外，还传输信息或错误数据。此字段的值是特定于类型的（见下文）。
The payload type for the Notify Payload is forty one (41).
通知有效负载的有效负载类型为四十一（41）。
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. The table below lists the Notification messages and their corresponding values. The number of different error statuses was greatly reduced from IKEv1 both for simplification and to avoid giving configuration information to probers.
通知信息可以是错误消息，指定无法建立SA的原因。它也可以是管理SA数据库的进程希望与对等进程通信的状态数据。下表列出了通知消息及其相应的值。从IKEv1中大大减少了不同错误状态的数量，以简化并避免向探测器提供配置信息。
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 except that 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
----------------------------- -----
RESERVED 0
NOTIFY MESSAGES - ERROR TYPES Value
----------------------------- -----
RESERVED 0
UNSUPPORTED_CRITICAL_PAYLOAD 1
不支持的\u关键\u有效负载1
Sent if the payload has the "critical" bit set and the payload type is not recognized. Notification Data contains the one-octet payload type.
如果有效负载设置了“关键”位且未识别有效负载类型，则发送。通知数据包含一个八位字节的有效负载类型。
INVALID_IKE_SPI 4
无效的_IKE_SPI 4
Indicates an IKE message was received with an unrecognized destination SPI. This usually indicates that the recipient has rebooted and forgotten the existence of an IKE_SA.
指示接收到带有无法识别的目标SPI的IKE消息。这通常表示收件人已重新启动并忘记IKE_SA的存在。
INVALID_MAJOR_VERSION 5
无效的\u主\u版本5
Indicates the recipient cannot handle the version of IKE specified in the header. The closest version number that the recipient can support will be in the reply header.
指示收件人无法处理标头中指定的IKE版本。收件人可以支持的最接近的版本号将在回复标题中。
INVALID_SYNTAX 7
无效的\u语法7
Indicates the IKE message that was received was invalid because some type, length, or value was out of range or
指示接收到的IKE消息无效，因为某些类型、长度或值超出范围或范围
because the request was rejected for policy reasons. To avoid a denial of service 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.
因为请求因策略原因被拒绝。为了避免使用伪造消息的拒绝服务攻击，只有在消息ID和加密校验和有效的情况下，才能在加密数据包中返回此状态。为了避免向探测节点的人泄漏信息，必须发送此状态以响应其他状态类型之一未包含的任何错误。为了帮助调试，应将更详细的错误信息写入控制台或日志。
INVALID_MESSAGE_ID 9
无效的\u消息\u ID 9
Sent when an IKE message ID outside the supported window is received. This Notify MUST NOT be sent in a response; the invalid request MUST NOT be acknowledged. Instead, inform the other side by initiating an INFORMATIONAL exchange with Notification data containing the four octet invalid message ID. Sending this notification is optional, and notifications of this type MUST be rate limited.
接收到支持窗口外的IKE消息ID时发送。此通知不得以响应形式发送；不能确认无效的请求。相反，通过与包含四个八位字节无效消息ID的通知数据进行信息交换来通知另一方。发送此通知是可选的，并且此类型的通知必须是速率受限的。
INVALID_SPI 11
无效的_SPI 11
MAY be sent in an IKE INFORMATIONAL exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If this Informational Message is sent outside the context of an IKE_SA, it should be used by the recipient only as a "hint" that something might be wrong (because it could easily be forged).
当节点接收到带有无效SPI的ESP或AH数据包时，可以在IKE信息交换中发送。通知数据包含无效数据包的SPI。这通常表示节点已重新启动并忘记SA。如果此信息消息是在IKE_SA的上下文之外发送的，则收件人应仅将其用作可能出错的“提示”（因为它很容易被伪造）。
NO_PROPOSAL_CHOSEN 14
没有选择方案14
None of the proposed crypto suites was acceptable.
提议的加密套件均不可接受。
INVALID_KE_PAYLOAD 17
有效载荷17无效
The D-H Group # field in the KE payload is not the group # selected by the responder for this exchange. There are two octets of data associated with this notification: the accepted D-H Group # in big endian order.
KE有效负载中的D-H组字段不是响应者为此交换选择的组。与此通知相关的数据有两个八位字节：以大端顺序接受的D-H组。
AUTHENTICATION_FAILED 24
身份验证失败24
Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data.
由于某种原因身份验证失败时，在对IKE_AUTH消息的响应中发送。没有关联的数据。
SINGLE_PAIR_REQUIRED 34
单对需要34
This error indicates that a CREATE_CHILD_SA request is unacceptable because its sender is only willing to accept traffic selectors specifying a single pair of addresses. The requestor is expected to respond by requesting an SA for only the specific traffic it is trying to forward.
此错误表示CREATE_CHILD_SA请求不可接受，因为其发送方只愿意接受指定一对地址的流量选择器。请求者应通过仅针对其试图转发的特定流量请求SA进行响应。
NO_ADDITIONAL_SAS 35
没有额外的SAS 35
This error indicates that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more CHILD_SAs on this IKE_SA. Some minimal implementations may only accept a single CHILD_SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more.
此错误表示CREATE_CHILD_SA请求不可接受，因为响应者不愿意在此IKE_SA上再接受任何子SA。一些最小实现可能只接受初始IKE交换上下文中的单个子_SA设置，并拒绝任何后续添加更多设置的尝试。
INTERNAL_ADDRESS_FAILURE 36
内部地址故障36
Indicates an error assigning an internal address (i.e., INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the processing of a Configuration Payload by a responder. If this error is generated within an IKE_AUTH exchange, no CHILD_SA will be created.
表示在响应程序处理配置有效负载期间分配内部地址（即内部IP 4地址或内部IP 6地址）时出错。如果此错误是在IKE_身份验证交换中生成的，则不会创建子SA。
FAILED_CP_REQUIRED 37
失败\u CP\u需要37
Sent by responder in the case where CP(CFG_REQUEST) was expected but not received, and so is a conflict with locally configured policy. There is no associated data.
由响应程序在预期CP（CFG_请求）但未收到的情况下发送，因此与本地配置的策略冲突。没有关联的数据。
TS_UNACCEPTABLE 38
TS_38
Indicates that none of the addresses/protocols/ports in the supplied traffic selectors is acceptable.
表示提供的流量选择器中的地址/协议/端口均不可接受。
INVALID_SELECTORS 39
无效的\u选择器39
MAY be sent in an IKE INFORMATIONAL exchange when a node receives an ESP or AH packet whose selectors do not match those of the SA on which it was delivered (and that caused the packet to be dropped). The Notification Data contains the start of the offending packet (as in ICMP messages) and the SPI field of the notification is set to match the SPI of the IPsec SA.
当节点接收到ESP或AH数据包时，其选择器与发送该数据包的SA的选择器不匹配（导致数据包被丢弃），可以在IKE信息交换中发送该数据包。通知数据包含违规数据包的开始（如在ICMP消息中），通知的SPI字段设置为与IPsec SA的SPI匹配。
RESERVED TO IANA - Error types 40 - 8191
保留给IANA-错误类型40-8191
Private Use - Errors 8192 - 16383
私人使用-错误8192-16383
NOTIFY MESSAGES - STATUS TYPES Value
------------------------------ -----
NOTIFY MESSAGES - STATUS TYPES Value
------------------------------ -----
INITIAL_CONTACT 16384
初始联系电话16384
This notification asserts that this IKE_SA is the only IKE_SA currently active between the authenticated identities. It MAY be sent when an IKE_SA is established after a crash, and the recipient MAY use this information to delete any other IKE_SAs it has to the same authenticated identity without waiting for a timeout. This notification MUST NOT be sent by an entity that may be replicated (e.g., a roaming user's credentials where the user is allowed to connect to the corporate firewall from two remote systems at the same time).
此通知断言此IKE_SA是在经过身份验证的身份之间当前活动的唯一IKE_SA。它可以在崩溃后建立IKE_SA时发送，并且接收者可以使用此信息删除其具有相同身份验证的任何其他IKE_SA，而无需等待超时。此通知不得由可复制的实体发送（例如，允许用户同时从两个远程系统连接到公司防火墙的漫游用户凭据）。
SET_WINDOW_SIZE 16385
设置窗口大小16385
This notification asserts that the sending endpoint is capable of keeping state for multiple outstanding exchanges, permitting the recipient to send multiple requests before getting a response to the first. The data associated with a SET_WINDOW_SIZE notification MUST be 4 octets long and contain the big endian representation of the number of messages the sender promises to keep. Window size is always one until the initial exchanges complete.
此通知断言发送端点能够保持多个未完成交换的状态，从而允许接收方在获得对第一个未完成交换的响应之前发送多个请求。与SET_WINDOW_SIZE通知关联的数据必须为4个八位字节长，并且包含发送方承诺保留的消息数量的大端表示。在初始交换完成之前，窗口大小始终为一。
ADDITIONAL_TS_POSSIBLE 16386
可能的额外费用16386
This notification asserts that the sending endpoint narrowed the proposed traffic selectors but that other traffic selectors would also have been acceptable, though only in a separate SA (see section 2.9). There is no data associated with this Notify type. It may be sent only as an additional payload in a message including accepted TSs.
此通知声明发送端点缩小了建议的流量选择器，但也可以接受其他流量选择器，尽管仅在单独的SA中（参见第2.9节）。没有与此通知类型关联的数据。它只能作为包含已接受TSs的消息中的附加有效负载发送。
IPCOMP_SUPPORTED 16387
IPCOMP_支持16387
This notification may be included only in a message containing an SA payload negotiating a CHILD_SA and indicates a willingness by its sender to use IPComp on this SA. The data associated with this notification includes a two-octet IPComp CPI followed by a one-octet transform ID optionally followed by attributes whose length and format are defined by that transform ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED notifications to indicate multiple supported algorithms. A message accepting an SA may contain at most one.
此通知只能包含在包含与子SA协商的SA有效负载的消息中，并表示其发送方愿意在此SA上使用IPComp。与此通知相关联的数据包括两个八位字节的IPComp CPI，后跟一个八位字节的转换ID（可选），后跟长度和格式由该转换ID定义的属性。建议SA的消息可能包含多个IPComp受支持的通知，以指示多个受支持的算法。接受SA的消息最多可以包含一个。
The transform IDs currently defined are:
当前定义的变换ID包括：
NAME NUMBER DEFINED IN
----------- ------ -----------
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2 RFC 2394
IPCOMP_LZS 3 RFC 2395
IPCOMP_LZJH 4 RFC 3051
NAME NUMBER DEFINED IN
----------- ------ -----------
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2 RFC 2394
IPCOMP_LZS 3 RFC 2395
IPCOMP_LZJH 4 RFC 3051
values 5-240 are reserved to IANA. Values 241-255 are for private use among mutually consenting parties.
值5-240保留给IANA。值241-255供双方同意的各方私人使用。
NAT_DETECTION_SOURCE_IP 16388
NAT_检测_源_IP 16388
This notification is used by its recipient to determine whether the source is behind a NAT box. The data associated with this notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port on which this packet was sent. There MAY be multiple Notify payloads of this type in a message if the sender does not know which of several network attachments will be used to send the packet. The recipient of this notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source IP address, and port, and if they don't match it SHOULD enable NAT traversal (see section 2.23). Alternately, it MAY reject the connection attempt if NAT traversal is not supported.
此通知由其收件人用于确定源是否位于NAT框后面。与此通知相关联的数据是SPI的SHA-1摘要（按照它们在报头中出现的顺序）、IP地址和发送此数据包的端口。如果发送方不知道将使用多个网络附件中的哪一个发送数据包，则消息中可能有多个此类Notify有效载荷。此通知的接收者可以将提供的值与SPI、源IP地址和端口的SHA-1哈希进行比较，如果它们不匹配，则应启用NAT遍历（参见第2.23节）。或者，如果不支持NAT遍历，它可能会拒绝连接尝试。
NAT_DETECTION_DESTINATION_IP 16389
NAT_检测_目的地_IP 16389
This notification is used by its recipient to determine whether it is behind a NAT box. The data associated with this notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port to which this packet was sent. The recipient of this notification MAY compare the supplied value to a hash of the SPIs, destination IP address, and port, and if they don't match it SHOULD invoke NAT traversal (see section 2.23). If they don't match, it means that this end is behind a NAT and this end SHOULD start sending keepalive packets as defined in [Hutt05]. Alternately, it MAY reject the connection attempt if NAT traversal is not supported.
收件人使用此通知来确定其是否位于NAT框后面。与此通知相关联的数据是SPI的SHA-1摘要（按照它们在报头中出现的顺序）、IP地址和发送此数据包的端口。此通知的接收者可以将提供的值与SPI、目标IP地址和端口的哈希值进行比较，如果它们不匹配，则应调用NAT遍历（参见第2.23节）。如果它们不匹配，则表示该端位于NAT后面，并且该端应开始发送[Hutt05]中定义的keepalive数据包。或者，如果不支持NAT遍历，它可能会拒绝连接尝试。
COOKIE 16390
曲奇16390
This notification MAY be included in an IKE_SA_INIT response. It indicates that the request should be retried with a copy of this notification as the first payload. This notification MUST be included in an IKE_SA_INIT request retry if a COOKIE notification was included in the initial response. The data associated with this notification MUST be between 1 and 64 octets in length (inclusive).
此通知可能包含在IKE_SA_INIT响应中。它指示应使用此通知的副本作为第一个有效负载重试请求。如果初始响应中包含COOKIE通知，则此通知必须包含在IKE_SA_INIT请求重试中。与此通知关联的数据长度必须介于1到64个八位字节之间（包括1到64个八位字节）。
USE_TRANSPORT_MODE 16391
使用运输模式16391
This notification MAY be included in a request message that also includes an SA payload requesting a CHILD_SA. It requests that the CHILD_SA use transport mode rather than tunnel mode for the SA created. If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the CHILD_SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA. Note: Except when using this option to negotiate transport mode, all CHILD_SAs will use tunnel mode.
This notification MAY be included in a request message that also includes an SA payload requesting a CHILD_SA. It requests that the CHILD_SA use transport mode rather than tunnel mode for the SA created. If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the CHILD_SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA. Note: Except when using this option to negotiate transport mode, all CHILD_SAs will use tunnel mode.translate error, please retry
Note: The ECN decapsulation modifications specified in [RFC4301] MUST be performed for every tunnel mode SA created by IKEv2.
注：必须对IKEv2创建的每个隧道模式SA执行[RFC4301]中规定的ECN去封装修改。
HTTP_CERT_LOOKUP_SUPPORTED 16392
支持的HTTP证书查找16392
This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format).
该通知可以包括在任何消息中，该消息可以包括CERTREQ有效负载，并指示发送方能够基于基于HTTP的URL查找证书（因此可能更愿意接收该格式的证书规范）。
REKEY_SA 16393
雷克尤萨16393
This notification MUST be included in a CREATE_CHILD_SA exchange if the purpose of the exchange is to replace an existing ESP or AH SA. The SPI field identifies the SA being rekeyed. There is no data.
如果交换的目的是替换现有ESP或AH SA，则此通知必须包含在CREATE_CHILD_SA交换中。SPI字段标识正在重新设置密钥的SA。没有数据。
ESP_TFC_PADDING_NOT_SUPPORTED 16394
ESP\u TFC\u填充\u不受支持16394
This notification asserts that the sending endpoint will NOT accept packets that contain Flow Confidentiality (TFC) padding.
此通知声明发送端点将不接受包含流机密性（TFC）填充的数据包。
NON_FIRST_FRAGMENTS_ALSO 16395
非首个片段也是16395
Used for fragmentation control. See [RFC4301] for explanation.
用于碎片控制。有关说明，请参见[RFC4301]。
RESERVED TO IANA - STATUS TYPES 16396 - 40959
保留给IANA-状态类型16396-40959
Private Use - STATUS TYPES 40960 - 65535
私人使用-状态类型40960-65535
The Delete Payload, denoted D in this memo, contains a protocol-specific security association identifier that the sender has removed from its security association database and is, therefore, no longer valid. Figure 17 shows the format of the Delete Payload. It is possible to send multiple SPIs in a Delete payload; however, each SPI MUST be for the same protocol. Mixing of protocol identifiers MUST NOT be performed in a Delete payload. It is permitted, however, to include multiple Delete payloads in a single INFORMATIONAL exchange where each Delete payload lists SPIs for a different protocol.
此备忘录中表示的删除有效负载包含特定于协议的安全关联标识符，发送方已从其安全关联数据库中删除该标识符，因此不再有效。图17显示了Delete有效负载的格式。可以在删除有效载荷中发送多个SPI；但是，每个SPI必须用于相同的协议。不得在删除有效负载中混合协议标识符。但是，允许在单个信息交换中包含多个删除有效负载，其中每个删除有效负载列出不同协议的SPI。
Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI is the SPI the sending endpoint would expect in inbound ESP or AH packets.
IKE_SA的删除由协议ID 1（IKE）表示，但没有SPI。删除子_SA（如ESP或AH）将包含该协议的IPsec协议ID（2表示AH，3表示ESP），并且SPI是发送端点在入站ESP或AH数据包中预期的SPI。
The Delete Payload is defined as follows:
删除有效负载的定义如下：
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 ! # 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 ! # 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, 2 for AH, or 3 for ESP.
o 协议ID（1个八位组）-IKE_SA必须为1，AH必须为2，ESP必须为3。
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 message header) or four for AH and ESP.
o SPI大小（1个八位字节）-协议ID定义的SPI的八位字节长度。IKE的长度必须为零（SPI位于消息头中），AH和ESP的长度必须为四。
o # of SPIs (2 octets) - The number of SPIs contained in the Delete payload. The size of each SPI is defined by the SPI Size field.
o #SPI数量（2个八位字节）-删除有效负载中包含的SPI数量。每个SPI的大小由SPI大小字段定义。
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 # of SPIs fields.
o 安全参数索引（可变长度）-标识要删除的特定安全关联。此字段的长度由SPI大小和SPIs字段的#决定。
The payload type for the Delete Payload is forty two (42).
删除有效负载的有效负载类型为四十二（42）。
The Vendor ID Payload, denoted V in this memo, contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backward compatibility.
供应商ID有效负载（在本备忘录中表示为V）包含供应商定义的常量。供应商使用该常量来识别和识别其实现的远程实例。此机制允许供应商在保持向后兼容性的同时试验新功能。
A Vendor ID payload MAY announce that the sender is capable to accepting certain extensions to the protocol, or it MAY simply identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification (i.e., the critical bit MUST be set to 0). Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to send any Vendor ID payload at all.
供应商ID有效载荷可以宣布发送方能够接受协议的某些扩展，或者它可以简单地将实现标识为调试中的一种帮助。供应商ID有效载荷不得改变本规范中定义的任何信息的解释（即，关键位必须设置为0）。可以发送多个供应商ID有效载荷。根本不需要实现来发送任何供应商ID有效负载。
A Vendor ID payload may be sent as part of any message. Reception of a familiar Vendor ID payload allows an implementation to make use of Private USE numbers described throughout this memo -- private payloads, private exchanges, private notifications, etc. Unfamiliar Vendor IDs MUST be ignored.
供应商ID有效负载可以作为任何消息的一部分发送。通过接收熟悉的供应商ID有效载荷，实现可以使用本备忘录中描述的私人使用编号——私人有效载荷、私人交换、私人通知等。必须忽略不熟悉的供应商ID。
Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts that gain acceptance and are standardized will be given "magic numbers" out of the Future Use range by IANA, and the requirement to use a Vendor ID will go away.
希望扩展此协议的Internet草案编写者必须定义供应商ID有效负载，以宣布在Internet草案中实现扩展的能力。预计获得认可和标准化的互联网草案将被IANA授予超出未来使用范围的“神奇数字”，使用供应商ID的要求也将消失。
The Vendor ID Payload fields are defined as follows:
供应商ID有效负载字段定义如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Vendor ID (VID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Vendor ID (VID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Vendor ID Payload Format
图18：供应商ID有效负载格式
o Vendor ID (variable length) - It is the responsibility of the person choosing the Vendor ID to assure its uniqueness in spite of the absence of any central registry for IDs. Good practice is to include a company name, a person name, or some such. If you want to show off, you might include the latitude and longitude and time where you were when you chose the ID and some random input. A message digest of a long unique string is preferable to the long unique string itself.
o 供应商ID（可变长度）-选择供应商ID的人员有责任确保其唯一性，尽管没有ID的中央注册表。良好的做法是包括公司名称、人名或类似名称。如果你想炫耀一下，你可以包括纬度和经度，以及你选择ID时所在的时间和一些随机输入。长唯一字符串的消息摘要比长唯一字符串本身更可取。
The payload type for the Vendor ID Payload is forty three (43).
供应商ID有效负载的有效负载类型为四十三（43）。
The Traffic Selector Payload, denoted TS in this memo, allows peers to identify packet flows for processing by IPsec security services. The Traffic Selector Payload consists of the IKE generic payload header followed by individual traffic selectors as follows:
此备忘录中表示为TS的流量选择器有效负载允许对等方识别数据包流，以供IPsec安全服务处理。流量选择器有效负载由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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 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 19: Traffic Selectors Payload Format
图19：流量选择器有效负载格式
o Number of TSs (1 octet) - Number of traffic selectors being provided.
o TSs数量（1个八位字节）-提供的流量选择器数量。
o RESERVED - This field MUST be sent as zero and MUST be ignored on receipt.
o 保留-此字段必须作为零发送，并且在收到时必须忽略。
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报头和所有流量选择器。
The payload type for the Traffic Selector payload is forty four (44) for addresses at the initiator's end of the SA and forty five (45) for addresses at the responder's end.
流量选择器有效负载的有效负载类型为四十四（44）个，用于SA发起者端的地址，四十五（45）个用于响应者端的地址。
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 20: Traffic Selector
图20：流量选择器
* Note: All fields other than TS Type and Selector Length depend on the TS Type. The fields shown are for TS Types 7 and 8, the only two values currently defined.
* 注意：除TS类型和选择器长度以外的所有字段都取决于TS类型。显示的字段用于TS类型7和8，这是当前定义的仅有的两个值。
o TS Type (one octet) - Specifies the type of traffic selector.
o TS类型（一个八位字节）-指定流量选择器的类型。
o IP protocol ID (1 octet) - Value specifying an associated IP protocol ID (e.g., UDP/TCP/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) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined, or if all ports are allowed, this field MUST be zero. For the ICMP protocol, the two one-octet fields Type and Code are treated as a single 16-bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field.
o 起始端口（2个八位字节）-指定此流量选择器允许的最小端口号的值。对于端口未定义的协议，或者如果允许所有端口，此字段必须为零。对于ICMP协议，两个一个八位字段类型和代码被视为单个16位整数（类型为最高有效8位，代码为最低有效8位）端口号，以便基于此字段进行过滤。
o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined, or if all ports are allowed, this field MUST be 65535. For the ICMP protocol, the two one-octet fields Type and Code are treated as a single 16-bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposed of filtering based on this field.
o End Port（2个八位字节）—指定此流量选择器允许的最大端口号的值。对于端口未定义的协议，或者如果允许所有端口，则此字段必须为65535。对于ICMP协议，两个一个八位字段类型和代码被视为一个16位整数（类型为最高有效8位，代码为最低有效8位）端口号，以便基于此字段进行过滤。
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类型决定）。
Systems that are complying with [RFC4301] that wish to indicate "ANY" ports MUST set the start port to 0 and the end port to 65535; note that according to [RFC4301], "ANY" includes "OPAQUE". Systems working with [RFC4301] that wish to indicate "OPAQUE" ports, but not "ANY" ports, MUST set the start port to 65535 and the end port to 0.
符合[RFC4301]要求且希望指示“任何”端口的系统必须将起始端口设置为0，将结束端口设置为65535；注意，根据[RFC4301]，“任何”包括“不透明”。使用[RFC4301]的系统如果希望指示“不透明”端口，而不是“任何”端口，则必须将起始端口设置为65535，将结束端口设置为0。
The following table lists the assigned values for the Traffic Selector Type field and the corresponding Address Selector Data.
下表列出了交通选择器类型字段的分配值和相应的地址选择器数据。
TS Type Value
------- -----
RESERVED 0-6
TS Type Value
------- -----
RESERVED 0-6
TS_IPV4_ADDR_RANGE 7
TS_IPV4_地址_范围7
A range of IPv4 addresses, represented by two four-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.
IPv4地址的范围，由两个四个八位组值表示。第一个值是起始IPv4地址（包括），第二个值是结束IPv4地址（包括）。两个指定地址之间的所有地址都被视为在列表中。
TS_IPV6_ADDR_RANGE 8
TS_IPV6_地址范围8
A range of IPv6 addresses, represented by two sixteen-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.
IPv6地址的范围，由两个十六位八位组值表示。第一个值是起始IPv6地址（含），第二个值是结束IPv6地址（含）。两个指定地址之间的所有地址都被视为在列表中。
RESERVED TO IANA 9-240 PRIVATE USE 241-255
保留给IANA 9-240专用241-255
The Encrypted Payload, denoted SK{...} or E in this memo, contains other payloads in encrypted form. The Encrypted Payload, if present in a message, MUST be the last payload in the message. Often, it is the only payload in the message.
加密的有效载荷，在本备忘录中表示为SK{…}或E，包含其他加密形式的有效载荷。加密的有效负载（如果存在于消息中）必须是消息中的最后一个有效负载。通常，它是消息中唯一的有效负载。
The algorithms for encryption and integrity protection are negotiated during IKE_SA setup, and the keys are computed as specified in sections 2.14 and 2.18.
加密和完整性保护的算法在IKE_SA设置期间协商，密钥按照第2.14节和第2.18节的规定计算。
The encryption and integrity protection algorithms are modeled after the ESP algorithms described in RFCs 2104 [KBC96], 4303 [RFC4303], and 2451 [ESPCBC]. This document completely specifies the cryptographic processing of IKE data, but those documents should be consulted for design rationale. We require a block cipher with a fixed block size and an integrity check algorithm that computes a fixed-length checksum over a variable size message.
加密和完整性保护算法以RFCs 2104[KBC96]、4303[RFC4303]和2451[ESPCBC]中描述的ESP算法为模型。本文件完全规定了IKE数据的加密处理，但设计原理应参考这些文件。我们需要具有固定块大小的分组密码和完整性检查算法，该算法在可变大小的消息上计算固定长度的校验和。
The payload type for an Encrypted payload is forty six (46). The Encrypted Payload consists of the IKE generic payload header followed by individual fields as follows:
加密有效负载的有效负载类型为四十六（46）。加密的有效负载由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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initialization Vector !
! (length is block size for 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 encryption algorithm) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Padding (0-255 octets) !
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
! ! Pad Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Encrypted Payload Format
图21：加密有效负载格式
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 and 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, IV, Encrypted IKE Payloads, Padding, Pad Length, and Integrity Checksum Data.
o 有效负载长度-包括标头的长度、IV、加密IKE有效负载、填充、焊盘长度和完整性校验和数据。
o Initialization Vector - A randomly chosen value whose length is equal to the block length of the underlying encryption algorithm. Recipients MUST accept any value. Senders SHOULD either pick this value pseudo-randomly and independently for each message or use the final ciphertext block of the previous message sent. Senders MUST NOT use the same value for each message, use a sequence of values with low hamming distance (e.g., a sequence number), or use ciphertext from a received message.
o 初始化向量-随机选择的值，其长度等于基础加密算法的块长度。收件人必须接受任何值。发送方应为每条消息单独伪随机选取该值，或使用前一条消息的最终密文块。发送方不得对每条消息使用相同的值，不得使用具有低汉明距离的值序列（例如，序列号），也不得使用接收到的消息中的密文。
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长度。必须对加密消息计算校验和。其长度由协商的完整性算法决定。
The Configuration payload, denoted CP in this document, is used to exchange configuration information between IKE peers. The exchange is for an IRAC to request an internal IP address from an IRAS and to exchange other information of the sort that one would acquire with Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly connected to a LAN.
配置有效负载在本文档中表示为CP，用于在IKE对等方之间交换配置信息。交换是指IRAC从IRAS请求内部IP地址，并交换其他信息，如果IRAC直接连接到LAN，则可使用动态主机配置协议（DHCP）获取此类信息。
Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE request. The IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK or a Notify payload with an error type indicating why the request could not be honored. An exception is that a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted as an indication that the request was not supported.
配置有效负载的类型为CFG_请求/CFG_回复或CFG_设置/CFG_确认（请参阅下面有效负载描述中的CFG类型）。CFG_请求和CFG_集有效载荷可以选择性地添加到任何IKE请求中。IKE响应必须包含相应的CFG_REPLY或CFG_ACK，或带有错误类型的Notify有效负载，指示无法执行请求的原因。例外情况是，最小实现可能会忽略所有CFG_请求和CFG_集有效负载，因此必须接受没有相应CFG_回复或CFG_确认的响应消息，作为不支持请求的指示。
"CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information from its peer. If an attribute in the CFG_REQUEST Configuration Payload is not zero-length, it is taken as a suggestion for that attribute. The CFG_REPLY Configuration Payload MAY return that value, or a new one. It MAY also add new attributes and not include some requested ones. Requestors MUST ignore returned attributes that they do not recognize.
“CFG_REQUEST/CFG_REPLY”允许IKE端点从其对等方请求信息。如果CFG_请求配置有效负载中的属性不是零长度，则将其作为该属性的建议。CFG_REPLY配置负载可能返回该值，或者返回一个新值。它还可以添加新属性，而不包括一些请求的属性。请求者必须忽略他们无法识别的返回属性。
Some attributes MAY be multi-valued, in which case multiple attribute values of the same type are sent and/or returned. Generally, all values of an attribute are returned when the attribute is requested. For some attributes (in this version of the specification only internal addresses), multiple requests indicates a request that multiple values be assigned. For these attributes, the number of values returned SHOULD NOT exceed the number requested.
某些属性可能是多值的，在这种情况下，发送和/或返回相同类型的多个属性值。通常，属性的所有值都会在请求该属性时返回。对于某些属性（在此版本的规范中，仅限内部地址），多个请求表示分配多个值的请求。对于这些属性，返回的值的数量不应超过请求的数量。
If the data type requested in a CFG_REQUEST is not recognized or not supported, the responder MUST NOT return an error type but rather MUST either send a CFG_REPLY that MAY be empty or a reply not containing a CFG_REPLY payload at all. Error returns are reserved for cases where the request is recognized but cannot be performed as requested or the request is badly formatted.
如果CFG_请求中请求的数据类型无法识别或不受支持，则响应程序不得返回错误类型，而是必须发送可能为空的CFG_回复或根本不包含CFG_回复有效负载的回复。错误返回保留用于识别请求但无法按请求执行或请求格式错误的情况。
"CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data to its peer. In this case, the CFG_SET Configuration Payload contains attributes the initiator wants its peer to alter. The responder MUST return a Configuration Payload if it accepted any of the configuration data and it MUST contain the attributes that the responder accepted with zero-length data. Those attributes that it did not accept MUST NOT be in the CFG_ACK Configuration Payload. If no attributes were accepted, the responder MUST return either an empty CFG_ACK payload or a response message without a CFG_ACK payload. There are currently no defined uses for the CFG_SET/CFG_ACK exchange, though they may be used in connection with extensions based on Vendor IDs. An minimal implementation of this specification MAY ignore CFG_SET payloads.
“CFG_SET/CFG_ACK”允许IKE端点将配置数据推送到其对等方。在这种情况下，CFG_集配置有效负载包含启动器希望其对等方更改的属性。如果响应程序接受任何配置数据，则它必须返回配置有效负载，并且它必须包含响应程序使用零长度数据接受的属性。它不接受的那些属性不能在CFG_ACK配置负载中。如果未接受任何属性，响应者必须返回空的CFG_ACK有效负载或不带CFG_ACK有效负载的响应消息。CFG_SET/CFG_ACK exchange目前没有定义的用途，尽管它们可以与基于供应商ID的扩展一起使用。本规范的最小实现可能忽略CFG_集有效载荷。
Extensions via the CP payload SHOULD NOT be used for general purpose management. Its main intent is to provide a bootstrap mechanism to exchange information within IPsec from IRAS to IRAC. While it MAY be useful to use such a method to exchange information between some Security Gateways (SGW) or small networks, existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP] should be preferred for enterprise management as well as subsequent information exchanges.
通过CP有效负载的扩展不应用于通用管理。其主要目的是提供一种引导机制，以便在IPsec内从IRA到IRAC交换信息。虽然使用这种方法在一些安全网关（SGW）或小型网络之间交换信息可能有用，但对于企业管理以及后续信息交换，应首选现有的管理协议，如DHCP[DHCP]、RADIUS[RADIUS]、SNMP或LDAP[LDAP]。
The Configuration Payload is defined as follows:
配置有效负载定义如下：
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CFG Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Configuration 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CFG Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Configuration Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Configuration Payload Format
图22：配置有效负载格式
The payload type for the Configuration Payload is forty seven (47).
配置有效载荷的有效载荷类型为四十七（47）。
o CFG Type (1 octet) - The type of exchange represented by the Configuration Attributes.
o CFG类型（1个八位字节）-由配置属性表示的交换类型。
CFG Type Value
=========== =====
RESERVED 0
CFG_REQUEST 1
CFG_REPLY 2
CFG_SET 3
CFG_ACK 4
CFG Type Value
=========== =====
RESERVED 0
CFG_REQUEST 1
CFG_REPLY 2
CFG_SET 3
CFG_ACK 4
values 5-127 are reserved to IANA. Values 128-255 are for private use among mutually consenting parties.
值5-127保留给IANA。值128-255供双方同意的各方私人使用。
o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on receipt.
o 保留（3个八位字节）-必须作为零发送；必须在收到时忽略。
o Configuration Attributes (variable length) - These are type length values specific to the Configuration Payload and are defined below. There may be zero or more Configuration Attributes in this payload.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Configuration Attribute Format
图23：配置属性格式
o Reserved (1 bit) - This bit MUST be set to zero and MUST be ignored on receipt.
o 保留（1位）-此位必须设置为零，并且在收到时必须忽略。
o Attribute Type (15 bits) - A unique identifier for each of the Configuration Attribute Types.
o 属性类型（15位）-每个配置属性类型的唯一标识符。
o Length (2 octets) - Length in octets of Value.
o 长度（2个八位字节）-值的八位字节长度。
o Value (0 or more octets) - The variable-length value of this Configuration Attribute.
o 值（0或更多八位字节）-此配置属性的可变长度值。
The following attribute types have been defined:
已定义以下属性类型：
Multi-
Attribute Type Value Valued Length
======================= ===== ====== ==================
RESERVED 0
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
RESERVED 9
INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_NBNS 11 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets
Multi-
Attribute Type Value Valued Length
======================= ===== ====== ==================
RESERVED 0
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
RESERVED 9
INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_NBNS 11 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets
* These attributes may be multi-valued on return only if multiple values were requested.
* 仅当请求了多个值时，这些属性在返回时才可以是多值的。
Types 16-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties.
类型16-16383保留给IANA。价值16384-32767供双方同意的私人使用。
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the internal network, sometimes called a red node address or private address and MAY be a private address on the Internet. In a request message, the address specified is a requested address (or zero if no specific address is requested). If a specific address is requested, it likely indicates that a previous connection existed with this address and the requestor would like to reuse that address. With IPv6, a requestor MAY supply the low-order address bytes it wants to use. Multiple internal addresses MAY be requested by requesting multiple internal address attributes. The responder MAY only send up to the number of addresses requested. The INTERNAL_IP6_ADDRESS is made up of two fields: the first is a sixteen-octet IPv6 address and the second is a one-octet prefix-length as defined in [ADDRIPV6].
o 内部IP地址，内部IP地址-内部网络上的地址，有时称为红色节点地址或专用地址，可能是Internet上的专用地址。在请求消息中，指定的地址是请求的地址（如果未请求特定地址，则为零）。如果请求了一个特定的地址，它很可能表示以前存在与该地址的连接，并且请求者希望重用该地址。使用IPv6，请求者可以提供它想要使用的低位地址字节。可以通过请求多个内部地址属性来请求多个内部地址。响应者最多只能发送请求的地址数。内部_IP6_地址由两个字段组成：第一个字段是16个八位字节的IPv6地址，第二个字段是[ADDRIPV6]中定义的一个八位字节前缀长度。
The requested address is valid until the expiry time defined with the INTERNAL_ADDRESS EXPIRY attribute or there are no IKE_SAs between the peers.
请求的地址在使用INTERNAL_address expiry属性定义的到期时间或对等方之间没有IKE_SA之前有效。
o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and reply messages (e.g., 255.255.255.0), and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute.
o INTERNAL_IP4_网络掩码-内部网络的网络掩码。请求和回复消息中只允许使用一个网络掩码（例如255.255.255.0），并且只能与内部_IP4_ADDRESS属性一起使用。
o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS server within the network. Multiple DNS servers MAY be requested. The responder MAY respond with zero or more DNS server attributes.
o INTERNAL_IP4_DNS，INTERNAL_IP6_DNS-指定网络中DNS服务器的地址。可能会请求多个DNS服务器。响应者可以使用零个或多个DNS服务器属性进行响应。
o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a NetBios Name Server (WINS) within the network. Multiple NBNS servers MAY be requested. The responder MAY respond with zero or more NBNS server attributes.
o INTERNAL_IP4_NBNS，INTERNAL_IP6_NBNS-指定网络中NetBios名称服务器（WINS）的地址。可能会请求多个NBNS服务器。响应者可以使用零个或多个NBNS服务器属性进行响应。
o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one of these attributes MAY be present in the reply.
o INTERNAL_ADDRESS_EXPIRY-指定主机可以使用内部IP地址的秒数。主机必须在此到期时间之前续订IP地址。回复中只能存在这些属性中的一个。
o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send any internal DHCP requests to the address contained within the attribute. Multiple DHCP servers MAY be requested. The responder MAY respond with zero or more DHCP server attributes.
o INTERNAL_IP4_DHCP、INTERNAL_IP6_DHCP-指示主机向属性中包含的地址发送任何内部DHCP请求。可能会请求多个DHCP服务器。响应者可以使用零个或多个DHCP服务器属性进行响应。
o APPLICATION_VERSION - The version or application information of the IPsec host. This is a string of printable ASCII characters that is NOT null terminated.
o APPLICATION_VERSION—IPsec主机的版本或应用程序信息。这是一个非空终止的可打印ASCII字符字符串。
o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-device protects. This attribute is made up of two fields: the first is an IP address and the second is a netmask. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-network attributes.
o 内部_IP4_子网-此边缘设备保护的受保护子网。此属性由两个字段组成：第一个是IP地址，第二个是网络掩码。可以请求多个子网络。响应者可以使用零个或多个子网络属性进行响应。
o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute MUST be zero-length and specifies a query to the responder to reply back with all of the attributes that it supports. The response contains an attribute that contains a set of attribute identifiers each in 2 octets. The length divided by 2 (octets) would state the number of supported attributes contained in the response.
o 受支持的_属性-当在请求中使用时，该属性的长度必须为零，并指定一个查询给响应程序，以使用其支持的所有属性进行回复。该响应包含一个属性，该属性包含一组属性标识符，每个标识符有两个八位字节。长度除以2（八位字节）表示响应中包含的受支持属性的数量。
o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-device protects. This attribute is made up of two fields: the first is a sixteen-octet IPv6 address and the second is a one-octet prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-network attributes.
o 内部_IP6_子网-此边缘设备保护的受保护子网。此属性由两个字段组成：第一个字段是16个八位字节的IPv6地址，第二个字段是[ADDRIPV6]中定义的一个八位字节前缀长度。可以请求多个子网络。响应者可以使用零个或多个子网络属性进行响应。
Note that no recommendations are made in this document as to how an implementation actually figures out what information to send in a reply. That is, we do not recommend any specific method of an IRAS determining which DNS server should be returned to a requesting IRAC.
请注意，本文档中没有提出关于实现如何实际确定在答复中发送哪些信息的建议。也就是说，我们不建议IRAS使用任何特定方法来确定应将哪个DNS服务器返回给请求的IRAC。
The Extensible Authentication Protocol Payload, denoted EAP in this memo, allows IKE_SAs to be authenticated using the protocol defined in RFC 3748 [EAP] and subsequent extensions to that protocol. The full set of acceptable values for the payload is defined elsewhere, but a short summary of RFC 3748 is included here to make this document stand alone in the common cases.
可扩展身份验证协议有效负载（在本备忘录中表示为EAP）允许使用RFC 3748[EAP]中定义的协议以及该协议的后续扩展对IKE_SAs进行身份验证。有效载荷的完整可接受值集在别处定义，但此处包含RFC 3748的简短摘要，以使本文件在常见情况下独立。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ EAP Message ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ EAP Message ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: EAP Payload Format
图24:EAP有效负载格式
The payload type for an EAP Payload is forty eight (48).
EAP有效载荷的有效载荷类型为四十八（48）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Code ! Identifier ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Type_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Code ! Identifier ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 25: EAP Message Format
图25:EAP消息格式
o Code (1 octet) indicates whether this message is a Request (1), Response (2), Success (3), or Failure (4).
o 代码（1个八位字节）指示此消息是请求（1）、响应（2）、成功（3）还是失败（4）。
o Identifier (1 octet) is used in PPP to distinguish replayed messages from repeated ones. Since in IKE, EAP runs over a reliable protocol, it serves no function here. In a response message, this octet MUST be set to match the identifier in the corresponding request. In other messages, this field MAY be set to any value.
o PPP中使用标识符（1个八位组）来区分重播消息和重复消息。因为在IKE中，EAP通过可靠的协议运行，所以它在这里不起任何作用。在响应消息中，必须将此八位字节设置为与相应请求中的标识符匹配。在其他消息中，此字段可以设置为任何值。
o Length (2 octets) is the length of the EAP message and MUST be four less than the Payload Length of the encapsulating payload.
o 长度（2个八位字节）是EAP消息的长度，必须比封装有效负载的有效负载长度小四个。
o Type (1 octet) is present only if the Code field is Request (1) or Response (2). For other codes, the EAP message length MUST be four octets and the Type and Type_Data fields MUST NOT be present. In a Request (1) message, Type indicates the data being requested. In a Response (2) message, Type MUST either be Nak or match the type of the data requested. The following types are defined in RFC 3748:
o 仅当代码字段为请求（1）或响应（2）时，类型（1个八位组）才存在。对于其他代码，EAP消息长度必须为四个八位字节，并且类型和类型_数据字段不得存在。在请求（1）消息中，Type表示所请求的数据。在响应（2）消息中，类型必须为Nak或与请求的数据类型匹配。RFC 3748中定义了以下类型：
1 Identity 2 Notification 3 Nak (Response Only) 4 MD5-Challenge 5 One-Time Password (OTP) 6 Generic Token Card
1身份2通知3 Nak（仅响应）4 MD5质询5一次性密码（OTP）6通用令牌卡
o Type_Data (Variable Length) varies with the Type of Request and the associated Response. For the documentation of the EAP methods, see [EAP].
o 类型_数据（可变长度）随请求类型和相关响应而变化。有关EAP方法的文档，请参阅[EAP]。
Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them.
请注意，由于IKE在协议的消息3中传递了启动器标识的指示，因此响应者不应发送EAP标识请求。但是，如果启动器收到此类请求，则应响应这些请求。
In order to assure that all implementations of IKEv2 can interoperate, there are "MUST support" requirements in addition to those listed elsewhere. Of course, IKEv2 is a security protocol, and one of its major functions is to allow only authorized parties to successfully complete establishment of SAs. So a particular implementation may be configured with any of a number of restrictions concerning algorithms and trusted authorities that will prevent universal interoperability.
为了确保IKEv2的所有实现都可以互操作，除了其他地方列出的要求外，还有“必须支持”的要求。当然，IKEv2是一种安全协议，其主要功能之一是只允许授权方成功完成SA的建立。因此，一个特定的实现可能被配置为与算法和可信机构有关的许多限制中的任何一个，这些限制将阻止通用互操作性。
IKEv2 is designed to permit minimal implementations that can interoperate with all compliant implementations. There are a series of optional features that can easily be ignored by a particular implementation if it does not support that feature. Those features include:
IKEv2被设计为允许与所有兼容实现互操作的最小实现。如果特定的实现不支持一系列可选功能，那么这些功能很容易被忽略。这些特点包括：
Ability to negotiate SAs through a NAT and tunnel the resulting ESP SA over UDP.
能够通过NAT协商SAs，并通过UDP隧道生成ESP SA。
Ability to request (and respond to a request for) a temporary IP address on the remote end of a tunnel.
能够在隧道的远程端请求（并响应请求）临时IP地址。
Ability to support various types of legacy authentication.
能够支持各种类型的旧式身份验证。
Ability to support window sizes greater than one.
能够支持大于1的窗口大小。
Ability to establish multiple ESP and/or AH SAs within a single IKE_SA.
能够在单个IKE_SA内建立多个ESP和/或AH SA。
Ability to rekey SAs.
重新输入SAs的能力。
To assure interoperability, all implementations MUST be capable of parsing all payload types (if only to skip over them) and to ignore payload types that it does not support unless the critical bit is set in the payload header. If the critical bit is set in an unsupported payload header, all implementations MUST reject the messages containing those payloads.
为了确保互操作性，所有实现必须能够解析所有有效负载类型（如果只是跳过它们），并忽略它不支持的有效负载类型，除非在有效负载报头中设置了关键位。如果在不受支持的负载头中设置了关键位，则所有实现都必须拒绝包含这些负载的消息。
Every implementation MUST be capable of doing four-message IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, one for ESP and/or AH). Implementations MAY be initiate-only or respond-only if appropriate for their platform. Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply (note that within the context of an IKE_SA, an "empty" message consists of an IKE header followed by an Encrypted payload with no payloads contained in it). A minimal implementation MAY support the CREATE_CHILD_SA exchange only in so far as to recognize requests and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A minimal implementation need not be able to initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA expires (based on locally configured values of either lifetime or octets passed), and implementation MAY either try to renew it with a CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and create a new one. If the responder rejects the CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS notification, the implementation MUST be capable of instead closing the old SA and creating a new one.
每个实现必须能够进行四次消息IKE_SA_INIT和IKE_AUTH交换，建立两个SA（一个用于IKE，一个用于ESP和/或AH）。实现可能仅在适合其平台的情况下启动或响应。每个实现都必须能够响应信息交换，但最小的实现可能会以空的信息回复响应任何信息性消息（注意，在IKE_SA的上下文中，“空”消息由IKE头和加密的有效负载组成，其中不包含有效负载）。最低限度的实现可能只支持CREATE_CHILD_SA交换，以识别请求并使用类型为NO_ADDITIONAL_SA的Notify payload拒绝它们。最低限度的实现不需要能够启动创建子SA或信息交换。当SA过期时（基于本地配置的生存期或已传递的八位字节值），实现可以尝试使用CREATE_CHILD_SA交换续订SA，也可以删除（关闭）旧SA并创建新SA。如果响应者拒绝了CREATE_CHILD_SA请求，并且没有附加的_SAS通知，则实现必须能够关闭旧SA并创建新SA。
Implementations are not required to support requesting temporary IP addresses or responding to such requests. If an implementation does support issuing such requests, it MUST include a CP payload in message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are optional. If an implementation supports responding to such requests, it MUST parse the CP payload of type CFG_REQUEST in message 3 and recognize a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing an address of the appropriate type, it MUST return a CP payload of type CFG_REPLY containing an address of the requested type. The responder SHOULD include all of the other related attributes if it has them.
实现不需要支持请求临时IP地址或响应此类请求。如果一个实现确实支持发出这样的请求，那么它必须在消息3中包含一个CP负载，其中至少包含一个类型为INTERNAL_IP4_ADDRESS或INTERNAL_IP6_ADDRESS的字段。所有其他字段都是可选的。如果实现支持响应此类请求，则必须解析消息3中CFG_REQUEST类型的CP有效负载，并识别INTERNAL_IP4_ADDRESS或INTERNAL_IP6_ADDRESS类型的字段。如果它支持租用适当类型的地址，则必须返回CFG_REPLY类型的CP有效负载，其中包含请求类型的地址。响应者应该包括所有其他相关属性（如果有）。
A minimal IPv4 responder implementation will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute and will respond with the address and other related attributes regardless of whether the initiator requested them.
最小IPv4响应程序实现将忽略CP有效负载的内容，除非确定其包含内部_IP4_地址属性，并将使用地址和其他相关属性进行响应，而不管启动器是否请求它们。
A minimal IPv4 initiator will generate a CP payload containing only an INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring attributes it does not know how to use. The only attribute it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must use to bound the lifetime of the SA unless it successfully renews the lease before it expires. Minimal initiators need not be able to request lease renewals and minimal responders need not respond to them.
最小IPv4启动器将生成仅包含内部IP地址属性的CP有效负载，并将忽略其不知道如何使用的属性来解析响应。它必须能够处理的唯一属性是INTERNAL_ADDRESS_expiration，它必须使用该属性来绑定SA的生存期，除非它在租约到期之前成功续订租约。最小发起人不需要能够请求续租，最小响应人也不需要响应。
For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following:
要调用符合本规范的实现，必须能够将其配置为接受以下内容：
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.
包含大小为1024或2048位的RSA密钥并由其签名的PKIX证书，其中传递的ID是ID_KEY_ID、ID_FQDN、ID_RFC822_ADDR或ID_DER_ASN1_DN中的任意一个。
Shared key authentication where the ID passes is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR.
ID传递的共享密钥身份验证是ID_key_ID、ID_FQDN或ID_RFC822_ADDR中的任意一个。
Authentication where the responder is authenticated using PKIX Certificates and the initiator is authenticated using shared key authentication.
身份验证，其中使用PKIX证书对响应者进行身份验证，使用共享密钥身份验证对启动器进行身份验证。
While this protocol is designed to minimize disclosure of configuration information to unauthenticated peers, some such disclosure is unavoidable. One peer or the other must identify itself first and prove its identity first. To avoid probing, the initiator of an exchange is required to identify itself first, and usually is required to authenticate itself first. The initiator can, however, learn that the responder supports IKE and what cryptographic protocols it supports. The responder (or someone impersonating the responder) can probe the initiator not only for its identity, but using CERTREQ payloads may be able to determine what certificates the initiator is willing to use.
虽然此协议旨在最大限度地减少向未经验证的对等方披露配置信息，但某些此类披露是不可避免的。一方或另一方必须首先确定自己的身份，并首先证明自己的身份。为了避免探测，要求交换的发起方首先标识自身，并且通常需要首先对自身进行身份验证。但是，发起者可以了解响应者支持IKE以及它支持什么加密协议。响应者（或模拟响应者的人）不仅可以探测启动器的身份，还可以使用CERTREQ有效负载确定启动器愿意使用的证书。
Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates.
EAP认证的使用在一定程度上改变了探测的可能性。当使用EAP身份验证时，响应程序在启动器之前验证其身份，因此知道有效启动器名称的启动器可以探测响应程序的名称和证书。
Repeated rekeying using CREATE_CHILD_SA without additional Diffie-Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a single key or overrun of either endpoint. Implementers should take note of this fact and set a limit on CREATE_CHILD_SA exchanges between exponentiations. This memo does not prescribe such a limit.
在不进行额外Diffie-Hellman交换的情况下，使用CREATE_CHILD_SA重复密钥更新会使所有SA容易受到单个密钥密码分析或任一端点溢出的攻击。实现者应该注意这一事实，并对求幂之间的CREATE_CHILD_SA交换设置一个限制。本备忘录未规定此类限制。
The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs, it is difficult to determine the strength of a key for any of the defined groups. Diffie-Hellman group number two, when used with a strong random number generator and an exponent no less than 200 bits, is common for use with 3DES. Group five provides greater security than group two. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these estimates when establishing policy and negotiating security parameters.
使用此处定义的任何组从Diffie-Hellman交换中导出的密钥的强度取决于组的固有强度、所用指数的大小以及所用随机数生成器提供的熵。由于这些输入，很难确定任何已定义组的键的强度。Diffie-Hellman第二组当与强随机数生成器和不小于200位的指数一起使用时，通常用于3DES。第五组提供了比第二组更高的安全性。第一组仅用于历史目的，除了与DES一起使用外，不提供足够的强度，DES也仅用于历史用途。在建立策略和协商安全参数时，实现应该注意这些估计。
Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE that prohibits using stronger groups nor is there anything that will dilute the strength obtained from stronger groups (limited by the strength of the other algorithms negotiated including the prf function). In fact, the extensible framework of IKE encourages the definition of more groups; use of elliptical curve groups may greatly increase strength using much smaller numbers.
请注意，这些限制是针对Diffie-Hellman组本身的。IKE中没有任何内容禁止使用更强的组，也没有任何内容会稀释从更强的组获得的强度（受协商的其他算法（包括prf函数）的强度限制）。事实上，IKE的可扩展框架鼓励定义更多的组；使用椭圆曲线组可以使用更小的数字大大提高强度。
It is assumed that all Diffie-Hellman exponents are erased from memory after use. In particular, these exponents MUST NOT be derived from long-lived secrets like the seed to a pseudo-random generator that is not erased after use.
假设所有Diffie-Hellman指数在使用后从内存中删除。特别是，这些指数不能来源于长期存在的秘密，如伪随机发生器的种子，该种子在使用后不会被擦除。
The strength of all keys is limited by the size of the output of the negotiated prf function. For this reason, a prf function whose output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with this protocol.
所有密钥的强度受协商prf函数输出的大小限制。因此，输出小于128位的prf函数（例如3DES-CBC）不得与本协议一起使用。
The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source (see [RFC4086]). Implementers should take care to ensure that use of random numbers for both keys and nonces is engineered in a fashion that does not undermine the security of the keys.
该协议的安全性主要取决于随机选择的参数的随机性。这些应该由强随机或正确播种的伪随机源生成（参见[RFC4086]）。实现者应该注意确保对密钥和nonce使用随机数的方式不会破坏密钥的安全性。
For information on the rationale of many of the cryptographic design choices in this protocol, see [SIGMA] and [SKEME]. Though the security of negotiated CHILD_SAs does not depend on the strength of the encryption and integrity protection negotiated in the IKE_SA, implementations MUST NOT negotiate NONE as the IKE integrity protection algorithm or ENCR_NULL as the IKE encryption algorithm.
有关本协议中许多密码设计选择的基本原理的信息，请参见[SIGMA]和[SKEME]。尽管协商的子_SA的安全性不取决于在IKE_SA中协商的加密和完整性保护的强度，但实现不能将无协商作为IKE完整性保护算法，也不能将ENCR_NULL协商作为IKE加密算法。
When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social engineering attacks, among others.
在使用预共享密钥时，一个重要的考虑因素是如何确保这些秘密的随机性。最强的实践是确保任何预共享密钥包含的随机性与正在协商的最强密钥一样多。从密码、名称或其他低熵源派生共享秘密是不安全的。这些来源受到字典和社会工程攻击等。
The NAT_DETECTION_*_IP notifications contain a hash of the addresses and ports in an attempt to hide internal IP addresses behind a NAT. Since the IPv4 address space is only 32 bits, and it is usually very sparse, it would be possible for an attacker to find out the internal address used behind the NAT box by trying all possible IP addresses and trying to find the matching hash. The port numbers are normally fixed to 500, and the SPIs can be extracted from the packet. This reduces the number of hash calculations to 2^32. With an educated guess of the use of private address space, the number of hash calculations is much smaller. Designers should therefore not assume that use of IKE will not leak internal address information.
NAT_检测_*_IP通知包含地址和端口的散列，试图将内部IP地址隐藏在NAT后面。由于IPv4地址空间只有32位，而且通常非常稀疏，攻击者可以通过尝试所有可能的IP地址并尝试查找匹配的哈希来找出NAT框后面使用的内部地址。端口号通常固定为500，可以从数据包中提取SPI。这将哈希计算的数量减少到2^32。通过对私有地址空间使用情况的合理猜测，散列计算的数量要小得多。因此，设计者不应该假设IKE的使用不会泄露内部地址信息。
When using an EAP authentication method that does not generate a shared key for protecting a subsequent AUTH payload, certain man-in-the-middle and server impersonation attacks are possible [EAPMITM]. These vulnerabilities occur when EAP is also used in protocols that are not protected with a secure tunnel. Since EAP is a general-
当使用不生成共享密钥的EAP身份验证方法来保护后续身份验证有效负载时，可能会发生某些中间人和服务器模拟攻击[EAPMITM]。当EAP也用于未受安全隧道保护的协议时，就会出现这些漏洞。因为EAP是一个通用的-
purpose authentication protocol, which is often used to provide single-signon facilities, a deployed IPsec solution that relies on an EAP authentication method that does not generate a shared key (also known as a non-key-generating EAP method) can become compromised due to the deployment of an entirely unrelated application that also happens to use the same non-key-generating EAP method, but in an unprotected fashion. Note that this vulnerability is not limited to just EAP, but can occur in other scenarios where an authentication infrastructure is reused. For example, if the EAP mechanism used by IKEv2 utilizes a token authenticator, a man-in-the-middle attacker could impersonate the web server, intercept the token authentication exchange, and use it to initiate an IKEv2 connection. For this reason, use of non-key-generating EAP methods SHOULD be avoided where possible. Where they are used, it is extremely important that all usages of these EAP methods SHOULD utilize a protected tunnel, where the initiator validates the responder's certificate before initiating the EAP exchange. Implementers SHOULD describe the vulnerabilities of using non-key-generating EAP methods in the documentation of their implementations so that the administrators deploying IPsec solutions are aware of these dangers.
目的身份验证协议，通常用于提供单一登录设施，是一种部署的IPsec解决方案，它依赖于不生成共享密钥的EAP身份验证方法（也称为非密钥生成EAP方法）由于部署一个完全不相关的应用程序，该应用程序也碰巧使用相同的非密钥生成EAP方法，但以不受保护的方式，因此可能会受到损害。请注意，此漏洞不仅限于EAP，而且在重用身份验证基础架构的其他场景中也可能发生。例如，如果IKEv2使用的EAP机制使用令牌身份验证器，中间人攻击者可以模拟web服务器，拦截令牌身份验证交换，并使用它启动IKEv2连接。因此，应尽可能避免使用非密钥生成EAP方法。在使用这些EAP方法的地方，这些EAP方法的所有使用都应使用受保护的隧道，在该隧道中，发起方在发起EAP交换之前验证响应方的证书，这一点非常重要。实施者应在其实施的文档中描述使用非密钥生成EAP方法的漏洞，以便部署IPsec解决方案的管理员了解这些危险。
An implementation using EAP MUST also use a public-key-based authentication of the server to the client before the EAP exchange begins, even if the EAP method offers mutual authentication. This avoids having additional IKEv2 protocol variations and protects the EAP data from active attackers.
使用EAP的实现还必须在EAP交换开始之前使用基于公钥的服务器到客户端的身份验证，即使EAP方法提供了相互身份验证。这避免了额外的IKEv2协议变体，并保护EAP数据免受主动攻击者的攻击。
If the messages of IKEv2 are long enough that IP-level fragmentation is necessary, it is possible that attackers could prevent the exchange from completing by exhausting the reassembly buffers. The chances of this can be minimized by using the Hash and URL encodings instead of sending certificates (see section 3.6). Additional mitigations are discussed in [KPS03].
如果IKEv2的消息足够长，需要IP级别的碎片，则攻击者可能会通过耗尽重组缓冲区来阻止交换完成。通过使用哈希和URL编码，而不是发送证书，可以最大限度地减少这种情况的发生（参见第3.6节）。[KPS03]中讨论了其他缓解措施。
This document defines a number of new field types and values where future assignments will be managed by the IANA.
本文件定义了许多新的字段类型和值，IANA将管理这些字段的未来分配。
The following registries have been created by the IANA:
IANA已经创建了以下注册：
IKEv2 Exchange Types (section 3.1) IKEv2 Payload Types (section 3.2) IKEv2 Transform Types (section 3.3.2) IKEv2 Transform Attribute Types (section 3.3.2) IKEv2 Encryption Transform IDs (section 3.3.2) IKEv2 Pseudo-random Function Transform IDs (section 3.3.2) IKEv2 Integrity Algorithm Transform IDs (section 3.3.2)
IKEv2交换类型（第3.1节）IKEv2有效负载类型（第3.2节）IKEv2转换类型（第3.3.2节）IKEv2转换属性类型（第3.3.2节）IKEv2加密转换ID（第3.3.2节）IKEv2伪随机函数转换ID（第3.3.2节）IKEv2完整性算法转换ID（第3.3.2节）
IKEv2 Diffie-Hellman Transform IDs (section 3.3.2) IKEv2 Identification Payload ID Types (section 3.5) IKEv2 Certificate Encodings (section 3.6) IKEv2 Authentication Method (section 3.8) IKEv2 Notify Message Types (section 3.10.1) IKEv2 Notification IPCOMP Transform IDs (section 3.10.1) IKEv2 Security Protocol Identifiers (section 3.3.1) IKEv2 Traffic Selector Types (section 3.13.1) IKEv2 Configuration Payload CFG Types (section 3.15) IKEv2 Configuration Payload Attribute Types (section 3.15.1)
IKEv2 Diffie-Hellman转换ID（第3.3.2节）IKEv2标识有效负载ID类型（第3.5节）IKEv2证书编码（第3.6节）IKEv2身份验证方法（第3.8节）IKEv2通知消息类型（第3.10.1节）IKEv2通知IPCOMP转换ID（第3.10.1节）IKEv2安全协议标识符（第3.3.1节）IKEv2流量选择器类型（第3.13.1节）IKEv2配置有效负载CFG类型（第3.15节）IKEv2配置有效负载属性类型（第3.15.1节）
Note: When creating a new Transform Type, a new registry for it must be created.
注意：创建新的转换类型时，必须为其创建新的注册表。
Changes and additions to any of those registries are by expert review.
对这些登记册的任何更改和增补都是通过专家审查进行的。
This document is a collaborative effort of the entire IPsec WG. If there were no limit to the number of authors that could appear on an RFC, the following, in alphabetical order, would have been listed: Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Reingold, and Michael Richardson. Many other people contributed to the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, each of which has its own list of authors. Hugh Daniel suggested the feature of having the initiator, in message 3, specify a name for the responder, and gave the feature the cute name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped refine the design of the traffic selector negotiation.
本文档是整个IPsec工作组的协作成果。如果RFC上可以出现的作者数量没有限制，那么按字母顺序排列的将列出以下作者：比尔·艾略、斯蒂芬·博列伊、史蒂夫·贝洛文、萨拉·比坦、马特·布雷兹、兰·卡内蒂、达伦·杜克斯、丹·哈金斯、保罗·霍夫曼、约翰·伊奥尼迪斯、查理·考夫曼、史蒂夫·肯特、安吉罗斯·科鲁米蒂斯、泰罗·基维宁、，雨果·克劳奇克、安德鲁·克鲁瓦尼乌克、拉迪亚·帕尔曼、奥马尔·莱因戈尔德和迈克尔·理查森。许多其他人对设计做出了贡献。它是IKEv1、ISAKMP和IPsec DOI的演变，它们都有自己的作者列表。Hugh Daniel建议让发起者在消息3中为响应者指定一个名称，并给该功能起了一个可爱的名字“You Tarzan，Me Jane”。David Faucher和Valery Smyzlov帮助改进了交通选择器协商的设计。
[ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[ADDGROUP]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman组”，RFC 3526，2003年5月。
[ADDRIPV6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRIPV6]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[EAP]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[ESPCBC]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[Hutt05] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[Hutt05]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption", American National Standards Institute, 1983.
[DES]ANSI X3.106，“美国信息系统数据链路加密国家标准”，美国国家标准协会，1983年。
[DH] Diffie, W., and Hellman M., "New Directions in Cryptography", IEEE Transactions on Information Theory, V. IT-22, n. 6, June 1977.
[DH]Diffie，W.和Hellman M.，“密码学的新方向”，IEEE信息论交易，V.IT-22，n。1977年6月6日。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP]Droms，R.，“动态主机配置协议”，RFC 21311997年3月。
[DSS] NIST, "Digital Signature Standard", FIPS 186, National Institute of Standards and Technology, U.S. Department of Commerce, May, 1994.
[DSS]NIST，“数字签名标准”，FIPS 186，美国商务部国家标准与技术研究所，1994年5月。
[EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle in Tunneled Authentication Protocols", http://eprint.iacr.org/2002/163, November 2002.
[EAPMITM]Asokan，N.，Nierni，V.，和Nyberg，K.，“隧道认证协议中的中间人”，http://eprint.iacr.org/2002/163，2002年11月。
[HC98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HC98]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[IDEA]Lai，X.，“分组密码的设计和安全性”，信息处理中的ETH系列，v。康斯坦茨：哈东·高尔·韦拉格，1992年。
[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[IPCOMP]Shacham，A.，Monsour，B.，Pereira，R.，和M.Thomas，“IP有效载荷压缩协议（IPCOMP）”，RFC 31732001年9月。
[KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003.
[KPS03]Kaufman，C.，Perlman，R.，和Sommerfeld，B.，“基于UDP协议的DoS保护”，ACM计算机和通信安全会议，2003年10月。
[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[KBC96]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[LDAP] Wahl, M., Howes, T., and S Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[LDAP]Wahl，M.，Howes，T.，和S Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[MSST98]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[Orm96] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[Orm96]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[PFKEY]McDonald，D.，Metz，C.，和B.Phan，“PF_密钥管理API，版本2”，RFC 2367，1998年7月。
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS1]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key exchange Standard", WET-ICE Security Conference, MIT,2001, http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.
[PK01]Perlman，R.和Kaufman，C.，“IPsec密钥交换标准的分析”，湿冰安全会议，麻省理工学院，2001年，http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.
[Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", RFC 2407, November 1998.
[Pip98]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RADIUS]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439]Bush，R.和D.Meyer，“一些互联网架构指南和哲学”，RFC 3439，2002年12月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 2, February 1978.
[RSA]Rivest，R.，Shamir，A.，和Adleman，L.，“获取数字签名和公钥密码系统的方法”，ACM通讯，v。21，n。1978年2月2日。
[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute of Standards and Technology, U.S. Department of Commerce, May 1994.
[SHA]NIST，“安全哈希标准”，FIPS 180-1，美国商务部国家标准与技术研究所，1994年5月。
[SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", in Advances in Cryptography - CRYPTO 2003 Proceedings, LNCS 2729, Springer, 2003. Available at: http://www.informatik.uni-trier.de/~ley/db/conf/ crypto/crypto2003.html.
[SIGMA]Krawczyk，H.，“SIGMA：认证Diffie-Hellman的`符号和MAc'方法及其在IKE协议中的使用”，《密码学进展——加密2003年会议录》，LNCS 2729，Springer，2003年。网址：http://www.informatik.uni-trier.de/~ley/db/conf/crypto/crypto2003.html。
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security.
[SKEME]Krawczyk，H.，“SKEME：一种通用的互联网安全密钥交换机制”，摘自1996年网络和分布式系统安全研讨会IEEE会议录。
[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
[X.501]ITU-T建议X.501：信息技术-开放系统互连-目录：模型，1993年。
[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997.
[X.509]ITU-T建议X.509（1997 E）：信息技术——开放系统互连——目录：认证框架，1997年6月。
Appendix A: Summary of changes from IKEv1
附录A:IKEv1的变更汇总
The goals of this revision to IKE are:
IKE本次修订的目标是：
1) To define the entire IKE protocol in a single document, replacing RFCs 2407, 2408, and 2409 and incorporating subsequent changes to support NAT Traversal, Extensible Authentication, and Remote Address acquisition;
1) 在单个文档中定义整个IKE协议，替换RFCs 2407、2408和2409，并合并后续更改以支持NAT遍历、可扩展身份验证和远程地址获取；
2) To simplify IKE by replacing the eight different initial exchanges with a single four-message exchange (with changes in authentication mechanisms affecting only a single AUTH payload rather than restructuring the entire exchange) see [PK01];
2) 通过将八个不同的初始交换替换为一个四消息交换来简化IKE（身份验证机制的更改只影响一个身份验证有效负载，而不是重新构造整个交换），请参见[PK01]；
3) To remove the Domain of Interpretation (DOI), Situation (SIT), and Labeled Domain Identifier fields, and the Commit and Authentication only bits;
3) 删除解释域（DOI）、情况（SIT）和标记的域标识符字段，以及仅提交和验证位；
4) To decrease IKE's latency in the common case by making the initial exchange be 2 round trips (4 messages), and allowing the ability to piggyback setup of a CHILD_SA on that exchange;
4) 在常见情况下，通过使初始交换为2次往返（4条消息），并允许在该交换上搭载子_SA的设置，来减少IKE的延迟；
5) To replace the cryptographic syntax for protecting the IKE messages themselves with one based closely on ESP to simplify implementation and security analysis;
5) 将用于保护IKE消息本身的密码语法替换为紧密基于ESP的密码语法，以简化实现和安全分析；
6) To reduce the number of possible error states by making the protocol reliable (all messages are acknowledged) and sequenced. This allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2;
6) 通过使协议可靠（所有消息均已确认）并按顺序排列，减少可能的错误状态数量。这允许将CREATE_CHILD_SA交换从3条消息缩短到2条；
7) To increase robustness by allowing the responder to not do significant processing until it receives a message proving that the initiator can receive messages at its claimed IP address, and not commit any state to an exchange until the initiator can be cryptographically authenticated;
7) 通过允许响应方在接收到证明发起方可以在其声明的IP地址接收消息之前不进行重要处理，并且在发起方可以通过加密身份验证之前不向交换机提交任何状态，从而提高健壮性；
8) To fix cryptographic weaknesses such as the problem with symmetries in hashes used for authentication documented by Tero Kivinen;
8) 修复加密弱点，如Tero Kivinen记录的用于身份验证的哈希中的对称性问题；
9) To specify Traffic Selectors in their own payloads type rather than overloading ID payloads, and making more flexible the Traffic Selectors that may be specified;
9) 在自己的有效负载类型中指定流量选择器，而不是重载ID有效负载，并使可能指定的流量选择器更加灵活；
10) To specify required behavior under certain error conditions or when data that is not understood is received, to make it easier to make future revisions that do not break backward compatibility;
10） 指定在某些错误条件下或接收到不可理解的数据时所需的行为，以便于将来进行不破坏向后兼容性的修订；
11) To simplify and clarify how shared state is maintained in the presence of network failures and Denial of Service attacks; and
11） 简化并澄清在出现网络故障和拒绝服务攻击时如何保持共享状态；和
12) To maintain existing syntax and magic numbers to the extent possible to make it likely that implementations of IKEv1 can be enhanced to support IKEv2 with minimum effort.
12） 尽可能地维护现有的语法和幻数，使IKEv1的实现能够得到增强，以尽可能少的努力支持IKEv2。
Appendix B: Diffie-Hellman Groups
附录B：Diffie-Hellman集团
There are two Diffie-Hellman groups defined here for use in IKE. These groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96].
这里定义了两个Diffie-Hellman组用于IKE。这些小组是由亚利桑那大学的Richard Schroeppel发明的。[Orm96]中描述了这些素数的性质。
The strength supplied by group one may not be sufficient for the mandatory-to-implement encryption algorithm and is here for historic reasons.
第一组提供的强度可能不足以强制实施加密算法，这是出于历史原因。
Additional Diffie-Hellman groups have been defined in [ADDGROUP].
[ADDGROUP]中定义了其他Diffie-Hellman组。
This group is assigned id 1 (one).
此组被分配id 1（一个）。
The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is:
素数是：2^768-2^704-1+2^64*{[2^638 pi]+149686}其十六进制值是：
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
FFFFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E6 F44C42E9 A63A3620 FFFFFFFFFF FFFFFF
The generator is 2.
发电机是2。
This group is assigned id 2 (two).
此组被分配id 2（两个）。
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its hexadecimal value is:
素数是2^1024-2^960-1+2^64*{[2^894pi]+129093}。其十六进制值为：
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF
FFFFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E6 F44C42E9 A637ED6B 0BFF5CB6 F406B7 EE386B5A899FA5 AE9F2411 7C4B16 49286651 FFFFFFFFFFFFFFFFFF
The generator is 2.
发电机是2。
Editor's Address
编辑地址
Charlie Kaufman Microsoft Corporation 1 Microsoft Way Redmond, WA 98052
Charlie Kaufman微软公司华盛顿州微软路雷德蒙德1号，邮编：98052
Phone: 1-425-707-3335 EMail: charliek@microsoft.com
电话：1-425-707-3335电子邮件：charliek@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。