Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 8221 Red Hat
Obsoletes: 7321 D. Migault
Category: Standards Track J. Mattsson
ISSN: 2070-1721 Ericsson
Y. Nir
Check Point
T. Kivinen
October 2017
Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 8221 Red Hat
Obsoletes: 7321 D. Migault
Category: Standards Track J. Mattsson
ISSN: 2070-1721 Ericsson
Y. Nir
Check Point
T. Kivinen
October 2017
Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
封装安全有效负载（ESP）和身份验证头（AH）的密码算法实现要求和使用指南
Abstract
摘要
This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.
本文档取代RFC 7321，“封装安全有效负载（ESP）和身份验证头（AH）的加密算法实现要求和使用指南”。本文档的目标是使ESP和AH能够受益于最新的加密技术，同时使IPsec具有互操作性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8221.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8221.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Encryption Must Be Authenticated . . . . . . . . . . . . . . 6
5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 7
6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 9
7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 10
8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Encryption Must Be Authenticated . . . . . . . . . . . . . . 6
5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 7
6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 9
7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 10
8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
The Encapsulating Security Payload (ESP) [RFC4303] and the Authentication Header (AH) [RFC4302] are the mechanisms for applying cryptographic protection to data being sent over an IPsec Security Association (SA) [RFC4301].
封装安全有效负载（ESP）[RFC4303]和身份验证头（AH）[RFC4302]是对通过IPsec安全关联（SA）[RFC4301]发送的数据应用加密保护的机制。
This document provides guidance and recommendations so that ESP and AH can be used with cryptographic algorithms that are up to date. The challenge of such documents is making sure that, over time, IPsec implementations can use secure and up-to-date cryptographic algorithms while keeping IPsec interoperable.
本文件提供了指导和建议，以便ESP和AH可以与最新的加密算法一起使用。这些文档的挑战在于确保随着时间的推移，IPsec实现可以使用安全和最新的加密算法，同时保持IPsec的互操作性。
The field of cryptography evolves continuously: new, stronger algorithms appear, and existing algorithms are found to be less secure than originally thought. Therefore, algorithm implementation requirements and usage guidance need to be updated from time to time to reflect the new reality. The choices for algorithms must be conservative to minimize the risk of algorithm compromise. Algorithms need to be suitable for a wide variety of CPU architectures and device deployments ranging from high-end bulk encryption devices to small, low-power Internet of Things (IoT) devices.
密码学领域不断发展：出现了新的、更强的算法，并且发现现有的算法不如最初认为的安全。因此，需要不时更新算法实现要求和使用指南，以反映新的现实。算法的选择必须是保守的，以最小化算法妥协的风险。算法需要适合各种CPU架构和设备部署，从高端批量加密设备到小型、低功耗物联网（IoT）设备。
The algorithm implementation requirements and usage guidance may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms was removed from the main Internet Key Exchange Protocol Version 2 (IKEv2) specification [RFC7296] and placed in a separate document.
算法实现要求和使用指南可能需要随着时间的推移而改变，以适应不断变化的世界。因此，从主Internet密钥交换协议版本2（IKEv2）规范[RFC7296]中删除了强制算法的选择，并将其放在单独的文档中。
The mandatory-to-implement algorithm of tomorrow should already be available in most implementations of AH/ESP by the time it is made mandatory. This document attempts to identify and introduce those algorithms for future mandatory-to-implement status. There is no guarantee that the algorithms in use today may become mandatory in the future. Published algorithms are continuously subjected to cryptographic attack and may become too weak or could become completely broken before this document is updated.
在强制实施AH/ESP时，明天的强制实施算法应该已经在大多数AH/ESP实施中可用。本文件试图确定并介绍这些算法，以供未来强制实施状态。目前使用的算法不能保证将来会成为强制性的。已发布的算法会持续受到加密攻击，并且在更新本文档之前可能会变得太弱或完全损坏。
This document only provides recommendations for the mandatory-to-implement algorithms and "too weak" algorithms that are recommended not to be implemented. As a result, any algorithm listed at the IPsec IANA registry that is not mentioned in this document MAY be implemented. It is expected that this document will be updated over
本文件仅为强制执行算法和建议不执行的“太弱”算法提供建议。因此，可以实现本文档中未提及的IPsec IANA注册表中列出的任何算法。预计本文件将在两年内更新
time and future versions will only mention algorithms that have evolved in status. For clarification, when an algorithm has been mentioned in [RFC7321], this document states explicitly the update of the status.
《时代》和《未来》的版本只会提到在地位上不断发展的算法。为了澄清，当[RFC7321]中提到算法时，本文件明确说明状态的更新。
Although this document updates the algorithms to keep the AH/ESP communication secure over time, it also aims at providing recommendations so that AH/ESP implementations remain interoperable. AH/ESP interoperability is addressed by an incremental introduction or deprecation of algorithms. In addition, this document also considers the new use cases for AH/ESP deployment, such as IoT.
尽管本文档更新了算法以保证AH/ESP通信的安全性，但也旨在提供建议，使AH/ESP实现保持互操作性。AH/ESP互操作性通过增量引入或弃用算法来解决。此外，本文件还考虑了AH/ESP部署的新用例，如物联网。
It is expected that deprecation of an algorithm be performed gradually. This provides time for various implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to MUST- or SHOULD, instead of MUST NOT (see Section 2). Similarly, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a SHOULD instead of a MUST.
预计将逐步执行算法的弃用。这为各种实现在保持互操作性的同时更新其实现的算法提供了时间。除非有强烈的安全原因，否则算法将从必须降级到必须或应该，而不是必须不降级（参见第2节）。类似地，一个未被提及为必须实现的算法预计将以“应该”而不是“必须”引入。
The current trend toward IoT and its adoption of AH/ESP requires this specific use case to be taken into account as well. IoT devices are resource-constrained devices, and their choice of algorithms is motivated by minimizing the footprint of the code, the computation effort, and the size of the messages to send. This document indicates "(IoT)" when a specified algorithm is specifically listed for IoT devices. Requirement levels that are marked as "IoT" apply to IoT devices and to server-side implementations that might presumably need to interoperate with them, including any general-purpose VPN gateways.
物联网的当前趋势及其AH/ESP的采用也需要考虑这个特定的用例。物联网设备是资源受限的设备，它们选择算法的动机是最小化代码占用、计算工作量和要发送的消息大小。当为物联网设备专门列出指定算法时，本文件指出“（物联网）”。标记为“IoT”的需求级别适用于IoT设备和可能需要与之互操作的服务器端实现，包括任何通用VPN网关。
The recommendations of this document mostly target AH/ESP implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure AH/ESP with only the safest cipher suite.
本文档的建议主要针对AH/ESP实施者，因为实施需要满足高安全性预期以及不同供应商之间以及不同版本之间的高互操作性。互操作性要求顺利过渡到更安全的密码套件。这可能不同于用户仅使用最安全的密码套件部署和配置AH/ESP的观点。
This document does not give any recommendations for the use of algorithms, it only gives recommendations for implementations. The use of algorithms by a specific user is dictated by their own security policy requirements, which are outside the scope of this document.
本文档没有给出任何关于算法使用的建议，只是给出了实现的建议。特定用户对算法的使用由其自身的安全策略要求决定，这超出了本文档的范围。
The algorithms considered here are listed by IANA as part of the IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is deprecated; the recommendations of this document must not be considered for IKEv1, nor may IKEv1 parameters be considered by this document.
IANA将此处考虑的算法作为IKEv2参数的一部分列出。IKEv1不在本文件范围内。IKEv1已弃用；对于IKEv1，不得考虑本文件的建议，本文件也不得考虑IKEv1参数。
The IANA registry for "Internet Key Exchange Version 2 (IKEv2) Parameters" contains some entries that are not for use with ESP or AH. This document does not modify the status of those algorithms.
“Internet密钥交换版本2（IKEv2）参数”的IANA注册表包含一些不用于ESP或AH的条目。本文档不修改这些算法的状态。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
We define some additional terms here:
我们在此定义了一些附加术语：
SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. MUST- This term means the same as MUST. However, we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST-algorithm, it will remain at least a SHOULD or a SHOULD-level. IoT The Internet of Things.
SHOULD+这个词的意思与SHOULD相同。然而，标记为SHOULD+的算法很可能会在将来某个时候被提升为必须的。应-该术语的含义与应相同。但是，在本文档的未来版本中，标记为“应该”的算法可能会被弃用为“可能”。必须-该术语的含义与必须相同。然而，我们希望在将来的文档中不再需要这种算法。虽然其状态将在稍后确定，但可以合理预期，如果未来的文档修订更改了“必须”算法的状态，它将至少保持“应该”或“应该”级别。物联网。
Manual keying SHOULD NOT be used, as it is inherently dangerous. Without any secure keying protocol, such as IKE, IPsec does not offer Perfect Forward Secrecy (PFS) protection; there is no entity to ensure the refreshing of session keys, the tracking of Security Parameter Index (SPI) uniqueness, and the single use of nonces, Initialization Vectors (IVs), and counters. This document was written for deploying ESP/AH using IKE [RFC7296] and assumes that keying happens using IKEv2 or higher.
不应使用手动键控，因为这本身就很危险。没有IKE等安全密钥协议，IPsec无法提供完美的前向保密（PFS）保护；没有实体可以确保会话密钥的刷新、安全参数索引（SPI）唯一性的跟踪以及一次性使用nonce、初始化向量（IVs）和计数器。本文档是为使用IKE[RFC7296]部署ESP/AH而编写的，并假设使用IKEv2或更高版本进行键控。
If manual keying is used regardless, Counter Mode algorithms such as ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM, and ENCR_CHACHA20_POLY1305 MUST NOT be used, as it is incompatible with a secure and persistent handling of the counter (as explained in the Security Considerations section of [RFC3686]). This particularly applies to IoT devices that have no state across reboots. At the time of writing, ENCR_AES_CBC is the only mandatory-to-implement encryption algorithm suitable for manual keying.
如果使用手动键控，则不得使用计数器模式算法，如ENCR_AES_CTR、ENCR_AES_CCM、ENCR_AES_GCM和ENCR_CHACHA20_POLY1305，因为它与计数器的安全和持久处理不兼容（如[RFC3686]的安全注意事项部分所述）。这尤其适用于在重启期间没有状态的物联网设备。在撰写本文时，ENCR_AES_CBC是实现适用于手动键控的加密算法的唯一强制性工具。
Encryption without authentication is not effective and MUST NOT be used. IPsec offers three ways to provide both encryption and authentication:
未经身份验证的加密无效，不得使用。IPsec提供了三种同时提供加密和身份验证的方法：
o ESP with an Authenticated Encryption with Associated Data (AEAD) cipher
o ESP，带有经过身份验证的关联数据加密（AEAD）密码
o ESP with a non-AEAD cipher + authentication
o 使用非AEAD密码+身份验证的ESP
o ESP with a non-AEAD cipher + AH with authentication
o ESP使用非AEAD密码+AH认证
The fastest and most modern method is to use ESP with a combined mode cipher, such as an AEAD cipher, that handles encryption/decryption and authentication in a single step. In this case, the AEAD cipher is set as the encryption algorithm, and the authentication algorithm is set to none. Examples of this are ENCR_AES_GCM_16 and ENCR_CHACHA20_POLY1305.
最快和最现代的方法是将ESP与组合模式密码（如AEAD密码）结合使用，该密码在一个步骤中处理加密/解密和身份验证。在这种情况下，AEAD密码设置为加密算法，身份验证算法设置为无。例如ENCR_AES_GCM_16和ENCR_CHACHA20_POLY1305。
A more traditional approach is to use ESP with an encryption and an authentication algorithm. This approach is slower, as the data has to be processed twice: once for encryption/decryption and once for authentication. An example of this is ENCR_AES_CBC combined with AUTH_HMAC_SHA2_512_256.
更传统的方法是将ESP与加密和身份验证算法一起使用。这种方法比较慢，因为数据必须处理两次：一次用于加密/解密，一次用于身份验证。例如，ENCR_AES_CBC与AUTH_HMAC_SHA2_512_256相结合。
The last method that can be used is ESP+AH. This method is NOT RECOMMENDED. It is the slowest method and also takes up more octets due to the double header of ESP+AH. This results in a smaller effective MTU for the encrypted data. With this method, ESP is only used for confidentiality without an authentication algorithm, and a second IPsec protocol of type AH is used for authentication. An example of this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256.
最后一种可以使用的方法是ESP+AH。不建议使用此方法。这是最慢的方法，而且由于ESP+AH的双报头，占用了更多的八位字节。这导致加密数据的有效MTU更小。使用此方法，ESP仅用于保密，没有身份验证算法，第二个AH类型的IPsec协议用于身份验证。这方面的一个例子是ESP与ENCR_AES_CBC和AH与AUTH_HMAC_SHA2_512_256。
+-------------------------+------------+---------+----------------+
| Name | Status | AEAD | Comment |
+-------------------------+------------+---------+----------------+
| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |
| ENCR_DES | MUST NOT | No | [RFC2405] |
| ENCR_3DES | SHOULD NOT | No | [RFC2451] |
| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |
| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |
| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |
| ENCR_NULL | MUST | No | [RFC2410] |
| ENCR_AES_CBC | MUST | No | [RFC3602][1] |
| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309](IoT) |
| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
+-------------------------+------------+---------+----------------+
+-------------------------+------------+---------+----------------+
| Name | Status | AEAD | Comment |
+-------------------------+------------+---------+----------------+
| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |
| ENCR_DES | MUST NOT | No | [RFC2405] |
| ENCR_3DES | SHOULD NOT | No | [RFC2451] |
| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |
| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |
| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |
| ENCR_NULL | MUST | No | [RFC2410] |
| ENCR_AES_CBC | MUST | No | [RFC3602][1] |
| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309](IoT) |
| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
+-------------------------+------------+---------+----------------+
[1] - This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at the MAY level.
[1] -此要求级别适用于128位和256位密钥。192位密钥保持在可能的级别。
(IoT) - This requirement is for interoperability with IoT. Only 128-bit keys are at the given level.
（物联网）-这一要求是为了与物联网的互操作性。只有128位密钥处于给定级别。
IPsec sessions may have very long lifetime and carry multiple packets, so there is a need to move to 256-bit keys in the long term. For that purpose, the requirement level for 128-bit keys and 256-bit keys is MUST (when applicable). In that sense, the status for 256-bit keys has been raised from MAY in [RFC7321] to MUST.
IPsec会话可能有很长的生命周期，并携带多个数据包，因此从长远来看需要移动到256位密钥。为此，必须满足128位密钥和256位密钥的要求级别（如适用）。从这个意义上说，256位密钥的状态已从[RFC7321]中的五月提升为必须。
IANA has allocated codes for cryptographic algorithms that have not been specified by the IETF. Such algorithms are noted as UNSPECIFIED. Usually, the use of these algorithms is limited to specific cases, and the absence of specification makes interoperability difficult for IPsec communications. These algorithms were not mentioned in [RFC7321], and this document clarifies that such algorithms MUST NOT be implemented for IPsec communications.
IANA为IETF未指定的加密算法分配了代码。这些算法被认为是未指定的。通常，这些算法的使用仅限于特定情况，缺乏规范使得IPsec通信的互操作性变得困难。[RFC7321]中未提及这些算法，本文件澄清了不得为IPsec通信实施此类算法。
Similarly, IANA also allocated code points for algorithms that are not expected to be used to secure IPsec communications. Such algorithms are noted as non-IPsec. As a result, these algorithms MUST NOT be implemented.
类似地，IANA还为不用于保护IPsec通信的算法分配了代码点。这种算法被称为非IPsec。因此，这些算法不能实现。
Various ciphers that are older, not well tested, and never widely implemented have been changed to MUST NOT.
各种较旧、未经良好测试且从未广泛实施的密码已改为“不得”。
ENCR_3DES status has been downgraded from MAY in [RFC7321] to SHOULD NOT. ENCR_CHACHA20_POLY1305 is a more modern approach and alternative for ENCR_3DES than ENCR_AES_CBC, and so it is expected to be favored to replace ENCR_3DES.
ENCR_3DES状态已从[RFC7321]中的5月降级为不应。ENCR_CHACHA20_POLY1305是一种比ENCR_AES_CBC更为现代的ENCR_3DES方法和替代品，因此有望取代ENCR_3DES。
ENCR_BLOWFISH has been downgraded to MUST NOT as it has been deprecated for years by TWOFISH, which is not standardized for ESP and therefore not listed in this document. Some implementations support TWOFISH using a private range number.
ENCR_河豚已被降级为不得，因为TWOFISH多年来一直不推荐使用它，它不是ESP的标准，因此未列入本文件。一些实现支持使用私有范围编号的TWOFISH。
ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to enable the use of ESP with only authentication, which is preferred over AH due to NAT traversal. ENCR_NULL is expected to remain MUST by protocol requirements.
在[RFC7321]中，ENCR_NULL状态被设置为必须，并且仍然是启用仅通过身份验证的ESP的必须，由于NAT遍历，这比AH更可取。根据协议要求，ENCR_NULL应保持不变。
ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be implemented in order to enable interoperability between implementations that followed [RFC7321]. However, there is a trend for the industry to move to AEAD encryption, and the overhead of ENCR_AES_CBC remains quite large, so it is expected to be replaced by AEAD algorithms in the long term.
ENCR_AES_CBC状态必须保持。必须实现ENCR_AES_CBC，以实现后续实现之间的互操作性[RFC7321]。然而，行业有向AEAD加密转移的趋势，并且ENCR_AES_CBC的开销仍然很大，因此从长远来看，预计将被AEAD算法取代。
ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised from MAY to SHOULD in order to interact with IoT devices. As this case is not a general use case for VPNs, its status is expected to remain as SHOULD.
[RFC7321]中的ENCR_AES_CCM_8状态设置为5月，并从5月提升为应，以便与物联网设备交互。由于这种情况不是VPN的一般使用情况，因此其状态应保持不变。
ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order to favor the use of authenticated encryption and AEAD algorithms. ENCR_AES_GCM_16 has been widely implemented for ESP due to its increased performance and key longevity compared to ENCR_AES_CBC.
ENCR_AES_GCM_16状态已从“应+更新为“必须”，以便于使用经过身份验证的加密和AEAD算法。与ENCR_AES_GCM_CBC相比，ENCR_AES_GCM_16具有更高的性能和密钥使用寿命，因此已广泛应用于ESP。
ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of [RFC7321]. It has been recommended by the Crypto Forum Research Group (CFRG) and others as an alternative to AES-CBC and AES-GCM. At the time of writing, there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to introduce it at the SHOULD+ level. Its status has been set to SHOULD and is expected to become MUST in the long term.
ENCR_CHACHA20_POLY1305在[RFC7321]时尚未准备好考虑。加密论坛研究小组（CFRG）和其他人推荐它作为AES-CBC和AES-GCM的替代品。在撰写本文时，ENCR_CHACHA20_POLY1305的ESP实现还不足以在“应该+级别”引入它。它的地位已经被设定为应该的，而且从长远来看有望成为必须的。
Authentication algorithm recommendations in this section are targeting two types of communications:
本节中的认证算法建议针对两种类型的通信：
o Authenticated-only communications without encryption, such as ESP with NULL encryption or AH communications.
o 仅经过身份验证的无加密通信，如带有空加密的ESP或AH通信。
o Communications that are encrypted with a non-AEAD algorithm that MUST be combined with an authentication algorithm.
o 使用非AEAD算法加密的通信，该算法必须与身份验证算法相结合。
+------------------------+----------------+-------------------------+
| Name | Status | Comment |
+------------------------+----------------+-------------------------+
| AUTH_NONE | MUST / | [RFC7296][RFC5282] |
| | MUST NOT | AEAD-only |
| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
| AUTH_DES_MAC | MUST NOT | UNSPECIFIED |
| AUTH_KPDK_MD5 | MUST NOT | UNSPECIFIED |
| AUTH_AES_XCBC_96 | SHOULD / MAY | [RFC3566][RFC7296] |
| | | (IoT) |
| AUTH_AES_128_GMAC | MAY | [RFC4543] |
| AUTH_AES_256_GMAC | MAY | [RFC4543] |
| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
+------------------------+----------------+-------------------------+
+------------------------+----------------+-------------------------+
| Name | Status | Comment |
+------------------------+----------------+-------------------------+
| AUTH_NONE | MUST / | [RFC7296][RFC5282] |
| | MUST NOT | AEAD-only |
| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
| AUTH_DES_MAC | MUST NOT | UNSPECIFIED |
| AUTH_KPDK_MD5 | MUST NOT | UNSPECIFIED |
| AUTH_AES_XCBC_96 | SHOULD / MAY | [RFC3566][RFC7296] |
| | | (IoT) |
| AUTH_AES_128_GMAC | MAY | [RFC4543] |
| AUTH_AES_256_GMAC | MAY | [RFC4543] |
| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
+------------------------+----------------+-------------------------+
(IoT) - This requirement is for interoperability with IoT.
（物联网）-这一要求是为了与物联网的互操作性。
AUTH_NONE has been downgraded from MAY in [RFC7321] to MUST NOT. The only case where AUTH_NONE is acceptable is when authenticated encryption algorithms are selected from Section 5. In all other cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide authentication, one may be tempted to combine these protocols to provide authentication. As mentioned by [RFC7321], it is NOT RECOMMENDED to use ESP with NULL authentication (with non-authenticated encryption) in conjunction with AH; some configurations of this combination of services have been shown to be insecure [PD10]. In addition, AUTH_NONE authentication cannot be combined with ESP NULL encryption.
已将[RFC7321]中的AUTH_NONE从五月降级为不得。唯一可以接受AUTH_NONE的情况是从第5节中选择经过身份验证的加密算法。在所有其他情况下，不能选择“无验证”。由于ESP和AH都提供身份验证，人们可能会尝试将这些协议结合起来提供身份验证。如[RFC7321]所述，不建议将ESP与空认证（非认证加密）结合使用；这种服务组合的某些配置已被证明是不安全的[PD10]。此外，AUTH_NONE身份验证不能与ESP NULL加密结合使用。
AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in [RFC7321]. As MD5 is known to be vulnerable to collisions, these algorithms MUST NOT be used.
[RFC7321]中未提及AUTH_HMAC_MD5_96和AUTH_KPDK_MD5。由于MD5易受冲突的影响，因此不得使用这些算法。
AUTH_HMAC_SHA1_96 has been downgraded from MUST in [RFC7321] to MUST-as there is an industry-wide trend to deprecate its usage.
AUTH_HMAC_SHA1_96已从[RFC7321]中的“必须”降级为“必须”，因为全行业都有反对其使用的趋势。
AUTH_DES_MAC was not mentioned in [RFC7321]. As DES is known to be vulnerable, it MUST NOT be used.
[RFC7321]中未提及MAC认证。由于已知DES易受攻击，因此不得使用。
AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as IoT deployments tend to prefer AES-based Hashed Message Authentication Code (HMAC) functions in order to avoid implementing SHA2. For the wide VPN deployment, as it has not been widely adopted, it has been downgraded from SHOULD to MAY.
AUTH_AES_XCBC_96应仅在物联网范围内设置，因为物联网部署倾向于使用基于AES的哈希消息认证码（HMAC）功能，以避免实现SHA2。对于广域VPN部署，由于尚未被广泛采用，已从应降级至5月。
AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms should only be used for AH and not for ESP. If using ENCR_NULL, AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES-GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended. Therefore, these algorithms are kept at MAY.
AUTH_AES_128_GMAC状态已从应+降级至5月。与AUTH_AES_192_GMAC和AUTH_AES_256_GMAC一起，这些算法应仅用于AH，而不用于ESP。如果使用ENCR_NULL，建议使用AUTH_HMAC_SHA2_256_128以确保完整性。如果在ESP中使用AES-GMAC而不进行身份验证，建议使用ENCR\u NULL\u AUTH\u AES\u GMAC。因此，这些算法保留在5月份。
AUTH_HMAC_SHA2_256_128 was not mentioned in [RFC7321], as no SHA2-based authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to a long standing common implementation bug of this algorithm that truncates the hash at 96 bits instead of 128 bits, it is recommended that implementations prefer AUTH_HMAC_SHA2_512_256 over AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.
[RFC7321]中未提及AUTH_HMAC_SHA2_256_128，因为未提及基于SHA2的身份验证。必须实施AUTH_HMAC_SHA2_256_128以替换AUTH_HMAC_SHA1_96。请注意，由于该算法的一个长期存在的常见实现错误，即将哈希值截断为96位而不是128位，因此建议如果实现了AUTH_HMAC_SHA2_512_256，则实现更倾向于AUTH_HMAC_SHA2_512_256而不是AUTH_HMAC_SHA2_256_128。
AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is required. This value has been preferred to AUTH_HMAC_SHA2_384, as the additional overhead of AUTH_HMAC_SHA2_512 is negligible.
AUTH_HMAC_SHA2_512_256应作为AUTH_HMAC_SHA2_256_128的未来替代品或在需要更高安全性时实施。由于AUTH_HMAC_SHA2_512的额外开销可以忽略不计，因此该值比AUTH_HMAC_SHA2_384更可取。
+----------------+----------+-------------+
| Name | Status | Comment |
+----------------+----------+-------------+
| IPCOMP_OUI | MUST NOT | UNSPECIFIED |
| IPCOMP_DEFLATE | MAY | [RFC3173] |
| IPCOMP_LZS | MAY | [RFC2395] |
| IPCOMP_LZJH | MAY | [RFC3051] |
+----------------+----------+-------------+
+----------------+----------+-------------+
| Name | Status | Comment |
+----------------+----------+-------------+
| IPCOMP_OUI | MUST NOT | UNSPECIFIED |
| IPCOMP_DEFLATE | MAY | [RFC3173] |
| IPCOMP_LZS | MAY | [RFC2395] |
| IPCOMP_LZJH | MAY | [RFC3051] |
+----------------+----------+-------------+
Compression was not mentioned in [RFC7321]. As it is not widely deployed, it remains optional and at the MAY level.
[RFC7321]中未提及压缩。由于没有广泛部署，它仍然是可选的，处于5月份的级别。
The following table summarizes the changes from RFC 7321.
下表总结了RFC 7321的变更。
+-------------------+----------+-----------------+
| Algorithm | RFC 7321 | RFC 8221 |
+-------------------+----------+-----------------+
| ENCR_AES_GCM_16 | SHOULD+ | MUST |
| ENCR_AES_CCM_8 | MAY | SHOULD |
| ENCR_AES_CTR | MAY | MAY(*) |
| ENCR_3DES | MAY | SHOULD NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_128_GMAC | SHOULD+ | MAY |
| AUTH_NONE | MAY | MUST / MUST NOT |
+-------------------+----------+-----------------+
+-------------------+----------+-----------------+
| Algorithm | RFC 7321 | RFC 8221 |
+-------------------+----------+-----------------+
| ENCR_AES_GCM_16 | SHOULD+ | MUST |
| ENCR_AES_CCM_8 | MAY | SHOULD |
| ENCR_AES_CTR | MAY | MAY(*) |
| ENCR_3DES | MAY | SHOULD NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_128_GMAC | SHOULD+ | MAY |
| AUTH_NONE | MAY | MUST / MUST NOT |
+-------------------+----------+-----------------+
(*) This algorithm is not mentioned in the above sections, so it defaults to MAY.
（*）上述章节未提及此算法，因此默认为MAY。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
The security of a system that uses cryptography depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
使用密码学的系统的安全性取决于所选择的加密算法的强度以及与这些算法一起使用的密钥的强度。安全性还取决于系统使用的协议的工程和管理，以确保没有非加密方式绕过整个系统的安全性。
This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection of mandatory-to-implement algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research to date leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. Therefore, we expect that revisions of that document will be issued from time to time to reflect the current best practice in this area.
本文件涉及ESP和AH使用的加密算法的选择，特别是强制算法的选择。本文件中确定为“必须实现”或“应该实现”的算法目前尚不存在漏洞，迄今为止的密码研究使我们相信，在可预见的未来，它们可能仍然安全。然而，这不一定是永远的。因此，我们期望该文件的修订将不时印发，以反映这一领域目前的最佳做法。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302]Kent，S.，“IP认证头”，RFC 4302，DOI 10.17487/RFC4302，2005年12月<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<https://www.rfc-editor.org/info/rfc4303>.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, <https://www.rfc-editor.org/info/rfc7321>.
[RFC7321]McGrew，D.和P.Hoffman，“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求和使用指南”，RFC 7321，DOI 10.17487/RFC7321，2014年8月<https://www.rfc-editor.org/info/rfc7321>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of IPsec in MAC-then-encrypt configurations", Proceedings of the 17th ACM Conference on Computer and Communications Security (ACM CCS), DOI 10.1145/1866307.1866363, 2010.
[PD10]Paterson，K.和J.Degabriele，“关于MAC加密配置中IPsec的（in）安全”，第17届ACM计算机和通信安全会议记录（ACM CCS），DOI 10.1145/1866307.1866362010。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, <https://www.rfc-editor.org/info/rfc2395>.
[RFC2395]Friend，R.和R.Monsour，“使用LZS的IP有效负载压缩”，RFC 2395，DOI 10.17487/RFC2395，1998年12月<https://www.rfc-editor.org/info/rfc2395>.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November 1998, <https://www.rfc-editor.org/info/rfc2403>.
[RFC2403]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，DOI 10.17487/RFC2403，1998年11月<https://www.rfc-editor.org/info/rfc2403>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998, <https://www.rfc-editor.org/info/rfc2404>.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，DOI 10.17487/RFC2404，1998年11月<https://www.rfc-editor.org/info/rfc2404>.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, DOI 10.17487/RFC2405, November 1998, <https://www.rfc-editor.org/info/rfc2405>.
[RFC2405]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，DOI 10.17487/RFC2405，1998年11月<https://www.rfc-editor.org/info/rfc2405>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, November 1998, <https://www.rfc-editor.org/info/rfc2410>.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，DOI 10.17487/RFC2410，1998年11月<https://www.rfc-editor.org/info/rfc2410>.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, DOI 10.17487/RFC2451, November 1998, <https://www.rfc-editor.org/info/rfc2451>.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，DOI 10.17487/RFC2451，1998年11月<https://www.rfc-editor.org/info/rfc2451>.
[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, January 2001, <https://www.rfc-editor.org/info/rfc3051>.
[RFC3051]Heath，J.和J.Border，“使用ITU-T V.44数据包方法的IP有效负载压缩”，RFC 3051，DOI 10.17487/RFC3051，2001年1月<https://www.rfc-editor.org/info/rfc3051>.
[RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, DOI 10.17487/RFC3173, September 2001, <https://www.rfc-editor.org/info/rfc3173>.
[RFC3173]Shacham，A.，Monsour，B.，Pereira，R.，和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 3173，DOI 10.17487/RFC3173，2001年9月<https://www.rfc-editor.org/info/rfc3173>.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, September 2003, <https://www.rfc-editor.org/info/rfc3566>.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，DOI 10.17487/RFC3566，2003年9月<https://www.rfc-editor.org/info/rfc3566>.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/RFC3602, September 2003, <https://www.rfc-editor.org/info/rfc3602>.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，DOI 10.17487/RFC3602，2003年9月<https://www.rfc-editor.org/info/rfc3602>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, <https://www.rfc-editor.org/info/rfc3686>.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效载荷（ESP）”，RFC 3686，DOI 10.17487/RFC3686，2004年1月<https://www.rfc-editor.org/info/rfc3686>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, <https://www.rfc-editor.org/info/rfc4106>.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效载荷（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，DOI 10.17487/RFC4106，2005年6月<https://www.rfc-editor.org/info/rfc4106>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, DOI 10.17487/RFC4309, December 2005, <https://www.rfc-editor.org/info/rfc4309>.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，DOI 10.17487/RFC4309，2005年12月<https://www.rfc-editor.org/info/rfc4309>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, DOI 10.17487/RFC4543, May 2006, <https://www.rfc-editor.org/info/rfc4543>.
[RFC4543]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，RFC 4543，DOI 10.17487/RFC4543，2006年5月<https://www.rfc-editor.org/info/rfc4543>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，DOI 10.17487/RFC4868，2007年5月<https://www.rfc-editor.org/info/rfc4868>.
[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, DOI 10.17487/RFC5282, August 2008, <https://www.rfc-editor.org/info/rfc5282>.
[RFC5282]Black，D.和D.McGrew，“使用互联网密钥交换版本2（IKEv2）协议的加密有效载荷的认证加密算法”，RFC 5282，DOI 10.17487/RFC5282，2008年8月<https://www.rfc-editor.org/info/rfc5282>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<https://www.rfc-editor.org/info/rfc7296>.
[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, DOI 10.17487/RFC7634, August 2015, <https://www.rfc-editor.org/info/rfc7634>.
[RFC7634]Nir，Y.，“ChaCha20，Poly1305及其在互联网密钥交换协议（IKE）和IPsec中的使用”，RFC 7634，DOI 10.17487/RFC7634，2015年8月<https://www.rfc-editor.org/info/rfc7634>.
Acknowledgements
致谢
Some of the wording in this document was adapted from [RFC7321], the document that this one obsoletes, which was written by D. McGrew and P. Hoffman.
本文件中的一些措辞是从[RFC7321]改编而来的，该文件已被D.McGrew和P.Hoffman废弃。
Authors' Addresses
作者地址
Paul Wouters Red Hat
保罗·沃特斯红帽
Email: pwouters@redhat.com
Email: pwouters@redhat.com
Daniel Migault Ericsson 8275 Trans Canada Route Saint-Laurent, QC H4S 0B6 Canada
Daniel Migault Ericsson 8275跨加拿大路线圣洛朗，加拿大QC H4S 0B6
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
John Mattsson Ericsson AB SE-164 80 Stockholm Sweden
John Mattsson Ericsson AB SE-164 80瑞典斯德哥尔摩
Email: john.mattsson@ericsson.com
Email: john.mattsson@ericsson.com
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim St. Tel Aviv 6789735 Israel
以色列特拉维夫Hasolelim街5号Yoav Nir Check Point软件技术有限公司6789735
Email: ynir.ietf@gmail.com
Email: ynir.ietf@gmail.com
Tero Kivinen
泰罗基文
Email: kivinen@iki.fi
Email: kivinen@iki.fi