Network Working Group S. Kent
Request for Comments: 2406 BBN Corp
Obsoletes: 1827 R. Atkinson
Category: Standards Track @Home Network
November 1998
Network Working Group S. Kent
Request for Comments: 2406 BBN Corp
Obsoletes: 1827 R. Atkinson
Category: Standards Track @Home Network
November 1998
IP Encapsulating Security Payload (ESP)
IP封装安全有效负载（ESP）
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Table of Contents
目录
1. Introduction..................................................2
2. Encapsulating Security Payload Packet Format..................3
2.1 Security Parameters Index................................4
2.2 Sequence Number .........................................4
2.3 Payload Data.............................................5
2.4 Padding (for Encryption).................................5
2.5 Pad Length...............................................7
2.6 Next Header..............................................7
2.7 Authentication Data......................................7
3. Encapsulating Security Protocol Processing....................7
3.1 ESP Header Location......................................7
3.2 Algorithms..............................................10
3.2.1 Encryption Algorithms..............................10
3.2.2 Authentication Algorithms..........................10
3.3 Outbound Packet Processing..............................10
3.3.1 Security Association Lookup........................11
3.3.2 Packet Encryption..................................11
3.3.3 Sequence Number Generation.........................12
3.3.4 Integrity Check Value Calculation..................12
3.3.5 Fragmentation......................................13
3.4 Inbound Packet Processing...............................13
3.4.1 Reassembly.........................................13
3.4.2 Security Association Lookup........................13
3.4.3 Sequence Number Verification.......................14
3.4.4 Integrity Check Value Verification.................15
1. Introduction..................................................2
2. Encapsulating Security Payload Packet Format..................3
2.1 Security Parameters Index................................4
2.2 Sequence Number .........................................4
2.3 Payload Data.............................................5
2.4 Padding (for Encryption).................................5
2.5 Pad Length...............................................7
2.6 Next Header..............................................7
2.7 Authentication Data......................................7
3. Encapsulating Security Protocol Processing....................7
3.1 ESP Header Location......................................7
3.2 Algorithms..............................................10
3.2.1 Encryption Algorithms..............................10
3.2.2 Authentication Algorithms..........................10
3.3 Outbound Packet Processing..............................10
3.3.1 Security Association Lookup........................11
3.3.2 Packet Encryption..................................11
3.3.3 Sequence Number Generation.........................12
3.3.4 Integrity Check Value Calculation..................12
3.3.5 Fragmentation......................................13
3.4 Inbound Packet Processing...............................13
3.4.1 Reassembly.........................................13
3.4.2 Security Association Lookup........................13
3.4.3 Sequence Number Verification.......................14
3.4.4 Integrity Check Value Verification.................15
3.4.5 Packet Decryption..................................16
4. Auditing.....................................................17
5. Conformance Requirements.....................................18
6. Security Considerations......................................18
7. Differences from RFC 1827....................................18
Acknowledgements................................................19
References......................................................19
Disclaimer......................................................20
Author Information..............................................21
Full Copyright Statement........................................22
3.4.5 Packet Decryption..................................16
4. Auditing.....................................................17
5. Conformance Requirements.....................................18
6. Security Considerations......................................18
7. Differences from RFC 1827....................................18
Acknowledgements................................................19
References......................................................19
Disclaimer......................................................20
Author Information..............................................21
Full Copyright Statement........................................22
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [KA97a].
封装安全有效负载（ESP）标头旨在提供IPv4和IPv6中的混合安全服务。ESP可单独应用，与IP认证头（AH）[KA97b]结合使用，或以嵌套方式应用，例如通过使用隧道模式（参见“互联网协议的安全架构”[KA97a]，以下简称为安全架构文件）。可以在一对通信主机之间、一对通信安全网关之间或安全网关与主机之间提供安全服务。有关如何在各种网络环境中使用ESP和AH的更多详细信息，请参阅安全体系结构文档[KA97a]。
The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below.
ESP报头插入在IP报头之后、上层协议报头之前（传输模式）或封装的IP报头之前（隧道模式）。下面将更详细地描述这些模式。
ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with (optional) confidentiality. The anti-replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) Traffic flow
ESP用于提供机密性、数据源身份验证、无连接完整性、反重播服务（部分序列完整性的一种形式）和有限的流量机密性。所提供的一组服务取决于安全关联建立时选择的选项和实施的位置。保密性可独立于所有其他服务进行选择。但是，在没有完整性/身份验证的情况下使用保密性（在ESP中或在AH中单独使用）可能会使流量受到某些形式的主动攻击，从而破坏保密服务（参见[Bel96]）。数据源身份验证和无连接完整性是联合服务（以下统称为“身份验证”），作为选项与（可选）一起提供保密性。只有在选择了数据源身份验证的情况下，才能选择反重播服务，其选择完全由接收方决定。（虽然默认情况下要求发送方增加用于反重播的序列号，但只有在接收方检查序列号时，该服务才有效。）交通流
confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. Note that although both confidentiality and authentication are optional, at least one of them MUST be selected.
保密性要求选择隧道模式，如果在安全网关上实现，则保密性最为有效，在安全网关中，流量聚合可能能够屏蔽真实的源-目的模式。请注意，尽管机密性和身份验证都是可选的，但必须至少选择其中一个。
It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by ESP and AH, the concept of Security Associations, the ways in which ESP can be used in conjunction with the Authentication Header (AH), and the different key management options available for ESP and AH. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via IKE [HC98].)
假定读者熟悉安全体系结构文档中描述的术语和概念。特别是，读者应熟悉ESP和AH提供的安全服务的定义、安全关联的概念、ESP与身份验证头（AH）结合使用的方式，以及ESP和AH可用的不同密钥管理选项。（关于最后一个主题，AH和ESP当前所需的密钥管理选项是通过IKE手动键控和自动键控[HC98]。）
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、可和可选时，应按照RFC 2119[Bra97]中的说明进行解释。
The protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2].
ESP头前面的协议头（IPv4、IPv6或扩展）将在其协议（IPv4）或下一个头（IPv6、扩展）字段[STD-2]中包含值50。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |erage*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Authentication Data (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |erage*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Authentication Data (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see
* 如果有效载荷字段中包含加密同步数据，例如初始化向量（IV，请参阅
Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext.
第2.3节），通常不加密本身，尽管它通常被称为密文的一部分。
The following subsections define the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an Integrity Check Value (ICV, see Section 2.7). Whether or not an option is selected is defined as part of Security Association (SA) establishment. Thus the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs.
以下小节定义了标题格式中的字段。“可选”是指如果未选择该选项，则忽略该字段，即该字段既不存在于传输的数据包中，也不存在于完整性检查值计算的格式化数据包中（ICV，见第2.7节）。是否选择某个选项被定义为安全关联（SA）建立的一部分。因此，在SA的持续时间内，给定SA的ESP数据包的格式是固定的。相反，对于所有SA，“必填”字段始终以ESP数据包格式存在。
The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI field is mandatory.
SPI是一个任意32位值，它与目标IP地址和安全协议（ESP）结合使用，唯一标识此数据报的安全关联。范围为1到255的SPI值集由互联网分配号码管理局（IANA）保留，以备将来使用；IANA通常不会指定保留的SPI值，除非RFC中指定使用指定的SPI值。它通常由目标系统在建立SA时选择（有关更多详细信息，请参阅安全体系结构文档）。SPI字段是必需的。
The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.
SPI值0（0）保留供本地特定于实现的使用，不得通过线路发送。例如，当IPsec实现已请求其密钥管理实体建立新SA，但SA尚未建立时，密钥管理实现可使用零SPI值来表示“不存在安全关联”。
This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below).
此无符号32位字段包含单调递增的计数器值（序列号）。它是强制性的，并且始终存在，即使接收方没有选择为特定SA启用反重播服务。序列号字段的处理由接收方自行决定，即发送方必须始终发送此字段，但接收方无需对其采取行动（请参阅下文“入站数据包处理”部分中的序列号验证讨论）。
The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 for more details on how the Sequence Number is generated.) If anti-replay is enabled
建立SA时，发送方计数器和接收方计数器初始化为0。（使用给定SA发送的第一个数据包的序列号为1；有关如何生成序列号的更多详细信息，请参阅第3.3.3节。）如果启用了反重播
(the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.
（默认情况下），不得允许传输的序列号循环。因此，在SA上传输第2^32个数据包之前，必须重置发送方计数器和接收方计数器（通过建立新SA和新密钥）。
Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC.
有效负载数据是一个可变长度字段，包含由下一个标头字段描述的数据。有效负载数据字段是必填字段，长度为整数字节。如果用于加密有效载荷的算法需要加密同步数据，例如初始化向量（IV），则该数据可显式地携带在有效载荷字段中。任何需要此类显式、每包同步数据的加密算法必须指明长度、此类数据的任何结构以及该数据的位置，作为RFC的一部分，指定该算法如何与ESP一起使用。如果此类同步数据是隐式的，则导出数据的算法必须是RFC的一部分。
Note that with regard to ensuring the alignment of the (real) ciphertext in the presence of an IV:
注意，关于确保在存在IV的情况下（真实）密文对齐：
o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved.
o 对于某些基于IV的操作模式，接收器将IV视为密文的开始，直接将其输入算法。在这些模式中，（实）密文的起始对齐在接收器处不是问题。o在某些情况下，接收者将IV与密文分开读取。在这些情况下，算法规范必须说明如何实现（实）密文的对齐。
Several factors require or motivate use of the Padding field.
有几个因素需要或促使使用填充字段。
o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm.
o 如果采用的加密算法要求明文是某些字节数（例如，分组密码的块大小）的倍数，则填充字段用于将明文（包括有效载荷数据、填充长度和下一个报头字段以及填充）填充到算法所需的大小。
o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically,
o 无论加密算法要求如何，也可能需要填充，以确保生成的密文终止于4字节边界。明确地
the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary.
Pad Length和Next Header字段必须在4字节字内右对齐，如上图ESP数据包格式所示，以确保身份验证数据字段（如果存在）在4字节边界上对齐。
o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care.
o 超出上述算法或对齐原因所需的填充可用于隐藏有效载荷的实际长度，以支持（部分）交通流机密性。然而，包含这种额外的填充会对带宽产生不利影响，因此应谨慎使用。
The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding.
发送方可以添加0-255字节的填充。在ESP数据包中包含Padding字段是可选的，但所有实现都必须支持Padding的生成和使用。
a. For the purpose of ensuring that the bits to be encrypted are a multiple of the algorithm's blocksize (first bullet above), the padding computation applies to the Payload Data exclusive of the IV, the Pad Length, and Next Header fields.
a. 为了确保要加密的比特是算法块大小的倍数（上面的第一个项目符号），填充计算应用于不包括IV、Pad长度和Next报头字段的有效载荷数据。
b. For the purposes of ensuring that the Authentication Data is aligned on a 4-byte boundary (second bullet above), the padding computation applies to the Payload Data inclusive of the IV, the Pad Length, and Next Header fields.
b. 为了确保认证数据在4字节边界上对齐（上面的第二个项目符号），填充计算应用于有效负载数据，包括IV、Pad长度和Next报头字段。
If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.)
如果需要填充字节，但加密算法未指定填充内容，则必须使用以下默认处理。填充字节由一系列（无符号，1字节）整数值初始化。附加到明文的第一个填充字节编号为1，随后的填充字节组成一个单调递增的序列：1、2、3、。。。当采用此填充方案时，接收器应检查填充字段。（之所以选择此方案，是因为它相对简单，易于在硬件中实现，并且如果接收器在解密时检查填充值，则在没有其他完整性措施的情况下，它对某些形式的“剪切粘贴”攻击提供有限的保护。）
Any encryption algorithm that requires Padding other than the default described above, MUST define the Padding contents (e.g., zeros or random data) and any required receiver processing of these Padding bytes in an RFC specifying how the algorithm is used with ESP. In such circumstances, the content of the Padding field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field or that a
除上述默认值外，任何需要填充的加密算法都必须定义填充内容（例如，零或随机数据）以及RFC中这些填充字节的任何所需接收器处理，并指定在这种情况下算法如何与ESP一起使用，填充字段的内容将由相应算法RFC中选择和定义的加密算法和模式确定。相关算法RFC可以指定接收器必须检查填充字段，或者
receiver MUST inform senders of how the receiver will handle the Padding field.
接收方必须通知发送方接收方将如何处理填充字段。
The Pad Length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that no Padding bytes are present. The Pad Length field is mandatory.
Pad Length字段指示紧靠它前面的Pad字节数。有效值的范围为0-255，其中值为零表示不存在填充字节。焊盘长度字段是必填字段。
The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol identifier. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory.
下一个报头是一个8位字段，用于标识有效负载数据字段中包含的数据类型，例如，IPv6中的扩展报头或上层协议标识符。该字段的值从互联网分配号码管理局（IANA）最近的“分配号码”[STD-2]RFC中定义的IP协议号码集中选择。下一个标题字段是必填字段。
The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
身份验证数据是一个可变长度字段，包含通过ESP数据包减去身份验证数据计算的完整性检查值（ICV）。字段的长度由所选的身份验证函数指定。“身份验证数据”字段是可选的，仅当已为相关SA选择了身份验证服务时，才会包含该字段。认证算法规范必须指定ICV的长度以及验证的比较规则和处理步骤。
Like AH, ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, but not the IP header. (In this mode, note that for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.)
与AH一样，ESP可采用两种方式：运输模式或隧道模式。前一种模式仅适用于主机实现，并为上层协议提供保护，但不保护IP报头。（在此模式下，请注意，对于“堆栈中的凹凸”或“导线中的凹凸”如安全体系结构文档中所定义的实现，入站和出站IP碎片可能需要IPsec实现来执行额外的IP重组/碎片化，以符合本规范并提供透明的IPsec支持。在这些实现中执行此类操作需要特别小心当使用多个接口时。）
In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of
在传输模式下，ESP插入在IP头之后和上层协议之前，例如TCP、UDP、ICMP等，或者插入在任何其他已插入的IPsec头之前。在
IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (The "ESP trailer" encompasses any Padding, plus the Pad Length, and Next Header fields.)
IPv4，这意味着将ESP放在IP头（及其包含的任何选项）之后，但放在上层协议之前。（请注意，术语“传输”模式不应被误解为仅限于TCP和UDP。例如，ICMP消息可以使用“传输”模式或“隧道”模式发送。）下图说明了典型IPv4数据包的ESP传输模式定位，以“之前和之后”为基础。（ESP拖车包含任何填充、填充长度和下一标题字段。）
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it generally may be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet.
在IPv6上下文中，ESP被视为端到端有效负载，因此应该出现在逐跳、路由和分段扩展头之后。目标选项扩展标题可能出现在ESP标题之前或之后，具体取决于所需的语义。但是，由于ESP仅保护ESP标头之后的字段，因此通常需要将目标选项标头放置在ESP标头之后。下图说明了典型IPv6数据包的ESP传输模式定位。
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
* = if present, could be before ESP, after ESP, or both
* =如果存在，可以在ESP之前、ESP之后或两者都存在
ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported.
ESP和AH头可以以多种模式组合。IPsec体系结构文档描述了必须支持的安全关联的组合。
Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets.
隧道模式ESP可用于主机或安全网关。当在安全网关中实施ESP（以保护用户传输流量）时，必须使用隧道模式。在隧道模式下，“内部”IP报头携带最终的源地址和目标地址，“外部”IP报头可能包含不同的IP地址，例如安全网关的地址。在隧道模式下，ESP保护整个内部IP数据包，包括整个内部IP报头。隧道模式下ESP相对于外部IP报头的位置与传输模式下ESP的位置相同。下图说明了典型IPv4和IPv6数据包的ESP隧道模式定位。
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|<--------- encrypted ---------->|
|<----------- authenticated ---------->|
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|<--------- encrypted ---------->|
|<----------- authenticated ---------->|
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth|
------------------------------------------------------------
|<--------- encrypted ----------->|
|<---------- authenticated ---------->|
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth|
------------------------------------------------------------
|<--------- encrypted ----------->|
|<---------- authenticated ---------->|
* = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below.
* =如果存在，下面讨论外部IP hdr/扩展的构造和内部IP hdr/扩展的修改。
The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements". Other algorithms MAY be supported. Note that although both confidentiality and authentication are optional, at least one of these services MUST be selected hence both algorithms MUST NOT be simultaneously NULL.
第5节“一致性要求”中描述了实现算法的强制性要求。可能支持其他算法。请注意，尽管机密性和身份验证都是可选的，但必须至少选择其中一个服务，因此这两个算法不能同时为NULL。
The encryption algorithm employed is specified by the SA. ESP is designed for use with symmetric encryption algorithms. Because IP packets may arrive out of order, each packet must carry any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the packet header. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Note that since encryption (confidentiality) is optional, this algorithm may be "NULL".
采用的加密算法由SA指定。ESP设计用于对称加密算法。由于IP数据包可能会无序到达，因此每个数据包必须携带允许接收方建立加密同步以进行解密所需的任何数据。该数据可以在有效载荷字段中显式地携带，例如作为IV（如上所述），或者该数据可以从分组报头导出。由于ESP提供了对明文的填充，所以ESP使用的加密算法可能表现出块模式或流模式特征。请注意，由于加密（机密性）是可选的，因此此算法可能为“空”。
The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. Note that since authentication is optional, this algorithm may be "NULL".
用于ICV计算的认证算法由SA指定。对于点对点通信，合适的认证算法包括基于对称加密算法（例如DES）或单向散列函数（例如MD5或SHA-1）的密钥消息认证码（MAC）。对于多播通信，单向散列算法与非对称签名算法相结合是合适的，尽管性能和空间方面的考虑目前阻碍了此类算法的使用。请注意，由于身份验证是可选的，因此此算法可能为“NULL”。
In transport mode, the sender encapsulates the upper layer protocol information in the ESP header/trailer, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document. If there is more than one IPsec header/extension required by security policy, the order of the application of the security headers MUST be defined by security policy.
在传输模式下，发送方将上层协议信息封装在ESP头/尾中，并保留指定的IP头（以及IPv6上下文中的任何IP扩展头）。在隧道模式下，外部和内部IP头/扩展可以以多种方式相互关联。安全体系结构文档中描述了封装过程中外部IP头/扩展的构造。如果安全策略需要多个IPsec头/扩展，则安全策略必须定义安全头的应用顺序。
ESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for ESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document.
只有在IPsec实现确定出站数据包与调用ESP处理的SA关联后，ESP才会应用于出站数据包。安全体系结构文档中描述了确定将什么（如果有的话）IPsec处理应用于出站流量的过程。
In this section, we speak in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm. Accordingly, the sender:
在本节中，我们将讨论始终应用加密的问题，因为它涉及到格式问题。这是在理解使用空加密算法“不保密”的情况下完成的。因此，发送方：
1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. - for tunnel mode -- the entire original IP datagram. 2. adds any necessary padding. 3. encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, algorithm mode indicated by the SA and cryptographic synchronization data (if any). - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the encryption algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the encryption algorithm as per the algorithm specification.
1. 封装（到ESP有效负载字段中）：-对于传输模式——仅封装原始上层协议信息。-对于隧道模式——整个原始IP数据报。2.添加任何必要的填充。3.使用SA指示的密钥、加密算法、算法模式和加密同步数据（如果有）加密结果（有效负载数据、填充、焊盘长度和下一个标头）。-如果显示了显式加密同步数据，例如IV，则根据算法规范将其输入加密算法，并将其置于有效载荷字段中。-如果指示了隐式加密同步数据，例如IV，则根据算法规范构造该数据并将其输入加密算法。
The exact steps for constructing the outer IP header depend on the mode (transport or tunnel) and are described in the Security Architecture document.
构建外部IP报头的确切步骤取决于模式（传输或隧道），并在安全体系结构文档中描述。
If authentication is selected, encryption is performed first, before the authentication, and the encryption does not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Note that since the Authentication Data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV.
如果选择了身份验证，则首先在身份验证之前执行加密，并且加密不包含身份验证数据字段。这种处理顺序有助于接收器在解密数据包之前快速检测和拒绝重播或伪造数据包，从而潜在地减少拒绝服务攻击的影响。它还允许在接收器处并行处理分组的可能性，即解密可以与认证并行进行。注意，由于认证数据不受加密保护，因此必须使用密钥认证算法来计算ICV。
The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field. Thus the first packet sent using a given SA will have a Sequence Number of 1.
建立SA时，发送方计数器初始化为0。发送方增加此SA的序列号，并将新值插入序列号字段。因此，使用给定SA发送的第一个分组的序列号为1。
If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.)
如果启用了反重播功能（默认设置），则发送方会进行检查，以确保在序列号字段中插入新值之前计数器没有循环。换句话说，如果这样做会导致序列号循环，则发送方不得在SA上发送数据包。试图传输可能导致序列号溢出的数据包是可审核事件。（请注意，这种序列号管理方法不需要使用模运算。）
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see 3.4.3). Thus, if the counter has cycled, the sender will set up a new SA and key (unless the SA was configured with manual key management).
除非接收方另有通知（见3.4.3），否则发送方假定默认启用了反重播功能。因此，如果计数器已循环，发送方将设置新的SA和密钥（除非SA配置了手动密钥管理）。
If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero.
如果禁用了防重播功能，发送方无需监控或重置计数器，例如，在手动密钥管理的情况下（参见第5节）。但是，发送方仍然增加计数器，当它达到最大值时，计数器将回滚到零。
If authentication is selected for the SA, the sender computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. Note that the last 4 fields will be in ciphertext form, since encryption is performed prior to authentication.
如果为SA选择了身份验证，则发送方计算ESP数据包减去身份验证数据后的ICV。因此，SPI、序列号、有效载荷数据、填充（如果存在）、填充长度和下一个报头都包含在ICV计算中。请注意，最后4个字段将采用密文形式，因为加密是在身份验证之前执行的。
For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the length of this byte string does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet, (after the Next Header field) prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions.
对于某些身份验证算法，执行ICV计算的字节字符串必须是算法指定的块大小的倍数。如果此字节字符串的长度与算法的块大小要求不匹配，则在ICV计算之前，必须将隐式填充添加到ESP数据包的末尾（在下一个报头字段之后）。填充八位字节的值必须为零。块大小（以及填充的长度）由算法规范指定。此填充不随数据包一起传输。注意，MD5和SHA-1被视为具有1字节的块大小，因为它们的内部填充约定。
If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments.
如有必要，在IPsec实现中的ESP处理之后执行分段。因此，传输模式ESP仅应用于整个IP数据报（而不是IP片段）。已应用ESP的IP数据包本身可能会在路由过程中被路由器分割，并且必须在接收器进行ESP处理之前重新组装这些片段。在隧道模式下，ESP应用于IP数据包，其有效负载可能是碎片化IP数据包。例如，安全网关或“堆栈中的通气”或“线路中的通气”IPsec实现（如安全体系结构文档中所定义）可以将隧道模式ESP应用于此类片段。
NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet.
注意：对于传输模式——如第3.1节开头所述，堆栈中的bump和有线实现中的bump可能必须首先重新组装由本地IP层分割的数据包，然后应用IPsec，然后分割生成的数据包。
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.
注意：对于IPv6——对于堆栈中的bump和有线实现中的bump，有必要遍历所有扩展头，以确定是否存在分段头，因此需要在IPsec处理之前重新组装数据包。
If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.
如果需要，在ESP处理之前进行重新组装。如果提供给ESP处理的数据包似乎是IP片段，即偏移字段非零或设置了“更多片段”标志，则接收方必须丢弃该数据包；这是一个可审核的事件。此事件的审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（在IPv6中）流ID。
NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet.
注意：对于数据包重组，当前的IPv4规范既不要求偏移量字段为零，也不要求清除MORE FRAGMENTS标志。为了让IPsec处理重新组装的数据包（而不是作为明显的片段丢弃），IP代码必须在重新组装数据包后完成这两件事。
Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will
在接收到包含ESP报头的（重新组装的）数据包后，接收器根据目标IP地址、安全协议（ESP）和SPI确定适当的（单向）SA。（此过程在安全体系结构文档中有更详细的描述。）SA指示序列号字段是否将
be checked, whether the Authentication Data field should be present, and it will specify the algorithms and keys to be employed for decryption and ICV computations (if applicable).
检查验证数据字段是否应存在，它将指定用于解密和ICV计算的算法和密钥（如果适用）。
If no valid Security Association exists for this session (for example, the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the cleartext Flow ID.
如果此会话不存在有效的安全关联（例如，接收方没有密钥），则接收方必须丢弃该数据包；这是一个可审核的事件。此事件的审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（在IPv6中）明文流ID。
All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.)
所有ESP实施必须支持反重播服务，尽管其使用可能由接收者根据每个SA启用或禁用。除非还为SA启用了身份验证服务，否则不得启用此服务，因为否则序列号字段未受到完整性保护。（请注意，对于将流量定向到单个SA的多个发送方之间的传输序列号值，没有管理规定（无论目标地址是单播、广播还是多播）。因此，不应在使用单个SA的多发送方环境中使用反重播服务。）
If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.3), if an SA establishment protocol such as IKE is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection.
如果接收器未为SA启用反重播，则不会对序列号执行入站检查。但是，从发送方的角度来看，默认情况是假定在接收方启用了反重播。为避免发送方进行不必要的序列号监控和SA设置（参见第3.3.3节），如果采用了诸如IKE之类的SA建立协议，则接收方应在SA建立期间通知发送方，如果接收方不提供防重放保护。
If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets.
如果接收器已为此SA启用了反重播服务，则在建立SA时，SA的接收数据包计数器必须初始化为零。对于每个接收到的分组，接收机必须验证该分组包含的序列号与在该SA的生命周期内接收到的任何其他分组的序列号不重复。这应该是数据包与SA匹配后应用于数据包的第一次ESP检查，以加快重复数据包的拒绝。
Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default.
通过使用滑动接收窗口拒绝重复项。（如何实现窗口是一个局部问题，但以下文本描述了实现必须展示的功能。）必须支持最小窗口大小32；但窗口大小为64是首选，应作为默认值使用。
Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.)
接收器可以选择另一个窗口大小（大于最小值）。（接收者不会将窗口大小通知发送者。）
The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in the Security Architecture document.
窗口的“右”边缘表示此SA上接收到的最高已验证序列号值。包含序列号低于窗口“左”边缘的数据包将被拒绝。根据窗口内接收的数据包列表检查窗口内的数据包。安全体系结构文档中描述了基于位掩码的使用来执行该检查的有效方法。
If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds.
如果接收到的数据包落在窗口内并且是新的，或者如果数据包在窗口的右侧，则接收机进行ICV验证。如果ICV验证失败，接收方必须将接收到的IP数据报丢弃为无效；这是一个可审核的事件。此事件的审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（在IPv6中）流ID。仅当ICV验证成功时，才会更新接收窗口。
DISCUSSION:
讨论：
Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data.
请注意，如果数据包在窗口内且是新的，或者在“右侧”的窗口外，则接收器必须在更新序列号窗口数据之前对数据包进行身份验证。
If authentication has been selected, the receiver computes the ICV over the ESP packet minus the Authentication Data using the specified authentication algorithm and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below.
如果选择了身份验证，则接收器使用指定的身份验证算法计算ESP数据包减去身份验证数据后的ICV，并验证其是否与数据包的身份验证数据字段中包含的ICV相同。计算详情如下。
If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the cleartext Flow ID.
如果计算出的和接收到的ICV匹配，则数据报有效，并被接受。如果测试失败，则接收器必须将接收到的IP数据报视为无效而丢弃；这是一个可审核的事件。日志数据应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（在IPv6中）明文流ID。
DISCUSSION:
讨论：
Begin by removing and saving the ICV value (Authentication Data field). Next check the overall length of the ESP packet minus the Authentication Data. If implicit padding is required, based on
首先删除并保存ICV值（身份验证数据字段）。接下来检查ESP数据包的总长度减去身份验证数据。如果需要隐式填充，则基于
the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.)
身份验证算法的blocksize，将零填充字节直接附加到ESP数据包末尾的下一个标头字段之后。使用算法规范定义的比较规则，执行ICV计算并将结果与保存的值进行比较。（例如，如果数字签名和单向散列用于ICV计算，则匹配过程更复杂。）
As in section 3.3.2, "Packet Encryption", we speak here in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm. Accordingly, the receiver:
正如第3.3.2节“数据包加密”中所述，由于格式的影响，我们在这里谈论的是始终应用的加密。这是在理解使用空加密算法“不保密”的情况下完成的。因此，接收方：
1. decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification. - If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. 2. processes any padding as specified in the encryption algorithm specification. If the default padding scheme (see Section 2.4) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer. 3. reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field.
1. 使用SA指示的密钥、加密算法、算法模式和加密同步数据（如果有）解密ESP有效负载数据、填充、填充长度和下一个报头。-如果指示了显式加密同步数据，例如IV，则根据算法规范，从有效载荷字段获取该数据，并将其输入解密算法。-如果指示隐式密码同步数据，例如IV，则构造IV的本地版本，并根据算法规范将其输入到解密算法。2.处理加密算法规范中指定的任何填充。如果采用了默认的填充方案（参见第2.4节），则接收方应在将解密数据传递到下一层之前，在移除填充之前检查填充字段。3.从以下内容重建原始IP数据报：-对于传输模式--原始IP报头加上ESP有效负载字段中的原始上层协议信息-对于隧道模式--隧道IP报头+ESP有效负载字段中的整个IP数据报。
The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field.
重建原始数据报的确切步骤取决于模式（传输或隧道），并在安全体系结构文档中描述。至少，在IPv6上下文中，接收方应确保解密的数据是8字节对齐的，以便于通过下一个报头字段中标识的协议进行处理。
If authentication has been selected, verification and decryption MAY be performed serially or in parallel. If performed serially, then ICV verification SHOULD be performed first. If performed in parallel, verification MUST be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. Note:
如果选择了身份验证，则可以串行或并行执行验证和解密。如果连续执行，则应首先执行ICV验证。如果并行执行，则必须在将解密的数据包传递给进一步处理之前完成验证。这种处理顺序有助于接收器在解密数据包之前快速检测和拒绝重播或伪造数据包，从而潜在地减少拒绝服务攻击的影响。注:
If the receiver performs decryption in parallel with authentication, care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet.
如果接收器与认证并行执行解密，则必须注意避免与包访问和解密包的重建有关的可能的竞争条件。
Note that there are several ways in which the decryption can "fail":
请注意，解密有几种可能“失败”的方式：
a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address, or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field.
a. 所选SA可能不正确——由于篡改SPI、目标地址或IPsec协议类型字段，SA可能被错误选择。如果这些错误将数据包映射到另一个现有SA，则无法将其与损坏的数据包区分开来（案例c）。可以通过使用身份验证来检测对SPI的篡改。但是，由于篡改IP目标地址或IPsec协议类型字段，SA不匹配仍可能发生。
b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use of authentication.
b. 焊盘长度或焊盘值可能是错误的——无论使用何种身份验证，都可以检测到错误的焊盘长度或焊盘值。
c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA.,
c. 加密的ESP数据包可能已损坏——如果为SA选择了身份验证，则可以检测到此情况。，
In case (a) or (c), the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not necessarily be detected by IPsec, and is the responsibility of later protocol processing.
在（a）或（c）情况下，解密操作的错误结果（无效的IP数据报或传输层帧）不一定会被IPsec检测到，这是后续协议处理的责任。
Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional
并非所有实施ESP的系统都将实施审核。但是，如果将ESP合并到支持审核的系统中，则ESP实施还必须支持审核，并且必须允许系统管理员启用或禁用ESP审核。在大多数情况下，审核的粒度是本地问题。但是，本规范中确定了几个可审核事件，并且为每个事件定义了应包含在审核日志中的最少信息集。审计日志中还可能包含这些事件的附加信息，以及附加信息
events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
本规范中未明确调用的事件也可能导致审核日志条目。不要求接收方在检测到可审计事件时向声称的发送方发送任何消息，因为通过这种行为可能导致拒绝服务。
Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here and MUST comply with all requirements of the Security Architecture document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms:
声明符合或符合本规范的实现必须实现此处描述的ESP语法和处理，并且必须符合安全体系结构文档的所有要求。如果用于计算ICV的密钥是手动分发的，则正确提供反重放服务需要在发送方正确维护计数器状态，直到密钥被替换，并且如果计数器溢出即将发生，则可能不会提供自动恢复。因此，兼容实现不应与手动键入的SAs一起提供此服务。符合要求的ESP实施必须支持以下强制算法：
- DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] - NULL Authentication algorithm - NULL Encryption algorithm
- CBC模式下的DES[MD97]-带MD5的HMAC[MG97a]-带SHA-1的HMAC[MG97b]-空身份验证算法-空加密算法
Since ESP encryption and authentication are optional, support for the 2 "NULL" algorithms is required to maintain consistency with the way these services are negotiated. NOTE that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL".
由于ESP加密和身份验证是可选的，因此需要支持2个“NULL”算法，以保持与这些服务协商方式的一致性。请注意，虽然身份验证和加密都可以为“NULL”，但它们不能同时为“NULL”。
Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
安全性是该协议设计的核心，因此安全性考虑贯穿于规范中。安全体系结构文档中讨论了使用IPsec协议的其他安全相关方面。
This document differs from RFC 1827 [ATK95] in several significant ways. The major difference is that, this document attempts to specify a complete framework and context for ESP, whereas RFC 1827 provided a "shell" that was completed through the definition of transforms. The combinatorial growth of transforms motivated the reformulation of the ESP specification as a more complete document, with options for security services that may be offered in the context of ESP. Thus, fields previously defined in transform documents are
本文件与RFC 1827[ATK95]在几个重要方面有所不同。主要区别在于，本文档试图为ESP指定一个完整的框架和上下文，而RFC1827提供了一个通过定义转换完成的“shell”。转换的组合增长推动了ESP规范的重新制定，使其成为一个更完整的文档，并提供了ESP上下文中可能提供的安全服务选项。因此，先前在转换文档中定义的字段如下：
now part of this base ESP specification. For example, the fields necessary to support authentication (and anti-replay) are now defined here, even though the provision of this service is an option. The fields used to support padding for encryption, and for next protocol identification, are now defined here as well. Packet processing consistent with the definition of these fields also is included in the document.
现在是本基础ESP规范的一部分。例如，现在这里定义了支持身份验证（和反重播）所需的字段，尽管提供此服务是一个选项。用于支持加密填充和下一个协议标识的字段现在也在这里定义。文档中还包括与这些字段的定义一致的数据包处理。
Acknowledgements
致谢
Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92, IB93].
本规范中包含的许多概念源自或受美国政府的SP3安全协议、ISO/IEC的NLSP或建议的刷卡安全协议的影响。[SDNS89、ISO92、IB93]。
For over 3 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina Yuan.
3年多来，本文档通过多个版本和迭代不断发展。在这段时间里，许多人为这一过程和文件本身贡献了重要的思想和精力。作者要感谢Karen Seo在本规范版本的审查、编辑、背景研究和协调方面提供的广泛帮助。作者还要感谢IPsec和IPng工作组的成员，并特别提到（按字母顺序排列）Steve Bellovin、Steve Deering、Phil Karn、Perry Metzger、David Mihelcic、Hilarie Orman、Norman Shulman、William Simpson和Nina Yuan的努力。
References
工具书类
[ATK95] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[ATK95]阿特金森，R.，“IP封装安全有效载荷（ESP）”，RFC 1827，1995年8月。
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.
[Bel96]Steven M.Bellovin，“IP安全协议的问题领域”，第六届Usenix Unix安全研讨会论文集，1996年7月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HC98]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993.
[IB93]John Ioannidis&Matt Blaze，“Unix下网络层安全的体系结构和实现”，USENIX安全研讨会论文集，加利福尼亚州圣克拉拉，1993年10月。
[ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
[ISO92]ISO/IEC JTC1/SC6，网络层安全协议，ISO-IEC DIS 11577，国际标准组织，瑞士日内瓦，1992年11月29日。
[KA97a] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[KA97a]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[KA97b] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[KA97b]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[MD97] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[MD97]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，1998年11月。
[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[MG97a]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[MG97b]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990.
[SDNS89]SDNS安全数据网络系统，安全协议3，SP3，文件SDN.301，修订版1.5，1989年5月15日，发布于NIST出版物NIST-IR-90-4250，1990年2月。
Disclaimer
免责声明
The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification.
这里的观点和规范是作者的观点和规范，不一定是他们的雇主的观点和规范。作者及其雇主明确否认对因正确或不正确实施或使用本规范而产生的任何问题负责。
Author Information
作者信息
Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA
美国马萨诸塞州剑桥福塞特街70号Stephen Kent BBN Corporation 02140
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA
美国加利福尼亚州红木市百老汇425号Randall Atkinson@Home Network，邮编94063
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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 assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。