Internet Engineering Task Force (IETF) S. Frankel
Request for Comments: 6071 NIST
Obsoletes: 2411 S. Krishnan
Category: Informational Ericsson
ISSN: 2070-1721 February 2011
Internet Engineering Task Force (IETF) S. Frankel
Request for Comments: 6071 NIST
Obsoletes: 2411 S. Krishnan
Category: Informational Ericsson
ISSN: 2070-1721 February 2011
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
IP安全（IPsec）和Internet密钥交换（IKE）文档路线图
Abstract
摘要
Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.
在过去的几年中，定义和使用IPsec和Internet密钥交换（IKE）的RFC数量激增。这些RFC来源于众多IETF工作组，这一事实使情况变得复杂：最初的IPsec工作组、其各种衍生产品以及使用IPsec和/或IKE保护其协议流量的其他工作组。
This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap."
本文档是IPsec和IKE相关RFC的快照。它包括对每个RFC的简要描述，以及解释IPsec衍生和扩展的动机和背景的背景信息。它淘汰了RFC 2411，即之前的“IP安全文档路线图”
The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms.
已过时的IPsec路线图（RFC 2411）简要描述了各类基本IPsec文档之间的相互关系。RFC 2411的主要重点是指定指定附加加密和身份验证算法的文档的推荐内容。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6071.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6071.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. IPsec/IKE Background Information ................................5
2.1. Interrelationship of IPsec/IKE Documents ...................5
2.2. Versions of IPsec ..........................................6
2.2.1. Differences between "Old" IPsec (IPsec-v2) and
"New" IPsec (IPsec-v3) ..............................6
2.3. Versions of IKE ............................................7
2.3.1. Differences between IKEv1 and IKEv2 .................8
2.4. IPsec and IKE IANA Registries ..............................9
3. IPsec Documents .................................................9
3.1. Base Documents .............................................9
3.1.1. "Old" IPsec (IPsec-v2) ..............................9
3.1.2. "New" IPsec (IPsec-v3) .............................11
3.2. Additions to IPsec ........................................11
3.3. General Considerations ....................................14
4. IKE Documents ..................................................15
4.1. Base Documents ............................................15
4.1.1. IKEv1 ..............................................15
4.1.2. IKEv2 ..............................................16
1. Introduction ....................................................4
2. IPsec/IKE Background Information ................................5
2.1. Interrelationship of IPsec/IKE Documents ...................5
2.2. Versions of IPsec ..........................................6
2.2.1. Differences between "Old" IPsec (IPsec-v2) and
"New" IPsec (IPsec-v3) ..............................6
2.3. Versions of IKE ............................................7
2.3.1. Differences between IKEv1 and IKEv2 .................8
2.4. IPsec and IKE IANA Registries ..............................9
3. IPsec Documents .................................................9
3.1. Base Documents .............................................9
3.1.1. "Old" IPsec (IPsec-v2) ..............................9
3.1.2. "New" IPsec (IPsec-v3) .............................11
3.2. Additions to IPsec ........................................11
3.3. General Considerations ....................................14
4. IKE Documents ..................................................15
4.1. Base Documents ............................................15
4.1.1. IKEv1 ..............................................15
4.1.2. IKEv2 ..............................................16
4.2. Additions and Extensions ..................................17
4.2.1. Peer Authentication Methods ........................17
4.2.2. Certificate Contents and Management (PKI4IPsec) ....18
4.2.3. Dead Peer Detection ................................19
4.2.4. Remote Access ......................................19
5. Cryptographic Algorithms and Suites ............................21
5.1. Algorithm Requirements ....................................22
5.2. Encryption Algorithms .....................................23
5.3. Integrity-Protection (Authentication) Algorithms ..........27
5.4. Combined Mode Algorithms ..................................30
5.5. Pseudo-Random Functions (PRFs) ............................33
5.6. Cryptographic Suites ......................................34
5.7. Diffie-Hellman Algorithms .................................35
6. IPsec/IKE for Multicast ........................................36
7. Outgrowths of IPsec/IKE ........................................38
7.1. IPsec Policy ..............................................38
7.2. IPsec MIBs ................................................39
7.3. IPComp (Compression) ......................................39
7.4. Better-Than-Nothing Security (BTNS) .......................39
7.5. Kerberized Internet Negotiation of Keys (KINK) ............40
7.6. IPsec Secure Remote Access (IPSRA) ........................41
7.7. IPsec Keying Information Resource Record (IPSECKEY) .......42
8. Other Protocols That Use IPsec/IKE .............................42
8.1. Mobile IP (MIPv4 and MIPv6) ...............................42
8.2. Open Shortest Path First (OSPF) ...........................44
8.3. Host Identity Protocol (HIP) ..............................45
8.4. Stream Control Transmission Protocol (SCTP) ...............46
8.5. Robust Header Compression (ROHC) ..........................46
8.6. Border Gateway Protocol (BGP) .............................47
8.7. IPsec Benchmarking ........................................47
8.8. Network Address Translators (NAT) .........................48
8.9. Session Initiation Protocol (SIP) .........................48
8.10. Explicit Packet Sensitivity Labels .......................49
9. Other Protocols That Adapt IKE for Non-IPsec Functionality .....49
9.1. Extensible Authentication Protocol (EAP) ..................49
9.2. Fibre Channel .............................................49
9.3. Wireless Security .........................................50
10. Acknowledgements ..............................................50
11. Security Considerations .......................................50
12. References ....................................................50
12.1. Informative References ...................................50
Appendix A. Summary of Algorithm Requirement Levels ..............61
4.2. Additions and Extensions ..................................17
4.2.1. Peer Authentication Methods ........................17
4.2.2. Certificate Contents and Management (PKI4IPsec) ....18
4.2.3. Dead Peer Detection ................................19
4.2.4. Remote Access ......................................19
5. Cryptographic Algorithms and Suites ............................21
5.1. Algorithm Requirements ....................................22
5.2. Encryption Algorithms .....................................23
5.3. Integrity-Protection (Authentication) Algorithms ..........27
5.4. Combined Mode Algorithms ..................................30
5.5. Pseudo-Random Functions (PRFs) ............................33
5.6. Cryptographic Suites ......................................34
5.7. Diffie-Hellman Algorithms .................................35
6. IPsec/IKE for Multicast ........................................36
7. Outgrowths of IPsec/IKE ........................................38
7.1. IPsec Policy ..............................................38
7.2. IPsec MIBs ................................................39
7.3. IPComp (Compression) ......................................39
7.4. Better-Than-Nothing Security (BTNS) .......................39
7.5. Kerberized Internet Negotiation of Keys (KINK) ............40
7.6. IPsec Secure Remote Access (IPSRA) ........................41
7.7. IPsec Keying Information Resource Record (IPSECKEY) .......42
8. Other Protocols That Use IPsec/IKE .............................42
8.1. Mobile IP (MIPv4 and MIPv6) ...............................42
8.2. Open Shortest Path First (OSPF) ...........................44
8.3. Host Identity Protocol (HIP) ..............................45
8.4. Stream Control Transmission Protocol (SCTP) ...............46
8.5. Robust Header Compression (ROHC) ..........................46
8.6. Border Gateway Protocol (BGP) .............................47
8.7. IPsec Benchmarking ........................................47
8.8. Network Address Translators (NAT) .........................48
8.9. Session Initiation Protocol (SIP) .........................48
8.10. Explicit Packet Sensitivity Labels .......................49
9. Other Protocols That Adapt IKE for Non-IPsec Functionality .....49
9.1. Extensible Authentication Protocol (EAP) ..................49
9.2. Fibre Channel .............................................49
9.3. Wireless Security .........................................50
10. Acknowledgements ..............................................50
11. Security Considerations .......................................50
12. References ....................................................50
12.1. Informative References ...................................50
Appendix A. Summary of Algorithm Requirement Levels ..............61
IPsec (Internet Protocol Security) is a suite of protocols that provides security to Internet communications at the IP layer. The most common current use of IPsec is to provide a Virtual Private Network (VPN), either between two locations (gateway-to-gateway) or between a remote user and an enterprise network (host-to-gateway); it can also provide end-to-end, or host-to-host, security. IPsec is also used by other Internet protocols (e.g., Mobile IP version 6 (MIPv6)) to protect some or all of their traffic. IKE (Internet Key Exchange) is the key negotiation and management protocol that is most commonly used to provide dynamically negotiated and updated keying material for IPsec. IPsec and IKE can be used in conjunction with both IPv4 and IPv6.
IPsec（Internet协议安全性）是一套在IP层为Internet通信提供安全性的协议。IPsec最常见的当前用途是在两个位置（网关到网关）之间或远程用户和企业网络（主机到网关）之间提供虚拟专用网络（VPN）；它还可以提供端到端或主机到主机的安全性。IPsec还被其他互联网协议（例如，移动IP版本6（MIPv6））用于保护其部分或全部流量。IKE（Internet密钥交换）是密钥协商和管理协议，最常用于为IPsec提供动态协商和更新的密钥材料。IPsec和IKE可以与IPv4和IPv6结合使用。
In addition to the base documents for IPsec and IKE, there are numerous RFCs that reference, extend, and in some cases alter the core specifications. This document obsoletes [RFC2411]. It attempts to list and briefly describe those RFCs, providing context and rationale where indicated. The title of each RFC is followed by a letter that indicates its category in the RFC series [RFC2026], as follows:
除了IPsec和IKE的基本文档外，还有许多RFC引用、扩展并在某些情况下更改核心规范。本文件废除了[RFC2411]。它试图列出并简要描述这些RFC，并在说明的地方提供上下文和基本原理。每个RFC的标题后面都有一个字母，表示其在RFC系列[RFC2026]中的类别，如下所示：
o S: Standards Track (Proposed Standard, Draft Standard, or Standard)
o S：标准跟踪（建议标准、标准草案或标准）
o E: Experimental
o E:实验性的
o B: Best Current Practice
o B:目前的最佳做法
o I: Informational
o I:信息性
For each RFC, the publication date is also given.
对于每个RFC，还提供了发布日期。
This document also categorizes the requirements level of each cryptographic algorithm for use with IKEv1, IKEv2, IPsec-v2, and IPsec-v3. These requirements are summarized in Appendix A. These levels are current as of February 2011; subsequent RFCs may result in altered requirement levels.
本文档还对用于IKEv1、IKEv2、IPsec-v2和IPsec-v3的每个加密算法的需求级别进行了分类。这些要求汇总在附录A中。这些水平截至2011年2月为现行水平；随后的RFC可能会导致需求水平的改变。
This document does not define requirement levels; it simply restates those found in the IKE and IPsec RFCs. If there is a conflict between this document and any other RFC, then the other RFC takes precedence.
本文件未定义需求级别；它只是重申了IKE和IPsec RFC中的内容。如果本文件与任何其他RFC之间存在冲突，则以其他RFC为准。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The main documents describing the set of IPsec protocols are divided into seven groups. This is illustrated in Figure 1. There is a main Architecture document that broadly covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology.
描述IPsec协议集的主要文档分为七组。这如图1所示。有一个主要的体系结构文档，广泛地涵盖了定义IPsec技术的一般概念、安全需求、定义和机制。
There are an Encapsulating Security Payload (ESP) Protocol document and an Authentication Header (AH) Protocol document that cover the packet format and general issues regarding the respective protocols. The "Encryption Algorithm" document set, shown on the left, is the set of documents describing how various encryption algorithms are used for ESP. The "Combined Algorithm" document set, shown in the middle, is the set of documents describing how various combined mode algorithms are used to provide both encryption and integrity protection for ESP. The "Integ-Protection Algorithm" document set, shown on the right, is the set of documents describing how various integrity-protection algorithms are used for both ESP and AH.
有一个封装安全有效负载（ESP）协议文档和一个身份验证头（AH）协议文档，它们涵盖了数据包格式和有关各个协议的一般问题。左边显示的“加密算法”文档集是一组描述如何使用各种加密算法的ESP文件，中间显示的是“组合算法”文档集，是描述如何使用各种组合模式算法为ESP提供加密和完整性保护的文档集。右侧显示的“Integ protection Algorithm”文档集是描述如何为ESP和AH使用各种完整性保护算法的文档集。
The "IKE" documents, shown at the bottom, are the documents describing the IETF Standards-Track key management schemes.
底部显示的“IKE”文档是描述IETF标准跟踪密钥管理方案的文档。
+--------------+
| Architecture |
+--------------+
v v
+<-<-<-<-<-<-<-<-+ +->->->->->->->->+
v v
+----------+ +----------+
| ESP | | AH |
| Protocol | | Protocol |
+----------+ +----------+
v v v v
v +->->->->->->->->+->->->->->->->->+ v v
v v v v v v
v v v v v v
v +------------+ +-----------+ +----------------+ v
v | +------------+ | +------------+ | +----------------+ v
v | | Encryption | | | Combined | | |Integ-Protection| v
v +-| Algorithm | +-| Algorithm | +-| Algorithm | v
v +------------+ +------------+ +----------------+ v
v v v v v
v v v v v
+>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+
^
^
+------------+
| IKE |
| Protocol |
+------------+
+--------------+
| Architecture |
+--------------+
v v
+<-<-<-<-<-<-<-<-+ +->->->->->->->->+
v v
+----------+ +----------+
| ESP | | AH |
| Protocol | | Protocol |
+----------+ +----------+
v v v v
v +->->->->->->->->+->->->->->->->->+ v v
v v v v v v
v v v v v v
v +------------+ +-----------+ +----------------+ v
v | +------------+ | +------------+ | +----------------+ v
v | | Encryption | | | Combined | | |Integ-Protection| v
v +-| Algorithm | +-| Algorithm | +-| Algorithm | v
v +------------+ +------------+ +----------------+ v
v v v v v
v v v v v
+>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+
^
^
+------------+
| IKE |
| Protocol |
+------------+
Figure 1. IPsec/IKE Document Interrelationships
图1。IPsec/IKE文档的相互关系
Two versions of IPsec can currently be found in implementations. The "new" IPsec (referred to as IPsec-v3 in this document; see Section 3.1.1 for the RFC descriptions) obsoleted the "old" IPsec (referred to as IPsec-v2 in this document; see Section 3.1.2 for the RFC descriptions); however, IPsec-v2 is still commonly found in operational use. In this document, when the unqualified term IPsec is used, it pertains to both versions of IPsec. An earlier version of IPsec (defined in RFCs 1825-1829), obsoleted by IPsec-v2, is not covered in this document.
目前在实现中可以找到两个版本的IPsec。“新”IPsec（本文件中称为IPsec-v3；RFC说明见第3.1.1节）淘汰了“旧”IPsec（本文件中称为IPsec-v2；RFC说明见第3.1.2节）；然而，IPsec-v2在操作使用中仍然很常见。在本文档中，当使用非限定术语IPsec时，它适用于两个版本的IPsec。IPsec-v2淘汰的早期版本IPsec（在RFCs 1825-1829中定义）不包含在本文档中。
2.2.1. Differences between "Old" IPsec (IPsec-v2) and "New" IPsec (IPsec-v3)
2.2.1. “旧”IPsec（IPsec-v2）和“新”IPsec（IPsec-v3）之间的区别
IPsec-v3 incorporates "lessons learned" from implementation and operational experience with IPsec-v2 and its predecessor, IPsec-v1.
IPsec-v3结合了IPsec-v2及其前身IPsec-v1的实施和运营经验中的“经验教训”。
Knowledge was gained about the barriers to IPsec deployment, the scenarios in which IPsec is most effective, and the requirements that needed to be added to IPsec to facilitate its use with other protocols. In addition, the documentation for IPsec-v3 clarifies and expands details that were underspecified or ambiguous in IPsec-v2.
了解了IPsec部署的障碍、IPsec最有效的场景以及需要添加到IPsec以便于与其他协议一起使用的要求。此外，IPsec-v3的文档澄清并扩展了IPsec-v2中未指定或不明确的细节。
Changes to the architecture document [RFC4301] include:
架构（architecture）文件[RFC4301]的变更包括：
o More detailed descriptions of IPsec processing, both unicast and multicast, and the interactions among the various IPsec databases
o IPsec处理（单播和多播）的更详细描述，以及各种IPsec数据库之间的交互
o In IPsec-v2, an SA (Security Association) is uniquely identified by a combination of the SPI (Security Parameters Index), protocol (ESP or AH) and the destination address. In IPsec-v3, a unicast SA is uniquely identified by the SPI and, optionally, by the protocol; a multicast SA is identified by a combination of the SPI and the destination address and, optionally, the source address.
o 在IPsec-v2中，SA（安全关联）由SPI（安全参数索引）、协议（ESP或AH）和目标地址的组合唯一标识。在IPsec-v3中，单播SA由SPI唯一标识，并且可选地由协议唯一标识；多播SA由SPI和目标地址以及可选的源地址的组合来标识。
o More flexible SPD (Security Policy Database) selectors, including ranges of values and ICMP message types as selectors
o 更灵活的SPD（安全策略数据库）选择器，包括作为选择器的值范围和ICMP消息类型
o Decorrelated (order-independent) SAD (Security Association Database) replaced the former ordered SAD
o 解相关（顺序独立）SAD（安全关联数据库）取代了以前的顺序SAD
o Extended sequence numbers (ESNs) were added
o 添加了扩展序列号（ESN）
o Mandatory algorithms defined in standalone document
o 独立文档中定义的强制算法
o AH [RFC4302] is mandatory to implement (MUST) in IPsec-v2, optional (MAY) in IPsec-v3
o AH[RFC4302]必须在IPsec-v2中实现（必须），在IPsec-v3中可选（可能）
Changes to ESP [RFC4303] include:
ESP[RFC4303]的变更包括：
o Combined mode algorithms were added, necessitating changes to packet format and processing
o 增加了组合模式算法，需要更改数据包格式和处理
o NULL authentication, mandatory (MUST) in ESP-v2, is optional (MAY) in ESP-v3
o ESP-v2中必须（必须）的空身份验证在ESP-v3中是可选的（可能）
Two versions of IKE can currently be found in implementations. The "new" IKE (generally referred to as IKEv2) obsoleted the "old" IKE (generally referred to as IKEv1); however, IKEv1 is still commonly found in operational use. In this document, when the unqualified term IKE is used, it pertains to both versions of IKE.
目前在实现中可以找到两个版本的IKE。“新”IKE（通常称为IKEv2）淘汰了“旧”IKE（通常称为IKEv1）；然而，IKEv1在实际使用中仍然很常见。在本文档中，当使用非限定术语IKE时，它适用于IKE的两个版本。
As with IPsec-v3, IKEv2 incorporates "lessons learned" from implementation and operational experience with IKEv1. Knowledge was gained about the barriers to IKE deployment, the scenarios in which IKE is most effective, and the requirements that needed to be added to IKE to facilitate its use with other protocols as well as in general-purpose use. The documentation for IKEv2 replaces multiple, at times contradictory, documents with a single document; it also clarifies and expands details that were underspecified or ambiguous in IKEv1.
与IPsec-v3一样，IKEv2结合了从IKEv1的实施和运营经验中获得的“经验教训”。了解了IKE部署的障碍、IKE最有效的场景以及需要添加到IKE以促进其与其他协议以及通用用途的使用的需求。IKEv2的文档将多个文档（有时相互矛盾）替换为一个文档；它还澄清和扩展了IKEv1中未明确或模棱两可的细节。
Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs. Since IKE always negotiates pairs of SAs, the term "SA" is generally used to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in reality a pair of one-way SAs). The first SA, the IKE SA, is used to protect IKE traffic. The second SA provides IPsec protection to data traffic between the peers and/or other devices for which the peers are authorized to negotiate. It is called the IPsec SA in IKEv1 and, in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child SA, and an IPsec SA. This document uses the term "IPsec SA". To further complicate the terminology, since IKEv1 consists of two sequential negotiations, called phases, the IKE SA is also referred to as a Phase 1 SA and the IPsec SA is referred to as a Phase 2 SA.
一旦IKE协商成功完成，对等方就建立了两对单向（入站和出站）sa。由于IKE总是协商成对的SA，因此术语“SA”通常用于指一对SA（例如，“IKE SA”或“IPsec SA”实际上是一对单向SA）。第一个SA，IKE SA，用于保护IKE流量。第二SA为对等方和/或对等方被授权协商的其他设备之间的数据通信提供IPsec保护。它在IKEv1中称为IPsec SA，在IKEv2 RFCs中，它被不同地称为CHILD_SA、CHILD SA和IPsec SA。本文档使用术语“IPsec SA”。为了进一步使术语复杂化，由于IKEv1由两个称为阶段的顺序协商组成，因此IKE SA也称为阶段1 SA，IPsec SA称为阶段2 SA。
Changes to IKE include:
IKE的更改包括：
o Replaced multiple alternate exchange types with a single, shorter exchange
o 将多个备用exchange类型替换为单个较短的exchange
o Streamlined negotiation format to avoid combinatorial bloat for multiple proposals
o 简化了协商格式，避免了多个提案的组合膨胀
o Protect responder from committing significant resources to the exchange until the initiator's existence and identity are confirmed
o 在确认启动器的存在和身份之前，保护响应者不向exchange提交重要资源
o Reliable exchanges: every request expects a response
o 可靠的交换：每个请求都需要响应
o Protection of IKE messages based on ESP, rather than a method unique to IKE
o 基于ESP的IKE消息保护，而不是IKE特有的方法
o Add traffic selectors: distinct from peer IDs and more flexible
o 添加流量选择器：与对等ID不同，更灵活
o Support of EAP-based authentication methods and asymmetric authentication (i.e., initiator and responder can use different authentication methods)
o 支持基于EAP的身份验证方法和非对称身份验证（即，发起方和响应方可以使用不同的身份验证方法）
Numerous IANA registries contain values that are used in IPsec, IKE, and related protocols. They include:
许多IANA注册表包含IPsec、IKE和相关协议中使用的值。这些措施包括：
o IKE Attributes (http://www.iana.org/assignments/ipsec-registry): values used during IKEv1 Phase 1 exchanges, defined in [RFC2409].
o IKE属性(http://www.iana.org/assignments/ipsec-registry)：在[RFC2409]中定义的IKEv1第1阶段交换期间使用的值。
o "Magic Numbers" for Internet Security Association and Key Management Protocol (ISAKMP) (http://www.iana.org/assignments/isakmp-registry): values used during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408], and numerous other cryptographic algorithm RFCs.
o Internet安全关联和密钥管理协议（ISAKMP）的“幻数”(http://www.iana.org/assignments/isakmp-registry)：在[RFC2407]、[RFC2408]和许多其他加密算法RFC中定义的IKEv1第2阶段交换期间使用的值。
o IKEv2 Parameters (http://www.iana.org/assignments/ikev2-parameters): values used in IKEv2 exchanges, defined in [RFC5996] and numerous other cryptographic algorithm RFCs.
o IKEv2参数(http://www.iana.org/assignments/ikev2-parameters)：在[RFC5996]和许多其他加密算法RFC中定义的IKEv2交换中使用的值。
o Cryptographic Suites for IKEv1, IKEv2, and IPsec (http://www.iana.org/assignments/crypto-suites): names of cryptographic suites in [RFC4308] and [RFC4869].
o IKEv1、IKEv2和IPsec的加密套件(http://www.iana.org/assignments/crypto-suites)：在[RFC4308]和[RFC4869]中加密套件的名称。
IPsec protections are provided by two special headers: the Encapsulating Security Payload (ESP) Header and the Authentication Header (AH). In IPv4, these headers take the form of protocol headers; in IPv6, they are classified as extension headers. There are three base IPsec documents: one that describes the IP security architecture, and one for each of the IPsec headers.
IPsec保护由两个特殊的头提供：封装安全有效负载（ESP）头和身份验证头（AH）。在IPv4中，这些报头采用协议报头的形式；在IPv6中，它们被分类为扩展头。有三个基本IPsec文档：一个用于描述IP安全体系结构，另一个用于每个IPsec头。
3.1.1.1. RFC 2401, Security Architecture for the Internet Protocol (S, November 1998)
3.1.1.1. RFC 2401，互联网协议的安全架构（S，1998年11月）
[RFC2401] specifies the mechanisms, procedures, and components required to provide security services at the IP layer. It also describes their interrelationship and the general processing required to inject IPsec protections into the network architecture.
[RFC2401]指定在IP层提供安全服务所需的机制、过程和组件。它还描述了它们之间的相互关系以及将IPsec保护注入网络体系结构所需的一般处理。
The components include:
这些组成部分包括：
- SA (Security Association): a one-way (inbound or outbound) agreement between two communicating peers that specifies the IPsec protections to be provided to their communications. This includes the specific security protections, cryptographic algorithms, and secret keys to be applied, as well as the specific types of traffic to be protected.
- SA（安全关联）：两个通信对等方之间的单向（入站或出站）协议，指定要为其通信提供的IPsec保护。这包括要应用的特定安全保护、加密算法和密钥，以及要保护的特定类型的通信量。
- SPI (Security Parameters Index): a value that, together with the destination address and security protocol (AH or ESP), uniquely identifies a single SA.
- SPI（安全参数索引）：与目标地址和安全协议（AH或ESP）一起唯一标识单个SA的值。
- SAD (Security Association Database): each peer's SA repository. The RFC describes how this database functions (SA lookup, etc.) and the types of information it must contain to facilitate SA processing; it does not dictate the format or layout of the database. SAs can be established in either transport mode or tunnel mode (see below).
- SAD（安全关联数据库）：每个对等方的SA存储库。RFC描述了该数据库的功能（SA查找等）及其必须包含的信息类型，以便于SA处理；它不指定数据库的格式或布局。SAs可以在传输模式或隧道模式下建立（见下文）。
- SPD (Security Policy Database): an ordered database that expresses the security protections to be afforded to different types and classes of traffic. The three general classes of traffic are traffic to be discarded, traffic that is allowed without IPsec protection, and traffic that requires IPsec protection.
- SPD（安全策略数据库）：一个有序的数据库，表示要为不同类型和类别的流量提供的安全保护。三类一般的通信量是要丢弃的通信量、在没有IPsec保护的情况下允许的通信量和需要IPsec保护的通信量。
RFC 2401 describes general inbound and outbound IPsec processing; it also includes details on several special cases: packet fragments, ICMP messages, and multicast traffic.
RFC 2401描述了一般的入站和出站IPsec处理；它还包括一些特殊情况的详细信息：数据包片段、ICMP消息和多播流量。
[RFC2402] defines the Authentication Header (AH), which provides integrity protection; it also provides data-origin authentication, access control, and, optionally, replay protection. A transport mode AH SA, used to protect peer-to-peer communications, protects upper-layer data, as well as those portions of the IP header that do not vary unpredictably during packet delivery. A tunnel mode AH SA can be used to protect gateway-to-gateway or host-to-gateway traffic; it can optionally be used for host-to-host traffic. This class of AH SA protects the inner (original) header and upper-layer data, as well as those portions of the outer (tunnel) header that do not vary unpredictably during packet delivery. Because portions of the IP header are not included in the AH calculations, AH processing is more complex than ESP processing. AH also does not work in the presence of Network Address Translation (NAT). Unlike IPsec-v3, IPsec-v2 classifies AH as mandatory to implement.
[RFC2402]定义提供完整性保护的认证头（AH）；它还提供数据源身份验证、访问控制和重播保护（可选）。用于保护对等通信的传输模式AH-SA保护上层数据，以及在分组传送期间不会不可预测地变化的IP报头的那些部分。隧道模式AH SA可用于保护网关到网关或主机到网关的流量；它可以选择性地用于主机到主机的通信。这类AH-SA保护内部（原始）报头和上层数据，以及在分组传送期间不会发生不可预测变化的外部（隧道）报头的那些部分。因为IP报头的部分不包括在AH计算中，所以AH处理比ESP处理更复杂。AH在存在网络地址转换（NAT）的情况下也不起作用。与IPsec-v3不同，IPsec-v2将AH分类为强制实现。
3.1.1.3. RFC 2406, IP Encapsulating Security Payload (ESP) (S, November 1998)
3.1.1.3. RFC 2406，IP封装安全有效载荷（ESP）（S，1998年11月）
[RFC2406] defines the IP Encapsulating Security Payload (ESP), which provides confidentiality (encryption) and/or integrity protection; it also provides data-origin authentication, access control, and, optionally, replay and/or traffic analysis protection. A transport mode ESP SA protects the upper-layer data, but not the IP header. A tunnel mode ESP SA protects the upper-layer data and the inner header, but not the outer header.
[RFC2406]定义IP封装安全有效负载（ESP），提供机密性（加密）和/或完整性保护；它还提供数据源身份验证、访问控制，以及（可选）重播和/或流量分析保护。传输模式ESP SA保护上层数据，但不保护IP报头。隧道模式ESP SA保护上层数据和内部报头，但不保护外部报头。
3.1.2.1. RFC 4301, Security Architecture for the Internet Protocol (S, December 2005)
3.1.2.1. RFC 4301，互联网协议的安全架构（S，2005年12月）
[RFC4301] obsoletes [RFC2401], and it includes a more complete and detailed processing model. The most notable changes are detailed above in Section 2.2.1. IPsec-v3 processing incorporates an additional database:
[RFC4301]淘汰了[RFC2401]，它包括一个更完整、更详细的处理模型。最显著的变化详见上文第2.2.1节。IPsec-v3处理包含一个附加数据库：
- PAD (Peer Authorization Database): contains information necessary to conduct peer authentication, providing a link between IPsec and the key management protocol (e.g., IKE)
- PAD（对等授权数据库）：包含进行对等身份验证所需的信息，提供IPsec和密钥管理协议（例如IKE）之间的链接
[RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies AH as optional.
[RFC4302]淘汰[RFC2402]。与IPsec-v2不同，IPsec-v3将AH分类为可选。
3.1.2.3. RFC 4303, IP Encapsulating Security Payload (ESP) (S, December 2005)
3.1.2.3. RFC 4303，IP封装安全有效载荷（ESP）（S，2005年12月）
[RFC4303] obsoletes [RFC2406]. The most notable changes are detailed above in Section 2.2.1.
[RFC4303]淘汰[RFC2406]。最显著的变化详见上文第2.2.1节。
Once the IKEv1 and IPsec-v2 RFCs were finalized, several additions were defined in separate documents: negotiation of NAT traversal, extended sequence numbers, UDP encapsulation of ESP packets, opportunistic encryption, and IPsec-related ICMP messages. Additional uses of IPsec transport mode were also described: protection of manually configured IPv6-in-IPv4 tunnels and protection of IP-in-IP tunnels. These documents describe atypical uses of IPsec transport mode, but do not define any new IPsec features.
IKEv1和IPsec-v2 RFC最终确定后，在单独的文档中定义了几个新增内容：NAT遍历协商、扩展序列号、ESP数据包的UDP封装、机会加密和IPsec相关ICMP消息。还描述了IPsec传输模式的其他用途：保护手动配置的IPv6-in-IPv4隧道和保护IP隧道中的IP。这些文档描述了IPsec传输模式的非典型用法，但没有定义任何新的IPsec功能。
Once the original IPsec Working Group concluded, additional IPsec-related issues were handled by the IPsecME (IPsec Maintenance and Extensions) Working Group. One such problem is the capability of middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from encrypted ones in a fast and accurate manner. Two solutions are described: a new protocol that requires changes to IKEv2 and IPsec-v3 and a heuristic method that imposes no new requirements. Another issue that was addressed is the problem of using IKE and IPsec in a high-availability environment.
最初的IPsec工作组结束后，IPsecME（IPsec维护和扩展）工作组处理了其他与IPsec相关的问题。其中一个问题是，中间盒能够快速准确地区分未加密的ESP数据包（ESP-NULL）和加密的ESP数据包。描述了两种解决方案：一种需要更改IKEv2和IPsec-v3的新协议，以及一种不提出新要求的启发式方法。解决的另一个问题是在高可用性环境中使用IKE和IPsec的问题。
3.2.1. RFC 3947, Negotiation of NAT-Traversal in the IKE (S, January 2005)
3.2.1. RFC 3947，IKE中NAT穿越的协商（S，2005年1月）
[RFC3947] defines an optional extension to IKEv1. It enables IKEv1 to detect whether there are any NATs between the negotiating peers and whether both peers support NAT traversal. It also describes how IKEv1 can be used to negotiate the use of UDP encapsulation of ESP packets for the IPsec SA. For IKEv2, this capability is described in [RFC5996].
[RFC3947]定义了IKEv1的可选扩展。它使IKEv1能够检测协商对等方之间是否存在任何NAT，以及两个对等方是否都支持NAT遍历。它还描述了如何使用IKEv1协商使用IPsec SA的ESP数据包的UDP封装。对于IKEv2，此功能在[RFC5996]中有描述。
3.2.2. RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, January 2005)
3.2.2. RFC 3948，IPsec ESP数据包的UDP封装（S，2005年1月）
[RFC3948] is an optional extension for IPsec-v2 and IPsec-v3. It defines how to encapsulate ESP packets in UDP packets to enable the traversal of NATs that discard packets with protocols other than UDP or TCP. This makes it possible for ESP packets to pass through the NAT device without requiring any change to the NAT device itself. The use of this solution is negotiated by IKE, as described in [RFC3947] for IKEv1 and [RFC5996] for IKEv2.
[RFC3948]是IPsec-v2和IPsec-v3的可选扩展。它定义了如何将ESP数据包封装在UDP数据包中，以便能够遍历使用UDP或TCP以外的协议丢弃数据包的NAT。这使得ESP数据包能够通过NAT设备，而无需对NAT设备本身进行任何更改。该解决方案的使用由IKE协商，如IKEv1的[RFC3947]和IKEv2的[RFC5996]所述。
3.2.3. RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) (S, December 2005)
3.2.3. RFC 4304，互联网安全关联和密钥管理协议（ISAKMP）IPsec解释域（DOI）的扩展序列号（ESN）附录（S，2005年12月）
The use of ESNs allows IPsec to use 64-bit sequence numbers for replay protection, but to send only 32 bits of the sequence number in the packet, enabling shorter packets and avoiding a redesign of the packet format. The larger sequence numbers allow an existing IPsec SA to be used for larger volumes of data. [RFC4304] describes an optional extension to IKEv1 that enables IKEv1 to negotiate the use of ESNs for IPsec SAs. For IKEv2, this capability is described in [RFC5996].
ESNs的使用允许IPsec使用64位序列号进行重播保护，但只发送数据包中序列号的32位，从而实现更短的数据包，并避免重新设计数据包格式。较大的序列号允许将现有IPsec SA用于较大的数据量。[RFC4304]描述了对IKEv1的可选扩展，该扩展使IKEv1能够协商将ESN用于IPsec SAs。对于IKEv2，此功能在[RFC5996]中有描述。
3.2.4. RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE) (I, December 2005)
3.2.4. RFC 4322，使用互联网密钥交换（IKE）的机会加密（I，2005年12月）
Opportunistic encryption allows a pair of end systems to use encryption without any specific pre-arrangements. [RFC4322] specifies a mechanism that uses DNS to distribute the public keys of each system involved and uses DNS Security (DNSSEC) to secure the mechanism against active attackers. It specifies the changes that are needed in existing IPsec and IKE implementations. The majority of the changes are needed in the IKE implementation and these changes relate to the handling of key acquisition requests, the lookup of public keys and TXT records, and the interactions with firewalls and other security facilities that may be co-resident on the same gateway.
机会主义加密允许一对终端系统使用加密，而无需任何特定的预先安排。[RFC4322]指定一种机制，该机制使用DNS分发涉及的每个系统的公钥，并使用DNS安全性（DNSSEC）保护该机制免受主动攻击者的攻击。它指定了现有IPsec和IKE实现中需要的更改。IKE实现中需要进行大多数更改，这些更改涉及密钥获取请求的处理、公钥和TXT记录的查找以及与防火墙和其他安全设施的交互，这些安全设施可能共同驻留在同一网关上。
3.2.5. RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May 2007)
3.2.5. RFC 4891，使用IPsec保护IPv4隧道中的IPv6（I，2007年5月）
[RFC4891] describes how to use IKE and transport-mode IPsec to provide security protection to manually configured IPv6-in-IPv4 tunnels. This document uses standard IKE and IPsec, without any new extensions. It does not apply to tunnels that are initiated in an automated manner (e.g., 6to4 tunnels [RFC3056]).
[RFC4891]介绍如何使用IKE和传输模式IPsec为手动配置的IPv6-in-IPv4隧道提供安全保护。本文档使用标准IKE和IPsec，没有任何新的扩展。它不适用于以自动方式启动的隧道（例如，6to4隧道[RFC3056]）。
3.2.6. RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I, September 2004)
3.2.6. RFC 3884，使用IPsec传输模式进行动态路由（I，2004年9月）
[RFC3884] describes the use of transport-mode IPsec to secure IP-in-IP tunnels, which constitute the links of a multi-hop, distributed virtual network (VN). This allows the traffic to be dynamically routed via the VN's trusted routers, rather than routing all traffic through a statically routed IPsec tunnel. This RFC has not been widely adopted.
[RFC3884]描述了使用传输模式IPsec保护IP隧道中的IP，该隧道构成多跳分布式虚拟网络（VN）的链路。这允许通过VN的受信任路由器动态路由流量，而不是通过静态路由的IPsec隧道路由所有流量。这种RFC尚未被广泛采用。
3.2.7. RFC 5840, Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility (S, April 2010)
3.2.7. RFC 5840，用于流量可见性的包装封装安全有效载荷（ESP）（S，2010年4月）
ESP, as defined in [RFC4303], does not allow a network device to easily determine whether protected traffic that is passing through the device is encrypted or only integrity protected (referred to as ESP-NULL packets). [RFC5840] extends ESPv3 to provide explicit notification of integrity-protected packets, and extends IKEv2 to negotiate this capability between the IPsec peers.
[RFC4303]中定义的ESP不允许网络设备轻松确定通过设备的受保护流量是加密的还是仅受完整性保护的（称为ESP-NULL数据包）。[RFC5840]扩展ESPv3以提供完整性保护数据包的显式通知，并扩展IKEv2以在IPsec对等方之间协商此功能。
3.2.8. RFC 5879, Heuristics for Detecting ESP-NULL packets (I, May 2010)
3.2.8. RFC 5879，检测ESP-NULL数据包的启发式算法（2010年5月，I）
[RFC5879] offers an alternative approach to differentiating between ESP-encrypted and ESP-NULL packets through packet inspection. This method does not require any change to IKE or ESP; it can be used with ESP-v2 or ESP-v3.
[RFC5879]提供了一种通过数据包检查区分ESP加密数据包和ESP-NULL数据包的替代方法。此方法不需要对IKE或ESP进行任何更改；它可以与ESP-v2或ESP-v3一起使用。
3.3.1. RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements (I, March 2004)
3.3.1. RFC 3715，IPsec网络地址转换（NAT）兼容性要求（I，2004年3月）
[RFC3715] "describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them". This is a critical issue, since IPsec is frequently used to provide VPN access to the corporate network for telecommuters, and NATs are widely deployed in home gateways, hotels, and other access networks typically used for remote access.
[RFC3715]“描述了NAT和IPsec之间已知的不兼容性，并描述了解决这些不兼容性的要求”。这是一个关键问题，因为IPsec经常用于为远程工作者提供对公司网络的VPN访问，而NAT广泛部署在家庭网关、酒店和其他通常用于远程访问的访问网络中。
3.3.2. RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 (B, February 2009)
3.3.2. RFC 5406，指定IPsec版本2使用的指南（B，2009年2月）
[RFC5406] offers guidance to protocol designers on how to ascertain whether IPsec is the appropriate security mechanism to provide an interoperable security solution for the protocol. If this is not the case, it advises against attempting to define a new security protocol; rather, it suggests using another standards-based security protocol. The details in this document apply only to IPsec-v2.
[RFC5406]就如何确定IPsec是否是为协议提供可互操作安全解决方案的适当安全机制向协议设计人员提供指导。如果不是这样，它建议不要试图定义新的安全协议；相反，它建议使用另一种基于标准的安全协议。本文档中的详细信息仅适用于IPsec-v2。
[RFC2521] specifies an ICMP message for indicating failures related to the use of IPsec protocols (AH and ESP). The specified ICMP message defines several codes for handling common failure modes for IPsec. The failures that are signaled by this message include invalid or expired SPIs, failure of authenticity or integrity checks on datagrams, decryption and decompression errors, etc. These messages can be used to trigger automated session-key management or to signal to an operator the need to manually reconfigure the SAs. This RFC has not been widely adopted. Furthermore, [RFC4301] discusses the pros and cons of relying on unprotected ICMP messages.
[RFC2521]指定用于指示与IPsec协议（AH和ESP）使用相关的故障的ICMP消息。指定的ICMP消息定义了几个用于处理IPsec常见故障模式的代码。此消息表示的故障包括无效或过期的SPI、数据报真实性或完整性检查失败、解密和解压缩错误等。这些消息可用于触发自动会话密钥管理或向操作员发出手动重新配置SAs的信号。这种RFC尚未被广泛采用。此外，[RFC4301]还讨论了依赖无保护ICMP消息的利弊。
[RFC6027] describes the problems of using IKE and IPsec in a high availability environment, in which one or both of the peers are clusters of gateways. It details the numerous types of stateful
[RFC6027]描述了在高可用性环境中使用IKE和IPsec的问题，其中一个或两个对等方是网关集群。它详细介绍了多种类型的有状态
information shared by IKE and IPsec peers that would have to be available to other members of the cluster in order to provide high-availability, load sharing, and/or failover capabilities.
IKE和IPsec对等方共享的信息，这些信息必须可供集群的其他成员使用，以提供高可用性、负载共享和/或故障切换功能。
IKE is the preferred key management protocol for IPsec. It is used for peer authentication; to negotiate, modify, and delete SAs; and to negotiate authenticated keying material for use within those SAs. The standard peer authentication methods used by IKEv1 (pre-shared secret keys and digital certificates) had several shortcomings related to use of IKEv1 to enable remote user authentication to a corporate VPN: it could not leverage the use of legacy authentication systems (e.g. RADIUS databases) to authenticate a remote user to a security gateway; and it could not be used to configure remote users with network addresses or other information needed in order to access the internal network. Automatic key distribution is required for IPsec-v2, but alternatives to IKE may be used to satisfy that requirement.
IKE是IPsec的首选密钥管理协议。用于对等身份验证；协商、修改和删除SAs；并协商在这些SA中使用的经过验证的密钥材料。IKEv1使用的标准对等身份验证方法（预共享密钥和数字证书）在使用IKEv1实现对公司VPN的远程用户身份验证方面存在若干缺陷：它无法利用传统身份验证系统（例如RADIUS数据库）向安全网关认证远程用户；而且它不能用于为远程用户配置访问内部网络所需的网络地址或其他信息。IPsec-v2需要自动密钥分发，但可以使用IKE的替代方案来满足该要求。
Several Internet Drafts were written to address these problems: two such documents include "Extended Authentication within IKE (XAUTH)" [IKE-XAUTH] (and its predecessor, "Extended Authentication within ISAKMP/Oakley (XAUTH)" [ISAKMP-XAUTH]) and "The ISAKMP Configuration Method" [IKE-MODE-CFG] (and its predecessor [ISAKMP-MODE-CFG]). These Internet Drafts did not progress to RFC status due to security flaws and other problems related to these solutions. However, many current IKEv1 implementations incorporate aspects of these solutions to facilitate remote user access to corporate VPNs. These solutions were not standardized, and different implementations implemented different versions. Thus, there is no assurance that the implementations adhere fully to the suggested solutions or that one implementation can interoperate with others that claim to incorporate the same features. Furthermore, these solutions have known security issues. All of those problems and security issues have been solved in IKEv2; thus, use of these non-standardized IKEv1 solutions is not recommended.
编写了几份互联网草案来解决这些问题：两份这样的文件包括“IKE（XAUTH）内的扩展认证”[IKE-XAUTH]（及其前身，“ISAKMP/Oakley（XAUTH）内的扩展认证”[ISAKMP-XAUTH]）和“ISAKMP配置方法”[IKE-MODE-CFG]（及其前身[ISAKMP-MODE-CFG]）。由于安全缺陷和与这些解决方案相关的其他问题，这些互联网草案没有进展到RFC状态。然而，许多当前的IKEv1实现结合了这些解决方案的各个方面，以方便远程用户访问公司VPN。这些解决方案没有标准化，不同的实现实现了不同的版本。因此，无法保证实现完全遵循建议的解决方案，或者一个实现可以与声称包含相同功能的其他实现进行互操作。此外，这些解决方案存在已知的安全问题。所有这些问题和安全问题都已在IKEv2中得到解决；因此，不建议使用这些非标准化IKEv1溶液。
This document defines a key exchange protocol that can be used to negotiate authenticated keying material for SAs. This document implements a subset of the Oakley protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for
本文档定义了一个密钥交换协议，可用于为SAs协商经过身份验证的密钥材料。本文档结合ISAKMP实现了Oakley协议的一个子集，以获取用于ISAKMP的经过身份验证的密钥材料，并用于
other security associations such as AH and ESP for the IETF IPsec DOI. While, historically, IKEv1 was created by combining two security protocols, ISAKMP and Oakley, in practice, the combination (along with the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The protocol's origins can be seen in the organization of the documents that define it.
其他安全关联，如IETF IPsec DOI的AH和ESP。历史上，IKEv1是通过组合两个安全协议ISAKMP和Oakley创建的，但在实践中，这种组合（以及IPsec DOI）通常被视为一个协议IKEv1。协议的起源可以从定义它的文档的组织中看出。
4.1.1.2. RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP) (S, November 1998)
4.1.1.2. RFC 2408，互联网安全协会和密钥管理协议（ISAKMP）（S，1998年11月）
This document defines procedures and packet formats to establish, negotiate, modify, and delete Security Associations (SAs). It is intended to support the negotiation of SAs for security protocols at all layers of the network stack. ISAKMP can work with many different key exchange protocols, each with different security properties.
本文档定义了建立、协商、修改和删除安全关联（SA）的过程和数据包格式。它旨在支持SAs在网络堆栈的所有层上协商安全协议。ISAKMP可以使用许多不同的密钥交换协议，每个协议都具有不同的安全属性。
4.1.1.3. RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP (S, November 1998)
4.1.1.3. RFC 2407，ISAKMP解释的互联网IP安全域（S，1998年11月）
Within ISAKMP, a Domain of Interpretation is used to group related protocols using ISAKMP to negotiate security associations. Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations.
在ISAKMP中，解释域用于使用ISAKMP对相关协议进行分组，以协商安全关联。共享DOI的安全协议从公共名称空间选择安全协议和加密转换，并共享密钥交换协议标识符。本文档定义了Internet IP安全DOI（IPSEC DOI），当IP使用ISAKMP协商安全关联时，它实例化ISAKMP与IP一起使用。
4.1.1.4. RFC 2412, The OAKLEY Key Determination Protocol (I, November 1998)
4.1.1.4. RFC 2412，《奥克利密钥确定协议》（I，1998年11月）
[RFC2412] describes a key establishment protocol that two authenticated parties can use to agree on secure and secret keying material. The Oakley protocol describes a series of key exchanges -- called "modes" -- and details the services provided by each (e.g., perfect forward secrecy for keys, identity protection, and authentication). This document provides additional theory and background to explain some of the design decisions and security features of IKE and ISAKMP; it does not include details necessary for the implementation of IKEv1.
[RFC2412]描述了一种密钥建立协议，经过身份验证的双方可以使用该协议来商定安全和保密密钥材料。Oakley协议描述了一系列被称为“模式”的密钥交换，并详细说明了每个交换提供的服务（例如，密钥的完美前向保密、身份保护和身份验证）。本文件提供了额外的理论和背景，以解释IKE和ISAKMP的一些设计决策和安全特性；它不包括实施IKEv1所需的细节。
4.1.2.1. RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, December 2005)
4.1.2.1. RFC 4306，因特网密钥交换（IKEv2）协议（S，2005年12月）
This document contains the original description of version 2 of the Internet Key Exchange (IKE) protocol. It covers what was previously covered by separate documents: ISAKMP, IKE, and DOI. It also
本文档包含Internet密钥交换（IKE）协议版本2的原始说明。它涵盖了以前由单独的文件所涵盖的内容：ISAKMP、IKE和DOI。它也
addresses NAT traversal, legacy authentication, and remote address acquisition. IKEv2 is not interoperable with IKEv1. Automatic key distribution is required for IPsec-v3, but alternatives to IKE may be used to satisfy that requirement. This document has been superseded by [RFC5996].
解决NAT遍历、传统身份验证和远程地址获取。IKEv2不能与IKEv1互操作。IPsec-v3需要自动密钥分发，但可以使用IKE的替代方案来满足该要求。本文件已被[RFC5996]取代。
4.1.2.2. RFC 4718, IKEv2 Clarifications and Implementation Guidelines (I, October 2006)
4.1.2.2. RFC 4718，IKEv2澄清和实施指南（I，2006年10月）
[RFC4718] clarifies many areas of the original IKEv2 specification [RFC4306] that were seen as potentially difficult to understand for developers who were not intimately familiar with the specification and its history. It does not introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The goal of this document was to encourage the development of interoperable implementations. The clarifications in this document have been included in the new version of the IKEv2 specification [RFC5996].
[RFC4718]澄清了原始IKEv2规范[RFC4306]的许多领域，这些领域对于不熟悉该规范及其历史的开发人员来说可能难以理解。它不会对协议进行任何更改，而是提供了不易产生歧义的描述。本文档的目标是鼓励开发可互操作的实现。本文件中的澄清已包含在新版IKEv2规范[RFC5996]中。
4.1.2.3. RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2) (S, September 2010)
4.1.2.3. RFC 5996，互联网密钥交换协议版本2（IKEv2）（S，2010年9月）
[RFC5996] combines the original IKEv2 RFC [RFC4306] with the Clarifications RFC [RFC4718], and resolves many implementation issues discovered by the community since the publication of these two documents. This document was developed by the IPsecME (IPsec Maintenance and Extensions) Working Group, after the conclusion of the original IPsec Working Group. Automatic key distribution is required for IPsec-v3, but alternatives to IKE may be used to satisfy that requirement.
[RFC5996]将原始的IKEv2 RFC[RFC4306]与澄清RFC[RFC4718]结合起来，解决了自这两个文档发布以来社区发现的许多实施问题。本文档是由IPsecME（IPsec维护和扩展）工作组在原始IPsec工作组结束后编写的。IPsec-v3需要自动密钥分发，但可以使用IKE的替代方案来满足该要求。
4.2.1.1. RFC 4478, Repeated Authentication in Internet Key Exchange (IKEv2) Protocol (E, April 2006)
4.2.1.1. RFC 4478，互联网密钥交换（IKEv2）协议中的重复认证（E，2006年4月）
[RFC4478] addresses a problem unique to remote access scenarios. How can the gateway (the IKE responder) force the remote user (the IKE initiator) to periodically reauthenticate, limiting the damage in the case where an unauthorized user gains physical access to the remote host? This document defines a new status notification, that a responder can send to an initiator, which notifies the initiator that the IPsec SA will be revoked unless the initiator reauthenticates within a specified period of time. This optional extension applies only to IKEv2, not to IKEv1.
[RFC4478]解决了远程访问场景特有的问题。网关（IKE响应程序）如何强制远程用户（IKE启动器）定期重新验证，从而在未经授权的用户获得对远程主机的物理访问时限制损坏？本文档定义了一个新的状态通知，响应者可以向启动器发送该通知，通知启动器IPsec SA将被撤销，除非启动器在指定的时间段内重新验证。此可选扩展仅适用于IKEv2，不适用于IKEv1。
4.2.1.2. RFC 4739, Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol (E, November 2006)
4.2.1.2. RFC 4739，《互联网密钥交换（IKEv2）协议中的多重认证交换》（E，2006年11月）
IKEv2 supports several mechanisms for authenticating the parties but each endpoint uses only one of these mechanisms to authenticate itself. [RFC4739] specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. This also allows for authentication by multiple administrative domains, if needed. This optional extension applies only to IKEv2, not to IKEv1.
IKEv2支持多种机制来认证各方，但每个端点仅使用其中一种机制来认证自身。[RFC4739]指定对IKEv2的扩展，该扩展允许使用不同机制或相同机制使用多个身份验证交换。例如，此扩展允许对客户端主机执行基于证书的身份验证，然后对用户执行EAP身份验证。如果需要，这还允许多个管理域进行身份验证。此可选扩展仅适用于IKEv2，不适用于IKEv1。
4.2.1.3. RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) (S, January 2007)
4.2.1.3. RFC 4754，使用椭圆曲线数字签名算法（ECDSA）的IKE和IKEv2认证（S，2007年1月）
[RFC4754] describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the IKEv1 and IKEv2 protocols. ECDSA provides many benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods like RSA and DSA. This optional extension applies to both IKEv1 and IKEv2.
[RFC4754]描述了如何将椭圆曲线数字签名算法（ECDSA）用作IKEv1和IKEv2协议中的身份验证方法。与其他可用的数字签名方法（如RSA和DSA）相比，ECDSA提供了许多好处，包括计算效率高、签名大小小和带宽最小。此可选扩展适用于IKEv1和IKEv2。
4.2.1.4. RFC 5998, An Extension for EAP-Only Authentication in IKEv2 (S, September 2010)
4.2.1.4. RFC 5998，IKEv2中仅EAP认证的扩展（S，2010年9月）
IKEv2 allows an initiator to use EAP for peer authentication, but requires the responder to authenticate through the use of a digital signature. [RFC5998] extends IKEv2 so that EAP methods that provide mutual authentication and key agreement can also be used to provide peer authentication for the responder. This optional extension applies only to IKEv2, not to IKEv1.
IKEv2允许发起方使用EAP进行对等身份验证，但要求响应方通过使用数字签名进行身份验证。[RFC5998]扩展了IKEv2，因此提供相互身份验证和密钥协商的EAP方法也可用于为响应者提供对等身份验证。此可选扩展仅适用于IKEv2，不适用于IKEv1。
The format, contents, and interpretation of Public Key Certificates (PKCs) proved to be a source of interoperability problems within IKE and IPsec. PKI4IPsec was an attempt to set in place some common procedures and interpretations to mitigate those problems.
公钥证书（PKC）的格式、内容和解释被证明是IKE和IPsec中互操作性问题的根源。PKI4IPsec试图建立一些通用程序和解释来缓解这些问题。
4.2.2.1. RFC 4809, Requirements for an IPsec Certificate Management Profile (I, February 2007)
4.2.2.1. RFC 4809，IPsec证书管理配置文件的要求（I，2007年2月）
[RFC4809] enumerates requirements for Public Key Certificate (PKC) lifecycle transactions between different VPN System and PKI System products in order to better enable large scale, PKI-enabled IPsec
[RFC4809]列举了不同VPN系统和PKI系统产品之间的公钥证书（PKC）生命周期事务的要求，以便更好地实现支持PKI的大规模IPsec
deployments with a common set of transactions. This document discusses requirements for both the IPsec and the PKI products. These optional requirements apply to both IKEv1 and IKEv2.
具有公共事务集的部署。本文档讨论了IPsec和PKI产品的要求。这些可选要求适用于IKEv1和IKEv2。
4.2.2.2. RFC 4945, The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX (S, August 2007)
4.2.2.2. RFC 4945，IKEv1/ISAKMP、IKEv2和PKIX的互联网IP安全PKI配置文件（S，2007年8月）
[RFC4945] defines a profile of the IKE and Public Key Infrastructure using X.509 (PKIX) frameworks in order to provide an agreed-upon standard for using PKI technology in the context of IPsec. It also documents the contents of the relevant IKE payloads and further specifies their semantics. In addition, it summarizes the current state of implementations and deployment and provides advice to avoid common interoperability issues. This optional extension applies to both IKEv1 and IKEv2.
[RFC4945]使用X.509（PKIX）框架定义了IKE和公钥基础设施的配置文件，以便为在IPsec环境中使用PKI技术提供商定的标准。它还记录了相关IKE有效负载的内容，并进一步指定了它们的语义。此外，它总结了实现和部署的当前状态，并提供了避免常见互操作性问题的建议。此可选扩展适用于IKEv1和IKEv2。
4.2.2.3. RFC 4806, Online Certificate Status Protocol (OCSP) Extensions to IKEv2 (S, February 2007)
4.2.2.3. RFC 4806，IKEv2的在线证书状态协议（OCSP）扩展（S，2007年2月）
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. [RFC4806] defines the "OCSP Content" extension to IKEv2. This document is applicable when OCSP is desired and security policy (e.g., firewall policy) prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. This optional extension applies only to IKEv2, not to IKEv1.
当证书与IKEv2一起使用时，通信的对等方需要一种机制来确定对等方证书的吊销状态。OCSP就是这样一种机制。[RFC4806]定义了IKEv2的“OCSP内容”扩展。当需要OCSP且安全策略（如防火墙策略）阻止IKEv2对等方之一直接访问相关OCSP响应程序时，本文件适用。此可选扩展仅适用于IKEv2，不适用于IKEv1。
4.2.3.1. RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers (I, February 2004)
4.2.3.1. RFC 3706，一种基于流量的检测死因特网密钥交换（IKE）对等点的方法（I，2004年2月）
When two peers communicate using IKE and IPsec, it is possible for the connectivity between the two peers to drop unexpectedly. But the SAs can still remain until their lifetimes expire, resulting in the packets getting tunneled into a "black hole". [RFC3706] describes an approach to detect peer liveliness without needing to send messages at regular intervals. This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers to this feature as a "liveness check" or "liveness test".
当两个对等点使用IKE和IPsec进行通信时，两个对等点之间的连接可能会意外中断。但是SAs仍然可以保留，直到其生命周期到期，导致数据包被隧道进入“黑洞”。[RFC3706]描述了一种检测对等活跃性的方法，无需定期发送消息。该RFC定义了对IKEv1的可选扩展；死点检测（DPD）是IKEv2不可分割的一部分，IKEv2将此功能称为“活性检查”或“活性测试”。
The IKEv2 Mobility and Multihoming (MOBIKE) protocol enables two additional capabilities for IPsec VPN users: 1) moving from one address to another without re-establishing existing SAs and 2) using
IKEv2 Mobility and Multihoming（MOBIKE）协议为IPsec VPN用户提供了两个附加功能：1）在不重新建立现有SAs的情况下从一个地址移动到另一个地址；2）使用
multiple interfaces simultaneously. These solutions are limited to IPsec VPNs; they are not intended to provide more general mobility or multihoming capabilities.
同时提供多个接口。这些解决方案仅限于IPsec VPN；它们的目的不是提供更通用的机动性或多宿能力。
The IPsecME Working Group identified some missing components needed for more extensive IKEv2 and IPsec-v3 support for remote access clients. These include efficient client resumption of a previously established session with a VPN gateway, efficient client redirection to an alternate VPN gateway, and support for IPv6 client configuration using IPsec configuration payloads.
IPsecME工作组发现了一些缺失的组件，这些组件需要为远程访问客户端提供更广泛的IKEv2和IPsec-v3支持。其中包括使用VPN网关高效地恢复先前建立的会话的客户端，高效地将客户端重定向到备用VPN网关，以及使用IPsec配置有效负载支持IPv6客户端配置。
4.2.4.1. RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S, June 2006)
4.2.4.1. RFC 4555，IKEv2移动和多址协议（MOBIKE）（S，2006年6月）
IKEv2 assumes that an IKE SA is created implicitly between the IP address pair that is used during the protocol execution when establishing the IKEv2 SA. IPsec-related documents had no provision to change this pair after an IKE SA was created. [RFC4555] defines extensions to IKEv2 that enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time.
IKEv2假设在建立IKEv2 SA时，在协议执行期间使用的IP地址对之间隐式创建IKE SA。IPsec相关文档没有在创建IKE SA后更改此对的规定。[RFC4555]定义了对IKEv2的扩展，当主机拥有多个IP地址和/或IPsec主机的IP地址随时间变化时，该扩展能够有效管理IKE和IPsec安全关联。
4.2.4.2. RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol (I, August 2006)
4.2.4.2. RFC 4621，IKEv2移动性和多址（MOBIKE）协议的设计（2006年8月，I）
[RFC4621] discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. It also records design decisions for the MOBIKE protocol, background information, and records discussions within the working group.
[RFC4621]讨论了涉及的网络实体以及IKEv2信令和其他协议提供的信息之间的关系。它还记录MOBIKE协议的设计决策、背景信息，并记录工作组内的讨论。
4.2.4.3. RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) (B, June 2008)
4.2.4.3. RFC 5266，使用移动IPv4和IKEv2移动和多址（MOBIKE）的安全连接和移动（B，2008年6月）
[RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility to enterprise users when they roam into untrusted networks.
[RFC5266]介绍了一种使用移动IPv4（MIPv4）和IKEv2移动扩展（MOBIKE）的解决方案，以在企业用户漫游到不受信任的网络时为他们提供安全的连接和移动。
4.2.4.4. RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption (S, January 2010)
4.2.4.4. RFC 5723，互联网密钥交换协议版本2（IKEv2）会话恢复（S，2010年1月）
[RFC5723] enables a remote client that has been disconnected from a gateway to re-establish SAs with the gateway in an expedited manner, without repeating the complete IKEv2 negotiation. This capability requires changes to IKEv2. This optional extension applies only to IKEv2, not to IKEv1.
[RFC5723]使与网关断开连接的远程客户端能够以快速方式与网关重新建立SAs，而无需重复完整的IKEv2协商。此功能需要对IKEv2进行更改。此可选扩展仅适用于IKEv2，不适用于IKEv1。
4.2.4.5. RFC 5685, Re-direct Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) (S, November 2009)
4.2.4.5. RFC 5685，互联网密钥交换协议版本2（IKEv2）的重新定向机制（S，2009年11月）
[RFC5685] enables a gateway to securely redirect VPN clients to another VPN gateway, either during or after the IKEv2 negotiation. Possible reasons include, but are not limited to, an overloaded gateway or a gateway that needs to shut down. This requires changes to IKEv2. This optional extension applies only to IKEv2, not to IKEv1.
[RFC5685]使网关能够在IKEv2协商期间或之后安全地将VPN客户端重定向到另一个VPN网关。可能的原因包括但不限于过载网关或需要关闭的网关。这需要对IKEv2进行更改。此可选扩展仅适用于IKEv2，不适用于IKEv1。
4.2.4.6. RFC 5739, IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) (E, February 2010)
4.2.4.6. RFC 5739，互联网密钥交换协议版本2（IKEv2）中的IPv6配置（E，2010年2月）
In IKEv2, a VPN gateway can assign an internal network address to a remote VPN client. This is accomplished through the use of configuration payloads. For an IPv6 client, the assignment of a single address is not sufficient to enable full-fledged IPv6 communications. [RFC5739] proposes several solutions that might remove this limitation. This optional extension applies only to IKEv2, not to IKEv1.
在IKEv2中，VPN网关可以将内部网络地址分配给远程VPN客户端。这是通过使用配置有效载荷来实现的。对于IPv6客户端，单个地址的分配不足以实现完整的IPv6通信。[RFC5739]提出了几种可能消除此限制的解决方案。此可选扩展仅适用于IKEv2，不适用于IKEv1。
Two basic requirements must be met for an algorithm to be used within IKE and/or IPsec: assignment of one or more IANA values and an RFC that describes how to use the algorithm within the relevant protocol, packet formats, special considerations, etc. For each RFC that describes a cryptographic algorithm, this roadmap will classify its requirement level for each protocol, as either MUST, SHOULD, or MAY [RFC2119]; SHOULD+, SHOULD-, or MUST- [RFC4835]; optional; undefined; or N/A (not applicable). A designation of "optional" means that the algorithm meets the two basic requirements, but its use is not specifically recommended for that protocol. "Undefined" means that one of the basic requirements is not met: either there is no relevant IANA number for the algorithm or there is no RFC specifying how it should be used within that specific protocol. "N/A" means that use of the algorithm is inappropriate in the context (e.g., NULL encryption for IKE, which always requires encryption; or combined mode algorithms, a new feature in IPsec-v3, for use with IPsec-v2).
在IKE和/或IPsec中使用的算法必须满足两个基本要求：一个或多个IANA值的分配和一个RFC，该RFC描述了如何在相关协议中使用该算法、数据包格式、特殊注意事项等。对于描述加密算法的每个RFC，该路线图将每个协议的需求级别分类为必须、应该或可能[RFC2119]；应+、应-或必须-[RFC4835]；可选择的未定义；或不适用（不适用）。“可选”表示该算法满足两个基本要求，但并不特别建议该协议使用该算法。“未定义”表示未满足其中一项基本要求：要么没有算法的相关IANA编号，要么没有RFC规定在该特定协议中应如何使用该算法。“N/A”表示在上下文中使用算法是不合适的（例如，IKE的空加密，总是需要加密；或组合模式算法，IPsec-v3中的新功能，用于IPsec-v2）。
This document categorizes the requirement level of each algorithm for IKEv1, IKEv2, IPsec-v2, and IPsec-v3. If an algorithm is recommended for use within IKEv1 or IKEv2, it is used either to protect the IKE SA's traffic (encryption and integrity-protection algorithms) or to generate keying material (Diffie-Hellman or DH groups, Pseudorandom Functions or PRFs). If an algorithm is recommended for use within IPsec, it is used to protect the IPsec/child SA's traffic, and IKE is capable of negotiating its use for that purpose. These requirements
本文档对IKEv1、IKEv2、IPsec-v2和IPsec-v3的每个算法的需求级别进行了分类。如果建议在IKEv1或IKEv2中使用算法，则该算法用于保护IKE SA的通信量（加密和完整性保护算法）或生成密钥材料（Diffie-Hellman或DH组、伪随机函数或PRF）。如果建议在IPsec中使用算法，则该算法用于保护IPsec/子SA的通信量，IKE能够为此目的协商使用该算法。这些要求
are summarized in Table 1 (Appendix A). These levels are current as of February 2011; subsequent RFCs may result in altered requirement levels. For algorithms, this could mean the introduction of new algorithms or upgrading or downgrading the requirement levels of current algorithms.
表1（附录A）总结了这些数据。截至2011年2月，这些水平为现行水平；随后的RFC可能会导致需求水平的改变。对于算法，这可能意味着引入新算法或升级或降低当前算法的需求水平。
The IANA registries for IKEv1 and IKEv2 include IANA values for various cryptographic algorithms. IKE uses these values to negotiate IPsec SAs that will provide protection using those algorithms. If a specific algorithm lacks a value for IKEv1 and/or IKEv2, that algorithm's use is classified as "undefined" (no IANA #) within IPsec-v2 and/or IPsec-v3.
IKEv1和IKEv2的IANA注册表包括各种密码算法的IANA值。IKE使用这些值协商将使用这些算法提供保护的IPsec SA。如果特定算法缺少IKEv1和/或IKEv2的值，则该算法的使用在IPsec-v2和/或IPsec-v3中被归类为“未定义”（无IANA）。
Specifying a core set of mandatory algorithms for each protocol facilitates interoperability. Defining those algorithms in an RFC separate from the base protocol RFC enhances algorithm agility. IPsec-v3 and IKEv2 each have an RFC that specifies their mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY), and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is included in the base protocol RFC. That was originally the case for IKEv1, but IKEv1's algorithm requirements were updated in [RFC4109].
为每个协议指定一组强制算法有助于实现互操作性。在与基本协议RFC分离的RFC中定义这些算法可以增强算法的灵活性。IPsec-v3和IKEv2都有一个RFC，用于指定强制实现（必须）、推荐（应该）、可选（可能）和弃用（不应该）算法。对于IPsec-v2，这包括在基本协议RFC中。IKEv1最初就是这样，但IKEv1的算法要求在[RFC4109]中进行了更新。
5.1.1. RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, April 2007)
5.1.1. RFC 4835，《封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求》（S，2007年4月）
[RFC4835] specifies the encryption and integrity-protection algorithms for IPsec (both versions). Algorithms for IPsec-v2 were originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted those requirements, and was in turn obsoleted by [RFC4835]. Therefore, [RFC4835] applies to IPsec-v2 as well as IPsec-v3. Combined mode algorithms are mentioned, but not assigned a requirement level.
[RFC4835]指定IPsec的加密和完整性保护算法（两个版本）。IPsec-v2的算法最初在[RFC2402]和[RFC2406]中定义。[RFC4305]废除了这些要求，并被[RFC4835]废除。因此，[RFC4835]适用于IPsec-v2和IPsec-v3。提到了组合模式算法，但未指定需求级别。
5.1.2. RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) (S, December 2005)
5.1.2. RFC 4307，互联网密钥交换版本2（IKEv2）中使用的加密算法（S，2005年12月）
[RFC4307] specifies the encryption and integrity-protection algorithms used by IKEv2 to protect its own traffic, the Diffie-Hellman (DH) groups used within IKEv2, and the pseudorandom functions used by IKEv2 to generate keys, nonces, and other random values. [RFC4307] contains conflicting requirements for IKEv2 encryption and integrity-protection algorithms. Where there are contradictory requirements, this document takes its requirement levels from Section
[RFC4307]指定IKEv2用于保护其自身流量的加密和完整性保护算法、IKEv2中使用的Diffie-Hellman（DH）组以及IKEv2用于生成密钥、nonce和其他随机值的伪随机函数。[RFC4307]包含对IKEv2加密和完整性保护算法的冲突要求。如果存在相互矛盾的需求，本文件从第节中获取其需求级别
3.1.1, "Encrypted Payload Algorithms", rather than from Section 3.1.3, "IKEv2 Transform Type 1 Algorithms", or Section 3.1.4, "IKEv2 Transform Type 2 Algorithms".
3.1.1“加密有效负载算法”，而不是第3.1.3节“IKEv2变换类型1算法”或第3.1.4节“IKEv2变换类型2算法”。
5.1.3. RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1) (S, May 2005)
5.1.3. RFC 4109，互联网密钥交换算法第1版（IKEv1）（S，2005年5月）
[RFC4109] updates IKEv1's algorithm specifications, which were originally defined in [RFC2409]. It specifies the encryption and integrity-protection algorithms used by IKEv1 to protect its own traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash and pseudorandom functions used by IKEv1 to generate keys, nonces and other random values; and the authentication methods and algorithms used by IKEv1 for peer authentication.
[RFC4109]更新了最初在[RFC2409]中定义的IKEv1算法规范。它规定了IKEv1用于保护自身流量的加密和完整性保护算法；IKEv1中使用的Diffie-Hellman（DH）群；IKEv1用于生成密钥、nonce和其他随机值的散列函数和伪随机函数；以及IKEv1用于对等身份验证的身份验证方法和算法。
The encryption-algorithm RFCs describe how to use these algorithms to encrypt IKE and/or ESP traffic, providing confidentiality protection to the traffic. They describe any special constraints, requirements, or changes to packet format appropriate for the specific algorithm. In general, they do not describe the detailed algorithmic computations; the reference section of each RFC includes pointers to documents that define the inner workings of the algorithm. Some of the RFCs include sample test data, to enable implementors to compare their results with standardized output.
加密算法RFCs描述了如何使用这些算法对IKE和/或ESP通信进行加密，从而为通信提供保密保护。它们描述了适用于特定算法的任何特殊约束、要求或对数据包格式的更改。一般来说，它们不描述详细的算法计算；每个RFC的参考部分包括指向定义算法内部工作的文档的指针。一些RFC包含样本测试数据，以使实现人员能够将其结果与标准化输出进行比较。
When any encryption algorithm is used to provide confidentiality, the use of integrity protection is strongly recommended. If the encryption algorithm is a stream cipher, omitting integrity protection seriously compromises the security properties of the algorithm.
当使用任何加密算法提供机密性时，强烈建议使用完整性保护。如果加密算法是流密码，忽略完整性保护会严重损害算法的安全性。
DES, as described in [RFC2405], was originally a required algorithm for IKEv1 and ESP-v2. Since the use of DES is now deprecated, this roadmap does not include [RFC2405].
如[RFC2405]所述，DES最初是IKEv1和ESP-v2所需的算法。由于现在不推荐使用DES，本路线图不包括[RFC2405]。
5.2.1. RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec (S, November 1998)
5.2.1. RFC 2410，空加密算法及其在IPsec中的使用（S，1998年11月）
[RFC2410] is a tongue-in-cheek description of the no-op encryption algorithm (i.e., using ESP without encryption). In order for IKE to negotiate the selection of the NULL encryption algorithm for use in an ESP SA, an identifying IANA number is needed. This number (the value 11 for ESP_NULL) is found on the IANA registries for both IKEv1 and IKEv2, but it is not mentioned in [RFC2410].
[RFC2410]是对无操作加密算法（即使用无加密的ESP）的开玩笑的描述。为了让IKE协商选择ESP SA中使用的空加密算法，需要识别IANA号。IKEv1和IKEv2的IANA注册表中都有该数字（ESP_NULL的值11），但[RFC2410]中未提及该数字。
Requirement levels for ESP-NULL:
ESP-NULL的要求级别：
IKEv1 - N/A
IKEv2 - N/A
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]
IKEv1 - N/A
IKEv2 - N/A
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]
NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this has been corrected in an errata submission for RFC 4307.
注：RFC 4307错误地将ESP-NULL分类为IKEv2的可能值；这已在RFC 4307的勘误表中更正。
[RFC2451] describes how to use encryption algorithms in cipher-block-chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically mentions Blowfish, CAST-128, Triple DES (3DES), International Data Encryption Algorithm (IDEA), and RC5, but it is applicable to any block-cipher algorithm used in CBC mode. The algorithms mentioned in the RFC all have a 64-bit blocksize and a 64-bit random Initialization Vector (IV) that is sent in the packet along with the encrypted data.
[RFC2451]描述了如何在密码块链接（CBC）模式下使用加密算法来加密IKE和ESP流量。它特别提到了Blowfish、CAST-128、Triple-DES（3DES）、国际数据加密算法（IDEA）和RC5，但它适用于CBC模式中使用的任何分组密码算法。RFC中提到的算法都具有64位块大小和64位随机初始化向量（IV），该向量与加密数据一起在数据包中发送。
Requirement levels for 3DES-CBC:
3DES-CBC的要求级别：
IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST- [RFC4835]
IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST- [RFC4835]
Requirement levels for other CBC algorithms (Blowfish, CAST, IDEA, RC5):
其他CBC算法（河豚、CAST、IDEA、RC5）的需求水平：
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
IKEv1-可选IKEv2-可选ESP-v2-可选ESP-v3-可选
5.2.3. RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec (S, September. 2003)
5.2.3. RFC 3602，AES-CBC密码算法及其在IPsec中的应用（S，2003年9月）
[RFC3602] describes how to use AES in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic. AES is the successor to DES. AES-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that is sent in the packet along with the encrypted data, and keysizes of 128, 192 and 256 bits. If AES-CBC is implemented, 128-bit keys are MUST; the other sizes are MAY. [RFC3602] includes IANA values for use in IKEv1 and ESP-v2. A single IANA value is defined for AES-CBC, so IKE negotiations need to specify the keysize.
[RFC3602]介绍了如何在密码块链接（CBC）模式下使用AES加密IKE和ESP流量。AES是DES的继承者。AES-CBC是一种块模式密码，块大小为128位，随机IV与加密数据一起在数据包中发送，密钥大小为128、192和256位。如果实现AES-CBC，则必须使用128位密钥；其他尺寸是5号。[RFC3602]包括IKEv1和ESP-v2中使用的IANA值。AES-CBC定义了一个IANA值，因此IKE协商需要指定密钥大小。
Requirement levels for AES-CBC with 128-bit keys:
具有128位密钥的AES-CBC的要求级别：
IKEv1 - SHOULD [RFC4109]
IKEv2 - SHOULD+ [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]
IKEv1 - SHOULD [RFC4109]
IKEv2 - SHOULD+ [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]
Requirement levels for AES-CBC with 192- or 256-bit keys:
具有192位或256位密钥的AES-CBC的要求级别：
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
IKEv1-可选IKEv2-可选ESP-v2-可选ESP-v3-可选
5.2.4. RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) (S, January 2004)
5.2.4. RFC 3686，使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）（S，2004年1月）
[RFC3686] describes how to use AES in counter (CTR) mode to encrypt ESP traffic. AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV. If AES-CTR is implemented, 128-bit keys are MUST; 192- and 256-byte keys are MAY. Reuse of the IV with the same key and nonce compromises the data's security; thus, AES-CTR should not be used with manual keying. AES-CTR can be pipelined and parallelized; it uses only the AES encryption operations for both encryption and decryption.
[RFC3686]介绍如何在计数器（CTR）模式下使用AES加密ESP通信。AES-CTR是一种具有32位随机nonce（1/SA）和64位IV的流密码。如果实现AES-CTR，则必须使用128位密钥；可以使用192字节和256字节的密钥。重复使用具有相同密钥和nonce的IV会损害数据的安全性；因此，AES-CTR不应与手动键控一起使用。AES-CTR可以流水线和并行化；它只使用AES加密操作进行加密和解密。
Requirement levels for AES-CTR:
AES-CTR的要求等级：
IKEv1 - undefined (no IANA #)
IKEv2 - optional [RFC5930]
ESP-v2 - SHOULD [RFC4835]
ESP-v3 - SHOULD [RFC4835]
IKEv1 - undefined (no IANA #)
IKEv2 - optional [RFC5930]
ESP-v2 - SHOULD [RFC4835]
ESP-v3 - SHOULD [RFC4835]
5.2.5. RFC 5930, Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol (I, July 210).
5.2.5. RFC 5930，使用互联网密钥交换版本02（IKEv2）协议的高级加密标准计数器模式（AES-CTR）（I，210年7月）。
[RFC5930] extends [RFC3686] to enable the use of AES-CTR to provide encryption and integrity protection for IKEv2 messages.
[RFC5930]扩展了[RFC3686]，允许使用AES-CTR为IKEv2消息提供加密和完整性保护。
5.2.6. RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec (S, December 2005)
5.2.6. RFC 4312，Camellia密码算法及其在IPsec中的使用（S，2005年12月）
[RFC4312] describes how to use Camellia in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that is sent in the packet along with the encrypted data, and keysizes of 128, 192, and
[RFC4312]描述了如何在密码块链接（CBC）模式下使用Camellia对IKE和ESP通信进行加密。Camellia CBC是一种块模式密码，具有128位块大小、随加密数据一起在数据包中发送的随机IV，密钥大小为128、192和128
256 bits. If Camellia-CBC is implemented, 128-bit keys are MUST; the other sizes are MAY. [RFC4312] includes IANA values for use in IKEv1 and IPsec-v2. A single IANA value is defined for Camellia-CBC, so IKEv1 negotiations need to specify the keysize.
256位。如果实现Camellia CBC，则必须使用128位密钥；其他尺寸是5号。[RFC4312]包括IKEv1和IPsec-v2中使用的IANA值。Camellia CBC定义了一个IANA值，因此IKEv1协商需要指定密钥大小。
5.2.7. RFC 5529, Modes of Operation for Camellia for Use with IPsec (S, April 2009)
5.2.7. RFC 5529，与IPsec一起使用的Camellia的操作模式（S，2009年4月）
[RFC5529] describes the use of the Camellia block-cipher algorithm in conjunction with several different modes of operation. It describes the use of Camellia in cipher block chaining (CBC) mode and counter (CTR) mode as an encryption algorithm within ESP. It also describes the use of Camellia in Counter with CBC-MAC (CCM) mode as a combined mode algorithm in ESP. This document defines how to use IKEv2 to generate keying material for a Camellia ESP SA; it does not define how to use Camellia within IKEv2 to protect an IKEv2 SA's traffic. However, this RFC, in conjunction with IKEv2's generalized description of block-mode encryption, provide enough detail to allow the use of Camellia-CBC algorithms within IKEv2. All three modes can use keys of length 128 bits, 192 bits, or 256 bits. [RFC5529] includes IANA values for use in IKEv2 and IPsec-v3. A single IANA value is defined for each Camellia mode, so IKEv2 negotiations need to specify the keysize.
[RFC5529]介绍了Camellia分组密码算法与几种不同操作模式的结合使用。它描述了在密码块链接（CBC）模式和计数器（CTR）模式中使用Camellia作为ESP中的加密算法。它还描述了在计数器中使用Camellia和CBC-MAC（CCM）模式作为ESP中的组合模式算法。本文档定义了如何使用IKEv2为Camellia ESP SA生成密钥材料；它没有定义如何在IKEv2中使用茶花来保护IKEv2 SA的流量。然而，该RFC结合IKEv2对块模式加密的一般描述，提供了足够的细节，允许在IKEv2中使用Camellia CBC算法。这三种模式都可以使用长度为128位、192位或256位的密钥。[RFC5529]包括IKEv2和IPsec-v3中使用的IANA值。每个Camellia模式都定义了一个IANA值，因此IKEv2需要指定密钥大小。
Requirement levels for Camellia-CBC:
茶花CBC的要求水平：
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
IKEv1-可选IKEv2-可选ESP-v2-可选ESP-v3-可选
Requirement levels for Camellia-CTR:
茶花CTR的要求水平：
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no RFC)
ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
ESP-v3 - optional
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no RFC)
ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
ESP-v3 - optional
Requirement levels for Camellia-CCM:
茶花CCM的要求水平：
IKEv1 - N/A
IKEv2 - undefined (no RFC)
ESP-v2 - N/A
ESP-v3 - optional
IKEv1 - N/A
IKEv2 - undefined (no RFC)
ESP-v2 - N/A
ESP-v3 - optional
5.2.8. RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec (S, October 2005)
5.2.8. RFC 4196，种子密码算法及其在IPsec中的使用（S，2005年10月）
[RFC4196] describes how to use SEED in cipher block chaining (CBC) mode to encrypt ESP traffic. It describes how to use IKEv1 to negotiate a SEED-ESP SA, but does not define the use of SEED to protect IKEv1 traffic. SEED-CBC is a block-mode cipher with a 128-bit blocksize, a random IV that is sent in the packet along with the encrypted data, and a keysize of 128 bits. [RFC4196] includes IANA values for use in IKEv1 and IPsec-v2. [RFC4196] includes test data.
[RFC4196]介绍了如何在密码块链接（CBC）模式下使用SEED对ESP通信进行加密。它描述了如何使用IKEv1协商SEED-ESP SA，但没有定义使用SEED保护IKEv1流量。SEED-CBC是一种块模式密码，块大小为128位，随机IV与加密数据一起在数据包中发送，密钥大小为128位。[RFC4196]包括IKEv1和IPsec-v2中使用的IANA值。[RFC4196]包括测试数据。
Requirement levels for SEED-CBC:
SEED-CBC的要求水平：
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no IANA #)
ESP-v2 - optional
ESP-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no IANA #)
ESP-v2 - optional
ESP-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
The integrity-protection algorithm RFCs describe how to use these algorithms to authenticate IKE and/or IPsec traffic, providing integrity protection to the traffic. This protection is provided by computing an Integrity Check Value (ICV), which is sent in the packet. The RFCs describe any special constraints, requirements, or changes to packet format appropriate for the specific algorithm. In general, they do not describe the detailed algorithmic computations; the reference section of each RFC includes pointers to documents that define the inner workings of the algorithm. Some of the RFCs include sample test data, to enable implementors to compare their results with standardized output.
完整性保护算法RFCs描述了如何使用这些算法对IKE和/或IPsec流量进行身份验证，从而为流量提供完整性保护。这种保护是通过计算完整性检查值（ICV）提供的，该值在数据包中发送。RFC描述了适用于特定算法的任何特殊约束、要求或对数据包格式的更改。一般来说，它们不描述详细的算法计算；每个RFC的参考部分包括指向定义算法内部工作的文档的指针。一些RFC包含样本测试数据，以使实现人员能够将其结果与标准化输出进行比较。
Some of these algorithms generate a fixed-length ICV, which is truncated when it is included in an IPsec-protected packet. For example, standard HMAC-SHA-1 (Hashed Message Authentication Code) generates a 160-bit ICV, which is truncated to 96 bits when it is used to provide integrity protection to an ESP or AH packet. The individual RFC descriptions mention those algorithms that are truncated. When these algorithms are used to protect IKEv2 SAs, they are also truncated. For IKEv1, HMAC-SHA-1 and HMAC-MD5 are negotiated by requesting the hash algorithms SHA-1 and MD5, respectively; these algorithms are not truncated when used to protect an IKEv1 SA. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains values for both the truncated version and the standard non-truncated version; thus, IKEv2 has the capability to negotiate either version of the algorithm. However, only the truncated version is used for IKEv2 SAs and for IPsec SAs. The non-truncated version is
其中一些算法生成一个固定长度的ICV，当它包含在受IPsec保护的数据包中时会被截断。例如，标准HMAC-SHA-1（散列消息认证码）生成160位ICV，当用于为ESP或AH数据包提供完整性保护时，ICV被截断为96位。单独的RFC描述提到了那些被截断的算法。当这些算法用于保护IKEv2 SAs时，它们也会被截断。对于IKEv1，分别通过请求散列算法SHA-1和MD5来协商HMAC-SHA-1和HMAC-MD5；当用于保护IKEv1 SA时，这些算法不会被截断。对于HMAC-SHA-1和HMAC-MD5，IKEv2 IANA注册表包含截断版本和标准非截断版本的值；因此，IKEv2能够协商算法的任一版本。但是，只有截断版本用于IKEv2 SAs和IPsec SAs。非截断版本为
reserved for use by the Fibre Channel protocol [RFC4595]. For the other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC-RIPEMD), only the truncated version can be used for both IKEv2 and IPsec-v3 SAs.
保留供光纤通道协议[RFC4595]使用。对于其他算法（AES-XCBC、HMAC-SHA-256/384/512、AES-CMAC和HMAC-RIPEMD），只有截断版本可用于IKEv2和IPsec-v3 SAs。
One other algorithm, AES-GMAC [RFC4543], can also provide integrity protection. It has two versions: an integrity-protection algorithm for use within AH-v3, and a combined mode algorithm with null encryption for use within ESP-v3. [RFC4543] is described in Section 5.4, "Combined Mode Algorithms".
另一种算法AES-GMAC[RFC4543]也可以提供完整性保护。它有两个版本：用于AH-v3的完整性保护算法，以及用于ESP-v3的带空加密的组合模式算法。[RFC4543]在第5.4节“组合模式算法”中描述。
5.3.1. RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, November 1998)
5.3.1. RFC 2404，在ESP和AH中使用HMAC-SHA-1-96（S，1998年11月）
[RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm with a 512-bit blocksize, and a 160-bit key and Integrity Check Value (ICV). For use within IPsec, the ICV is truncated to 96 bits. This is currently the most commonly used integrity-protection algorithm.
[RFC2404]描述了HMAC-SHA-1，一种具有512位块大小和160位密钥和完整性检查值（ICV）的完整性保护算法。为了在IPsec中使用，ICV被截断为96位。这是目前最常用的完整性保护算法。
Requirement levels for HMAC-SHA-1:
HMAC-SHA-1的要求等级：
IKEv1 - MUST [RFC4109]
IKEv2 - MUST [RFC4307]
IPsec-v2 - MUST [RFC4835]
IPsec-v3 - MUST [RFC4835]
IKEv1 - MUST [RFC4109]
IKEv2 - MUST [RFC4307]
IPsec-v2 - MUST [RFC4835]
IPsec-v3 - MUST [RFC4835]
5.3.2. RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec (S, September 2003)
5.3.2. RFC 3566，AES-XCBC-MAC-96算法及其在IPsec中的使用（S，2003年9月）
[RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC, which is secure for messages of varying lengths (unlike classic CBC-MAC). It is an integrity-protection algorithm with a 128-bit blocksize and a 128-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. [RFC3566] includes test data.
[RFC3566]描述了AES-XCBC-MAC，它是CBC-MAC的一种变体，对于不同长度的消息是安全的（与经典的CBC-MAC不同）。它是一种完整性保护算法，具有128位块大小、128位密钥和ICV。为了在IPsec中使用，ICV被截断为96位。[RFC3566]包括测试数据。
Requirement levels for AES-XCBC-MAC:
AES-XCBC-MAC的要求级别：
IKEv1 - undefined (no RFC)
IKEv2 - optional
IPsec-v2 - SHOULD+ [RFC4835]
IPsec-v3 - SHOULD+ [RFC4835]
IKEv1 - undefined (no RFC)
IKEv2 - optional
IPsec-v2 - SHOULD+ [RFC4835]
IPsec-v3 - SHOULD+ [RFC4835]
5.3.3. RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec (S, May 2007)
5.3.3. RFC 4868，在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512（S，2007年5月）
[RFC4868] describes a family of algorithms, successors to HMAC-SHA-1. HMAC-SHA-256 has a 512-bit blocksize and a 256-bit key and ICV. HMAC-SHA-384 has a 1024-bit blocksize and a 384-bit key and ICV.
[RFC4868]描述了一系列算法，它们是HMAC-SHA-1的继承者。HMAC-SHA-256具有512位块大小、256位密钥和ICV。HMAC-SHA-384具有1024位块大小和384位密钥和ICV。
HMAC-SHA-512 has a 1024-bit blocksize and a 512-bit key and ICV. For use within IKE and IPsec, the ICV is truncated to half its original size (128 bits, 192 bits, or 256 bits). Each of the three algorithms has its own IANA value, so IKE does not have to negotiate the keysize.
HMAC-SHA-512具有1024位块大小和512位密钥和ICV。为了在IKE和IPsec中使用，ICV被截断为其原始大小的一半（128位、192位或256位）。这三种算法都有自己的IANA值，因此IKE不必协商密钥大小。
Requirement levels for HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512:
HMAC-SHA-256、HMAC-SHA-384、HMAC-SHA-512的要求等级：
IKEv1 - optional IKEv2 - optional IPsec-v2 - optional IPsec-v3 - optional
IKEv1-可选IKEv2-可选IPsec-v2-可选IPsec-v3-可选
5.3.4. RFC 2403, The Use of HMAC-MD5-96 within ESP and AH (S, November 1998)
5.3.4. RFC 2403，在ESP和AH中使用HMAC-MD5-96（S，1998年11月）
[RFC2403] describes HMAC-MD5, an integrity-protection algorithm with a 512-bit blocksize and a 128-bit key and Integrity Check Value (ICV). For use within IPsec, the ICV is truncated to 96 bits. It was a required algorithm for IKEv1 and IPsec-v2. The use of plain MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC".
[RFC2403]描述了HMAC-MD5，一种具有512位块大小和128位密钥和完整性检查值（ICV）的完整性保护算法。为了在IPsec中使用，ICV被截断为96位。这是IKEv1和IPsec-v2所需的算法。现在不推荐使用普通MD5，但[RFC4835]指出：“MD5中的弱点已变得明显；但是，这些不应影响MD5与HMAC的结合使用”。
Requirement levels for HMAC-MD5:
HMAC-MD5的要求水平：
IKEv1 - MAY [RFC4109]
IKEv2 - optional [RFC4307]
IPsec-v2 - MAY [RFC4835]
IPsec-v3 - MAY [RFC4835]
IKEv1 - MAY [RFC4109]
IKEv2 - optional [RFC4307]
IPsec-v2 - MAY [RFC4835]
IPsec-v3 - MAY [RFC4835]
5.3.5. RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S, June 2006)
5.3.5. RFC 4494，AES-CMAC-96算法及其在IPsec中的使用（S，2006年6月）
[RFC4494] describes AES-CMAC, another variant of CBC-MAC, which is secure for messages of varying lengths. It is an integrity-protection algorithm with a 128-bit blocksize and 128-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. [RFC4494] includes test data.
[RFC4494]描述了AES-CMAC，CBC-MAC的另一个变体，它对不同长度的消息是安全的。它是一种完整性保护算法，具有128位块大小、128位密钥和ICV。为了在IPsec中使用，ICV被截断为96位。[RFC4494]包括测试数据。
Requirement levels for AES-CMAC:
AES-CMAC的要求级别：
IKEv1 - undefined (no IANA #)
IKEv2 - optional
IPsec-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
IPsec-v3 - optional
IKEv1 - undefined (no IANA #)
IKEv2 - optional
IPsec-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
IPsec-v3 - optional
5.3.6. RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S, June 2000)
5.3.6. RFC 2857，在ESP和AH中使用HMAC-RIPEMD-160-96（S，2000年6月）
[RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm with a 512-bit blocksize and a 160-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits.
[RFC2857]描述了HMAC-RIPEMD，这是一种完整性保护算法，具有512位块大小和160位密钥和ICV。为了在IPsec中使用，ICV被截断为96位。
Requirement levels for HMAC-RIPEMD:
HMAC-RIPEMD的要求水平：
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no IANA #)
IPsec-v2 - optional
IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no IANA #)
IPsec-v2 - optional
IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
5.3.7. RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec (I, May 2007)
5.3.7. RFC 4894，在Internet密钥交换（IKE）和IPsec中使用哈希算法（2007年5月，I）
In light of recent attacks on MD5 and SHA-1, [RFC4894] examines whether it is necessary to replace the hash functions currently used by IKE and IPsec for key generation, integrity protection, digital signatures, or PKIX certificates. It concludes that the algorithms recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not currently susceptible to any known attacks. Nonetheless, it suggests that implementors add support for AES-XCBC-MAC-96 [RFC3566], AES-XCBC-PRF-128 [RFC4434], and HMAC-SHA-256, -384, and -512 [RFC4868] for future use. It also suggests that IKEv2 implementors add support for PKIX certificates signed with SHA-256, -384, and -512.
根据最近对MD5和SHA-1的攻击，[RFC4894]检查是否有必要替换IKE和IPsec当前用于密钥生成、完整性保护、数字签名或PKIX证书的哈希函数。结论是，建议用于IKEv2[RFC4307]和IPsec-v3[RFC4305]的算法目前不易受到任何已知攻击。尽管如此，它建议实现者添加对AES-XCBC-MAC-96[RFC3566]、AES-XCBC-PRF-128[RFC4434]和HMAC-SHA-256、-384和-512[RFC4868]的支持，以备将来使用。它还建议IKEv2实现者添加对使用SHA-256、-384和-512签名的PKIX证书的支持。
IKEv1 and ESP-v2 use separate algorithms to provide encryption and integrity protection, and IKEv1 can negotiate different combinations of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity protection. [RFC5996] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. When properly designed, these algorithms can provide increased efficiency in both implementation and execution.
IKEv1和ESP-v2使用单独的算法来提供加密和完整性保护，IKEv1可以为不同的SA协商不同的算法组合。在ESP-v3中，引入了一类新的算法，其中单个算法可以同时提供加密和完整性保护。[RFC5996]描述了IKEv2如何协商ESP-v3 SAs中使用的组合模式算法。[RFC5282]将该功能添加到IKEv2中，使IKEv2能够协商并为其自身流量使用组合模式算法。如果设计得当，这些算法可以提高实现和执行的效率。
Although ESP-v2 did not originally include combined mode algorithms, some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. IANA numbers for combined mode algorithms have been added to the IKEv1 registry.
尽管ESP-v2最初不包括组合模式算法，但一些IKEv1实现增加了协商组合模式算法以用于IPsec SAs的能力；这些实现不包括使用组合模式算法保护IKE SA的能力。组合模式算法的IANA编号已添加到IKEv1注册表中。
5.4.1. RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) (S, December 2005)
5.4.1. RFC 4309，使用高级加密标准（AES）CCM模式和IPsec封装安全有效负载（ESP）（S，2005年12月）
[RFC4309] describes how to use AES in counter with CBC-MAC (CCM) mode, a combined algorithm, to encrypt and integrity protect ESP traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a random IV that is sent in the packet along with the encrypted data; a 24-bit salt value (1/SA); keysizes of 128, 192, and 256 bits and ICV sizes of 64, 96 and 128 bits. If AES-CCM is implemented, 128-bit keys are MUST; the other sizes are MAY. ICV sizes of 64 and 128 bits are MUST; 96 bits is MAY. The salt value is generated by IKE during the key-generation process. Reuse of the IV with the same key compromises the data's security; thus, AES-CCM should not be used with manual keying. [RFC4309] includes IANA values that IKE can use to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own IANA value, but IKE negotiations need to specify the keysize. [RFC4309] includes test data. [RFC4309] describes how IKE can negotiate the use of AES-CCM to use in an ESP SA. [RFC5282] extends this to the use of AES-CCM to protect an IKEv2 SA.
[RFC4309]描述了如何在计数器中使用AES和CBC-MAC（CCM）模式（一种组合算法）对ESP通信进行加密和完整性保护。AES-CCM是具有128位块大小的块模式密码；与加密数据一起在分组中发送的随机IV；24位盐值（1/SA）；密钥大小为128、192和256位，ICV大小为64、96和128位。如果实现AES-CCM，则必须使用128位密钥；其他尺寸是5号。必须使用64位和128位的ICV大小；96位是五月。salt值由IKE在密钥生成过程中生成。使用相同密钥重复使用IV会损害数据的安全性；因此，AES-CCM不应与手动键控一起使用。[RFC4309]包括IKE可用于协商ESP-v3 SAs的IANA值。三个ICV长度中的每一个都有自己的IANA值，但IKE协商需要指定密钥大小。[RFC4309]包括测试数据。[RFC4309]描述了IKE如何协商在ESP SA中使用AES-CCM。[RFC5282]将此扩展到使用AES-CCM保护IKEv2 SA。
Requirement levels for AES-CCM:
AES-CCM的要求级别：
IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]
IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]
NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
注意：IPsec-v2 IANA注册表包含AES-CCM的值，但组合模式算法不是IPsec-v2的功能。尽管一些IKEv1/IPsec-v2实现包括此功能（参见第5.4节），但它不是协议的一部分。
5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) (S, June 2005)
5.4.2. RFC 4106，在IPsec封装安全有效载荷（ESP）中使用Galois/计数器模式（GCM）（S，2005年6月）
[RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a combined algorithm, to encrypt and integrity protect ESP traffic. AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV that is sent in the packet along with the encrypted data; a 32-bit salt value (1/SA); keysizes of 128, 192, and 256 bits; and ICV sizes of 64, 96, and 128 bits. If AES-GCM is implemented, 128-bit keys are MUST; the other sizes are MAY. An ICV size of 128 bits is a MUST; 64 and 96 bits are MAY. The salt value is generated by IKE during the key-generation process. Reuse of the IV with the same key compromises the data's security; thus, AES-GCM should not be used with manual keying. [RFC4106] includes IANA values that IKE can use to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own IANA value, but IKE negotiations need to specify the keysize.
[RFC4106]描述了如何在Galois/Counter（GCM）模式下使用AES（一种组合算法）对ESP通信进行加密和完整性保护。AES-GCM是具有128位块大小的块模式密码；与加密数据一起在分组中发送的随机IV；32位salt值（1/SA）；128、192和256位的密钥大小；以及64、96和128位的ICV大小。如果实现AES-GCM，则必须使用128位密钥；其他尺寸是5号。必须具有128位的ICV大小；64位和96位是可以的。salt值由IKE在密钥生成过程中生成。使用相同密钥重复使用IV会损害数据的安全性；因此，AES-GCM不应与手动键控一起使用。[RFC4106]包括IKE可用于协商ESP-v3 SAs的IANA值。三个ICV长度中的每一个都有自己的IANA值，但IKE协商需要指定密钥大小。
[RFC4106] includes test data. [RFC4106] describes how IKE can negotiate the use of AES-GCM to use in an ESP SA. [RFC5282] extends this to the use of AES-GCM to protect an IKEv2 SA.
[RFC4106]包括测试数据。[RFC4106]描述了IKE如何协商在ESP SA中使用AES-GCM。[RFC5282]将此扩展到使用AES-GCM保护IKEv2 SA。
Requirement levels for AES-GCM:
AES-GCM的要求水平：
IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]
IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]
NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
注意：IPsec-v2 IANA注册表包含AES-GCM的值，但组合模式算法不是IPsec-v2的功能。尽管一些IKEv1/IPsec-v2实现包括此功能（参见第5.4节），但它不是协议的一部分。
5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH (S, May 2006)
5.4.3. RFC 4543，在IPsec ESP和AH中使用Galois消息认证码（GMAC）（S，2006年5月）
[RFC4543] is the variant of AES-GCM [RFC4106] that provides integrity protection without encryption. It has two versions: an integrity-protection algorithm for use within AH, and a combined mode algorithm with null encryption for use within ESP. It can use a key of 128-, 192-, or 256-bits; the ICV is always 128 bits, and is not truncated. AES-GMAC uses a nonce, consisting of a 64-bit IV and a 32-bit salt (1/SA). The salt value is generated by IKE during the key generation process. Reuse of the salt value with the same key compromises the data's security; thus, AES-GMAC should not be used with manual keying. For use within AH, each keysize has its own IANA value, so IKE does not have to negotiate the keysize. For use within ESP, there is only one IANA value, so IKE negotiations must specify the keysize. AES-GMAC cannot be used by IKE to protect its own SAs, since IKE traffic requires encryption.
[RFC4543]是AES-GCM[RFC4106]的变体，它在不加密的情况下提供完整性保护。它有两个版本：用于AH的完整性保护算法，以及用于ESP的带空加密的组合模式算法。它可以使用128、192或256位的密钥；ICV始终为128位，并且不会被截断。AES-GMAC使用nonce，由64位IV和32位salt（1/SA）组成。salt值由IKE在密钥生成过程中生成。重复使用具有相同密钥的salt值会损害数据的安全性；因此，AES-GMAC不应与手动键控一起使用。在AH中使用时，每个密钥大小都有自己的IANA值，因此IKE不必协商密钥大小。对于在ESP中使用，只有一个IANA值，因此IKE协商必须指定密钥大小。AES-GMAC不能被IKE用来保护自己的SAs，因为IKE通信需要加密。
Requirement levels for AES-GMAC:
AES-GMAC的要求水平：
IKEv1 - N/A
IKEv2 - N/A
IPsec-v2 - N/A
IPsec-v3 - optional
IKEv1 - N/A
IKEv2 - N/A
IPsec-v2 - N/A
IPsec-v3 - optional
NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
注意：IPsec-v2 IANA注册表包含AES-GMAC的值，但组合模式算法不是IPsec-v2的功能。尽管一些IKEv1/IPsec-v2实现包括此功能（参见第5.4节），但它不是协议的一部分。
5.4.4. RFC 5282, Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol (S, August 2008)
5.4.4. RFC 5282，使用互联网密钥交换版本2（IKEv2）协议加密有效载荷的认证加密算法（S，2008年8月）
[RFC5282] extends [RFC4309] and [RFC4106] to enable the use of AES-CCM and AES-GCM to provide encryption and integrity protection for IKEv2 messages.
[RFC5282]扩展了[RFC4309]和[RFC4106]以支持使用AES-CCM和AES-GCM为IKEv2消息提供加密和完整性保护。
IKE uses pseudorandom functions (PRFs) to generate the secret keys that are used in IKE SAs and IPsec SAs. These PRFs are generally the same algorithms used for integrity protection, but their output is not truncated, since all of the generated bits are generally needed for the keys. If the PRF's output is not long enough to supply the required number of bits of keying material, the PRF is applied iteratively until the requisite amount of keying material is generated.
IKE使用伪随机函数（PRF）生成IKE SAs和IPsec SAs中使用的密钥。这些PRF通常与用于完整性保护的算法相同，但它们的输出不会被截断，因为所有生成的位通常都是密钥所需的。如果PRF的输出长度不足以提供所需数量的键控材料，则重复应用PRF，直到生成所需数量的键控材料。
For each IKEv2 SA, the peers negotiate both a PRF algorithm and an integrity-protection algorithm; the former is used to generate keying material and other values, and the latter is used to provide protection to the IKE SA's traffic.
对于每个IKEv2 SA，对等方协商PRF算法和完整性保护算法；前者用于生成键控材料和其他值，后者用于为IKE SA的流量提供保护。
IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function to generate keying material and to provide integrity protection for the IKE SA. Therefore, PRFs that are not HMACs cannot currently be used in IKEv1.
IKEv1的方法更为复杂。IKEv1[RFC2409]未指定任何PRF算法。对于每个IKEv1 SA，对等方同意使用一个未定义的哈希函数（例如，SHA-1）。IKEv1使用此函数的HMAC版本生成键控材料，并为IKE SA提供完整性保护。因此，目前不能在IKEv1中使用非HMAC的PRF。
Requirement levels for PRF-HMAC-SHA1:
PRF-HMAC-SHA1的要求水平：
IKEv1 - MUST [RFC4109] IKEv2 - MUST [RFC4307]
IKEv1-必须[RFC4109]IKEv2-必须[RFC4307]
Requirement levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512:
PRF-HMAC-SHA-256、PRF-HMAC-SHA-384和PRF-HMAC-SHA-512的要求等级：
IKEv1 - optional [RFC4868] IKEv2 - optional [RFC4868]
IKEv1-可选[RFC4868]IKEv2-可选[RFC4868]
5.5.1. RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) (S, February 2006)
5.5.1. RFC 4434，互联网密钥交换协议（IKE）的AES-XCBC-PRF-128算法（S，2006年2月）
[RFC3566] defines AES-XCBC-MAC-96, which is used for integrity protection within IKE and IPsec. [RFC4434] enables the use of AES-XCBC-MAC as a PRF within IKE. The PRF differs from the integrity-
[RFC3566]定义了AES-XCBC-MAC-96，用于IKE和IPsec内的完整性保护。[RFC4434]支持将AES-XCBC-MAC用作IKE中的PRF。PRF不同于完整性-
protection algorithm in two ways: its 128-bit output is not truncated to 96 bits, and it accepts a variable-length key, which is modified (lengthened via padding or shortened through application of AES-XCBC) to a 128-bit key. [RFC4434] includes test data.
保护算法有两种方式：其128位输出不被截断为96位，并且它接受一个可变长度的密钥，该密钥被修改（通过填充延长或通过应用AES-XCBC缩短）为128位密钥。[RFC4434]包括测试数据。
Requirement levels for AES-XCBC-PRF:
AES-XCBC-PRF的要求等级：
IKEv1 - undefined (no RFC) IKEv2 - SHOULD+ [RFC4307]
IKEv1-未定义（无RFC）IKEv2-应+[RFC4307]
NOTE: RFC 4109 erroneously classifies AES-XCBC-PRF as SHOULD for IKEv1; this has been corrected in an errata submission for RFC 4109.
注：RFC 4109错误地将AES-XCBC-PRF归类为IKEv1的应有类别；这已在RFC 4109的勘误表提交中更正。
5.5.2. RFC 4615, The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudorandom Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) (S, August 2006)
5.5.2. RFC 4615，互联网密钥交换协议（IKE）的高级加密标准基于密码的消息认证码伪随机函数-128（AES-CMAC-PRF-128）算法（S，2006年8月）
[RFC4615] extends [RFC4494] to enable the use of AES-CMAC as a PRF within IKEv2, in a manner analogous to that used by [RFC4434] for AES-XCBC.
[RFC4615]扩展了[RFC4494]，以类似于[RFC4434]用于AES-XCBC的方式，允许将AES-CMAC用作IKEv2内的PRF。
Requirement levels for AES-CMAC-PRF:
AES-CMAC-PRF的要求水平：
IKEv1 - undefined (no IANA #) IKEv2 - optional
IKEv1-未定义（无IANA）IKEv2-可选
An IKE negotiation consists of multiple cryptographic attributes, both for the IKE SA and for the IPsec SA. The number of possible combinations can pose a challenge to peers trying to find a common policy. To enhance interoperability, [RFC4308] defines two pre-defined suites, consisting of combinations of algorithms that comprise typical security policies. IKE/ESP suite "VPN-A" includes use of 3DES, HMAC-SHA-1, and 1024-bit modular exponentiation group (MODP) Diffie-Hellman (DH); IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit MODP DH. These suites are intended to be named "single-button" choices in the administrative interface, but do not prevent the use of alternative combinations.
IKE协商由IKE SA和IPsec SA的多个加密属性组成。可能的组合数量可能会对试图找到共同策略的同行构成挑战。为了增强互操作性，[RFC4308]定义了两个预定义的套件，由组成典型安全策略的算法组合组成。IKE/ESP套件“VPN-A”包括使用3DES、HMAC-SHA-1和1024位模幂组（MODP）Diffie-Hellman（DH）；IKE/ESP套件“VPN-B”包括AES-CBC、AES-XCBC-MAC和2048位MODP DH。这些套件旨在在管理界面中命名为“单按钮”选项，但不阻止使用替代组合。
[RFC4869] adds four pre-defined suites, based upon the United States National Security Agency's "Suite B" specifications, to those specified in [RFC4308]. IKE/ESP suites "Suite-B-GCM-128" and "Suite-
[RFC4869]根据美国国家安全局的“套件B”规范，将四个预定义套件添加到[RFC4308]中指定的套件中。IKE/ESP套房“套房-B-GCM-128”和“套房”-
B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or 384-bit elliptic-curve (EC) DH groups. IKE/AH suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include use of AES-CBC, AES-GMAC, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or 384-bit EC DH groups. While [RFC4308] does not specify a peer-authentication method, [RFC4869] mandates pre-shared key authentication for IKEv1; public key authentication using ECDSA is recommended for IKEv1 and required for IKEv2.
B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or 384-bit elliptic-curve (EC) DH groups. IKE/AH suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include use of AES-CBC, AES-GMAC, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or 384-bit EC DH groups. While [RFC4308] does not specify a peer-authentication method, [RFC4869] mandates pre-shared key authentication for IKEv1; public key authentication using ECDSA is recommended for IKEv1 and required for IKEv2.translate error, please retry
IKE negotiations include a Diffie-Hellman exchange, which establishes a shared secret to which both parties contributed. This value is used to generate keying material to protect both the IKE SA and the IPsec SA.
IKE谈判包括Diffie-Hellman交换，该交换建立了双方共同分享的秘密。该值用于生成密钥材料，以保护IKE SA和IPsec SA。
IKEv1 [RFC2409] contains definitions of two DH MODP groups and two elliptic curve (EC) groups; IKEv2 [RFC5996] only references the MODP groups. The requirements levels of these groups are:
IKEv1[RFC2409]包含两个DH MODP群和两个椭圆曲线（EC）群的定义；IKEv2[RFC5996]仅引用MODP组。这些群体的需求水平如下：
Requirement levels for DH MODP group 1:
DH MODP第1组的需求水平：
IKEv1 - MAY [RFC4109] IKEv2 - optional
IKEv1-可能[RFC4109]IKEv2-可选
Requirement levels for DH MODP group 2:
DH MODP第2组的需求水平：
IKEv1 - MUST [RFC4109] IKEv2 - MUST- [RFC4307]
IKEv1-必须[RFC4109]IKEv2-必须-[RFC4307]
Requirement levels for EC groups 3-4:
EC第3-4组的要求水平：
IKEv1 - MAY [RFC4109] IKEv2 - undefined (no IANA #)
IKEv1-可能[RFC4109]IKEv2-未定义（无IANA）
5.7.1. RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) (S, May 2003)
5.7.1. RFC 3526，因特网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman组（S，2003年5月）
[RFC2409] and [RFC5996] define two MODP DH groups (groups 1 and 2) for use within IKE. [RFC3526] adds six more groups (groups 5 and 14-18). Group 14 is a 2048-bit group that is strongly recommended for use in IKE.
[RFC2409]和[RFC5996]定义了用于IKE的两个MODP DH组（组1和组2）。[RFC3526]又添加了六个组（组5和14-18）。组14是一个2048位的组，强烈建议在IKE中使用。
Requirement levels for DH MODP group 14:
DH MODP第14组的需求水平：
IKEv1 - SHOULD [RFC4109] IKEv2 - SHOULD+ [RFC4307]
IKEv1-SHOULD[RFC4109]IKEv2-SHOULD+[RFC4307]
Requirement levels for DH MODP groups 5, 15-18:
DH MODP第5、15-18组的需求水平：
IKEv1 - optional [RFC4109] IKEv2 - optional
IKEv1-可选[RFC4109]IKEv2-可选
[RFC4753] defines three EC DH groups (groups 19-21) for use within IKE.
[RFC4753]定义了三个EC DH组（组19-21）用于IKE。
The document includes test data.
该文件包括测试数据。
Requirement levels for DH EC groups 19-21:
DH EC第19-21组的需求水平：
IKEv1 - optional [RFC4109] IKEv2 - optional
IKEv1-可选[RFC4109]IKEv2-可选
5.7.3. RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 (I, June 2010)
5.7.3. RFC 5903，IKE和IKEv2的模素数的椭圆曲线群（ECP群）（I，2010年6月）
[RFC5903] obsoletes [RFC4753], fixing an inconsistency in the DH shared secret value.
[RFC5903]淘汰[RFC4753]，修复DH共享机密值中的不一致性。
5.7.4. RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards (I, January 2008)
5.7.4. RFC 5114，用于IETF标准的其他Diffie-Hellman组（I，2008年1月）
[RFC5114] defines five additional DH groups (MODP groups 22-24 and EC groups 25-26) for use in IKE. It also includes three EC DH groups (groups 19-21) that were originally defined in [RFC4753]; however, the current specification for these groups is [RFC5903]. The IANA group numbers are specific to IKE, but the DH groups are intended for use in multiple IETF protocols, including Transport Layer Security/Secure Socket Layer (TLS/SSL), Secure/Multipurpose Internet Mail Extensions (S/MIME), and X.509 Certificates.
[RFC5114]定义了用于IKE的五个附加DH组（MODP组22-24和EC组25-26）。它还包括最初在[RFC4753]中定义的三个EC DH组（组19-21）；但是，这些组的当前规范为[RFC5903]。IANA组编号特定于IKE，但DH组用于多种IETF协议，包括传输层安全/安全套接字层（TLS/SSL）、安全/多用途Internet邮件扩展（S/MIME）和X.509证书。
Requirement levels for DH MODP groups 22-24, EC groups 25-26:
DH MODP组22-24、EC组25-26的需求水平：
IKEv1 - optional IKEv2 - optional
IKEv1-可选IKEv2-可选
[RFC4301] describes IPsec processing for unicast and multicast traffic. However, classical IPsec SAs provide point-to-point protection; the security afforded by IPsec's cryptographic algorithms is not applicable when the SA is one-to-many or many-to-many, the case for multicast. The Multicast Security (msec) Working Group has defined alternatives to IKE and extensions to IPsec for use with
[RFC4301]描述了单播和多播流量的IPsec处理。然而，经典的IPsec SA提供点对点保护；当SA为一对多或多对多（多播）时，IPsec加密算法提供的安全性不适用。多播安全（msec）工作组已经定义了IKE的替代方案和IPsec的扩展，以用于
multicast traffic. Different multicast groups have differing characteristics and requirements: number of senders (one-to-many or many-to-many), number of members (few, moderate, very large), volatility of membership, real-time delivery, etc. Their security requirements vary as well. Each solution defined by msec applies to a subset of the large variety of possible multicast groups.
多播通信。不同的多播组具有不同的特征和要求：发送者的数量（一对多或多对多）、成员的数量（少数、中等、非常大）、成员的波动性、实时交付等。它们的安全要求也不同。msec定义的每个解决方案都适用于各种可能的多播组的子集。
6.1. RFC 3740, The Multicast Group Security Architecture (I, March 2004)
6.1. RFC 3740，多播组安全体系结构（I，2004年3月）
[RFC3740] defines the multicast security architecture, which is used to provide security for packets exchanged by large multicast groups. It defines the components of the architectural framework; discusses Group Security Associations (GSAs), key management, data handling, and security policies. Several existing protocols, including Group DOI (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], and Multimedia Internet KEYing (MIKEY) [RFC3830], satisfy the group key management requirements defined in this document. Both the architecture and the components for Multicast Group Security differ from IPsec.
[RFC3740]定义了多播安全架构，该架构用于为大型多播组交换的数据包提供安全性。它定义了架构框架的组件；讨论组安全关联（GSA）、密钥管理、数据处理和安全策略。一些现有协议，包括组DOI（GDOI）[RFC3547]、组安全关联密钥管理协议（GSAKMP）[RFC4535]和多媒体互联网密钥（MIKEY）[RFC3830]满足本文档中定义的组密钥管理要求。多播组安全的体系结构和组件都不同于IPsec。
6.2. RFC 5374, Multicast Extensions to the Security Architecture for the Internet Protocol (S, November 2008)
6.2. RFC 5374，互联网协议安全架构的多播扩展（S，2008年11月）
[RFC5374] extends the security architecture defined in [RFC4301] to apply to multicast traffic. It defines a new class of SAs (GSAs - Group Security Associations) and additional databases used to apply IPsec protection to multicast traffic. It also describes revisions and additions to the processing algorithms in [RFC4301].
[RFC5374]扩展了[RFC4301]中定义的安全体系结构，以应用于多播通信。它定义了一类新的SA（GSAs-组安全关联）和用于对多播通信应用IPsec保护的其他数据库。它还描述了对[RFC4301]中处理算法的修订和添加。
GDOI [RFC3547] extends IKEv1 so that it can be used to establish SAs to protect multicast traffic. This document defines additional exchanges and payloads to be used for that purpose.
GDOI[RFC3547]扩展了IKEv1，因此可以使用它来建立SA以保护多播流量。本文件定义了用于该目的的额外交换和有效载荷。
6.4. RFC 4046, Multicast Security (MSEC) Group Key Management Architecture (I, April 2005)
6.4. RFC 4046，多播安全（MSEC）组密钥管理体系结构（I，2005年4月）
[RFC4046] sets out the general requirements and design principles for protocols that are used for multicast key management. It does not go into the specifics of an individual protocol that can be used for that purpose.
[RFC4046]规定了用于多播密钥管理的协议的一般要求和设计原则。它不涉及可用于该目的的单个协议的细节。
6.5. RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, January 2006)
6.5. RFC 4359，《在封装安全有效载荷（ESP）和身份验证头（AH）中使用RSA/SHA-1签名》（S，2006年1月）
[RFC4359] describes the use of the RSA digital signature algorithm to provide integrity protection for multicast traffic within ESP and AH. The algorithms used for integrity protection for unicast traffic (e.g., HMAC) are not suitable for this purpose when used with multicast traffic.
[RFC4359]介绍了如何使用RSA数字签名算法为ESP和AH中的多播通信提供完整性保护。用于单播流量（例如，HMAC）完整性保护的算法在用于多播流量时不适用于此目的。
Operational experience with IPsec revealed additional capabilities that could make IPsec more useful in real-world scenarios. These include support for IPsec policy mechanisms, IPsec MIBs, payload compression (IPComp), extensions to facilitate additional peer authentication methods (Better-Than-Nothing Security (BTNS), Kerberized Internet Negotiation of Keys (KINK), and IPSECKEY), and additional capabilities for VPN clients (IPSRA).
IPsec的运行经验表明，额外的功能可以使IPsec在实际场景中更有用。其中包括支持IPsec策略机制、IPsec MIB、有效负载压缩（IPComp）、扩展以促进其他对等身份验证方法（比没有更好的安全性（BTN）、Kerberized Internet密钥协商（KINK）和IPSECKEY），以及VPN客户端的附加功能（IPSRA）。
The IPsec Policy (ipsp) Working Group originally planned an RFC that would allow entities with no common Trust Anchor and no prior knowledge of each other's security policies to establish an IPsec-protected connection. The solutions that were proposed for gateway discovery and security policy negotiation proved to be overly complex and fragile, in the absence of prior knowledge or compatible configuration policies.
IPsec策略（ipsp）工作组最初计划了一个RFC，该RFC允许没有公共信任锚点且事先不了解彼此安全策略的实体建立受IPsec保护的连接。在缺乏先验知识或兼容的配置策略的情况下，为网关发现和安全策略协商提出的解决方案被证明过于复杂和脆弱。
7.1.1. RFC 3586, IP Security Policy (IPSP) Requirements (S, August 2003)
7.1.1. RFC 3586，IP安全策略（IPSP）要求（S，2003年8月）
[RFC3586] describes the functional requirements of a generalized IPsec policy framework, that could be used to discover, negotiate, and manage IPsec policies.
[RFC3586]描述了通用IPsec策略框架的功能需求，该框架可用于发现、协商和管理IPsec策略。
7.1.2. RFC 3585, IPsec Configuration Policy Information Model (S, August 2003)
7.1.2. RFC 3585，IPsec配置策略信息模型（S，2003年8月）
As stated in [RFC3585]:
如[RFC3585]所述：
This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints.
本文档介绍了一种面向对象的IP安全（IPsec）策略信息模型，旨在促进IPsec策略的内容和语义的一致性，并支持派生IPsec策略的任务特定表示，如存储模式、分发表示，以及用于配置启用IPsec的端点的策略规范语言。
This RFC has not been widely adopted.
这种RFC尚未被广泛采用。
Over the years, several MIB-related Internet Drafts were proposed for IPsec and IKE, but only one progressed to RFC status.
多年来，为IPsec和IKE提出了几个与MIB相关的Internet草案，但只有一个发展到RFC状态。
7.2.1. RFC 4807, IPsec Security Policy Database Configuration MIB (S, March 2007)
7.2.1. RFC 4807，IPsec安全策略数据库配置MIB（S，2007年3月）
[RFC4807] defines a MIB module that can be used to configure the SPD of an IPsec device. This RFC has not been widely adopted.
[RFC4807]定义可用于配置IPsec设备的SPD的MIB模块。这种RFC尚未被广泛采用。
The IP Payload Compression Protocol (IPComp) is a protocol that provides lossless compression for IP datagrams. Although IKE can be used to negotiate the use of IPComp in conjunction with IPsec, IPComp can also be used when IPsec is not applied.
IP有效负载压缩协议（IPComp）是一种为IP数据报提供无损压缩的协议。尽管IKE可用于协商IPComp与IPsec的联合使用，但IPComp也可在未应用IPsec时使用。
The IPComp protocol allows the compression of IP datagrams by supporting different compression algorithms. Three of these algorithms are: DEFLATE [RFC2394], LZS [RFC2395], and the ITU-T V.44 Packet Method [RFC3051], which is based on the LZJH algorithm.
IPComp协议允许通过支持不同的压缩算法来压缩IP数据报。其中三种算法是：DEFLATE[RFC2394]、LZS[RFC2395]和基于LZJH算法的ITU-T V.44数据包方法[RFC3051]。
7.3.1. RFC 3173, IP Payload Compression Protocol (IPComp) (S, September 2001)
7.3.1. RFC3173，IP有效载荷压缩协议（IPComp）（S，2001年9月）
IP payload compression is especially useful when IPsec-based encryption is applied to IP datagrams. Encrypting the IP datagram causes the data to be random in nature, rendering compression at lower protocol layers ineffective. If IKE is used to negotiate compression in conjunction with IPsec, compression can be performed prior to encryption. [RFC3173] defines the payload compression protocol, the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA.
当基于IPsec的加密应用于IP数据报时，IP有效负载压缩特别有用。加密IP数据报会导致数据本质上是随机的，从而导致较低协议层的压缩无效。如果IKE与IPsec一起用于协商压缩，则可以在加密之前执行压缩。[RFC3173]定义了有效负载压缩协议、IPComp数据包结构、IPComp关联（IPCA）以及协商IPCA的几种方法。
One of the major obstacles to widespread implementation of IPsec is the lack of pre-existing credentials that can be used for peer authentication. Better-Than-Nothing Security (BTNS) is an attempt to sidestep this problem by allowing IKE to negotiate unauthenticated (anonymous) IPsec SAs, using credentials such as self-signed certificates or "bare" public keys (public keys that are not connected to a public key certificate) for peer authentication. This ensures that subsequent traffic protected by the SA is conducted with
IPsec广泛实施的主要障碍之一是缺乏可用于对等身份验证的现有凭据。Better that Nothing Security（BTN）是通过允许IKE协商未经身份验证（匿名）的IPsec SA，使用自签名证书或“裸”公钥（未连接到公钥证书的公钥）等凭据进行对等身份验证，从而试图回避此问题。这可确保SA保护的后续通信以
the same peer, and protects the communications from passive attack. These SAs can then be cryptographically bound to a higher-level application protocol, which performs its own peer authentication.
相同的对等方，并保护通信免受被动攻击。然后，可以将这些SA以加密方式绑定到更高级别的应用程序协议，该协议执行自己的对等身份验证。
[RFC5660] specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create channels by latching connections (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.
[RFC5660]抽象地指定了如何将应用程序和传输协议与IPsec连接起来，以便通过在连接的生命周期内锁定到特定IPsec安全关联（SA）参数的连接（数据包流）来创建通道。连接锁存是在IPsec之上分层的，不会修改底层IPsec体系结构。
7.4.2. RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec (S, November 2008)
7.4.2. RFC 5386，《比没有更好的安全性：未经验证的IPsec模式》（S，2008年11月）
[RFC5386] specifies how to use IKEv2 to set up unauthenticated security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). This document does not require any changes to the bits on the wire, but specifies extensions to the Peer Authorization Database (PAD) and Security Policy Database (SPD).
[RFC5386]指定如何使用IKEv2设置未经身份验证的安全关联（SA），以便与IPsec封装安全负载（ESP）和IPsec身份验证标头（AH）一起使用。本文档不需要对线路上的位进行任何更改，但指定了对等授权数据库（PAD）和安全策略数据库（SPD）的扩展。
7.4.3. RFC 5387, Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) (I, November 2008)
7.4.3. RFC 5387，《比没有更好的安全性（BTNS）的问题和适用性声明》（I，2008年11月）
[RFC5387] considers that the need to deploy authentication information and its associated identities is a significant obstacle to the use of IPsec. This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication.
[RFC5387]认为需要部署身份验证信息及其相关标识是使用IPsec的一个重大障碍。本文档解释了扩展Internet网络安全协议套件的基本原理，以便在不进行身份验证的情况下使用IPsec安全服务。
Kerberized Internet Negotiation of Keys (KINK) is an attempt to provide an alternative to IKE for IPsec peer authentication. It uses Kerberos, instead of IKE, to establish IPsec SAs. For enterprises that already deploy the Kerberos centralized key management system, IPsec can then be implemented without the need for additional peer credentials. Some vendors have implemented proprietary extensions for using Kerberos in IKEv1, as an alternative to the use of KINK. These extensions, as well as the KINK protocol, apply only to IKEv1, and not to IKEv2.
Kerberized Internet密钥协商（KINK）试图为IPsec对等身份验证提供IKE的替代方案。它使用Kerberos而不是IKE来建立IPsec SAs。对于已经部署Kerberos集中式密钥管理系统的企业，可以在不需要其他对等凭据的情况下实现IPsec。一些供应商已经实现了在IKEv1中使用Kerberos的专有扩展，以替代KINK的使用。这些扩展以及扭结协议仅适用于IKEv1，而不适用于IKEv2。
7.5.1. RFC 3129, Requirements for Kerberized Internet Negotiation of Keys (I, June 2001)
7.5.1. RFC 3129，密钥的Kerberized Internet协商要求（I，2001年6月）
[RFC3129] considers that peer-to-peer authentication and keying mechanisms have inherent drawbacks such as computational complexity and difficulty in enforcing security policies. This document specifies the requirements for using basic features of Kerberos and uses them to its advantage to create a protocol that can establish and maintain IPsec security associations ([RFC2401]).
[RFC3129]认为对等身份验证和密钥机制具有固有的缺陷，例如计算复杂性和执行安全策略的困难。本文档指定了使用Kerberos基本功能的要求，并利用这些功能创建了一个可以建立和维护IPsec安全关联的协议（[RFC2401]）。
7.5.2. RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S, March 2006)
7.5.2. RFC 4430，密钥的Kerberized Internet协商（扭结）（S，2006年3月）
[RFC4430] defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. This document reuses the Quick Mode payloads of IKEv1 in order to foster substantial reuse of IKEv1 implementations. This RFC has not been widely adopted.
[RFC4430]定义了一个低延迟、计算成本低、易于管理、加密可靠的协议，以使用Kerberos身份验证系统建立和维护安全关联。本文档重用了IKEv1的快速模式有效负载，以促进IKEv1实现的实质性重用。这种RFC尚未被广泛采用。
IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec protection to "road warriors", allowing IKE to authenticate not only the user's device but also the user, without changing IKEv1. The working group defined generic requirements of different IPsec remote access scenarios. An attempt was made to define an IKE-like protocol that would use legacy authentication mechanisms to create a temporary or short-lived user credential that could be used for peer authentication within IKE. This protocol proved to be more cumbersome than standard Public Key protocols, and was abandoned. This led to the development of IKEv2, which incorporates the use of EAP for user authentication.
IPsec安全远程访问（IPSRA）试图将IPsec保护扩展到“道路勇士”，允许IKE不仅对用户的设备进行身份验证，而且对用户进行身份验证，而无需更改IKEv1。工作组定义了不同IPsec远程访问场景的一般要求。试图定义一个类似IKE的协议，该协议将使用遗留身份验证机制创建一个临时或短期用户凭证，该凭证可用于IKE内的对等身份验证。该协议被证明比标准公钥协议更麻烦，因此被放弃。这导致了IKEv2的开发，它将EAP用于用户身份验证。
7.6.1. RFC 3457, Requirements for IPsec Remote Access Scenarios (I, January 2003)
7.6.1. RFC 3457，IPsec远程访问场景的要求（I，2003年1月）
[RFC3457] explores and enumerates the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them.
[RFC3457]探讨并列举了各种IPsec远程访问场景的要求，但没有为它们提出特定的解决方案。
7.6.2. RFC 3456, Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode (S, January 2003)
7.6.2. RFC 3456，IPsec隧道模式的动态主机配置协议（DHCPv4）配置（S，2003年1月）
[RFC3456] explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be used for providing such configuration information. This RFC has not been widely adopted.
[RFC3456]探讨了IPsec隧道模式下的主机配置要求，并描述了如何使用动态主机配置协议（DHCPv4）来提供此类配置信息。这种RFC尚未被广泛采用。
The IPsec Keying Information Resource Record (IPSECKEY) enables the storage of public keys and other information that can be used to facilitate opportunistic IPsec in a new type of DNS resource record.
IPsec密钥信息资源记录（IPSECKEY）支持在新型DNS资源记录中存储公钥和其他信息，这些信息可用于促进机会主义IPsec。
7.7.1. RFC 4025, A method for storing IPsec keying material in DNS (S, February 2005)
7.7.1. RFC 4025，在DNS中存储IPsec密钥材料的方法（S，2005年2月）
[RFC4025] describes a method of storing IPsec keying material in the DNS using a new type of resource record. This document describes how to store the public key of the target node in this resource record. This RFC has not been widely adopted.
[RFC4025]描述了使用新型资源记录在DNS中存储IPsec密钥材料的方法。本文档描述如何在此资源记录中存储目标节点的公钥。这种RFC尚未被广泛采用。
IPsec and IKE were designed to provide IP-layer security protection to other Internet protocols' traffic as well as generic communications. Since IPsec is a general-purpose protocol, in some cases, its features do not provide the granularity or distinctive features required by another protocol; in some cases, its overhead or prerequisites do not match another protocol's requirements. However, a number of other protocols do use IKE and/or IPsec to protect some or all of their communications.
IPsec和IKE旨在为其他Internet协议的流量以及通用通信提供IP层安全保护。由于IPsec是一种通用协议，在某些情况下，其特性不提供另一协议所需的粒度或独特特性；在某些情况下，其开销或先决条件与另一个协议的要求不匹配。然而，许多其他协议确实使用IKE和/或IPsec来保护其部分或全部通信。
8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways (I, August 2005)
8.1.1. RFC 4093，问题陈述：虚拟专用网络（VPN）网关的移动IPv4穿越（I，2005年8月）
[RFC4093] describes the issues with deploying Mobile IPv4 across virtual private networks (VPNs). IPsec is one of the VPN technologies covered by this document. It identifies and describes practical deployment scenarios for Mobile IPv4 running alongside IPsec in enterprise and operator environments. It also specifies a set of framework guidelines to evaluate proposed solutions for supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN gateways.
[RFC4093]介绍了跨虚拟专用网络（VPN）部署移动IPv4的问题。IPsec是本文档介绍的VPN技术之一。它确定并描述了在企业和运营商环境中与IPsec一起运行的移动IPv4的实际部署场景。它还指定了一组框架指南，用于评估支持跨基于IPsec的VPN网关的多供应商无缝IPv4移动的建议解决方案。
8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways (S, June 2008)
8.1.2. RFC 5265，跨基于IPsec的VPN网关的移动IPv4穿越（S，2008年6月）
[RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec to provide session mobility between enterprise intranets and external networks. The proposed solution minimizes changes to existing firewall/VPN/DMZ deployments and does not require any changes to IPsec or key exchange protocols. It also proposes a mechanism to minimize IPsec renegotiation when the mobile node moves.
[RFC5265]介绍了一种基本解决方案，该解决方案使用移动IPv4和IPsec在企业内部网和外部网络之间提供会话移动。建议的解决方案最大限度地减少了对现有防火墙/VPN/DMZ部署的更改，并且不需要对IPsec或密钥交换协议进行任何更改。它还提出了一种在移动节点移动时最小化IPsec重新协商的机制。
8.1.3. RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents (S, June 2004)
8.1.3. RFC 3776，使用IPsec保护移动节点和归属代理之间的移动IPv6信令（S，2004年6月）
This document specifies the use of IPsec in securing Mobile IPv6 traffic between mobile nodes and home agents. It specifies the required wire formats for the protected packets and illustrates examples of Security Policy Database and Security Association Database entries that can be used to protect Mobile IPv6 signaling messages. It also describes how to configure either manually keyed IPsec security associations or IKEv1 to establish the SAs automatically. Mobile IPv6 requires considering the home address destination option and Routing Header in IPsec processing. Also, IPsec and IKE security association addresses can be updated by Mobile IPv6 signaling messages.
本文档指定了IPsec在保护移动节点和归属代理之间的移动IPv6流量方面的使用。它指定了受保护数据包所需的有线格式，并举例说明了可用于保护移动IPv6信令消息的安全策略数据库和安全关联数据库条目的示例。它还描述了如何配置手动键控IPsec安全关联或IKEv1以自动建立SAs。移动IPv6要求在IPsec处理中考虑家庭地址目标选项和路由头。此外，可以通过移动IPv6信令消息更新IPsec和IKE安全关联地址。
8.1.4. RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (S, April 2007)
8.1.4. RFC 4877，使用IKEv2的移动IPv6操作和修订的IPsec体系结构（S，2007年4月）
This document updates [RFC3776] in order to work with the revised IPsec architecture [RFC4301]. Since the revised IPsec architecture expands the list of selectors to include the Mobility Header message type, it becomes much easier to differentiate between different mobility header messages. Since the ICMP message type and code are also newly added as selectors, this document uses them to protect Mobile Prefix Discovery messages. This document also specifies the use of IKEv2 configuration payloads for dynamic home address configuration. Finally, this document describes the use of IKEv2 in order to set up the SAs for Mobile IPv6.
本文档对[RFC3776]进行了更新，以便使用修订后的IPsec体系结构[RFC4301]。由于修改后的IPsec体系结构扩展了选择器列表以包括移动报头消息类型，因此区分不同的移动报头消息变得更加容易。由于ICMP消息类型和代码也是新添加的选择器，因此本文档使用它们来保护移动前缀发现消息。本文档还规定了动态家庭地址配置的IKEv2配置有效负载的使用。最后，本文档描述了使用IKEv2为移动IPv6设置SAs。
8.1.5. RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, October 2007)
8.1.5. RFC 5026，拆分场景中的移动IPv6引导（S，2007年10月）
[RFC5026] extends [RFC4877] to support dynamic discovery of home agents and the home network prefix; for the latter purpose, it specifies a new IKEv2 configuration attribute and notification. It describes how a Mobile IPv6 node can obtain the address of its home agent, its home address, and create IPsec security associations with its home agent using DNS lookups and security credentials preconfigured on the Mobile Node. It defines how a mobile node (MN) can request its home address and home prefixes through the Configuration Payload in the IKE_AUTH exchange and what attributes need to be present in the CFG_REQUEST messages in order to do this. It also specifies how the home agent can authorize the credentials used for IKEv2 exchange.
[RFC5026]扩展了[RFC4877]以支持家庭代理和家庭网络前缀的动态发现；对于后一个目的，它指定了一个新的IKEv2配置属性和通知。它描述了移动IPv6节点如何使用在移动节点上预配置的DNS查找和安全凭据获取其归属代理的地址、归属地址，并创建与其归属代理的IPsec安全关联。它定义了移动节点（MN）如何通过IKE_身份验证交换中的配置有效负载请求其家庭地址和家庭前缀，以及CFG_请求消息中需要显示哪些属性才能做到这一点。它还指定归属代理如何授权用于IKEv2 exchange的凭据。
[RFC5213] describes a network-based mobility management protocol that is used to provide mobility services to hosts without requiring their participation in any mobility-related signaling. It uses IPsec to protect the mobility signaling messages between the two network entities called the mobile access gateway (MAG) and the local mobility anchor (LMA). It also uses IKEv2 in order to set up the security associations between the MAG and the LMA.
[RFC5213]描述了一种基于网络的移动性管理协议，该协议用于向主机提供移动性服务，而无需主机参与任何移动性相关信令。它使用IPsec保护称为移动接入网关（MAG）和本地移动锚（LMA）的两个网络实体之间的移动信令消息。它还使用IKEv2在MAG和LMA之间建立安全关联。
When Mobile IPv6 is used for a handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. [RFC5568] specifies a protocol between the Previous Access Router (PAR) and the New Access Router (NAR) to improve handover latency due to Mobile IPv6 procedures. It uses IPsec ESP in transport mode with integrity protection for protecting the signaling messages between the PAR and the NAR. It also describes the SPD entries and the PAD entries when IKEv2 is used for setting up the required SAs.
当移动IPv6用于切换时，存在一段时间，在此期间，移动节点由于链路切换延迟和IP协议操作而无法发送或接收数据包。[RFC5568]指定先前接入路由器（PAR）和新接入路由器（NAR）之间的协议，以改善移动IPv6过程导致的切换延迟。它使用IPSec ESP在传输模式中进行完整性保护，以保护PAR和NAR之间的信令消息。它还描述了当IKEv2用于设置所需SAs时的SPD条目和PAD条目。
8.1.8. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management (S, October 2008)
8.1.8. RFC 5380，分层移动IPv6（HMIPv6）移动性管理（S，2008年10月）
[RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbor Discovery to allow for local mobility handling in order to reduce the amount of signaling between the mobile node, its correspondent nodes, and its home agent. It also improves handover speed of Mobile IPv6. It uses IPsec for protecting the signaling between the mobile node and a local mobility management entity called the Mobility Anchor Point (MAP). The MAP also uses IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] in order to allocate a Regional Care-of Address (RCoA) for mobile nodes.
[RFC5380]描述了移动IPv6和IPv6邻居发现的扩展，以允许本地移动性处理，从而减少移动节点、其对应节点和其归属代理之间的信令量。它还提高了移动IPv6的切换速度。它使用IPsec来保护移动节点和称为移动锚定点（MAP）的本地移动管理实体之间的信令。MAP还使用[RFC4877]中描述的IPsec对等授权数据库（PAD）条目和配置有效负载，以便为移动节点分配区域转交地址（RCoA）。
8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 (S, June 2006)
8.2.1. RFC 4552，《OSPFv3的认证/保密》（S，2006年6月）
OSPF is a link-state routing protocol that is designed to be run inside a single Autonomous System. OSPFv2 provided its own authentication mechanisms using the AuType and Authentication protocol header fields but OSPFv3 removed these fields and uses IPsec instead. [RFC4552] describes how to use IPsec ESP and AH in order to protect OSPFv3 signaling between two routers. It also enumerates the IPsec capabilities the routers require in order to support this specification. Finally, it also describes the operation of OSPFv3
OSPF是一种链路状态路由协议，设计用于在单个自治系统内运行。OSPFv2使用AuType和authentication protocol头字段提供了自己的身份验证机制，但OSPFv3删除了这些字段，而是使用IPsec。[RFC4552]描述了如何使用IPsec ESP和AH来保护两个路由器之间的OSPFv3信令。它还列举了路由器支持此规范所需的IPsec功能。最后，还描述了OSPFv3的操作
with IPsec over virtual links where the other endpoint is not known at configuration time. Since OSPFv3 exchanges multicast packets as well as unicast ones, the use of IKE within OSPFv3 is not appropriate. Therefore, this document mandates the use of manual keys.
通过虚拟链路使用IPsec，其中另一个端点在配置时未知。由于OSPFv3交换多播数据包以及单播数据包，因此在OSPFv3中使用IKE是不合适的。因此，本文件要求使用手动钥匙。
IP addresses perform two distinct functions: host identifier and locator. This document specifies a protocol that allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses. This enables continuity of communications across IP address (locator) changes. It uses public key identifiers from a new Host Identity (HI) namespace for peer authentication. It uses the HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for protecting its signaling messages.
IP地址执行两个不同的功能：主机标识符和定位器。本文档指定了一个协议，允许同意的主机安全地建立和维护共享IP层状态，允许IP地址的标识符和定位器角色分离。这使得跨IP地址（定位器）更改的通信保持连续性。它使用来自新主机标识（HI）命名空间的公钥标识符进行对等身份验证。它使用HMAC-SHA-1-96和AES-CBC算法以及IPsec ESP和AH来保护其信令消息。
8.3.2. RFC 5202, Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (E, April 2008)
8.3.2. RFC 5202，使用主机标识协议（HIP）的封装安全有效负载（ESP）传输格式（E，2008年4月）
The HIP base exchange specification [RFC5201] does not describe any transport formats or methods for describing how ESP is used to protect user data to be used during the actual communication. [RFC5202] specifies a set of HIP extensions for creating a pair of ESP Security Associations (SAs) between the hosts during the base exchange. After the HIP association and required ESP SAs have been established between the hosts, the user data communication is protected using ESP. In addition, this document specifies how the ESP Security Parameter Index (SPI) is used to indicate the right host context (host identity) and methods to update an existing ESP Security Association.
HIP base exchange规范[RFC5201]未描述任何传输格式或方法，用于描述如何使用ESP保护实际通信期间使用的用户数据。[RFC5202]指定一组HIP扩展，用于在基本交换期间在主机之间创建一对ESP安全关联（SA）。在主机之间建立HIP关联和所需的ESP SA后，用户数据通信将使用ESP进行保护。此外，本文档规定了如何使用ESP安全参数索引（SPI）来指示正确的主机上下文（主机标识）和更新现有ESP安全关联的方法。
8.3.3. RFC 5206, End-Host Mobility and Multihoming with the Host Identity (E, April 2008)
8.3.3. RFC 5206，终端主机移动性和具有主机标识的多宿（E，2008年4月）
When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets) and Encapsulating Security Payload (ESP) Security Associations (SAs) are bound to representations of these host identities, and the IP addresses are only used for packet forwarding. [RFC5206] defines a generalized LOCATOR parameter for use in HIP messages that allows a HIP host to notify a peer about alternate addresses at which it is reachable. It also specifies how a host can change its IP address and continue to send packets to its peers without necessarily rekeying.
当主机使用HIP时，覆盖的协议子层（例如，传输层套接字）和封装安全有效负载（ESP）安全关联（SA）绑定到这些主机标识的表示，并且IP地址仅用于数据包转发。[RFC5206]定义一个通用定位器参数，用于HIP消息中，该参数允许HIP主机通知对等方其可访问的备用地址。它还指定主机如何更改其IP地址并继续向其对等方发送数据包，而无需重新设置密钥。
8.3.4. RFC 5207, NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) (I, April 2008)
8.3.4. RFC 5207，主机标识协议（HIP）的NAT和防火墙穿越问题（I，2008年4月）
[RFC5207] discusses the problems associated with HIP communication across network paths that include network address translators and firewalls. It analyzes the impact of NATs and firewalls on the HIP base exchange and the ESP data exchange. It discusses possible changes to HIP that attempt to improve NAT and firewall traversal and proposes a rendezvous point for letting HIP nodes behind a NAT be reachable. It also suggests mechanisms for NATs to be more aware of the HIP messages.
[RFC5207]讨论与跨网络路径（包括网络地址转换器和防火墙）的HIP通信相关的问题。分析了NAT和防火墙对HIP-base交换和ESP数据交换的影响。它讨论了HIP的可能变化，试图改进NAT和防火墙穿越，并提出了一个让NAT后面的HIP节点可以到达的集合点。它还提出了NAT更了解HIP消息的机制。
8.4.1. RFC 3554, On the Use of Stream Control Transmission Protocol (SCTP) with IPsec (S, July 2003)
8.4.1. RFC 3554，关于流控制传输协议（SCTP）与IPsec的使用（S，2003年7月）
The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connection-less packet network such as IP. [RFC3554] describes functional requirements for IPsec and IKE to be used in securing SCTP traffic. It adds support for SCTP in the form of a new ID type in IKE [RFC2409] and implementation choices in the IPsec processing to account for the multiple source and destination addresses associated with a single SCTP association. This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 AND IPsec-v3.
流控制传输协议（SCTP）是一种可靠的传输协议，在IP等无连接分组网络上运行。[RFC3554]描述了用于保护SCTP流量的IPsec和IKE的功能要求。它以IKE[RFC2409]中的新ID类型和IPsec处理中的实现选项的形式添加了对SCTP的支持，以说明与单个SCTP关联关联的多个源地址和目标地址。本文件仅适用于IKEv1和IPsec-v2；它不适用于IKEv2和IPsec-v3。
8.5.1. RFC 3095, RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed (S, July 2001)
8.5.1. RFC3095，健壮的头压缩（ROHC）：框架和四个配置文件：RTP、UDP、ESP和未压缩（S，2001年7月）
ROHC is a framework for header compression, intended to be used in resource-constrained environments. [RFC3095] applies this framework to four protocols, including ESP.
ROHC是一个用于头压缩的框架，旨在用于资源受限的环境中。[RFC3095]将此框架应用于四个协议，包括ESP。
8.5.2. RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)
8.5.2. RFC 5225，健壮的头压缩版本2（ROHCv2）：RTP、UDP、IP、ESP和UDP Lite的配置文件（S，2008年4月）
[RFC5225] defines an updated ESP/IP profile for use with ROHC version 2. It analyzes the ESP header and classifies the fields into several classes like static, well-known, irregular, etc., in order to efficiently compress the headers.
[RFC5225]定义用于ROHC版本2的更新ESP/IP配置文件。它分析ESP报头，并将字段分为静态、已知、不规则等几个类，以便有效地压缩报头。
8.5.3. RFC 5856, Integration of Robust Header Compression over IPsec Security Associations (I, May 2010)
8.5.3. RFC 5856，IPsec安全关联上的健壮头压缩集成（I，2010年5月）
[RFC5856] describes a mechanism to compress inner IP headers at the ingress point of IPsec tunnels and to decompress them at the egress point. Since the Robust Header Compression (ROHC) specifications only describe operations on a per-hop basis, this document also specifies extensions to enable ROHC over multiple hops. This document applies only to tunnel mode SAs and does not support transport mode SAs.
[RFC5856]描述了一种在IPsec隧道的入口点压缩内部IP头并在出口点解压的机制。由于鲁棒头压缩（ROHC）规范仅描述每跳的操作，因此本文档还指定了在多跳上启用ROHC的扩展。本文档仅适用于隧道模式SAs，不支持传输模式SAs。
8.5.4. RFC 5857, IKEv2 Extensions to Support Robust Header Compression over IPsec (S, May 2010)
8.5.4. RFC 5857，IKEv2扩展，支持IPsec上的健壮报头压缩（S，2010年5月）
ROHC requires initial configuration at the compressor and decompressor ends. Since ROHC usually operates on a per-hop basis, this configuration information is carried over link-layer protocols such as PPP. Since [RFC5856] operates over multiple hops, a different signaling mechanism is required. [RFC5857] describes how to use IKEv2 in order to dynamically communicate the configuration parameters between the compressor and decompressor.
ROHC要求在压缩机和减压器端部进行初始配置。由于ROHC通常以每跳为基础运行，因此该配置信息通过链路层协议（如PPP）进行传输。由于[RFC5856]在多个跃点上运行，因此需要不同的信令机制。[RFC5857]介绍如何使用IKEv2在压缩机和减压器之间动态通信配置参数。
8.5.5. RFC 5858, IPsec Extensions to Support Robust Header Compression over IPsec (S, May 2010)
8.5.5. RFC 5858，支持IPsec上的健壮头压缩的IPsec扩展（S，2010年5月）
[RFC5856] describes how to use ROHC with IPsec. This is not possible without extensions to IPsec. [RFC5858] describes the extensions needed to IPsec in order to support ROHC. Specifically, it describes extensions needed to the IPsec SPD, SAD, and IPsec processing including ICV computation and integrity verification.
[RFC5856]介绍了如何将ROHC与IPsec一起使用。如果没有对IPsec的扩展，这是不可能的。[RFC5858]描述了IPsec支持ROHC所需的扩展。具体来说，它描述了IPsec SPD、SAD和IPsec处理所需的扩展，包括ICV计算和完整性验证。
8.6.1. RFC 5566, BGP IPsec Tunnel Encapsulation Attribute (S, June 2009)
8.6.1. RFC 5566，BGP IPsec隧道封装属性（S，2009年6月）
[RFC5566] adds an additional BGP Encapsulation Subsequent Address Family Identifier (SAFI), allowing the use of IPsec and, optionally, IKE to protect BGP tunnels. It defines the use of AH and ESP in tunnel mode and the use of AH and ESP in transport mode to protect IP in IP and MPLS-in-IP tunnels. It also defines how public key fingerprints (hashes) are distributed via BGP and used later to authenticate IKEv2 exchange between the tunnel endpoints.
[RFC5566]添加了一个额外的BGP封装后续地址族标识符（SAFI），允许使用IPsec和IKE（可选）来保护BGP隧道。它定义了在隧道模式下使用AH和ESP，以及在传输模式下使用AH和ESP来保护IP隧道中的IP和IP隧道中的MPLS。它还定义了如何通过BGP分发公钥指纹（哈希），并在以后用于验证隧道端点之间的IKEv2交换。
The Benchmarking Methodology WG in the IETF is working on documents that relate to benchmarking IPsec [BMWG-1] [BMWG-2].
IETF中的基准测试方法工作组正在编写与IPsec基准测试相关的文件[BMWG-1][BMWG-2]。
[BMWG-1] defines a set of tests that can be used to measure and report the performance characteristics of IPsec devices. It extends the methodology defined for benchmarking network interconnecting devices to include IPsec gateways and adds further tests that can be used to measure IPsec performance of end-hosts. The document focuses on establishing a performance testing methodology for IPsec devices that support manual keying and IKEv1, but does not cover IKEv2.
[BMWG-1]定义了一组测试，可用于测量和报告IPsec设备的性能特征。它扩展了为基准网络互连设备定义的方法，以包括IPsec网关，并添加了可用于测量终端主机IPsec性能的进一步测试。本文档重点介绍为支持手动键控和IKEv1的IPsec设备建立性能测试方法，但不包括IKEv2。
[BMWG-2] defines the standardized performance testing terminology for IPsec devices that support manual keying and IKEv1. It also describes the benchmark tests that would be used to test the performance of the IPsec devices.
[BMWG-2]定义了支持手动键控和IKEv1的IPsec设备的标准化性能测试术语。它还描述了用于测试IPsec设备性能的基准测试。
8.8.1. RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains (I, October 1999)
8.8.1. RFC 2709，NAT域的带隧道模式IPsec的安全模型（1999年10月，I）
NAT devices provide transparent routing to end-hosts trying to communicate from disparate address realms, by modifying IP and transport headers en route. This makes it difficult for applications to pursue end-to-end application-level security. [RFC2709] describes a security model by which tunnel mode IPsec security can be architected on NAT devices. It defines how NATs administer security policies and SA attributes based on private realm addressing. It also specifies how to operate IKE in such scenarios by specifying an IKE-ALG (Application Level Gateway) that translates policies from private realm addressing into public addressing. Although the model presented here uses terminology from IKEv1, it can be deployed within IKEv1, IKEv2, IPsec-v2, and IPsec-v3. This security model has not been widely adopted
NAT设备通过修改路由中的IP和传输头，向试图从不同地址域进行通信的终端主机提供透明路由。这使得应用程序很难实现端到端应用程序级别的安全性。[RFC2709]描述了一种安全模型，通过该模型可以在NAT设备上构建隧道模式IPsec安全性。它定义了NAT如何基于私有领域寻址管理安全策略和SA属性。它还通过指定将策略从私有领域寻址转换为公共寻址的IKE-ALG（应用程序级网关），指定如何在此类场景中操作IKE。尽管这里介绍的模型使用了IKEv1中的术语，但它可以部署在IKEv1、IKEv2、IPsec-v2和IPsec-v3中。这种安全模式尚未被广泛采用
8.9.1. RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol (SIP) (S, January 2003)
8.9.1. RFC 3329，《会话启动协议（SIP）的安全机制协议》（S，2003年1月）
[RFC3329] describes how a SIP client can select one of the various available SIP security mechanisms. In particular, the method allows secure negotiation to prevent bidding down attacks. It also describes a security mechanism called ipsec-3gpp and its associated parameters (algorithms, protocols, mode, SPIs and ports) as they are used in the 3GPP IP Multimedia Subsystem.
[RFC3329]描述SIP客户端如何选择各种可用的SIP安全机制之一。特别是，该方法允许安全协商，以防止出价下降攻击。它还描述了称为ipsec-3gpp的安全机制及其在3gpp IP多媒体子系统中使用的相关参数（算法、协议、模式、SPI和端口）。
8.10.1. RFC 5570, Common Architecture Label IPv6 Security Option (CALIPSO) (I, July 2009)
8.10.1. RFC 5570，通用体系结构标签IPv6安全选项（CALIPSO）（2009年7月1日）
[RFC5570] describes a mechanism used to encode explicit packet Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS) networks. The method is implemented using an IPv6 hop-by-hop option. This document uses the IPsec Authentication Header (AH) in order to detect any malicious modification of the Sensitivity Label in a packet.
[RFC5570]描述了一种用于在多级安全（MLS）网络中对IPv6数据包上的显式数据包敏感标签进行编码的机制。该方法使用IPv6逐跳选项实现。本文档使用IPsec身份验证头（AH）来检测数据包中敏感度标签的任何恶意修改。
Some protocols protect their traffic through mechanisms other than IPsec, but use IKEv2 as a basis for their key negotiation and key management functionality.
有些协议通过IPsec以外的机制保护其通信量，但使用IKEv2作为密钥协商和密钥管理功能的基础。
9.1.1. RFC 5106, The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method (E, February 2008)
9.1.1. RFC 5106，可扩展认证协议互联网密钥交换协议版本2（EAP-IKEv2）方法（E，2008年2月）
[RFC5106] specifies an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange version 2 (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session-key establishment between an EAP peer and an EAP server. It describes the full EAP-IKEv2 message exchange and the composition of the protocol messages.
[RFC5106]指定基于Internet密钥交换版本2（IKEv2）协议的可扩展身份验证协议（EAP）方法。EAP-IKEv2提供EAP对等方和EAP服务器之间的相互身份验证和会话密钥建立。它描述了完整的EAP-IKEv2消息交换和协议消息的组成。
9.2.1. RFC 4595, Use of IKEv2 in the Fibre Channel Security Association Management Protocol (I, July 2006)
9.2.1. RFC 4595，在光纤通道安全关联管理协议中使用IKEv2（I，2006年7月）
Fibre Channel (FC) is a gigabit-speed network technology used for Storage Area Networking. The Fibre Channel Security Protocols (FC-SP) standard has adapted the IKEv2 protocol [RFC4306] to provide authentication of Fibre Channel entities and setup of security associations. Since IP is transported over Fibre Channel and Fibre Channel is transported over IP, there is the potential for confusion when IKEv2 is used for both IP and FC traffic. [RFC4595] specifies identifiers for IKEv2 over FC in a fashion that ensures that any mistaken usage of IKEv2/FC over IP or IKEv2/IP over FC will result in a negotiation failure due to the absence of an acceptable proposal.
光纤通道（FC）是一种用于存储区域网络的千兆速度网络技术。光纤通道安全协议（FC-SP）标准采用了IKEv2协议[RFC4306]，以提供光纤通道实体的身份验证和安全关联的设置。由于IP是通过光纤通道传输的，而光纤通道是通过IP传输的，因此当IKEv2同时用于IP和FC流量时，可能会出现混淆。[RFC4595]指定IKEv2 over FC的标识符，确保IKEv2/FC over IP或IKEv2/IP over FC的任何错误使用都会由于没有可接受的提案而导致协商失败。
9.3.1. RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, October 2006)
9.3.1. RFC 4705，GigaBeam高速无线链路加密（I，2006年10月）
[RFC4705] describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio-link products and is intended to serve as a guideline for similar wireless product development efforts to include comparable capabilities. It specifies the algorithms that are used to provide confidentiality and integrity protection of both subscriber and management traffic. It also specifies a custom security protocol that runs between two Gigabeam Radio Control Modules (RCMs).
[RFC4705]描述了GigaBeam作为无线链路产品WiFiber（tm）系列的一部分使用的加密和密钥管理，旨在作为类似无线产品开发工作的指南，以包括类似的功能。它指定了用于为订户和管理流量提供机密性和完整性保护的算法。它还指定了在两个Gigabeam无线电控制模块（RCM）之间运行的自定义安全协议。
The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel Montenegro, Sean Turner, Julien Laganier, Grey Daley, Scott Moonen, Richard Graveman, Tero Kivinen, Pasi Eronen, Ran Atkinson, David Black, and Tim Polk for reviewing this document and suggesting changes.
作者要感谢亚龙·谢弗、保罗·霍夫曼、约阿夫·尼尔、拉杰什瓦尔·辛格·詹瓦尔、阿尔弗雷德·霍恩斯、艾尔·莫顿、加布里埃尔·黑山、肖恩·特纳、朱利安·拉加尼尔、格雷·戴利、斯科特·莫宁、理查德·格拉维曼、泰罗·基维宁、帕西·艾隆、拉恩·阿特金森、大卫·布莱克和蒂姆·波尔克对本文件进行了审查并提出了修改建议。
This RFC serves as a review of other documents and introduces no new security considerations itself; however, please see each of the individual documents described herein for security considerations related to each protocol.
本RFC作为对其他文件的审查，本身没有引入新的安全考虑因素；但是，请参阅本文描述的每个单独文档，了解与每个协议相关的安全注意事项。
[BMWG-1] Kaeo, M. and T. Van Herck, "Methodology for Benchmarking IPsec Devices", Work in Progress, July 2009.
[BMWG-1]Kaeo，M.和T.Van Herck，“IPsec设备基准测试方法”，正在进行的工作，2009年7月。
[BMWG-2] Kaeo, M., Van Herck T., and M. Bustos, "Terminology for Benchmarking IPsec Devices", Work in Progress, July 2009.
[BMWG-2]Kaeo，M.，Van Herck T.，和M.Bustos，“IPsec设备基准测试术语”，正在进行的工作，2009年7月。
[IKE-MODE-CFG] Dukes, D. and R. Pereira, "The ISAKMP Configuration Method", Work in Progress, September 2001.
[IKE-MODE-CFG]Dukes，D.和R.Pereira，“ISAKMP配置方法”，正在进行的工作，2001年9月。
[IKE-XAUTH] Beaulieu, S. and R. Pereira, "Extended Authentication within IKE (XAUTH)", Work in Progress, October 2001.
[IKE-XAUTH]Beaulieu，S.和R.Pereira，“IKE（XAUTH）内的扩展身份验证”，正在进行的工作，2001年10月。
[ISAKMP-MODE-CFG] Pereira, R., Anand, S., and B. Patel, "The ISAKKMP Configuration Method", Work in Progress, August 1999.
[ISAKMP-MODE-CFG]Pereira，R.，Anand，S.，和B.Patel，“ISAKMP配置方法”，正在进行的工作，1999年8月。
[ISAKMP-XAUTH] Pereira, R. and S. Beaulieu, "Extended Authentication within ISAKMP/Oakley (XAUTH)", Work in Progress, December 1999.
[ISAKMP-XAUTH]Pereira，R.和S.Beaulieu，“ISAKMP/Oakley（XAUTH）内部的扩展认证”，正在进行的工作，1999年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
[RFC2394]Pereira，R.，“使用DEFLATE的IP有效载荷压缩”，RFC 2394，1998年12月。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[RFC2395]Friend，R.和R.Monsour，“使用LZS的IP有效负载压缩”，RFC 2395，1998年12月。
[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月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.
[RFC2521]Karn，P.和W.Simpson，“ICMP安全故障消息”，RFC 25211999年3月。
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[RFC2709]Srisuresh，P.，“NAT域的隧道模式IPsec安全模型”，RFC 2709，1999年10月。
[RFC2857] Keromytis, A. and N. Provos, "The Use of HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June 2000.
[RFC2857]Keromytis，A.和N.Provos，“HMAC-RIPEMD-160-96在ESP和AH中的使用”，RFC 2857，2000年6月。
[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, January 2001.
[RFC3051]Heath，J.和J.Border，“使用ITU-T V.44数据包方法的IP有效负载压缩”，RFC 3051，2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，2001年7月。
[RFC3129] Thomas, M., "Requirements for Kerberized Internet Negotiation of Keys", RFC 3129, June 2001.
[RFC3129]Thomas，M.“密钥的Kerberized Internet协商要求”，RFC31292001年6月。
[RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[RFC3173]Shacham，A.，Monsour，B.，Pereira，R.，和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 31732001年9月。
[RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
[RFC3329]Arkko，J.，Torvinen，V.，Camarillo，G.，Niemi，A.，和T.Haukka，“会话启动协议（SIP）的安全机制协议”，RFC 33292003年1月。
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456]Patel，B.，Aboba，B.，Kelly，S.，和V.Gupta，“IPsec隧道模式的动态主机配置协议（DHCPv4）配置”，RFC 3456，2003年1月。
[RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", RFC 3457, January 2003.
[RFC3457]Kelly，S.和S.Ramamoorthi，“IPsec远程访问场景的要求”，RFC 3457，2003年1月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3554]Bellovin，S.，Ioannidis，J.，Keromytis，A.，和R.Stewart，“关于流控制传输协议（SCTP）与IPsec的使用”，RFC 3554，2003年7月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003.
[RFC3585]Jason，J.，Rafalow，L.，和E.Vyncke，“IPsec配置策略信息模型”，RFC 3585，2003年8月。
[RFC3586] Blaze, M., Keromytis, A., Richardson, M., and L. Sanchez, "IP Security Policy (IPSP) Requirements", RFC 3586, August 2003.
[RFC3586]Blaze，M.，Keromytis，A.，Richardson，M.，和L.Sanchez，“IP安全策略（IPSP）要求”，RFC 3586，2003年8月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC3706] Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", RFC 3706, February 2004.
[RFC3706]Huang，G.，Beaulieu，S.，和D.Rochefort，“一种基于流量的检测死亡互联网密钥交换（IKE）对等点的方法”，RFC 3706，2004年2月。
[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月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776]Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[RFC3884]Touch，J.，Eggert，L.，和Y.Wang，“使用IPsec传输模式进行动态路由”，RFC 3884，2004年9月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]Richardson，M.，“在DNS中存储IPsec密钥材料的方法”，RFC 4025，2005年3月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046]Baugher，M.，Canetti，R.，Dondeti，L.，和F.Lindholm，“多播安全（MSEC）组密钥管理体系结构”，RFC 4046，2005年4月。
[RFC4093] Adrangi, F., Ed., and H. Levkowetz, Ed., "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005.
[RFC4093]Adrangi，F.，Ed.，和H.Levkowetz，Ed.，“问题陈述：虚拟专用网络（VPN）网关的移动IPv4穿越”，RFC 4093，2005年8月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 1 (IKEv1)", RFC 4109, May 2005.
[RFC4109]Hoffman，P.，“互联网密钥交换算法第1版（IKEv1）”，RFC 4109，2005年5月。
[RFC4196] Lee, H., Yoon, J., Lee, S., and J. Lee, "The SEED Cipher Algorithm and Its Use with IPsec", RFC 4196, October 2005.
[RFC4196]Lee，H.，Yoon，J.，Lee，S.，和J.Lee，“种子密码算法及其在IPsec中的使用”，RFC 41962005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[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月。
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005.
[RFC4304]Kent，S.，“互联网安全关联和密钥管理协议（ISAKMP）IPsec解释域（DOI）的扩展序列号（ESN）附录”，RFC 43042005年12月。
[RFC4305] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[RFC4305]Eastlake 3rd，D.，“封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求”，RFC 4305，2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005.
[RFC4308]Hoffman，P.，“IPsec加密套件”，RFC 4308，2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月。
[RFC4312] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher Algorithm and Its Use With IPsec", RFC 4312, December 2005.
[RFC4312]Kato，A.，Moraii，S.，和M.Kanda，“茶花密码算法及其与IPsec的使用”，RFC 4312，2005年12月。
[RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005.
[RFC4322]Richardson，M.和D.Redelmeier，“使用互联网密钥交换（IKE）的机会主义加密”，RFC 4322，2005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]Weis，B.“在封装安全有效载荷（ESP）和身份验证头（AH）中使用RSA/SHA-1签名”，RFC 4359，2006年1月。
[RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[RFC4430]Sakane，S.，Kamada，K.，Thomas，M.，和J.Vilhuber，“密钥的Kerberized Internet协商（扭结）”，RFC 4430，2006年3月。
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006.
[RFC4434]Hoffman，P.，“互联网密钥交换协议（IKE）的AES-XCBC-PRF-128算法”，RFC 4434，2006年2月。
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4478]Nir，Y，“互联网密钥交换（IKEv2）协议中的重复认证”，RFC 4478，2006年4月。
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 Algorithm and Its Use with IPsec", RFC 4494, June 2006.
[RFC4494]Song，JH.，Poovendran，R.，和J.Lee，“AES-CMAC-96算法及其与IPsec的使用”，RFC 44942006年6月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，RFC 4543，2006年5月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，2006年6月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006.
[RFC4595]Maino，F.和D.Black，“在光纤通道安全关联管理协议中使用IKEv2”，RFC 45952006年7月。
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.
[RFC4615]Song，J.，Poovendran，R.，Lee，J.，和T.Iwata，“互联网密钥交换协议（IKE）的基于密码的消息认证码伪随机函数128（AES-CMAC-PRF-128）算法的高级加密标准”，RFC 4615，2006年8月。
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, August 2006.
[RFC4621]Kivinen，T.和H.Tschofenig，“IKEv2移动和多址（MOBIKE）协议的设计”，RFC 46212006年8月。
[RFC4705] Housley, R. and A. Corry, "GigaBeam High-Speed Radio Link Encryption", RFC 4705, October 2006.
[RFC4705]Housley，R.和A.Corry，“GigaBeam高速无线链路加密”，RFC 4705，2006年10月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718]Erenen，P.和P.Hoffman，“IKEv2澄清和实施指南”，RFC 4718，2006年10月。
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, November 2006.
[RFC4739]Eronen，P.和J.Korhonen，“互联网密钥交换（IKEv2）协议中的多重认证交换”，RFC 4739，2006年11月。
[RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC 4753, January 2007.
[RFC4753]Fu，D.和J.Solinas，“IKE和IKEv2的ECP组”，RFC 4753，2007年1月。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007.
[RFC4754]Fu，D.和J.Solinas，“使用椭圆曲线数字签名算法（ECDSA）的IKE和IKEv2认证”，RFC 4754，2007年1月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806]Myers，M.和H.Tschofenig，“IKEv2的在线证书状态协议（OCSP）扩展”，RFC 4806，2007年2月。
[RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec Security Policy Database Configuration MIB", RFC 4807, March 2007.
[RFC4807]Baer，M.，Charlet，R.，Hardaker，W.，Story，R.，和C.Wang，“IPsec安全策略数据库配置MIB”，RFC 4807，2007年3月。
[RFC4809] Bonatti, C., Ed., Turner, S., Ed., and G. Lebovitz, Ed., "Requirements for an IPsec Certificate Management Profile", RFC 4809, February 2007.
[RFC4809]Bonatti，C.，Ed.，Turner，S.，Ed.，和G.Lebovitz，Ed.，“IPsec证书管理配置文件的要求”，RFC 4809，2007年2月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月。
[RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007.
[RFC4869]Law，L.和J.Solinas，“用于IPsec的套件B加密套件”，RFC 4869，2007年5月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877]Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891]Graveman，R.，Parthasarathy，M.，Savola，P.，和H.Tschofenig，“使用IPsec保护IPv4隧道中的IPv6”，RFC 4891，2007年5月。
[RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec", RFC 4894, May 2007.
[RFC4894]Hoffman，P.，“哈希算法在因特网密钥交换（IKE）和IPsec中的使用”，RFC 4894，2007年5月。
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC4945]Korver，B.“IKEv1/ISAKMP、IKEv2和PKIX的互联网IP安全PKI配置文件”，RFC 49452007年8月。
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]Giaretta，G.，Ed.，Kempf，J.，和V.Devarapalli，Ed.，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.
[RFC5106]Tschofenig，H.，Kroeselberg，D.，Pashalidis，A.，Ohba，Y.，和F.Bersani，“可扩展认证协议互联网密钥交换协议版本2（EAP-IKEv2）方法”，RFC 5106，2008年2月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114]Lepinski，M.和S.Kent，“与IETF标准一起使用的其他Diffie-Hellman组”，RFC 5114，2008年1月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，Ed.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202]Jokela，P.，Moskowitz，R.，和P.Nikander，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 52022008年4月。
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Nikander，P.，Henderson，T.，Ed.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多址”，RFC 52062008年4月。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
[RFC5207]Stieemerling，M.，Quittek，J.，和L.Eggert，“主机身份协议（HIP）通信的NAT和防火墙穿越问题”，RFC 5207，2008年4月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Ed.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5225]Pelletier，G.和K.Sandlund，“鲁棒头压缩版本2（ROHCv2）：RTP、UDP、IP、ESP和UDP Lite的配置文件”，RFC 52252008年4月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5265]Vaarala，S.和E.Kloving，“跨基于IPsec的VPN网关的移动IPv4穿越”，RFC 5265，2008年6月。
[RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.
[RFC5266]Devarapalli，V.和P.Eronen，“使用移动IPv4和IKEv2移动和多址（MOBIKE）实现安全连接和移动”，BCP 136，RFC 5266，2008年6月。
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
[RFC5282]Black，D.和D.McGrew，“使用互联网密钥交换第2版（IKEv2）协议的加密有效负载的认证加密算法”，RFC 5282，2008年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]Soliman，H.，Castelluccia，C.，ElMalki，K.，和L.Bellier，“分层移动IPv6（HMIPv6）移动性管理”，RFC 53802008年10月。
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[RFC5386]Williams，N.和M.Richardson，“比没有更好的安全性：未经验证的IPsec模式”，RFC 5386，2008年11月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，2008年11月。
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008.
[RFC5387]Touch，J.，Black，D.，和Y.Wang，“比没有更好的安全性（BTNS）的问题和适用性声明”，RFC 5387，2008年11月。
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
[RFC5406]Bellovin，S.，“指定IPsec版本2使用的指南”，BCP 146，RFC 5406，2009年2月。
[RFC5529] Kato, A., Kanda, M., and S. Kanno, "Modes of Operation for Camellia for Use with IPsec", RFC 5529, April 2009.
[RFC5529]Kato，A.，Kanda，M.，和S.Kanno，“与IPsec一起使用的茶花的操作模式”，RFC 55292009年4月。
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, June 2009.
[RFC5566]Berger，L.，White，R.，和E.Rosen，“BGP IPsec隧道封装属性”，RFC 5566，2009年6月。
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568]Koodli，R.，Ed.，“移动IPv6快速切换”，RFC 5568，2009年7月。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
[RFC5570]StJohns，M.，Atkinson，R.，和G.Thomas，“通用架构标签IPv6安全选项（CALIPSO）”，RFC 55702009年7月。
[RFC5660] Williams, N., "IPsec Channels: Connection Latching", RFC 5660, October 2009.
[RFC5660]Williams，N.，“IPsec通道：连接锁存”，RFC5660，2009年10月。
[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009.
[RFC5685]Devarapalli，V.和K.Weniger，“互联网密钥交换协议版本2（IKEv2）的重定向机制”，RFC 56852009年11月。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[RFC5723]Sheffer，Y.和H.Tschofenig，“互联网密钥交换协议第2版（IKEv2）会话恢复”，RFC 57232010年1月。
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, February 2010.
[RFC5739]Eronen，P.，Laganier，J.，和C.Madson，“互联网密钥交换协议版本2（IKEv2）中的IPv6配置”，RFC 5739，2010年2月。
[RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility", RFC 5840, April 2010.
[RFC5840]Grewal，K.，黑山，G.，和M.Bhatia，“用于流量可见性的包装封装安全有效载荷（ESP）”，RFC 58402010年4月。
[RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, "Integration of Robust Header Compression over IPsec Security Associations", RFC 5856, May 2010.
[RFC5856]Ertekin，E.，Jasani，R.，Christou，C.，和C.Bormann，“IPsec安全关联上的鲁棒头压缩集成”，RFC 5856，2010年5月。
[RFC5857] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, "IKEv2 Extensions to Support Robust Header Compression over IPsec", RFC 5857, May 2010.
[RFC5857]Ertekin，E.，Christou，C.，Jasani，R.，Kivinen，T.，和C.Bormann，“IKEv2扩展以支持IPsec上的健壮报头压缩”，RFC 5857，2010年5月。
[RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec Extensions to Support Robust Header Compression over IPsec", RFC 5858, May 2010.
[RFC5858]Ertekin，E.，Christou，C.，和C.Bormann，“支持IPsec上的健壮头压缩的IPsec扩展”，RFC 5858，2010年5月。
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting ESP-NULL Packets", RFC 5879, May 2010.
[RFC5879]Kivinen，T.和D.McDonald，“检测ESP-NULL数据包的启发式”，RFC 5879，2010年5月。
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
[RFC5903]Fu，D.和J.Solinas，“IKE和IKEv2的模素数的椭圆曲线群（ECP群）”，RFC 5903，2010年6月。
[RFC5930] Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol", RFC 5930, July 2010.
[RFC5930]Shen，S.，Mao，Y.，和NSS。Murthy，“使用互联网密钥交换版本02（IKEv2）协议的高级加密标准计数器模式（AES-CTR）”，RFC 59302010年7月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010.
[RFC5998]Eronen，P.，Tschofenig，H.，和Y.Sheffer，“IKEv2中仅EAP认证的扩展”，RFC 5998，2010年9月。
[RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
[RFC6027]Nir，Y，“IPsec群集问题声明”，RFC 6027，2010年10月。
Table 1: Algorithm Requirement Levels
表1：算法需求级别
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Encryption Algorithms: |
|--------------------- |
| ESP-NULL | N/A N/A MUST MUST |
| | |
| 3DES-CBC | MUST MUST- MUST MUST- |
| | |
| Blowfish/CAST/IDEA/RC5 | optional optional optional optional |
| | |
| AES-CBC 128-bit key | SHOULD SHOULD+ MUST MUST |
| | |
| AES-CBC 192/256-bit key | optional optional optional optional |
| | |
| AES-CTR | undefined optional SHOULD SHOULD |
| | |
| Camellia-CBC | optional optional optional optional |
| | |
| Camellia-CTR | undefined undefined undefined optional |
| | |
| SEED-CBC | undefined undefined optional undefined|
| | |
|Integrity-Protection Algorithms: |
|------------------------------ |
| HMAC-SHA-1 | MUST MUST MUST MUST |
| | |
| AES-XCBC-MAC | undefined optional SHOULD+ SHOULD+ |
| | |
| HMAC-SHA-256/384/512 | optional optional optional optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| HMAC-MD5 | MAY optional MAY MAY |
| | |
| AES-CMAC | undefined optional undefined optional |
| | |
| HMAC-RIPEMD | undefined undefined optional undefined|
+--------------------------+----------------------------------------+
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Encryption Algorithms: |
|--------------------- |
| ESP-NULL | N/A N/A MUST MUST |
| | |
| 3DES-CBC | MUST MUST- MUST MUST- |
| | |
| Blowfish/CAST/IDEA/RC5 | optional optional optional optional |
| | |
| AES-CBC 128-bit key | SHOULD SHOULD+ MUST MUST |
| | |
| AES-CBC 192/256-bit key | optional optional optional optional |
| | |
| AES-CTR | undefined optional SHOULD SHOULD |
| | |
| Camellia-CBC | optional optional optional optional |
| | |
| Camellia-CTR | undefined undefined undefined optional |
| | |
| SEED-CBC | undefined undefined optional undefined|
| | |
|Integrity-Protection Algorithms: |
|------------------------------ |
| HMAC-SHA-1 | MUST MUST MUST MUST |
| | |
| AES-XCBC-MAC | undefined optional SHOULD+ SHOULD+ |
| | |
| HMAC-SHA-256/384/512 | optional optional optional optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| HMAC-MD5 | MAY optional MAY MAY |
| | |
| AES-CMAC | undefined optional undefined optional |
| | |
| HMAC-RIPEMD | undefined undefined optional undefined|
+--------------------------+----------------------------------------+
Table 1: Algorithm Requirement Levels (continued)
表1：算法需求水平（续）
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Combined Mode Algorithms: |
|------------------------ |
| AES-CCM | N/A optional N/A optional |
| | |
| AES-GCM | N/A optional N/A optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| Camellia-CCM | N/A undefined N/A optional |
| | |
|Pseudorandom Functions: |
|----------------------- |
| PRF-HMAC-SHA1 | MUST MUST |
| | |
| PRF-HMAC-SHA-256/384/512 | optional optional |
| | |
| AES-XCBC-PRF | undefined SHOULD+ |
| | |
| AES-CMAC-PRF | undefined optional |
| | |
|Diffie-Hellman Algorithms: |
|------------------------- |
| DH MODP grp 1 | MAY optional |
| | |
| DH MODP grp 2 | MUST MUST- |
| | |
| DH MODP grp 5 | optional optional |
| | |
| DH MODP grp 14 | SHOULD SHOULD+ |
| | |
| DH MODP grp 15-18 | optional optional |
| | |
| DH MODP grp 22-24 | optional optional |
| | |
| DH EC grp 3-4 | MAY undefined |
| | |
| DH EC grp 19-21 | optional optional |
| | |
| DH EC grp 25-26 | optional optional |
+--------------------------+----------------------------------------+
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Combined Mode Algorithms: |
|------------------------ |
| AES-CCM | N/A optional N/A optional |
| | |
| AES-GCM | N/A optional N/A optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| Camellia-CCM | N/A undefined N/A optional |
| | |
|Pseudorandom Functions: |
|----------------------- |
| PRF-HMAC-SHA1 | MUST MUST |
| | |
| PRF-HMAC-SHA-256/384/512 | optional optional |
| | |
| AES-XCBC-PRF | undefined SHOULD+ |
| | |
| AES-CMAC-PRF | undefined optional |
| | |
|Diffie-Hellman Algorithms: |
|------------------------- |
| DH MODP grp 1 | MAY optional |
| | |
| DH MODP grp 2 | MUST MUST- |
| | |
| DH MODP grp 5 | optional optional |
| | |
| DH MODP grp 14 | SHOULD SHOULD+ |
| | |
| DH MODP grp 15-18 | optional optional |
| | |
| DH MODP grp 22-24 | optional optional |
| | |
| DH EC grp 3-4 | MAY undefined |
| | |
| DH EC grp 19-21 | optional optional |
| | |
| DH EC grp 25-26 | optional optional |
+--------------------------+----------------------------------------+
Authors' Addresses
作者地址
Sheila Frankel NIST Bldg. 223 Rm. B366 Gaithersburg, MD 20899
希拉·弗兰克尔NIST大厦223室。马里兰州盖瑟斯堡B366 20899
Phone: 1-301-975-3297 EMail: sheila.frankel@nist.gov
电话：1-301-975-3297电子邮件：希拉。frankel@nist.gov
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: 1-514-345-7900 x42871 EMail: suresh.krishnan@ericsson.com
电话：1-514-345-7900 x42871电子邮件：suresh。krishnan@ericsson.com