Network Working Group S. Frankel
Request for Comments: 3602 R. Glenn
Category: Standards Track NIST
S. Kelly
Airespace
September 2003
Network Working Group S. Frankel
Request for Comments: 3602 R. Glenn
Category: Standards Track NIST
S. Kelly
Airespace
September 2003
The AES-CBC Cipher Algorithm and Its Use with IPsec
AES-CBC密码算法及其在IPsec中的应用
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).
本文档描述了在密码块链接（CBC）模式下使用高级加密标准（AES）密码算法，以及显式初始化向量（IV），作为IPsec封装安全有效负载（ESP）上下文中的保密机制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
2. The AES Cipher Algorithm . . . . . . . . . . . . . . . . . . . 3
2.1. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Key Size and Number of Rounds. . . . . . . . . . . . . . 4
2.3. Weak Keys. . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Block Size and Padding . . . . . . . . . . . . . . . . . 4
2.5. Additional Information . . . . . . . . . . . . . . . . . 4
2.6. Performance. . . . . . . . . . . . . . . . . . . . . . . 5
3. ESP Payload . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ESP Algorithmic Interactions . . . . . . . . . . . . . . 6
3.2. Keying Material. . . . . . . . . . . . . . . . . . . . . 6
4. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IKE Interactions . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . 10
5.2. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . 10
5.3. Key Length Attribute . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
2. The AES Cipher Algorithm . . . . . . . . . . . . . . . . . . . 3
2.1. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Key Size and Number of Rounds. . . . . . . . . . . . . . 4
2.3. Weak Keys. . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Block Size and Padding . . . . . . . . . . . . . . . . . 4
2.5. Additional Information . . . . . . . . . . . . . . . . . 4
2.6. Performance. . . . . . . . . . . . . . . . . . . . . . . 5
3. ESP Payload . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ESP Algorithmic Interactions . . . . . . . . . . . . . . 6
3.2. Keying Material. . . . . . . . . . . . . . . . . . . . . 6
4. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IKE Interactions . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . 10
5.2. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . 10
5.3. Key Length Attribute . . . . . . . . . . . . . . . . . . 10
5.4. Hash Algorithm Considerations. . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Intellectual Property Rights Statement . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
5.4. Hash Algorithm Considerations. . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Intellectual Property Rights Statement . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
As the culmination of a four-year competitive process, NIST (the National Institute of Standards and Technology) has selected the AES (Advanced Encryption Standard), the successor to the venerable DES (Data Encryption Standard). The competition was an open one, with public participation and comment solicited at each step of the process. The AES [AES], formerly known as Rijndael, was chosen from a field of five finalists.
作为四年竞争过程的高潮，NIST（国家标准与技术研究所）选择了AES（高级加密标准），这是古老的DES（数据加密标准）的继任者。比赛是公开的，每一步都有公众参与并征求意见。AES[AES]，原名Rijndael，从五名决赛选手中选出。
The AES selection was made on the basis of several characteristics:
AES选择基于以下几个特征：
+ security
+ 安全
+ unclassified
+ 未分类
+ publicly disclosed
+ 公开披露
+ available royalty-free, worldwide
+ 全球范围内提供免版税服务
+ capable of handling a block size of at least 128 bits
+ 能够处理至少128位的块大小
+ at a minimum, capable of handling key sizes of 128, 192, and 256 bits
+ 至少能够处理128、192和256位的密钥大小
+ computational efficiency and memory requirements on a variety of software and hardware, including smart cards
+ 各种软件和硬件（包括智能卡）的计算效率和内存需求
+ flexibility, simplicity and ease of implementation
+ 灵活性、简单性和易于实施
The AES will be the government's designated encryption cipher. The expectation is that the AES will suffice to protect sensitive (unclassified) government information until at least the next century. It is also expected to be widely adopted by businesses and financial institutions.
AES将是政府指定的加密密码。人们期望AES至少在下个世纪之前足以保护敏感（非机密）政府信息。预计它还将被企业和金融机构广泛采用。
It is the intention of the IETF IPsec Working Group that AES will eventually be adopted as the default IPsec ESP cipher and will obtain the status of MUST be included in compliant IPsec implementations.
IETF IPsec工作组的意图是，AES最终将被采用为默认IPsec ESP密码，并将获得必须包含在兼容IPsec实现中的状态。
The remainder of this document specifies the use of the AES within the context of IPsec ESP. For further information on how the various pieces of ESP fit together to provide security services, refer to [ARCH], [ESP], and [ROAD].
本文档的其余部分指定了在IPsec ESP的上下文中使用AES。有关ESP的各个部分如何组合在一起以提供安全服务的更多信息，请参阅[ARCH]、[ESP]和[ROAD]。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in [RFC-2119].
本文件中出现的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
All symmetric block cipher algorithms share common characteristics and variables, including mode, key size, weak keys, block size, and rounds. The following sections contain descriptions of the relevant characteristics of the AES cipher.
所有对称分组密码算法都具有共同的特征和变量，包括模式、密钥大小、弱密钥、块大小和轮数。以下部分包含AES密码相关特征的描述。
NIST has defined 5 modes of operation for AES and other FIPS-approved ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR (Counter). The CBC mode is well-defined and well-understood for symmetric ciphers, and is currently required for all other ESP ciphers. This document specifies the use of the AES cipher in CBC mode within ESP. This mode requires an Initialization Vector (IV) that is the same size as the block size. Use of a randomly generated IV prevents generation of identical ciphertext from packets which have identical data that spans the first block of the cipher algorithm's block size.
NIST为AES和其他FIPS批准的密码定义了5种操作模式[模式]：CBC（密码块链接）、ECB（电子码本）、CFB（密码反馈）、OFB（输出反馈）和CTR（计数器）。CBC模式对于对称密码是定义良好且易于理解的，目前所有其他ESP密码都需要CBC模式。本文件规定了在ESP中CBC模式下使用AES密码。该模式需要与块大小相同的初始化向量（IV）。使用随机生成的IV可防止从具有跨越密码算法块大小的第一个块的相同数据的包生成相同的密文。
The IV is XOR'd with the first plaintext block before it is encrypted. Then for successive blocks, the previous ciphertext block is XOR'd with the current plaintext, before it is encrypted.
IV在加密前与第一个明文块异或。然后，对于连续的块，前一个密文块在加密之前与当前明文异或。
More information on CBC mode can be obtained in [MODES, CRYPTO-S]. For the use of CBC mode in ESP with 64-bit ciphers, see [CBC].
有关CBC模式的更多信息，请访问[MODES，CRYPTO-S]。有关64位密码ESP中CBC模式的使用，请参阅[CBC]。
AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The default key size is 128 bits, and all implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.
AES支持三种密钥大小：128位、192位和256位。默认密钥大小为128位，所有实现都必须支持此密钥大小。实现还可以支持192位和256位的密钥大小。
AES uses a different number of rounds for each of the defined key sizes. When a 128-bit key is used, implementations MUST use 10 rounds. When a 192-bit key is used, implementations MUST use 12 rounds. When a 256-bit key is used, implementations MUST use 14 rounds.
AES对每个定义的密钥大小使用不同的轮数。使用128位密钥时，实现必须使用10轮。当使用192位密钥时，实现必须使用12轮。使用256位密钥时，实现必须使用14轮。
At the time of writing this document there are no known weak keys for the AES.
在编写本文档时，AES没有已知的弱密钥。
Some cipher algorithms have weak keys or keys that MUST not be used due to their interaction with some aspect of the cipher's definition. If weak keys are discovered for the AES, then weak keys SHOULD be checked for and discarded when using manual key management. When using dynamic key management, such as [IKE], weak key checks SHOULD NOT be performed as they are seen as an unnecessary added code complexity that could weaken the intended security [EVALUATION].
某些密码算法具有弱密钥或由于与密码定义的某些方面相互作用而不能使用的密钥。如果发现AES的弱密钥，则应在使用手动密钥管理时检查并丢弃弱密钥。当使用动态密钥管理（如[IKE]）时，不应执行弱密钥检查，因为它们被视为不必要的增加的代码复杂性，可能会削弱预期的安全性[EVALUATION]。
The AES uses a block size of sixteen octets (128 bits).
AES使用16个八位字节（128位）的块大小。
Padding is required by the AES to maintain a 16-octet (128-bit) blocksize. Padding MUST be added, as specified in [ESP], such that the data to be encrypted (which includes the ESP Pad Length and Next Header fields) has a length that is a multiple of 16 octets.
AES需要填充以保持16个八位组（128位）的块大小。必须按照[ESP]中的规定添加填充，以便要加密的数据（包括ESP填充长度和下一个标头字段）的长度为16个八位字节的倍数。
Because of the algorithm specific padding requirement, no additional padding is required to ensure that the ciphertext terminates on a 4- octet boundary (i.e., maintaining a 16-octet blocksize guarantees that the ESP Pad Length and Next Header fields will be right aligned within a 4-octet word). Additional padding MAY be included, as specified in [ESP], as long as the 16-octet blocksize is maintained.
由于算法特定的填充要求，不需要额外的填充来确保密文在4个八位字节的边界上终止（即，保持16个八位字节的块大小可以保证ESP填充长度和下一个标头字段在4个八位字节的字内右对齐）。按照[ESP]中的规定，只要保持16个八位组的块大小，就可以包括额外的填充。
AES was invented by Joan Daemen from Banksys/PWI and Vincent Rijmen from ESAT-COSIC, both in Belgium, and is available world-wide on a royalty-free basis. It is not covered by any patents, and the Rijndael homepage contains the following statement: "Rijndael is
AES由比利时Banksys/PWI的Joan Daemen和ESAT-COSIC的Vincent Rijmen发明，在全球范围内免费提供。它不属于任何专利范围，Rijndael主页包含以下声明：“Rijndael是
available for free. You can use it for whatever purposes you want, irrespective of whether it is accepted as AES or not." AES's description can be found in [AES]. The Rijndael homepage is: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/.
免费提供。您可以出于任何目的使用它，无论它是否被接受为AES。”AES的说明可在[AES]中找到。Rijndael主页为：http://www.esat.kuleuven.ac.be/~rijmen/rijndael/。
The AES homepage, http://www.nist.gov/aes, contains a wealth of information about the AES, including a definitive description of the AES algorithm, performance statistics, test vectors and intellectual property information. This site also contains information on how to obtain an AES reference implementation from NIST.
AES主页，http://www.nist.gov/aes，包含有关AES的丰富信息，包括AES算法的明确描述、性能统计、测试向量和知识产权信息。该网站还包含如何从NIST获得AES参考实施的信息。
For a comparison table of the estimated speeds of AES and other cipher algorithms, please see [PERF-1], [PERF-2], [PERF-3], or [PERF-4]. The AES homepage has pointers to other analyses.
有关AES和其他密码算法估计速度的比较表，请参阅[PERF-1]、[PERF-2]、[PERF-3]或[PERF-4]。AES主页有指向其他分析的指针。
The ESP payload is made up of the IV followed by raw cipher-text. Thus the payload field, as defined in [ESP], is broken down according to the following diagram:
ESP有效载荷由IV和原始密码文本组成。因此，[ESP]中定义的有效载荷字段根据下图进行分解：
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (16 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length, a multiple of 16 octets) ~
| |
+---------------------------------------------------------------+
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (16 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length, a multiple of 16 octets) ~
| |
+---------------------------------------------------------------+
The IV field MUST be the same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random, and MUST be unpredictable.
IV字段的大小必须与所用密码算法的块大小相同。静脉注射必须是随机选择的，而且必须是不可预测的。
Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit.
在每个数据报中包括IV确保可以对每个接收到的数据报进行解密，即使某些数据报被丢弃，或者数据报在传输过程中被重新排序。
To avoid CBC encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs.
为了避免对不同数据包中非常相似的明文块进行CBC加密，实现过程中不得使用计数器或其他用于IVs的低汉明距离源。
Currently, there are no known issues regarding interactions between the AES and other aspects of ESP, such as use of certain authentication schemes.
目前，关于AES和ESP的其他方面之间的交互，例如某些身份验证方案的使用，还没有已知的问题。
The minimum number of bits sent from the key exchange protocol to the ESP algorithm must be greater than or equal to the key size.
从密钥交换协议发送到ESP算法的最小位数必须大于或等于密钥大小。
The cipher's encryption and decryption key is taken from the first <x> bits of the keying material, where <x> represents the required key size.
密码的加密和解密密钥取自密钥材料的第一个<x>位，其中<x>表示所需的密钥大小。
The first 4 test cases test AES-CBC encryption. Each test case includes the key, the plaintext, and the resulting ciphertext. The values of keys and data are either hexadecimal numbers (prefixed by "0x") or ASCII character strings (surrounded by double quotes). If a value is an ASCII character string, then the AES-CBC computation for the corresponding test case DOES NOT include the trailing null character ('\0') of the string. The computed cyphertext values are all hexadecimal numbers.
前4个测试用例测试AES-CBC加密。每个测试用例包括密钥、明文和生成的密文。键和数据的值可以是十六进制数（前缀为“0x”）或ASCII字符串（用双引号括起来）。如果值是ASCII字符串，则相应测试用例的AES-CBC计算不包括字符串的尾部空字符（'\0'）。计算出的cyphertext值都是十六进制数。
The last 4 test cases illustrate sample ESP packets using AES-CBC for encryption. All data are hexadecimal numbers (not prefixed by "0x").
最后4个测试用例演示了使用AES-CBC进行加密的示例ESP数据包。所有数据都是十六进制数（不以“0x”作为前缀）。
These test cases were verified using 2 independent implementations: the NIST AES-CBC reference implementation and an implementation provided by the authors of the Rijndael algorithm (http://csrc.nist.gov/encryption/aes/rijndael/ rijndael-unix-refc.tar).
这些测试用例使用两个独立的实现进行了验证：NIST AES-CBC参考实现和Rijndael算法作者提供的实现(http://csrc.nist.gov/encryption/aes/rijndael/ rijndael unix refc.tar）。
Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
Key : 0x06a9214036b8a15b512e03d534120006
IV : 0x3dafba429d9eb430b422da802c9fac41
Plaintext : "Single block msg"
Ciphertext: 0xe353779c1079aeb82708942dbe77181a
Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
Key : 0x06a9214036b8a15b512e03d534120006
IV : 0x3dafba429d9eb430b422da802c9fac41
Plaintext : "Single block msg"
Ciphertext: 0xe353779c1079aeb82708942dbe77181a
Case #2: Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key
Key : 0xc286696d887c9aa0611bbb3e2025a45a
IV : 0x562e17996d093d28ddb3ba695a2e6f58
Plaintext : 0x000102030405060708090a0b0c0d0e0f
101112131415161718191a1b1c1d1e1f
Ciphertext: 0xd296cd94c2cccf8a3a863028b5e1dc0a
7586602d253cfff91b8266bea6d61ab1
Case #2: Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key
Key : 0xc286696d887c9aa0611bbb3e2025a45a
IV : 0x562e17996d093d28ddb3ba695a2e6f58
Plaintext : 0x000102030405060708090a0b0c0d0e0f
101112131415161718191a1b1c1d1e1f
Ciphertext: 0xd296cd94c2cccf8a3a863028b5e1dc0a
7586602d253cfff91b8266bea6d61ab1
Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key
Key : 0x6c3ea0477630ce21a2ce334aa746c2cd
IV : 0xc782dc4c098c66cbd9cd27d825682c81
Plaintext : "This is a 48-byte message (exactly 3 AES blocks)"
Ciphertext: 0xd0a02b3836451753d493665d33f0e886
2dea54cdb293abc7506939276772f8d5
021c19216bad525c8579695d83ba2684
Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key
Key : 0x6c3ea0477630ce21a2ce334aa746c2cd
IV : 0xc782dc4c098c66cbd9cd27d825682c81
Plaintext : "This is a 48-byte message (exactly 3 AES blocks)"
Ciphertext: 0xd0a02b3836451753d493665d33f0e886
2dea54cdb293abc7506939276772f8d5
021c19216bad525c8579695d83ba2684
Case #4: Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key
Key : 0x56e47a38c5598974bc46903dba290349
IV : 0x8ce82eefbea0da3c44699ed7db51b7d9
Plaintext : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf
b0b1b2b3b4b5b6b7b8b9babbbcbdbebf
c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
Ciphertext: 0xc30e32ffedc0774e6aff6af0869f71aa
0f3af07a9a31a9c684db207eb0ef8e4e
35907aa632c3ffdf868bb7b29d3d46ad
83ce9f9a102ee99d49a53e87f4c3da55
Case #4: Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key
Key : 0x56e47a38c5598974bc46903dba290349
IV : 0x8ce82eefbea0da3c44699ed7db51b7d9
Plaintext : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf
b0b1b2b3b4b5b6b7b8b9babbbcbdbebf
c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
Ciphertext: 0xc30e32ffedc0774e6aff6af0869f71aa
0f3af07a9a31a9c684db207eb0ef8e4e
35907aa632c3ffdf868bb7b29d3d46ad
83ce9f9a102ee99d49a53e87f4c3da55
Case #5: Sample transport-mode ESP packet (ping 192.168.123.100) Key: 90d382b4 10eeba7a d938c46c ec1a82bf SPI: 4321 Source address: 192.168.123.3 Destination address: 192.168.123.100 Sequence number: 1 IV: e96e8c08 ab465763 fd098d45 dd3ff893
案例5：样本传输模式ESP数据包（ping 192.168.123.100）密钥：90d382b4 10eeba7a d938c46c ec1a82bf SPI:4321源地址：192.168.123.3目标地址：192.168.123.100序列号：1 IV:e96e8c08 ab465763 fd098d45 dd3ff893
Original packet: IP header (20 bytes): 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 Data (64 bytes): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637
原始数据包：IP头（20字节）：45000054 08f20000 4001f9fe c0a87b03 c0a87b64数据（64字节）：08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1C1D1F 20212223 24252627 28292B 2C2E2F 30313233 34353637
Augment data with: Padding: 01020304 05060708 090a0b0c 0d0e Pad length: 0e Next header: 01 (ICMP)
增加数据：填充：01020304 05060708 090a0b0c 0d0e填充长度：0e下一个标题：01（ICMP）
Pre-encryption Data with padding, pad length and next header (80 bytes): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01
带填充、焊盘长度和下一个标头（80字节）的预加密数据：08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1C1D1E1 1F 20212223 24252627 28292B 2C2E2F 30313233 34353637 01020304 05060708 090a0b0c 0D0E01
Post-encryption packet with SPI, Sequence number, IV: IP header: 4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64 SPI/Seq #: 00004321 00000001 IV: e96e8c08 ab465763 fd098d45 dd3ff893 Encrypted Data (80 bytes): f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856 a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a a269add0 47ad2d59 13ac19b7 cfbad4a6
带SPI的加密后数据包，序列号，IV:IP头：4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64 SPI/Seq#：000043210000000 1 IV:e96e8c08 ab465763 fd098d45 dd3ff893加密数据（80字节）：f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856 a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a A269 AD0 47ad2d59 13ac19b7 cfbad4a6
Case #6: Sample transport-mode ESP packet
(ping -p 77 -s 20 192.168.123.100)
Key: 90d382b4 10eeba7a d938c46c ec1a82bf
SPI: 4321
Source address: 192.168.123.3
Destination address: 192.168.123.100
Sequence number: 8
IV: 69d08df7 d203329d b093fc49 24e5bd80
Case #6: Sample transport-mode ESP packet
(ping -p 77 -s 20 192.168.123.100)
Key: 90d382b4 10eeba7a d938c46c ec1a82bf
SPI: 4321
Source address: 192.168.123.3
Destination address: 192.168.123.100
Sequence number: 8
IV: 69d08df7 d203329d b093fc49 24e5bd80
Original packet: IP header (20 bytes): 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64 Data (28 bytes): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777
原始数据包：IP头（20字节）：45000030 08fe0000 4001fa16 c0a87b03 c0a87b64数据（28字节）：0800b5e8 a80a0500 a69c083d 0b660e00 7777
Augment data with: Padding: 0102 Pad length: 02 Next header: 01 (ICMP)
增加数据：Padding:0102 Pad length:02下一个标题：01（ICMP）
Pre-encryption Data with padding, pad length and next header (32 bytes): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201
带填充、焊盘长度和下一个标头（32字节）的预加密数据：0800b5e8 a80a0500 a69c083d 0b660e00 777777 01020201
Post-encryption packet with SPI, Sequence number, IV: IP header: 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 SPI/Seq #: 00004321 00000008 IV: 69d08df7 d203329d b093fc49 24e5bd80 Encrypted Data (32 bytes): f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75
带SPI的加密后数据包，序列号，IV:IP头：4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 SPI/序列号：000043210000000 8 IV:69d08df7 d203329d b093fc49 24e5bd80加密数据（32字节）：f5199588 1EC4E0C4488987CE 742e8109 689bb379 d2d750c0 d915dca3 46a89f75
Case #7: Sample tunnel-mode ESP packet (ping 192.168.123.200) Key: 01234567 89abcdef 01234567 89abcdef SPI: 8765 Source address: 192.168.123.3 Destination address: 192.168.123.200 Sequence number: 2 IV: f4e76524 4f6407ad f13dc138 0f673f37
案例7：示例隧道模式ESP数据包（ping 192.168.123.200）密钥：01234567 89abcdef 01234567 89abcdef SPI:8765源地址：192.168.123.3目标地址：192.168.123.200序列号：2 IV:f4e76524 4f6407ad f13dc138 0f673f37
Original packet: IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 Data (64 bytes): 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637
原始数据包：IP头（20字节）：45000054 09040000 4001f988 c0a87b03 c0a87bc8数据（64字节）：08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1C1D11F 20212223 24252627 2829A2B 2C2E2F 30313233 34353637
Augment data with: Padding: 01020304 05060708 090a Pad length: 0a Next header: 04 (IP-in-IP)
使用以下内容扩充数据：Padding:01020304 05060708 090a Pad length:0a Next header:04（IP中的IP）
Pre-encryption Data with original IP header, padding, pad length and next header (96 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04
带有原始IP头、填充、焊盘长度和下一个头（96字节）的预加密数据：45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 02a20400 0809A0B 0C0E0F 10111213 14151617 18191a1b 1C1F1F 20212223 24252627 28292B 2C2E2F 30313233 34353637 01020304 05060708 090A04
Post-encryption packet with SPI, Sequence number, IV: IP header: 4500008c 09050000 4032f91e c0a87b03 c0a87bc8 SPI/Seq #: 00008765 00000002 IV: f4e76524 4f6407ad f13dc138 0f673f37 Encrypted Data (96 bytes): 773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8 e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5 c177f132 ad3fbfb2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d
带SPI的加密后数据包，序列号，IV:IP头：4500008c 09050000 4032f91e c0a87b03 c0a87bc8 SPI/Seq#：0000876500002 IV:f4e76524 4f6407ad f13dc138 0f673f37加密数据（96字节）：773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8 E4ECEC7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8A4D2D ecd136e5 c177f132 AD3FB2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d
Case #8: Sample tunnel-mode ESP packet
(ping -p ff -s 40 192.168.123.200)
Key: 01234567 89abcdef 01234567 89abcdef
SPI: 8765
Source address: 192.168.123.3
Destination address: 192.168.123.200
Sequence number: 5
IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22
Case #8: Sample tunnel-mode ESP packet
(ping -p ff -s 40 192.168.123.200)
Key: 01234567 89abcdef 01234567 89abcdef
SPI: 8765
Source address: 192.168.123.3
Destination address: 192.168.123.200
Sequence number: 5
IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22
Original packet: IP header (20 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 Data (48 bytes): 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
原始数据包：IP头（20字节）：45000044 090c0000 4001f990 c0a87b03 c0a87bc8数据（48字节）：0800d63c aa0a0200 c69c083d a3de0300 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Augment data with: Padding: 01020304 05060708 090a Pad length: 0a Next header: 04 (IP-in-IP)
使用以下内容扩充数据：Padding:01020304 05060708 090a Pad length:0a Next header:04（IP中的IP）
Pre-encryption Data with original IP header, padding, pad length and next header (80 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 01020304 05060708 090a0a04
带有原始IP头、填充、焊盘长度和下一个头（80字节）的预加密数据：45000044 090C00000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF01020304 05060708 090A04
Post-encryption packet with SPI, Sequence number, IV: IP header: 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 SPI/Seq #: 00008765 00000005 IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22 Encrypted Data (80 bytes): 15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3 d2726d9b 5ef6affc 6d17a0de cbb13892
带SPI的加密后数据包，序列号，IV:IP头：4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 SPI/Seq#：0000876500005 IV:85d47224 b5f3dd5d 2101d4ea 8dffab22加密数据（80字节）：15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3 d2726d9b 5ef6affc 6d17a0de cbb13892
For Phase 1 negotiations, IANA has assigned an Encryption Algorithm ID of 7 for AES-CBC.
对于第1阶段协商，IANA为AES-CBC分配了加密算法ID 7。
For Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 12 for ESP_AES.
对于第2阶段协商，IANA为ESP_AES分配了12个ESP转换标识符。
Since the AES allows variable key lengths, the Key Length attribute MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2 exchange [DOI].
由于AES允许可变密钥长度，因此必须在阶段1交换[IKE]和阶段2交换[DOI]中指定密钥长度属性。
A companion competition, to select the successor to SHA-1, the widely-used hash algorithm, recently concluded. The resulting hashes, called SHA-256, SHA-384 and SHA-512 [SHA2-1, SHA2-2] are capable of producing output of three different lengths (256, 384 and 512 bits), sufficient for the generation (within IKE) and authentication (within ESP) of the three AES key sizes (128, 192 and 256 bits).
最近，一场选择广泛使用的哈希算法SHA-1的继任者的竞赛结束了。产生的散列称为SHA-256、SHA-384和SHA-512[SHA2-1、SHA2-2]能够产生三种不同长度（256、384和512位）的输出，足以生成（IKE内）和认证（ESP内）三种AES密钥大小（128、192和256位）。
However, HMAC-SHA-1 [HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently considered of sufficient strength to serve both as IKE generators of 128-bit AES keys and as ESP authenticators for AES encryption using 128-bit keys.
然而，HMAC-SHA-1[HMAC-SHA]和HMAC-MD5[HMAC-MD5]目前被认为具有足够的强度，既可以作为128位AES密钥的IKE生成器，也可以作为使用128位密钥进行AES加密的ESP认证器。
Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their particular hardware and software configuration. Note that encryption necessarily impacts both sides of a secure channel, so such consideration must take into account not only the client side, but the server as well. However, a key size of 128 bits is considered secure for the foreseeable future.
在考虑特定硬件和软件配置的性能考虑因素时，鼓励实现使用最大的密钥大小。请注意，加密必然会影响安全通道的两侧，因此这种考虑不仅要考虑客户端，还要考虑服务器。然而，128位的密钥大小在可预见的将来被认为是安全的。
For more information regarding the necessary use of random IV values, see [CRYPTO-B].
有关随机IV值必要使用的更多信息，请参阅[CRYPTO-B]。
For further security considerations, the reader is encouraged to read [AES].
出于进一步的安全考虑，鼓励读者阅读[AES]。
IANA has assigned Encryption Algorithm ID 7 to AES-CBC. IANA has assigned ESP Transform Identifier 12 to ESP_AES.
IANA已将加密算法ID 7分配给AES-CBC。IANA已将ESP转换标识符12分配给ESP_AES。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
(AES)," November 2001.
http://csrc.nist.gov/publications/fips/fips197/
fips-197.{ps,pdf}
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
(AES)," November 2001.
http://csrc.nist.gov/publications/fips/fips197/
fips-197.{ps,pdf}
[CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[CBC]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the
IP Security Protocols", Proceedings of the Symposium on
Network and Distributed System Security, San Diego, CA,
pp. 155-160, February 1997.
http://www.research.att.com/~smb/papers/probtxt.pdf
[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the
IP Security Protocols", Proceedings of the Symposium on
Network and Distributed System Security, San Diego, CA,
pp. 155-160, February 1997.
http://www.research.att.com/~smb/papers/probtxt.pdf
[CRYPTO-S] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.
[CRYPTO-S]B.Schneier，“应用密码学第二版”，约翰·威利父子出版社，纽约，1995年，ISBN 0-471-12845-7。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[EVALUATION] Ferguson, N. and B. Schneier, "A Cryptographic Evaluation of IPsec," Counterpane Internet Security, Inc., January 2000. http://www.counterpane.com/ipsec.pdf
[评估]Ferguson，N.和B.Schneier，“IPsec的加密评估”，Counterpane Internet Security，Inc.，2000年1月。http://www.counterpane.com/ipsec.pdf
[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[HMAC-MD5]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[HMAC-SHA]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques," NIST Special
Publication 800-38A, December 2001.
http://csrc.nist.gov/publications/nistpubs/
800-38a/sp800-38a.pdf
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques," NIST Special
Publication 800-38A, December 2001.
http://csrc.nist.gov/publications/nistpubs/
800-38a/sp800-38a.pdf
[PERF-1] Bassham, L. III, "Efficiency Testing of ANSI C
Implementations of Round1 Candidate Algorithms for the
Advanced Encryption Standard."
http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf
[PERF-1] Bassham, L. III, "Efficiency Testing of ANSI C
Implementations of Round1 Candidate Algorithms for the
Advanced Encryption Standard."
http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf
[PERF-2] Lipmaa, Helger, "AES/Rijndael: speed."
http://www.tcs.hut.fi/~helger/aes/rijndael.html
[PERF-2] Lipmaa, Helger, "AES/Rijndael: speed."
http://www.tcs.hut.fi/~helger/aes/rijndael.html
[PERF-3] Nechvetal, J., E. Barker, D. Dodson, M. Dworkin, J.
Foti and E. Roback, "Status Report on the First Round of
the Development of the Advanced Encryption Standard."
http://csrc.nist.gov/encryption/aes/round1/r1report.pdf
[PERF-3] Nechvetal, J., E. Barker, D. Dodson, M. Dworkin, J.
Foti and E. Roback, "Status Report on the First Round of
the Development of the Advanced Encryption Standard."
http://csrc.nist.gov/encryption/aes/round1/r1report.pdf
[PERF-4] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the AES Submissions." http://www.counterpane.com/aes-performance.pdf
[PERF-4]Schneier，B.，J.Kelsey，D.Whiting，D.Wagner，C.Hall和N.Ferguson，“AES提交的性能比较。”http://www.counterpane.com/aes-performance.pdf
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[ROAD] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[ROAD]Thayer，R.，Doraswamy，N.和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[SHA2-1] NIST, FIPS PUB 180-2 "Specifications for the Secure Hash
Standard," August 2002.
http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf
[SHA2-1] NIST, FIPS PUB 180-2 "Specifications for the Secure Hash
Standard," August 2002.
http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf
[SHA2-2] "Descriptions of SHA-256, SHA-384, and SHA-512."
http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf
[SHA2-2] "Descriptions of SHA-256, SHA-384, and SHA-512."
http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf
Portions of this text, as well as its general structure, were unabashedly lifted from [CBC].
这篇文章的部分内容，以及它的总体结构，都是毫不掩饰地从[CBC]中删去的。
The authors want to thank Hilarie Orman for providing expert advice (and a sanity check) on key sizes, requirements for Diffie-Hellman groups, and IKE interactions. We also thank Scott Fluhrer for his helpful comments and recommendations.
作者要感谢Hilarie Orman就关键尺寸、Diffie-Hellman组的要求和IKE交互提供了专家建议（和健康检查）。我们还感谢Scott Fluhrer提出了有益的意见和建议。
Sheila Frankel NIST 820 West Diamond Ave. Room 677 Gaithersburg, MD 20899
Sheila Frankel NIST马里兰州盖瑟斯堡西钻石大道820号677室20899
Phone: +1 (301) 975-3297
EMail: sheila.frankel@nist.gov
Phone: +1 (301) 975-3297
EMail: sheila.frankel@nist.gov
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134
Scott Kelly Airespace 110 Nortech Pkwy加利福尼亚州圣何塞95134
Phone: +1 408 635 2000
EMail: scott@hyperthought.com
Phone: +1 408 635 2000
EMail: scott@hyperthought.com
Rob Glenn NIST 820 West Diamond Ave. Room 605 Gaithersburg, MD 20899
Rob Glenn NIST马里兰州盖瑟斯堡西钻石大道820号605室20899
Phone: +1 (301) 975-3667
EMail: rob.glenn@nist.gov
Phone: +1 (301) 975-3667
EMail: rob.glenn@nist.gov
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。