Network Working Group S. Kent
Request for Comments: 4303 BBN Technologies
Obsoletes: 2406 December 2005
Category: Standards Track
Network Working Group S. Kent
Request for Comments: 4303 BBN Technologies
Obsoletes: 2406 December 2005
Category: Standards Track
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. 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. This document obsoletes RFC 2406 (November 1998).
本文档描述了封装安全有效负载（ESP）协议的更新版本，该协议旨在提供IPv4和IPv6中的混合安全服务。ESP用于提供机密性、数据源身份验证、无连接完整性、反重播服务（部分序列完整性的一种形式）和有限的流量机密性。本文件废除RFC 2406（1998年11月）。
Table of Contents
目录
1. Introduction ....................................................3
2. Encapsulating Security Payload Packet Format ....................5
2.1. Security Parameters Index (SPI) ...........................10
2.2. Sequence Number ...........................................12
2.2.1. Extended (64-bit) Sequence Number ..................12
2.3. Payload Data ..............................................13
2.4. Padding (for Encryption) ..................................14
2.5. Pad Length ................................................15
2.6. Next Header ...............................................16
2.7. Traffic Flow Confidentiality (TFC) Padding ................17
2.8. Integrity Check Value (ICV) ...............................17
3. Encapsulating Security Protocol Processing .....................18
3.1. ESP Header Location .......................................18
3.1.1. Transport Mode Processing ..........................18
3.1.2. Tunnel Mode Processing .............................19
1. Introduction ....................................................3
2. Encapsulating Security Payload Packet Format ....................5
2.1. Security Parameters Index (SPI) ...........................10
2.2. Sequence Number ...........................................12
2.2.1. Extended (64-bit) Sequence Number ..................12
2.3. Payload Data ..............................................13
2.4. Padding (for Encryption) ..................................14
2.5. Pad Length ................................................15
2.6. Next Header ...............................................16
2.7. Traffic Flow Confidentiality (TFC) Padding ................17
2.8. Integrity Check Value (ICV) ...............................17
3. Encapsulating Security Protocol Processing .....................18
3.1. ESP Header Location .......................................18
3.1.1. Transport Mode Processing ..........................18
3.1.2. Tunnel Mode Processing .............................19
3.2. Algorithms ................................................20
3.2.1. Encryption Algorithms ..............................21
3.2.2. Integrity Algorithms ...............................21
3.2.3. Combined Mode Algorithms ...........................22
3.3. Outbound Packet Processing ................................22
3.3.1. Security Association Lookup ........................22
3.3.2. Packet Encryption and Integrity Check Value
(ICV) Calculation ..................................22
3.3.2.1. Separate Confidentiality and
Integrity Algorithms ......................23
3.3.2.2. Combined Confidentiality and
Integrity Algorithms ......................24
3.3.3. Sequence Number Generation .........................25
3.3.4. Fragmentation ......................................26
3.4. Inbound Packet Processing .................................27
3.4.1. Reassembly .........................................27
3.4.2. Security Association Lookup ........................27
3.4.3. Sequence Number Verification .......................28
3.4.4. Integrity Check Value Verification .................30
3.4.4.1. Separate Confidentiality and
Integrity Algorithms ......................30
3.4.4.2. Combined Confidentiality and
Integrity Algorithms ......................32
4. Auditing .......................................................33
5. Conformance Requirements .......................................34
6. Security Considerations ........................................34
7. Differences from RFC 2406 ......................................34
8. Backward-Compatibility Considerations ..........................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Appendix A: Extended (64-bit) Sequence Numbers ....................38
A1. Overview ...................................................38
A2. Anti-Replay Window .........................................38
A2.1. Managing and Using the Anti-Replay Window ............39
A2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................40
A2.3. Pseudo-Code Example ..................................41
A3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................42
A3.1. Triggering Re-synchronization ........................43
A3.2. Re-synchronization Process ...........................43
3.2. Algorithms ................................................20
3.2.1. Encryption Algorithms ..............................21
3.2.2. Integrity Algorithms ...............................21
3.2.3. Combined Mode Algorithms ...........................22
3.3. Outbound Packet Processing ................................22
3.3.1. Security Association Lookup ........................22
3.3.2. Packet Encryption and Integrity Check Value
(ICV) Calculation ..................................22
3.3.2.1. Separate Confidentiality and
Integrity Algorithms ......................23
3.3.2.2. Combined Confidentiality and
Integrity Algorithms ......................24
3.3.3. Sequence Number Generation .........................25
3.3.4. Fragmentation ......................................26
3.4. Inbound Packet Processing .................................27
3.4.1. Reassembly .........................................27
3.4.2. Security Association Lookup ........................27
3.4.3. Sequence Number Verification .......................28
3.4.4. Integrity Check Value Verification .................30
3.4.4.1. Separate Confidentiality and
Integrity Algorithms ......................30
3.4.4.2. Combined Confidentiality and
Integrity Algorithms ......................32
4. Auditing .......................................................33
5. Conformance Requirements .......................................34
6. Security Considerations ........................................34
7. Differences from RFC 2406 ......................................34
8. Backward-Compatibility Considerations ..........................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Appendix A: Extended (64-bit) Sequence Numbers ....................38
A1. Overview ...................................................38
A2. Anti-Replay Window .........................................38
A2.1. Managing and Using the Anti-Replay Window ............39
A2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................40
A2.3. Pseudo-Code Example ..................................41
A3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................42
A3.1. Triggering Re-synchronization ........................43
A3.2. Re-synchronization Process ...........................43
This document assumes that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Ken-Arch], hereafter referred to as the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by the Encapsulating Security Payload (ESP) and the IP Authentication Header (AH), the concept of Security Associations, the ways in which ESP can be used in conjunction with AH, and the different key management options available for ESP and AH.
本文件假设读者熟悉“互联网协议的安全体系结构”[Ken Arch]中描述的术语和概念，以下称为安全体系结构文件。特别是，读者应熟悉封装安全有效负载（ESP）和IP认证头（AH）提供的安全服务的定义、安全关联的概念、ESP与AH结合使用的方式以及ESP和AH可用的不同密钥管理选项。
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 Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6 [DH98]. ESP may be applied alone, in combination with AH [Ken-AH], or in a nested fashion (see the Security Architecture document [Ken-Arch]). 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 [Ken-Arch].
封装安全有效负载（ESP）标头旨在提供IPv4和IPv6中的混合安全服务[DH98]。ESP可以单独应用，与AH[Ken-AH]结合使用，也可以以嵌套方式应用（请参阅安全体系结构文档[Ken-Arch]）。可以在一对通信主机之间、一对通信安全网关之间或安全网关与主机之间提供安全服务。有关如何在各种网络环境中使用ESP和AH的更多详细信息，请参阅安全体系结构文档[Ken Arch]。
The ESP header is inserted after the IP header and before the next 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 can be 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 (SA) establishment and on the location of the implementation in a network topology.
ESP可用于提供机密性、数据源身份验证、无连接完整性、反重放服务（部分序列完整性的一种形式）和（有限的）流量机密性。提供的服务集取决于安全关联（SA）建立时选择的选项以及实现在网络拓扑中的位置。
Using encryption-only for confidentiality is allowed by ESP. However, it should be noted that in general, this will provide defense only against passive attackers. Using encryption without a strong integrity mechanism on top of it (either in ESP or separately via AH) may render the confidentiality service insecure against some forms of active attacks [Bel96, Kra01]. Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against active attackers [Kra01]. ESP allows encryption-only SAs because this may offer considerably better performance and still provide
ESP允许仅为保密目的使用加密。但是，应注意的是，一般而言，这将仅针对被动攻击者提供防御。在没有强大完整性机制的情况下使用加密（在ESP中或通过AH单独使用）可能会使保密服务对某些形式的主动攻击不安全[Bel96，Kra01]。此外，加密前应用的基础完整性服务（如AH）不一定能保护仅加密的机密性，以防主动攻击者[Kra01]。ESP只允许加密SAs，因为这样可以提供相当好的性能，并且仍然提供
adequate security, e.g., when higher-layer authentication/integrity protection is offered independently. However, this standard does not require ESP implementations to offer an encryption-only service.
足够的安全性，例如，当独立提供更高层的身份验证/完整性保护时。但是，本标准不要求ESP实现提供仅加密的服务。
Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity". (This term is employed because, on a per-packet basis, the computation being performed provides connectionless integrity directly; data origin authentication is provided indirectly as a result of binding the key used to verify the integrity to the identity of the IPsec peer. Typically, this binding is effected through the use of a shared, symmetric key.) Integrity-only ESP MUST be offered as a service selection option, e.g., it must be negotiable in SA management protocols and MUST be configurable via management interfaces. Integrity-only ESP is an attractive alternative to AH in many contexts, e.g., because it is faster to process and more amenable to pipelining in many implementations.
数据源身份验证和无连接完整性是联合服务，以下统称为“完整性”。（之所以使用此术语，是因为在每个数据包的基础上，正在执行的计算直接提供无连接的完整性；将用于验证完整性的密钥绑定到IPsec对等方的身份，从而间接提供数据源身份验证。通常，此绑定通过使用共享的symmetri来实现c）仅完整性ESP必须作为服务选择选项提供，例如，它必须在SA管理协议中可协商，并且必须通过管理接口进行配置。在许多情况下，仅完整性ESP是AH的一个有吸引力的替代方案，例如，因为它处理速度更快，并且在许多实现中更易于管道化。
Although confidentiality and integrity can be offered independently, ESP typically will employ both services, i.e., packets will be protected with regard to confidentiality and integrity. Thus, there are three possible ESP security service combinations involving these services:
尽管机密性和完整性可以独立提供，但ESP通常会同时使用这两种服务，即，数据包将在机密性和完整性方面受到保护。因此，有三种可能的ESP安全服务组合涉及这些服务：
- confidentiality-only (MAY be supported) - integrity only (MUST be supported) - confidentiality and integrity (MUST be supported)
- 仅机密性（可支持）-仅完整性（必须支持）-机密性和完整性（必须支持）
The anti-replay service may be selected for an SA only if the integrity service is selected for that SA. The selection of this service is solely at the discretion of the receiver and thus need not be negotiated. However, to make use of the Extended Sequence Number feature in an interoperable fashion, ESP does impose a requirement on SA management protocols to be able to negotiate this feature (see Section 2.2.1 below).
仅当为SA选择了完整性服务时，才可以为SA选择反重播服务。此服务的选择完全由接收方自行决定，因此无需协商。然而，为了以可互操作的方式使用扩展序列号功能，ESP确实对SA管理协议提出了要求，以便能够协商此功能（请参见下面的第2.2.1节）。
The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in a fashion that conceals the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways, and only if sufficient traffic flows between IPsec peers (either naturally or as a result of generation of masking traffic) to conceal the characteristics of specific, individual subscriber traffic flows. (ESP may be employed as part of a higher-layer TFC system, e.g., Onion Routing [Syverson], but such systems are outside the scope of this standard.) New TFC features present in ESP facilitate efficient generation and discarding of dummy traffic and better padding of real traffic, in a backward-compatible fashion.
流量机密性（TFC）服务通常只有在ESP以隐藏通信方最终源地址和目标地址的方式使用时才有效，例如，在安全网关之间的隧道模式下，并且只有在IPsec对等方之间有足够的流量时才有效（自然地或由于产生屏蔽流量）隐藏特定的单个用户流量的特征。（ESP可作为更高层TFC系统的一部分使用，例如洋葱路由[Syverson]，但此类系统不在本标准的范围内。）ESP中的新TFC功能以向后兼容的方式促进了虚拟流量的高效生成和丢弃，以及真实流量的更好填充。
Section 7 provides a brief review of the differences between this document and RFC 2406.
第7节简要回顾了本文件与RFC 2406之间的差异。
The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header SHALL contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web page at http://www.iana.org/assignments/protocol-numbers). Figure 1 illustrates the top-level format of an ESP packet. The packet begins with two 4-byte fields (Security Parameters Index (SPI) and Sequence Number). Following these fields is the Payload Data, which has substructure that depends on the choice of encryption algorithm and mode, and on the use of TFC padding, which is examined in more detail later. Following the Payload Data are Padding and Pad Length fields, and the Next Header field. The optional Integrity Check Value (ICV) field completes the packet.
ESP报头前面的（外部）协议报头（IPv4、IPv6或扩展）应在其协议（IPv4）或下一报头（IPv6、扩展）字段中包含值50（请参见http://www.iana.org/assignments/protocol-numbers). 图1说明了ESP数据包的顶级格式。数据包以两个4字节字段（安全参数索引（SPI）和序列号）开始。在这些字段之后是有效载荷数据，其子结构取决于加密算法和模式的选择，以及TFC填充的使用，稍后将对其进行更详细的研究。在有效负载数据之后是Padding和Pad Length字段，以及Next Header字段。可选完整性检查值（ICV）字段完成数据包。
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) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (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) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Top-Level Format of an ESP Packet
图1。ESP数据包的顶级格式
* If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext.
* 如果包括在有效载荷字段中，加密同步数据，例如初始化向量（IV，见第2.3节）本身通常不加密，尽管它通常被称为密文的一部分。
The (transmitted) ESP trailer consists of the Padding, Pad Length, and Next Header fields. Additional, implicit ESP trailer data (which is not transmitted) is included in the integrity computation, as described below.
（传输的）ESP尾部由Padding、Pad Length和Next Header字段组成。完整性计算中还包括其他隐式ESP拖车数据（未传输），如下所述。
If the integrity service is selected, the integrity computation encompasses the SPI, Sequence Number, Payload Data, and the ESP trailer (explicit and implicit).
如果选择了完整性服务，完整性计算将包括SPI、序列号、有效负载数据和ESP拖车（显式和隐式）。
If the confidentiality service is selected, the ciphertext consists of the Payload Data (except for any cryptographic synchronization data that may be included) and the (explicit) ESP trailer.
如果选择保密服务，则密文由有效负载数据（可能包含的任何加密同步数据除外）和（显式）ESP尾部组成。
As noted above, the Payload Data may have substructure. An encryption algorithm that requires an explicit Initialization Vector (IV), e.g., Cipher Block Chaining (CBC) mode, often prefixes the Payload Data to be protected with that value. Some algorithm modes combine encryption and integrity into a single operation; this document refers to such algorithm modes as "combined mode algorithms". Accommodation of combined mode algorithms requires that the algorithm explicitly describe the payload substructure used to convey the integrity data.
如上所述，有效载荷数据可能具有子结构。需要显式初始化向量（IV）的加密算法，例如，密码块链接（CBC）模式，通常在要保护的有效负载数据前加上该值。一些算法模式将加密和完整性结合到一个操作中；本文件将此类算法模式称为“组合模式算法”。适应组合模式算法要求算法明确描述用于传输完整性数据的有效载荷子结构。
Some combined mode algorithms provide integrity only for data that is encrypted, whereas others can provide integrity for some additional data that is not encrypted for transmission. Because the SPI and Sequence Number fields require integrity as part of the integrity service, and they are not encrypted, it is necessary to ensure that they are afforded integrity whenever the service is selected, regardless of the style of combined algorithm mode employed.
一些组合模式算法仅为加密的数据提供完整性，而其他算法可以为未加密传输的其他数据提供完整性。由于SPI和序列号字段要求完整性作为完整性服务的一部分，并且它们未加密，因此无论采用何种组合算法模式，都必须确保在选择服务时为它们提供完整性。
When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity check. For combined mode algorithms, the ICV that would normally appear at the end of the ESP packet (when integrity is selected) may be omitted. When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm to encode within the Payload Data an ICV-equivalent means of verifying the integrity of the packet.
当采用任何组合模式算法时，算法本身应返回解密的明文和完整性检查的通过/失败指示。对于组合模式算法，可以省略通常出现在ESP数据包末尾（当选择完整性时）的ICV。当省略ICV并且选择完整性时，组合模式算法负责在有效载荷数据内编码ICV等效装置以验证分组的完整性。
If a combined mode algorithm offers integrity only to data that is encrypted, it will be necessary to replicate the SPI and Sequence Number as part of the Payload Data.
如果组合模式算法仅为加密的数据提供完整性，则有必要将SPI和序列号复制为有效负载数据的一部分。
Finally, a new provision is made to insert padding for traffic flow confidentiality after the Payload Data and before the ESP trailer. Figure 2 illustrates this substructure for Payload Data. (Note: This
最后，制定了一项新规定，在有效载荷数据之后和ESP拖车之前插入交通流机密性填充。图2说明了有效载荷数据的子结构。（注：本
diagram shows bits-on-the-wire. So even if extended sequence numbers are being used, only 32 bits of the Sequence Number will be transmitted (see Section 2.2.1).)
图中显示了导线上的位。因此，即使使用扩展序列号，也只能传输序列号的32位（见第2.2.1节）
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Substructure of Payload Data
图2。有效载荷数据的子结构
* If tunnel mode is being used, then the IPsec implementation can add Traffic Flow Confidentiality (TFC) padding (see Section 2.4) after the Payload Data and before the Padding (0-255 bytes) field.
* 如果正在使用隧道模式，则IPsec实现可以在有效负载数据之后和填充（0-255字节）字段之前添加流量机密性（TFC）填充（请参见第2.4节）。
If a combined algorithm mode is employed, the explicit ICV shown in Figures 1 and 2 may be omitted (see Section 3.3.2.2 below). Because algorithms and modes are fixed when an SA is established, the detailed format of ESP packets for a given SA (including the Payload Data substructure) is fixed, for all traffic on the SA.
如果采用组合算法模式，则可省略图1和图2中所示的显式ICV（见下文第3.3.2.2节）。由于建立SA时算法和模式是固定的，因此对于SA上的所有流量，给定SA（包括有效负载数据子结构）的ESP数据包的详细格式是固定的。
The tables below refer to the fields in the preceding figures and illustrate how several categories of algorithmic options, each with a different processing model, affect the fields noted above. The processing details are described in later sections.
下表参考了上图中的字段，并说明了几种类型的算法选项（每种具有不同的处理模型）如何影响上述字段。处理细节将在后面的章节中描述。
Table 1. Separate Encryption and Integrity Algorithms
表1。单独的加密和完整性算法
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M Y plain
Seq# (low-order bits) 4 M Y plain p
------ a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher[3] |-l
TFC padding [4] variable O Y Y cipher[3] | o
------ a
Padding 0-255 M Y Y cipher[3] d
Pad Length 1 M Y Y cipher[3]
Next Header 1 M Y Y cipher[3]
Seq# (high-order bits) 4 if ESN [5] Y not xmtd
ICV Padding variable if need Y not xmtd
ICV variable M [6] plain
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M Y plain
Seq# (low-order bits) 4 M Y plain p
------ a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher[3] |-l
TFC padding [4] variable O Y Y cipher[3] | o
------ a
Padding 0-255 M Y Y cipher[3] d
Pad Length 1 M Y Y cipher[3]
Next Header 1 M Y Y cipher[3]
Seq# (high-order bits) 4 if ESN [5] Y not xmtd
ICV Padding variable if need Y not xmtd
ICV variable M [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] ciphertext if encryption has been selected
[4] Can be used only if payload specifies its "real" length
[5] See section 2.2.1
[6] mandatory if a separate integrity algorithm is used
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] ciphertext if encryption has been selected
[4] Can be used only if payload specifies its "real" length
[5] See section 2.2.1
[6] mandatory if a separate integrity algorithm is used
Table 2. Combined Mode Algorithms
表2。组合模式算法
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M plain
Seq# (low-order bits) 4 M plain p
--- a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher |-l
TFC padding [3] variable O Y Y cipher | o
--- a
Padding 0-255 M Y Y cipher d
Pad Length 1 M Y Y cipher
Next Header 1 M Y Y cipher
Seq# (high-order bits) 4 if ESN [4] Y [5]
ICV Padding variable if need Y [5]
ICV variable O [6] plain
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M plain
Seq# (low-order bits) 4 M plain p
--- a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher |-l
TFC padding [3] variable O Y Y cipher | o
--- a
Padding 0-255 M Y Y cipher d
Pad Length 1 M Y Y cipher
Next Header 1 M Y Y cipher
Seq# (high-order bits) 4 if ESN [4] Y [5]
ICV Padding variable if need Y [5]
ICV variable O [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] Can be used only if payload specifies its "real" length
[4] See Section 2.2.1
[5] The algorithm choices determines whether these are
transmitted, but in either case, the result is invisible
to ESP
[6] The algorithm spec determines whether this field is
present
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] Can be used only if payload specifies its "real" length
[4] See Section 2.2.1
[5] The algorithm choices determines whether these are
transmitted, but in either case, the result is invisible
to ESP
[6] The algorithm spec determines whether this field is
present
The following subsections describe 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 ICV (see Section 2.7). Whether or not an option is selected is determined 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的ESP数据包的格式在SA期间是固定的。相反，对于所有SA，“必填”字段始终以ESP数据包格式存在。
Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix of RFC 791 [Pos81]) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.
注意：IPsec中使用的所有加密算法都希望以规范的网络字节顺序输入（参见RFC 791[Pos81]的附录），并以规范的网络字节顺序生成输出。IP数据包也以网络字节顺序传输。
ESP does not contain a version number, therefore if there are concerns about backward compatibility, they MUST be addressed by using a signaling mechanism between the two IPsec peers to ensure compatible versions of ESP (e.g., Internet Key Exchange (IKEv2) [Kau05]) or an out-of-band configuration mechanism.
ESP不包含版本号，因此，如果存在向后兼容性问题，则必须使用两个IPsec对等方之间的信令机制来解决这些问题，以确保ESP的兼容版本（例如，Internet密钥交换（IKEv2）[Kau05]）或带外配置机制。
The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory.
SPI是一个任意的32位值，接收器使用它来标识传入数据包绑定到的SA。SPI字段是必需的。
For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Because the SPI value is generated by the receiver for a unicast SA, whether the value is sufficient to identify an SA by itself or whether it must be used in conjunction with the IPsec protocol value is a local matter. This mechanism for mapping inbound traffic to unicast SAs MUST be supported by all ESP implementations.
对于单播SA，SPI可以自己指定SA，也可以与IPsec协议类型（在本例中为ESP）结合使用。由于SPI值是由接收器为单播SA生成的，因此该值是否足以单独识别SA，或者该值是否必须与IPsec协议值一起使用是本地问题。所有ESP实现都必须支持这种将入站流量映射到单播SAs的机制。
If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
如果IPsec实现支持多播，则必须使用以下算法支持多播SAs，以便将入站IPsec数据报映射到SAs。仅支持单播通信的实现不需要实现此解复用算法。
In many secure multicast architectures (e.g., [RFC3740]), a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that comprise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.
在许多安全多播架构（例如，[RFC3740]）中，中央组控制器/密钥服务器单方面分配组安全关联的SPI。该SPI分配不与驻留在组成该组的各个终端系统中的密钥管理（如IKE）子系统协商或协调。因此，组安全关联和单播安全关联可以同时使用相同的SPI。支持多播的IPsec实现必须正确地解复用入站流量，即使在SPI冲突的情况下也是如此。
Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows:
安全关联数据库（SAD）[Ken Arch]中的每个条目都必须指明SA查找除了使用SPI外，还使用了目的地、目的地和源IP地址。对于多播SA，协议字段不用于SA查找。对于每个受IPsec保护的入站数据包，实现必须对SAD进行搜索，以便找到与“最长”SA标识符匹配的条目。在此上下文中，如果两个或多个SAD条目基于SPI值匹配，则也基于目的地或目的地与源地址比较（如SAD条目中所示）匹配的条目是“最长”匹配。这意味着SAD搜索的逻辑顺序如下：
1. Search the SAD for a match on {SPI, destination address, source address}. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2.
1. 在SAD中搜索{SPI，目标地址，源地址}上的匹配项。如果SAD条目匹配，则使用匹配的SAD条目处理入站ESP数据包。否则，继续执行步骤2。
2. Search the SAD for a match on {SPI, destination address}. If the SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3.
2. 在SAD中搜索{SPI，destination address}上的匹配项。如果SAD条目匹配，则使用匹配的SAD条目处理入站ESP数据包。否则，继续执行步骤3。
3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, or on {SPI, protocol} otherwise. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event.
3. 如果接收器选择为AH和ESP保留单个SPI空间，则仅在{SPI}上搜索SAD，否则在{SPI，protocol}上搜索匹配。如果SAD条目匹配，则使用匹配的SAD条目处理入站ESP数据包。否则，丢弃数据包并记录可审核事件。
In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features.
实际上，实现可以选择任何方法来加速此搜索，尽管其外部可见的行为在功能上必须等同于按上述顺序搜索SAD。例如，基于软件的实现可以通过SPI索引到哈希表中。每个哈希表存储桶的链接列表中的SAD条目保持排序，以使那些SA标识符最长的SAD条目位于该链接列表的第一位。对具有最短SA标识符的SAD条目进行排序，使其成为链接列表中的最后一个条目。基于硬件的实现可能能够使用常用的三值内容寻址存储器（TCAM）功能，从本质上实现最长匹配搜索。
The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier.
将入站IPsec通信映射到SAs时是否需要源地址和目标地址匹配的指示必须设置为手动SA配置的副作用，或使用SA管理协议（例如IKE或组解释域（GDOI））通过协商进行设置[RFC3547]。通常，源特定多播（SSM）[HC03]组使用由SPI、目标多播地址和源地址组成的三元组SA标识符。任何源多播组SA只需要SPI和目标多播地址作为标识符。
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. 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 might use the zero SPI value to mean "No Security Association Exists"
范围为1到255的SPI值集由互联网分配号码管理局（IANA）保留，以备将来使用；IANA通常不会指定保留的SPI值，除非RFC中指定使用指定的SPI值。SPI值0（0）保留供本地特定于实现的使用，不得通过线路发送。（例如，密钥管理实现可能使用零SPI值表示“不存在安全关联”
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.)
在IPsec实现请求其密钥管理实体建立新SA，但尚未建立SA的期间。）
This unsigned 32-bit field contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number. For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. Sharing an SA among multiple senders is permitted, though generally not recommended. ESP provides no means of synchronizing packet counters among multiple senders or meaningfully managing a receiver packet counter and window in the context of multiple senders. Thus, for a multi-sender SA, the anti-replay features of ESP are not available (see Sections 3.3.3 and 3.4.3.)
此无符号32位字段包含一个计数器值，每个发送的数据包增加一个计数器值，即每个SA数据包序列号。对于单播SA或单发送方多播SA，发送方必须为每个传输的数据包增加此字段。允许在多个发件人之间共享SA，但通常不建议这样做。ESP无法在多个发送方之间同步数据包计数器，也无法在多个发送方的上下文中有意义地管理接收方数据包计数器和窗口。因此，对于多发送方SA，ESP的防重播功能不可用（请参见第3.3.3节和第3.4.3节）
The field is mandatory and MUST always be 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, but all ESP implementations MUST be capable of performing the processing described in Sections 3.3.3 and 3.4.3. Thus, 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 (3.4.3) below).
该字段是必填字段，即使接收方未选择为特定SA启用反重播服务，该字段也必须始终存在。序列号字段的处理由接收方自行决定，但所有ESP实施必须能够执行第3.3.3节和第3.4.3节所述的处理。因此，发送方必须始终发送此字段，但接收方无需对其采取行动（见下文“入站数据包处理”部分（3.4.3）中关于序列号验证的讨论）。
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 (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时，发送方计数器和接收方计数器初始化为0。（使用给定SA发送的第一个数据包的序列号为1；有关如何生成序列号的更多详细信息，请参阅第3.3.3节。）如果启用了反重播（默认），则决不能允许传输的序列号循环。因此，在SA上传输第2^32个数据包之前，必须重置发送方计数器和接收方计数器（通过建立新SA和新密钥）。
To support high-speed IPsec implementations, Extended Sequence Numbers (ESNs) SHOULD be implemented, as an extension to the current, 32-bit sequence number field. Use of an ESN MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit sequence numbers are explicitly negotiated. (The ESN feature is applicable to multicast as well as unicast SAs.)
为了支持高速IPsec实现，应该实现扩展序列号（ESN），作为当前32位序列号字段的扩展。ESN的使用必须通过SA管理协议协商。注意，在IKEv2中，这种协商是隐含的；除非明确协商32位序列号，否则默认为ESN。（ESN功能适用于多播和单播SAs。）
The ESN facility allows use of a 64-bit sequence number for an SA. (See Appendix A, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in the plaintext ESP header of each packet, thus minimizing packet overhead. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV (if the integrity service is selected). If a separate integrity algorithm is employed, the high order bits are included in the implicit ESP trailer, but are not transmitted, analogous to integrity algorithm padding bits. If a combined mode algorithm is employed, the algorithm choice determines whether the high-order ESN bits are transmitted or are included implicitly in the computation. See Section 3.3.2.2 for processing details.
ESN设施允许对SA使用64位序列号。（详见附录A“扩展（64位）序列号”），每个数据包的明文ESP报头中仅传输序列号的低阶32位，从而最大限度地减少数据包开销。高阶32位由发射机和接收机作为序列号计数器的一部分进行维护，并包括在ICV的计算中（如果选择了完整性服务）。如果采用单独的完整性算法，则高阶位包括在隐式ESP尾部中，但不传输，类似于完整性算法填充位。如果采用组合模式算法，则算法选择确定是传输高阶ESN比特还是隐式地包括在计算中。处理细节见第3.3.2.2节。
Payload Data is a variable-length field containing data (from the original IP packet) 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 is carried explicitly in the Payload field, but it is not called out as a separate field in ESP, i.e., the transmission of an explicit IV is invisible to ESP. (See Figure 2.) 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. (Typically, the IV immediately precedes the ciphertext. See Figure 2.) If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the algorithm definition RFC. (If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV), usually is not encrypted per se (see Tables 1 and 2), although it sometimes is referred to as being part of the ciphertext.)
有效负载数据是一个可变长度字段，包含由下一个报头字段描述的数据（来自原始IP数据包）。有效负载数据字段是必填字段，长度为整数字节。如果用于加密有效载荷的算法需要加密同步数据，例如初始化向量（IV），则该数据在有效载荷字段中显式携带，但在ESP中不作为单独字段调用，即显式IV的传输对ESP不可见（见图2）任何需要此类显式、每包同步数据的加密算法必须指明长度、此类数据的任何结构以及该数据的位置，作为RFC的一部分，指定该算法如何与ESP一起使用。（通常，IV紧跟在密文之前。见图2。）如果此类同步数据是隐式的，导出数据的算法必须是算法定义RFC的一部分。（如果包括在有效载荷字段中，加密同步数据，例如初始化向量（IV）本身通常不加密（见表1和表2），尽管有时它被称为密文的一部分。）
Note that the beginning of the next layer protocol header MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes.
请注意，下一层协议头的开头必须与ESP头的开头对齐，如下所示。对于IPv4，此对齐是4字节的倍数。对于IPv6，对齐是8字节的倍数。
With regard to ensuring the alignment of the (real) ciphertext in the presence of an IV, note the following:
关于在有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 对于某些基于IV的操作模式，接收器将IV视为密文的开始，直接将其输入算法。在这些模式中，（实）密文的起始对齐在接收器处不是问题。
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与密文分开读取。在这些情况下，算法规范必须说明如何实现（实）密文的对齐。
Two primary 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, Padding, Pad Length, and Next Header fields) 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, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figures above, to ensure that the ICV field (if present) is aligned on a 4-byte boundary.
o 无论加密算法要求如何，也可能需要填充，以确保生成的密文终止于4字节边界。具体而言，Pad Length和Next Header字段必须在4字节字内右对齐，如上述ESP数据包格式图所示，以确保ICV字段（如果存在）在4字节边界上对齐。
Padding beyond that required for the algorithm or alignment reasons cited above could be used to conceal the actual length of the payload, in support of TFC. However, the Padding field described is too limited to be effective for TFC and thus should not be used for that purpose. Instead, the separate mechanism described below (see Section 2.7) should be used when TFC is required.
超出上述算法或对齐原因所需的填充可用于隐藏有效负载的实际长度，以支持TFC。但是，所描述的填充字段太有限，无法对TFC有效，因此不应用于此目的。相反，当需要TFC时，应使用下面描述的单独机制（见第2.7节）。
The sender MAY add 0 to 255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, subject to the requirements noted above, but all implementations MUST support generation and consumption of padding.
发送方可以添加0到255字节的填充。根据上述要求，在ESP数据包中包含填充字段是可选的，但所有实现都必须支持填充的生成和使用。
o For the purpose of ensuring that the bits to be encrypted are a multiple of the algorithm's block size (first bullet above), the padding computation applies to the Payload Data exclusive of any IV, but including the ESP trailer fields. If a combined algorithm mode requires transmission of the SPI and Sequence Number to effect integrity, e.g., replication of the SPI and Sequence Number in the Payload Data, then the replicated versions of these data items, and any associated, ICV-equivalent data, are included in the computation of the pad length. (If the ESN option is
o 为了确保要加密的位是算法块大小的倍数（上面的第一个项目符号），填充计算应用于不包括任何IV的有效负载数据，但包括ESP拖车字段。如果组合算法模式需要传输SPI和序列号以实现完整性，例如，有效载荷数据中SPI和序列号的复制，则这些数据项的复制版本以及任何相关的ICV等效数据都包括在焊盘长度的计算中。（如果ESN选项为
selected, the high-order 32 bits of the ESN also would enter into the computation, if the combined mode algorithm requires their transmission for integrity.)
选择后，如果组合模式算法要求传输完整性，ESN的高阶32位也将进入计算。）
o For the purposes of ensuring that the ICV 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. If a combined mode algorithm is used, any replicated data and ICV-equivalent data are included in the Payload Data covered by the padding computation.
o 为了确保ICV在4字节边界上对齐（上面的第二个项目符号），填充计算应用于有效负载数据，包括IV、Pad长度和Next报头字段。如果使用组合模式算法，任何复制数据和ICV等效数据都将包含在填充计算所涵盖的有效载荷数据中。
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.)
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.)
If an encryption or combined mode algorithm imposes constraints on the values of the bytes used for padding, they MUST be specified by the RFC defining how the algorithm is employed with ESP. If the algorithm requires checking of the values of the bytes used for padding, this too MUST be specified in that RFC.
如果加密或组合模式算法对用于填充的字节的值施加约束，则必须由RFC指定这些约束，RFC定义算法如何用于ESP。如果算法需要检查用于填充的字节的值，则也必须在该RFC中指定。
The Pad Length field indicates the number of pad bytes immediately preceding it in the Padding field. The range of valid values is 0 to 255, where a value of zero indicates that no Padding bytes are present. As noted above, this does not include any TFC padding bytes. The Pad Length field is mandatory.
Pad Length字段表示Padding字段中紧靠它前面的Pad字节数。有效值的范围为0到255，其中0表示不存在填充字节。如上所述，这不包括任何TFC填充字节。焊盘长度字段是必填字段。
The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP.
下一报头是一个必需的8位字段，用于标识有效负载数据字段中包含的数据类型，例如IPv4或IPv6数据包，或下一层报头和数据。此字段的值从IANA网页上定义的IP协议编号集合中选择，例如，值4表示IPv4，值41表示IPv6，值6表示TCP。
To facilitate the rapid generation and discarding of the padding traffic in support of traffic flow confidentiality (see Section 2.4), the protocol value 59 (which means "no next header") MUST be used to designate a "dummy" packet. A transmitter MUST be capable of generating dummy packets marked with this value in the next protocol field, and a receiver MUST be prepared to discard such packets, without indicating an error. All other ESP header and trailer fields (SPI, Sequence Number, Padding, Pad Length, Next Header, and ICV) MUST be present in dummy packets, but the plaintext portion of the payload, other than this Next Header field, need not be well-formed, e.g., the rest of the Payload Data may consist of only random bytes. Dummy packets are discarded without prejudice.
为了便于快速生成和丢弃填充流量以支持流量机密性（参见第2.4节），必须使用协议值59（表示“无下一个报头”）来指定“虚拟”数据包。发射机必须能够在下一个协议字段中生成标记有该值的虚拟数据包，并且接收机必须准备丢弃此类数据包，而不指示错误。所有其他ESP报头和尾部字段（SPI、序列号、填充、Pad长度、下一报头和ICV）必须存在于虚拟数据包中，但除此下一报头字段外，有效负载的明文部分不需要格式良好，例如，剩余的有效负载数据可能仅由随机字节组成。虚拟数据包被丢弃而不受影响。
Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls; for example, the controls might allow an administrator to generate random-length or fixed-length dummy packets.
实施应提供本地管理控制，以便在每个SA的基础上使用此功能。控件应允许用户指定是否使用此功能，并提供参数化控件；例如，这些控件可能允许管理员生成随机长度或固定长度的虚拟数据包。
DISCUSSION: Dummy packets can be inserted at random intervals to mask the absence of actual traffic. One can also "shape" the actual traffic to match some distribution to which dummy traffic is added as dictated by the distribution parameters. As with the packet length padding facility for Traffic Flow Security (TFS), the most secure approach would be to generate dummy packets at whatever rate is needed to maintain a constant rate on an SA. If packets are all the same size, then the SA presents the appearance of a constant bit rate data stream, analogous to what a link crypto would offer at layer 1 or 2. However, this is unlikely to be practical in many contexts, e.g., when there are multiple SAs active, because it would imply reducing the allowed bandwidth for a site, based on the number of SAs, and that would undermine the benefits of packet switching. Implementations SHOULD provide controls to enable local administrators to manage the generation of dummy packets for TFC purposes.
讨论：可以以随机间隔插入虚拟数据包，以掩盖实际通信量的缺失。还可以“塑造”实际流量，以匹配根据分布参数添加虚拟流量的某些分布。与用于流量安全（TFS）的数据包长度填充功能一样，最安全的方法是以任何速率生成虚拟数据包，以在SA上保持恒定速率。如果数据包的大小都相同，则SA呈现恒定比特率数据流的外观，类似于链路加密在第1层或第2层提供的情况。然而，这在许多情况下不太可能实际，例如，当有多个SA处于活动状态时，因为这将意味着根据SA的数量减少站点的允许带宽，这将破坏分组交换的好处。实现应提供控制，以使本地管理员能够为TFC目的管理虚拟数据包的生成。
As noted above, the Padding field is limited to 255 bytes in length. This generally will not be adequate to hide traffic characteristics relative to traffic flow confidentiality requirements. An optional field, within the payload data, is provided specifically to address the TFC requirement.
如上所述，填充字段的长度限制为255字节。这通常不足以隐藏与交通流保密要求相关的交通特征。有效负载数据中提供了一个可选字段，专门用于满足TFC要求。
An IPsec implementation SHOULD be capable of padding traffic by adding bytes after the end of the Payload Data, prior to the beginning of the Padding field. However, this padding (hereafter referred to as TFC padding) can be added only if the Payload Data field contains a specification of the length of the IP datagram. This is always true in tunnel mode, and may be true in transport mode depending on whether the next layer protocol (e.g., IP, UDP, ICMP) contains explicit length information. This length information will enable the receiver to discard the TFC padding, because the true length of the Payload Data will be known. (ESP trailer fields are located by counting back from the end of the ESP packet.) Accordingly, if TFC padding is added, the field containing the specification of the length of the IP datagram MUST NOT be modified to reflect this padding. No requirements for the value of this padding are established by this standard.
IPsec实现应该能够通过在有效负载数据结束之后、填充字段开始之前添加字节来填充流量。但是，仅当有效负载数据字段包含IP数据报长度的规范时，才能添加此填充（以下称为TFC填充）。这在隧道模式下始终正确，在传输模式下可能正确，具体取决于下一层协议（例如，IP、UDP、ICMP）是否包含显式长度信息。此长度信息将使接收器能够丢弃TFC填充，因为有效负载数据的真实长度是已知的。（ESP尾部字段通过从ESP数据包末尾倒数来定位。）因此，如果添加了TFC填充，则不得修改包含IP数据报长度规范的字段以反映此填充。本标准未对该填料的值提出任何要求。
In principle, existing IPsec implementations could have made use of this capability previously, in a transparent fashion. However, because receivers may not have been prepared to deal with this padding, the SA management protocol MUST negotiate this service prior to a transmitter employing it, to ensure backward compatibility. Combined with the convention described in Section 2.6 above, about the use of protocol ID 59, an ESP implementation is capable of generating dummy and real packets that exhibit much greater length variability, in support of TFC.
原则上，现有的IPsec实现以前可以以透明的方式使用此功能。然而，由于接收机可能尚未准备好处理这种填充，SA管理协议必须在发射机使用该服务之前协商该服务，以确保向后兼容性。结合上面第2.6节中描述的关于协议ID 59的使用的约定，ESP实现能够生成显示出更大长度可变性的伪数据包和实数据包，以支持TFC。
Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls for the feature.
实施应提供本地管理控制，以便在每个SA的基础上使用此功能。控件应允许用户指定是否使用此功能，并为该功能提供参数化控件。
The Integrity Check Value is a variable-length field computed over the ESP header, Payload, and ESP trailer fields. Implicit ESP trailer fields (integrity padding and high-order ESN bits, if applicable) are included in the ICV computation. The ICV field is optional. It is present only if the integrity service is selected and is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICV. The length of the field is
完整性检查值是通过ESP标题、有效负载和ESP拖车字段计算的可变长度字段。隐式ESP拖车字段（完整性填充和高阶ESN位，如果适用）包括在ICV计算中。ICV字段是可选的。仅当选择了完整性服务，并且由单独的完整性算法或使用ICV的组合模式算法提供时，才会出现该服务。字段的长度为
specified by the integrity algorithm selected and associated with the SA. The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
由选定的完整性算法指定，并与SA关联。完整性算法规范必须指定ICV的长度以及验证的比较规则和处理步骤。
ESP may be employed in two ways: transport mode or tunnel mode.
ESP可采用两种方式：运输模式或隧道模式。
In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol. (If AH is also applied to a packet, it is applied to the ESP header, Payload, ESP trailer, and ICV, if present.) (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (This and subsequent diagrams in this section show the ICV field, the presence of which is a function of the security services and the algorithm/mode selected.)
在传输模式下，ESP插入在IP头之后和下一层协议之前，例如TCP、UDP、ICMP等。在IPv4上下文中，这意味着将ESP放置在IP头之后（及其包含的任何选项），但在下一层协议之前。（如果AH也应用于数据包，则它应用于ESP报头、有效负载、ESP拖车和ICV（如果存在）。（请注意，术语“传输”模式不应被误解为限制其使用TCP和UDP。）下图说明了典型IPv4数据包的ESP传输模式定位，以“之前和之后”为基础。（本节中的此图和后续图显示了ICV字段，该字段的存在是安全服务和所选算法/模式的函数。）
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 | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
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. Destination options extension header(s) could appear before, after, or both before and after the ESP header depending on the semantics desired. However, because ESP protects only fields after the ESP header, it generally will 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| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------>|
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------>|
* = if present, could be before ESP, after ESP, or both
* =如果存在，可以在ESP之前、ESP之后或两者都存在
Note that in transport mode, 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.
请注意，在传输模式下，对于安全体系结构文档中定义的“堆栈中的通气”或“线路中的通气”实现，入站和出站IP片段可能需要IPsec实现来执行额外的IP重组/分段，以便符合此规范并提供透明的IPsec支持。当使用多个接口时，在这些实现中执行此类操作需要特别小心。
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. 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.
在隧道模式下，“内部”IP报头包含最终（IP）源地址和目标地址，“外部”IP报头包含IPsec“对等方”的地址，例如安全网关的地址。允许混合内部和外部IP版本，即IPv4上的IPv6和IPv6上的IPv4。在隧道模式下，ESP保护整个内部IP数据包，包括整个内部IP报头。隧道模式下ESP相对于外部IP报头的位置与传输模式下ESP的位置相同。下图说明了典型IPv4和IPv6数据包的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
应用ESP后
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
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
应用ESP后
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
* = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed in the Security Architecture document.
* =如果存在，外部IP hdr/扩展的构造和内部IP hdr/扩展的修改将在安全体系结构文档中讨论。
The mandatory-to-implement algorithms for use with ESP are described in a separate RFC, to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported. Note that although both confidentiality and integrity are optional, at least one of these services MUST be selected, hence both algorithms MUST NOT be simultaneously NULL.
在单独的RFC中描述了与ESP一起使用的强制实现算法，以便于独立于协议本身更新算法要求。除ESP强制使用的算法外，还可能支持其他算法。请注意，尽管机密性和完整性都是可选的，但必须至少选择其中一个服务，因此这两个算法不能同时为NULL。
The encryption algorithm employed to protect an ESP packet is specified by the SA via which the packet is transmitted/received. Because IP packets may arrive out of order, and not all packets may arrive (packet loss), 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 plaintext portions of the (outer IP or ESP) packet header. (Note that if plaintext header information is used to derive an IV, that information may become security critical and thus the protection boundary associated with the encryption process may grow. For example, if one were to use the ESP Sequence Number to derive an IV, the Sequence Number generation logic (hardware or software) would have to be evaluated as part of the encryption algorithm implementation. In the case of FIPS 140-2 [NIST01], this could significantly extend the scope of a cryptographic module evaluation.) Because ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Note that because encryption (confidentiality) MAY be an optional service (e.g., integrity-only ESP), this algorithm MAY be "NULL" [Ken-Arch].
用于保护ESP数据包的加密算法由SA指定，通过SA发送/接收数据包。由于IP数据包可能会无序到达，并且并非所有数据包都会到达（数据包丢失），因此每个数据包必须携带允许接收方建立加密同步以进行解密所需的任何数据。该数据可以在有效载荷字段中显式地携带，例如作为IV（如上所述），或者该数据可以从（外部IP或ESP）分组报头的明文部分导出。（请注意，如果使用明文标题信息导出IV，则该信息可能成为安全关键信息，因此与加密过程相关的保护边界可能会增加。例如，如果要使用ESP序列号导出IV，则序列号生成逻辑（硬件或软件）必须作为加密算法实现的一部分进行评估。在FIPS 140-2[NIST01]的情况下，这可能会显著扩展加密模块评估的范围。）因为ESP提供了明文填充，ESP使用的加密算法可能表现出块模式或流模式特征。请注意，由于加密（机密性）可能是可选服务（例如，仅完整性ESP），因此此算法可能为“空”[Ken Arch]。
To allow an ESP implementation to compute the encryption padding required by a block mode encryption algorithm, and to determine the MTU impact of the algorithm, the RFC for each encryption algorithm used with ESP must specify the padding modulus for the algorithm.
为了允许ESP实现计算块模式加密算法所需的加密填充，并确定算法的MTU影响，ESP使用的每个加密算法的RFC必须指定算法的填充模数。
The integrity algorithm employed for the ICV computation is specified by the SA via which the packet is transmitted/received. As was the case for encryption algorithms, any integrity algorithm employed with ESP must make provisions to permit processing of packets that arrive out of order and to accommodate packet loss. The same admonition noted above applies to use of any plaintext data to facilitate receiver synchronization of integrity algorithms. Note that because the integrity service MAY be optional, this algorithm may be "NULL".
用于ICV计算的完整性算法由SA指定，通过SA发送/接收数据包。与加密算法的情况一样，ESP使用的任何完整性算法都必须作出规定，以允许处理无序到达的数据包，并适应数据包丢失。上述警告同样适用于任何纯文本数据的使用，以促进完整性算法的接收器同步。请注意，由于完整性服务可能是可选的，因此此算法可能为“NULL”。
To allow an ESP implementation to compute any implicit integrity algorithm padding required, the RFC for each algorithm used with ESP must specify the padding modulus for the algorithm.
为了允许ESP实现计算所需的任何隐式完整性算法填充，ESP使用的每个算法的RFC必须指定算法的填充模数。
If a combined mode algorithm is employed, both confidentiality and integrity services are provided. As was the case for encryption algorithms, a combined mode algorithm must make provisions for per-packet cryptographic synchronization, to permit decryption of packets that arrive out of order and to accommodate packet loss. The means by which a combined mode algorithm provides integrity for the payload, and for the SPI and (Extended) Sequence Number fields, may vary for different algorithm choices. In order to provide a uniform, algorithm-independent approach to invocation of combined mode algorithms, no payload substructure is defined. For example, the SPI and Sequence Number fields might be replicated within the ciphertext envelope and an ICV may be appended to the ESP trailer. None of these details should be observable externally.
如果采用组合模式算法，则同时提供机密性和完整性服务。与加密算法的情况一样，组合模式算法必须为每个数据包的加密同步做出规定，以允许对无序到达的数据包进行解密，并适应数据包丢失。组合模式算法为有效负载以及SPI和（扩展）序列号字段提供完整性的方法可能因不同的算法选择而不同。为了提供一种统一的、独立于算法的方法来调用组合模式算法，没有定义有效负载子结构。例如，SPI和序列号字段可以在密文信封内复制，并且ICV可以附加到ESP尾部。所有这些细节都不应在外部可见。
To allow an ESP implementation to determine the MTU impact of a combined mode algorithm, the RFC for each algorithm used with ESP must specify a (simple) formula that yields encrypted payload size, as a function of the plaintext payload and sequence number sizes.
为了允许ESP实现确定组合模式算法的MTU影响，ESP使用的每个算法的RFC必须指定一个（简单）公式，该公式产生加密的有效负载大小，作为明文有效负载和序列号大小的函数。
In transport mode, the sender encapsulates the next layer protocol information between the ESP header and the ESP trailer fields, 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 interrelated in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document.
在传输模式下，发送方封装ESP头和ESP尾字段之间的下一层协议信息，并保留指定的IP头（以及IPv6上下文中的任何IP扩展头）。在隧道模式下，外部和内部IP头/扩展可以以多种方式相互关联。安全体系结构文档中描述了封装过程中外部IP头/扩展的构造。
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 (RFC 2410). There are several algorithmic options.
在本节中，我们将讨论始终应用加密的问题，因为它涉及到格式问题。这是在理解使用空加密算法（RFC 2410）提供“无机密性”的情况下完成的。有几个算法选项。
If separate confidentiality and integrity algorithms are employed, the Sender proceeds as follows:
如果采用单独的保密性和完整性算法，发送方将按如下方式进行：
1. Encapsulate (into the ESP Payload field): - for transport mode -- just the original next layer protocol information. - for tunnel mode -- the entire original IP datagram.
1. 封装（到ESP有效负载字段中）：-对于传输模式——仅包含原始的下一层协议信息。-对于隧道模式——整个原始IP数据报。
2. Add any necessary padding -- Optional TFC padding and (encryption) Padding
2. 添加任何必要的填充--可选的TFC填充和（加密）填充
3. Encrypt the result using the key, encryption algorithm, and algorithm mode specified for the SA and using any required cryptographic synchronization data. - 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 synchronization data is employed, it is constructed and input to the encryption algorithm as per the algorithm specification. - If integrity is selected, encryption is performed first, before the integrity algorithm is applied, and the encryption does not encompass the ICV 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 (DoS) attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with integrity checking. Note that because the ICV is not protected by encryption, a keyed integrity algorithm must be employed to compute the ICV.
3. 使用为SA指定的密钥、加密算法和算法模式以及任何必需的加密同步数据对结果进行加密。-如果显示了显式加密同步数据，例如IV，则根据算法规范将其输入加密算法，并将其置于有效载荷字段中。-如果采用隐式加密同步数据，则根据算法规范构造并输入加密算法。-如果选择了integrity，则在应用integrity算法之前首先执行加密，并且加密不包括ICV字段。这种处理顺序有助于接收器在解密数据包之前快速检测和拒绝重播或伪造数据包，从而潜在地减少拒绝服务（DoS）攻击的影响。它还允许在接收器处并行处理分组的可能性，即解密可以与完整性检查并行进行。请注意，由于ICV不受加密保护，因此必须使用密钥完整性算法来计算ICV。
4. Compute the ICV over the ESP packet minus the ICV field. Thus, the ICV computation encompasses the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header. (Note that the last 4 fields will be in ciphertext form, because encryption is performed first.) If the ESN option is enabled for the SA, the high-order 32 bits of the sequence number are appended after the Next Header field for purposes of this computation, but are not transmitted.
4. 计算ESP数据包上的ICV减去ICV字段。因此，ICV计算包括SPI、序列号、有效载荷数据、填充（如果存在）、填充长度和下一个报头。（请注意，最后4个字段将采用密文形式，因为首先执行加密。）如果为SA启用ESN选项，则出于此计算的目的，序列号的高阶32位将附加在下一个报头字段之后，但不会传输。
For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a block size specified by the algorithm. If the length of ESP packet (as described above) does not match the block size requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet. (This padding is added after the Next Header field, or after the high-order 32 bits of the sequence number, if ESN is selected.) The block size (and hence the length of the padding) is specified by the integrity algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this question, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's block size.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.
对于某些完整性算法，执行ICV计算的字节字符串必须是算法指定的块大小的倍数。如果ESP数据包的长度（如上所述）与算法的块大小要求不匹配，则必须在ESP数据包的末尾追加隐式填充。（如果选择了ESN，则在下一个标头字段之后或序列号的高阶32位之后添加此填充。）块大小（以及填充长度）由完整性算法规范指定。此填充不随数据包一起传输。必须查阅定义完整性算法的文档，以确定是否需要如上所述的隐式填充。如果文档未指定此问题的答案，则默认情况下假定需要隐式填充（根据需要将数据包长度与算法的块大小匹配）。如果需要填充字节，但算法未指定填充内容，则填充八位字节的值必须为零。
If a combined confidentiality/integrity algorithm is employed, the Sender proceeds as follows:
如果采用了组合保密性/完整性算法，则发送方将按如下方式进行：
1. Encapsulate into the ESP Payload Data field: - for transport mode -- just the original next layer protocol information. - for tunnel mode -- the entire original IP datagram.
1. 封装到ESP有效负载数据字段：-对于传输模式-仅原始下一层协议信息。-对于隧道模式——整个原始IP数据报。
2. Add any necessary padding -- includes optional TFC padding and (encryption) Padding.
2. 添加任何必要的填充--包括可选的TFC填充和（加密）填充。
3. Encrypt and integrity protect the result using the key and combined mode algorithm specified for the SA and using any required cryptographic synchronization data. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the combined mode algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronization data is employed, it is constructed and input to the encryption algorithm as per the algorithm specification. - The Sequence Number (or Extended Sequence Number, as appropriate) and the SPI are inputs to the algorithm, as they must be included in the integrity check computation. The means by which these values are included in this computation are a function of
3. 加密和完整性使用为SA指定的密钥和组合模式算法以及任何所需的加密同步数据来保护结果。-如果显示了显式加密同步数据，例如IV，则根据算法规范将其输入到组合模式算法，并将其置于有效载荷字段中。-如果采用隐式加密同步数据，则根据算法规范构造并输入加密算法。-序列号（或扩展序列号，视情况而定）和SPI是算法的输入，因为它们必须包含在完整性检查计算中。计算中包含这些值的方法是
the combined mode algorithm employed and thus not specified in this standard. - The (explicit) ICV field MAY be a part of the ESP packet format when a combined mode algorithm is employed. If one is not used, an analogous field usually will be a part of the ciphertext payload. The location of any integrity fields, and the means by which the Sequence Number and SPI are included in the integrity computation, MUST be defined in an RFC that defines the use of the combined mode algorithm with ESP.
采用的组合模式算法，因此未在本标准中规定。-当采用组合模式算法时，（显式）ICV字段可能是ESP数据包格式的一部分。如果不使用类似字段，则类似字段通常将成为密文有效载荷的一部分。任何完整性字段的位置以及完整性计算中包含序列号和SPI的方式必须在RFC中定义，RFC定义了组合模式算法与ESP的使用。
The sender's counter is initialized to 0 when an SA is established. The sender increments the sequence number (or ESN) counter for this SA and inserts the low-order 32 bits of the value into the Sequence Number field. Thus, the first packet sent using a given SA will contain a sequence number of 1.
建立SA时，发送方计数器初始化为0。发送方递增此SA的序列号（或ESN）计数器，并将值的低位32位插入序列号字段。因此，使用给定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. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID.
如果启用了反重播功能（默认设置），则发送方会进行检查，以确保在序列号字段中插入新值之前计数器没有循环。换句话说，如果这样做会导致序列号循环，则发送方不得在SA上发送数据包。试图传输可能导致序列号溢出的数据包是可审核事件。此事件的审核日志条目应包括SPI值、当前日期/时间、源地址、目标地址和（在IPv6中）明文流ID。
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3). Thus, typical behavior of an ESP implementation calls for the sender to establish a new SA when the Sequence Number (or ESN) cycles, or in anticipation of this value cycling.
除非接收方另有通知，否则发送方假定默认启用了反重播（见第3.4.3节）。因此，ESP实现的典型行为要求发送方在序列号（或ESN）循环时或预期该值循环时建立新的SA。
If the key used to compute an ICV is manually distributed, a compliant implementation SHOULD NOT provide anti-replay service. If a user chooses to employ anti-replay in conjunction with SAs that are manually keyed, the sequence number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced. (See Section 5.)
如果用于计算ICV的密钥是手动分发的，则符合要求的实现不应提供反重放服务。如果用户选择将防重播与手动键入的SAs结合使用，则必须在本地重新启动等过程中正确维护发送方的序列号计数器，直到更换密钥。（见第5节。）
If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter. However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside
如果禁用了反重播功能（如上所述），发送方无需监视或重置计数器。但是，发送方仍然增加计数器，当它达到最大值时，计数器将回滚到零。（建议多发送方、多播SAs使用此行为，除非外部有防重播机制
the scope of this standard are negotiated between the sender and receiver.)
本标准的范围由发送方和接收方协商。）
If ESN (see Appendix) is selected, only the low-order 32 bits of the sequence number are transmitted in the Sequence Number field, although both sender and receiver maintain full 64-bit ESN counters. The high order 32 bits are included in the integrity check in an algorithm/mode-specific fashion, e.g., the high-order 32 bits may be appended after the Next Header field when a separate integrity algorithm is employed.
如果选择了ESN（见附录），则在序列号字段中仅传输序列号的低位32位，尽管发送方和接收方都保持完整的64位ESN计数器。高阶32位以算法/模式特定的方式包括在完整性检查中，例如，当采用单独的完整性算法时，高阶32位可以附加在下一报头字段之后。
Note: If a receiver chooses to not enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high-order bits of the ESN, which are employed in the ICV computation), which is generally contrary to the notion of disabling anti-replay for an SA.
注意：如果接收器选择不为SA启用反重播，则接收器不应在SA管理协议中协商ESN。ESN的使用导致接收机需要管理反重放窗口（以确定ICV计算中使用的ESN高阶位的正确值），这通常与禁用SA反重放的概念相反。
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, which may be a fragment of an IP datagram. 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 end of Section 3.1.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.1节末尾所述，堆栈中的bump和有线实现中的bump可能必须首先重新组装由本地IP层分割的数据包，然后应用IPsec，然后分割生成的数据包。
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine 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处理之前重新组装数据包。
Fragmentation, whether performed by an IPsec implementation or by routers along the path between IPsec peers, significantly reduces performance. Moreover, the requirement for an ESP receiver to accept fragments for reassembly creates denial of service vulnerabilities. Thus, an ESP implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery. In any case, an ESP implementation MUST
分段，无论是由IPsec实现还是由IPsec对等点之间的路由器执行，都会显著降低性能。此外，ESP接收器接受重组碎片的要求造成了拒绝服务漏洞。因此，ESP实现可以选择不支持分段，并且可以用DF位标记传输的分组，以促进路径MTU（PMTU）发现。在任何情况下，ESP实施都必须
support generation of ICMP PMTU messages (or equivalent internal signaling for native host implementations) to minimize the likelihood of fragmentation. Details of the support required for MTU management are contained in the Security Architecture document.
支持生成ICMP PMTU消息（或本机主机实现的等效内部信令），以最大限度地降低碎片化的可能性。MTU管理所需支持的详细信息包含在安全体系结构文档中。
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 zeroing 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规范不需要对偏移量字段进行调零，也不需要清除“更多碎片”标志。为了让IPsec处理重新组装的数据包（而不是作为明显的片段丢弃），IP代码必须在重新组装数据包后完成这两件事。
Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.1. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field will be checked, whether 32- or 64-bit sequence numbers are employed for the SA, and whether the (explicit) ICV field should be present (and if so, its size). Also, the SAD entry will specify the algorithms and keys to be employed for decryption and ICV computation (if applicable).
在接收到包含ESP报头的数据包后，接收器通过SAD中的查找确定适当的（单向）SA。对于单播SA，该确定基于SPI或SPI plus协议字段，如第2.1节所述。如第2.1节所述，如果一个实现支持多播通信，那么在查找中也会使用目的地地址（除了SPI之外），也可以使用发送方地址。（此过程在安全体系结构文档中有更详细的描述。）SA的SAD条目还指示是否将检查序列号字段，SA是否使用32位或64位序列号，以及（显式）ICV字段是否应存在（如果是，其大小）。此外，SAD条目将指定用于解密和ICV计算的算法和密钥（如果适用）。
If no valid Security Association exists for this packet, 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。
(Note that SA management traffic, such as IKE packets, does not need to be processed based on SPI, i.e., one can demultiplex this traffic separately based on Next Protocol and Port fields, for example.)
（请注意，SA管理流量（例如IKE数据包）不需要基于SPI进行处理，即，可以基于下一个协议和端口字段分别对该流量进行解复用。）
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 ESP integrity service also is enabled for the SA, because otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below.
所有ESP实施必须支持反重播服务，尽管其使用可能由接收者根据每个SA启用或禁用。除非还为SA启用了ESP完整性服务，否则不得启用此服务，因为否则序列号字段未受到完整性保护。反重播适用于单播和多播SAs。但是，本标准未规定为多发送方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 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节），如果采用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检查，以加快重复数据包的拒绝。
ESP permits two-stage verification of packet sequence numbers. This capability is important whenever an ESP implementation (typically the cryptographic module portion thereof) is not capable of performing decryption and/or integrity checking at the same rate as the interface(s) to unprotected networks. If the implementation is capable of such "line rate" operation, then it is not necessary to perform the preliminary verification stage described below.
ESP允许对数据包序列号进行两阶段验证。当ESP实现（通常为其加密模块部分）不能以与未受保护网络接口相同的速率执行解密和/或完整性检查时，此功能非常重要。如果实施能够进行这种“线路速率”操作，则无需执行下述初步验证阶段。
The preliminary Sequence Number check is effected utilizing the Sequence Number value in the ESP Header and is performed prior to integrity checking and decryption. If this preliminary check fails,
利用ESP报头中的序列号值进行初步序列号检查，并在完整性检查和解密之前执行。如果初步检查失败，
the packet is discarded, thus avoiding the need for any cryptographic operations by the receiver. If the preliminary check is successful, the receiver cannot yet modify its local counter, because the integrity of the Sequence Number has not been verified at this point.
数据包被丢弃，从而避免了接收方进行任何加密操作的需要。如果初步检查成功，接收器还不能修改其本地计数器，因为此时序列号的完整性尚未验证。
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.
通过使用滑动接收窗口拒绝重复项。如何实现窗口是一个局部问题，但是下面的文本描述了实现必须展示的功能。
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. If the ESN option is selected for an SA, only the low-order 32 bits of the sequence number are explicitly transmitted, but the receiver employs the full sequence number computed using the high-order 32 bits for the indicated SA (from his local counter) when checking the received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for a single SA as large as 2**32-1 packets. If a larger gap occurs, additional, heuristic checks for re-synchronization of the receiver sequence number counter MAY be employed, as described in the Appendix.)
窗口的“右”边缘表示此SA上接收到的最高已验证序列号值。包含序列号低于窗口“左”边缘的数据包将被拒绝。根据窗口内接收的数据包列表检查窗口内的数据包。如果为SA选择ESN选项，则仅显式发送序列号的低阶32位，但在对照接收窗口检查接收序列号时，接收器使用使用所指示SA的高阶32位计算的完整序列号（从其本地计数器）。在构造完整序列号时，如果分组中携带的低阶32位的值低于接收机序列号的低阶32位，则接收机假定高阶32位已经增加，移动到新的序列号子空间。（该算法适应单个SA的接收间隔，最大为2**32-1个数据包。如果出现更大的间隔，可采用额外的启发式检查，以重新同步接收器序列号计数器，如附录所述。）
If the received packet falls within the window and is not a duplicate, or if the packet is to the right of the window, and if a separate integrity algorithm is employed, then the receiver proceeds to integrity verification. If a combined mode algorithm is employed, the integrity check is performed along with decryption. In either case, if the integrity check 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 integrity verification succeeds. (If a combined mode algorithm is being used, then the integrity protected Sequence Number must also match the Sequence Number used for anti-replay protection.)
如果接收到的数据包落在窗口内并且不是重复的，或者如果数据包在窗口的右侧，并且如果采用了单独的完整性算法，则接收器进行完整性验证。如果采用组合模式算法，完整性检查将与解密一起执行。在任何一种情况下，如果完整性检查失败，接收器必须将接收到的IP数据报视为无效而丢弃；这是一个可审核的事件。此事件的审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（在IPv6中）流ID。只有完整性验证成功时，才会更新接收窗口。（如果使用组合模式算法，则完整性保护的序列号也必须与用于防重放保护的序列号匹配。）
A minimum window size of 32 packets MUST be supported when 32-bit sequence numbers are employed; a window size of 64 is preferred and SHOULD be employed as the default. 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 receive window size
当使用32位序列号时，必须支持32个数据包的最小窗口大小；窗口大小为64是首选，应作为默认值使用。接收器可以选择另一个窗口大小（大于最小值）。（接收方不通知发送方窗口大小。）接收窗口大小
should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window sizes for very high-speed (e.g., multi-gigabit/second) devices are not specified by this standard.
对于更高速度的环境，无论保证问题如何，都应增加。本标准未规定超高速（例如，千兆位/秒）设备的最小和推荐接收窗口大小值。
As with outbound processing, there are several options for inbound processing, based on features of the algorithms employed.
与出站处理一样，根据所采用算法的特点，有几个入站处理选项。
If separate confidentiality and integrity algorithms are employed processing proceeds as follows:
如果采用单独的保密性和完整性算法，处理过程如下：
1. If integrity has been selected, the receiver computes the ICV over the ESP packet minus the ICV, using the specified integrity algorithm and verifies that it is the same as the ICV carried in the packet. Details of the computation are provided below.
1. 如果选择了完整性，则接收器使用指定的完整性算法计算ESP数据包减去ICV后的ICV，并验证其是否与数据包中携带的ICV相同。计算详情如下。
If the computed and received ICVs 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 (for IPv6) the cleartext Flow ID.
如果计算出的ICV与接收到的ICV匹配，则数据报有效，并被接受。如果测试失败，则接收器必须将接收到的IP数据报视为无效而丢弃；这是一个可审核的事件。日志数据应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（对于IPv6）明文流ID。
Implementation Note:
实施说明：
Implementations can use any set of steps that results in the same result as the following set of steps. Begin by removing and saving the ICV field. Next check the overall length of the ESP packet minus the ICV field. If implicit padding is required, based on the block size of the integrity algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field, or after the high-order 32 bits of the sequence number if ESN is selected. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification.
实现可以使用与以下步骤集产生相同结果的任何步骤集。首先删除并保存ICV字段。接下来检查ESP数据包的总长度减去ICV字段。如果需要隐式填充，则根据完整性算法的块大小，将零填充字节直接附加到ESP数据包末尾的下一个报头字段之后，或者如果选择了ESN，则在序列号的高阶32位之后。使用算法规范定义的比较规则，执行ICV计算并将结果与保存的值进行比较。
2. The receiver 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. As in Section 3.3.2, we speak here in terms of encryption always being applied because of
2. 接收器使用SA指示的密钥、加密算法、算法模式和加密同步数据（如果有）对ESP有效负载数据、填充、Pad长度和下一个报头进行解密。如第3.3.2节所述，我们在这里谈论的是由于以下原因而始终应用的加密：
the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm (RFC 2410).
格式含义。这是在理解使用空加密算法（RFC 2410）提供“无机密性”的情况下完成的。
- 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.
- 如果指示了显式加密同步数据，例如IV，则从有效载荷字段中获取该数据，并根据算法规范将其输入到解密算法。
- If implicit cryptographic synchronization data is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification.
- 如果指示隐式加密同步数据，则构造IV的本地版本，并根据算法规范将其输入解密算法。
3. The receiver 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. 接收方按照加密算法规范中的规定处理任何填充。如果采用了默认的填充方案（参见第2.4节），则接收方应在将解密数据传递到下一层之前，在移除填充之前检查填充字段。
4. The receiver checks the Next Header field. If the value is "59" (no next header), the (dummy) packet is discarded without further processing.
4. 接收器检查下一个标题字段。如果值为“59”（无下一个报头），则丢弃（虚拟）数据包，无需进一步处理。
5. The receiver reconstructs the original IP datagram from:
5. 接收器从以下内容重建原始IP数据报：
- for transport mode -- outer IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- the entire IP datagram in the ESP Payload field.
- 对于传输模式——外部IP报头加上ESP有效负载字段中的原始下一层协议信息——对于隧道模式——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. This processing "discards" any (optional) TFC padding that has been added for traffic flow confidentiality. (If present, this will have been inserted after the IP datagram (or transport-layer frame) and before the Padding field (see Section 2.4).)
重建原始数据报的确切步骤取决于模式（传输或隧道），并在安全体系结构文档中描述。至少，在IPv6上下文中，接收方应确保解密的数据是8字节对齐的，以便于通过下一个报头字段中标识的协议进行处理。此处理“丢弃”为流量机密性而添加的任何（可选）TFC填充。（如果存在，将在IP数据报（或传输层帧）之后和填充字段之前插入（参见第2.4节）
If integrity checking and encryption are performed in parallel, integrity checking 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: If the receiver performs decryption in parallel with integrity checking, care must be taken to avoid possible race conditions with regard to packet access and extraction of the decrypted packet.
注意：如果接收器与完整性检查并行执行解密，则必须注意避免与数据包访问和解密数据包提取相关的可能竞争条件。
If a combined confidentiality and integrity algorithm is employed, then the receiver proceeds as follows:
如果采用了组合的保密性和完整性算法，则接收机进行如下操作：
1. Decrypts and integrity checks the ESP Payload Data, Padding, Pad Length, and Next Header, using the key, algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. The SPI from the ESP header, and the (receiver) packet counter value (adjusted as required from the processing described in Section 3.4.3) are inputs to this algorithm, as they are required for the integrity check.
1. 使用SA指示的密钥、算法、算法模式和加密同步数据（如果有），对ESP有效负载数据、填充、填充长度和下一个报头进行解密和完整性检查。ESP报头的SPI和（接收器）数据包计数器值（根据第3.4.3节所述处理的要求进行调整）是该算法的输入，因为它们是完整性检查所必需的。
- 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.
- 如果指示了显式加密同步数据，例如IV，则从有效载荷字段中获取该数据，并根据算法规范将其输入到解密算法。
- 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.
- 如果指示隐式密码同步数据，例如IV，则构造IV的本地版本，并根据算法规范将其输入到解密算法。
2. If the integrity check performed by the combined mode algorithm fails, 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.
2. 如果组合模式算法执行的完整性检查失败，则接收器必须将接收到的IP数据报丢弃为无效；这是一个可审核的事件。日志数据应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（在IPv6中）明文流ID。
3. Process any Padding as specified in the encryption algorithm specification, if the algorithm has not already done so.
3. 按照加密算法规范中的规定处理任何填充（如果算法尚未这样做）。
4. The receiver checks the Next Header field. If the value is "59" (no next header), the (dummy) packet is discarded without further processing.
4. 接收器检查下一个标题字段。如果值为“59”（无下一个报头），则丢弃（虚拟）数据包，无需进一步处理。
5. Extract the original IP datagram (tunnel mode) or transport-layer frame (transport mode) from the ESP Payload Data field. This implicitly discards any (optional) padding
5. 从ESP有效负载数据字段中提取原始IP数据报（隧道模式）或传输层帧（传输模式）。这将隐式放弃任何（可选）填充
that has been added for traffic flow confidentiality. (If present, the TFC padding will have been inserted after the IP payload and before the Padding field (see Section 2.4).)
这是为交通流保密而添加的。（如果存在，TFC填充将在IP有效负载之后和填充字段之前插入（参见第2.4节）
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.
并非所有实施ESP的系统都将实施审核。但是，如果将ESP合并到支持审核的系统中，则ESP实施还必须支持审核，并且必须允许系统管理员启用或禁用ESP审核。在大多数情况下，审核的粒度是本地问题。但是，本规范中确定了几个可审核事件，并且为每个事件定义了应包含在审核日志中的最少信息集。
- No valid Security Association exists for a session. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (for IPv6) the cleartext Flow ID.
- 会话不存在有效的安全关联。此事件的审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（对于IPv6）明文流ID。
- 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 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进行处理的数据包似乎是IP片段，即偏移量字段为非零或设置了“更多片段”标志。此事件的审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（在IPv6中）流ID。
- Attempt to transmit a packet that would result in Sequence Number overflow. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, Sequence Number, and (for IPv6) the cleartext Flow ID.
- 尝试传输可能导致序列号溢出的数据包。此事件的审核日志条目应包括SPI值、当前日期/时间、源地址、目标地址、序列号和（对于IPv6）明文流ID。
- The received packet fails the anti-replay checks. 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.
- 收到的数据包未通过反重播检查。此事件的审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（在IPv6中）流ID。
- The integrity check fails. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (for IPv6) the Flow ID.
- 完整性检查失败。此事件的审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址、序列号和（对于IPv6）流ID。
Additional information also MAY be included in the audit log for each of these events, and additional 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 for unicast traffic, and MUST comply with all additional packet processing requirements levied by the Security Architecture document [Ken-Arch]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service requires correct maintenance of the counter state at the sender (across local reboots, etc.), 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 anti-replay service in conjunction with SAs that are manually keyed.
声明符合或符合本规范的实现必须实现此处描述的单播通信的ESP语法和处理，并且必须符合安全体系结构文档[Ken Arch]规定的所有附加数据包处理要求。此外，如果一个实现声称支持多播通信，那么它必须遵守为支持这种通信而指定的附加要求。如果用于计算ICV的密钥是手动分发的，则正确提供反重播服务需要正确维护发送方的计数器状态（通过本地重新启动等），直到密钥被替换，并且如果计数器即将溢出，则可能不会提供自动恢复。因此，兼容实现不应与手动键入的SAs一起提供反重播服务。
The mandatory-to-implement algorithms for use with ESP are described in a separate document [Eas04], to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported.
在单独的文件[Eas04]中描述了与ESP一起使用的强制算法，以便于独立于协议本身更新算法要求。除ESP强制使用的算法外，还可能支持其他算法。
Because use of encryption in ESP is optional, support for the "NULL" encryption algorithm also is required to maintain consistency with the way ESP services are negotiated. Support for the confidentiality-only service version of ESP is optional. If an implementation offers this service, it MUST also support the negotiation of the "NULL" integrity algorithm. NOTE that although integrity and encryption may each be "NULL" under the circumstances noted above, they MUST NOT both be "NULL".
由于在ESP中使用加密是可选的，因此还需要支持“NULL”加密算法，以保持与ESP服务协商方式的一致性。支持ESP的仅保密服务版本是可选的。如果实现提供此服务，它还必须支持“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 2406 in a number of significant ways.
本文件在许多重要方面与RFC 2406不同。
o Confidentiality-only service -- now a MAY, not a MUST.
o 只提供保密服务——现在是可能的，而不是必须的。
o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA, or may be combined with the protocol, at the option of the receiver. For multicast SAs, the SPI is combined with the destination address, and optionally the source address, to select an SA. o Extended Sequence Number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. o Payload data -- broadened model to accommodate combined mode algorithms. o Padding for improved traffic flow confidentiality -- added requirement to be able to add bytes after the end of the IP Payload, prior to the beginning of the Padding field. o Next Header -- added requirement to be able to generate and discard dummy padding packets (Next Header = 59) o ICV -- broadened model to accommodate combined mode algorithms. o Algorithms -- Added combined confidentiality mode algorithms. o Moved references to mandatory algorithms to a separate document. o Inbound and Outbound packet processing -- there are now two paths: (1) separate confidentiality and integrity algorithms and (2) combined confidentiality mode algorithms. Because of the addition of combined mode algorithms, the encryption/decryption and integrity sections have been combined for both inbound and outbound packet processing.
o SPI——修改为指定单播和多播SA的SAD查找的统一算法，涵盖更广泛的多播技术。对于单播，SPI可单独用于选择SA，或可根据接收机的选择与协议组合。对于多播SA，SPI与目标地址（可选）和源地址组合以选择SA。o扩展序列号——为用于高速通信的64位序列号添加了一个新选项。阐明了多播SAs和多发送方SAs的发送方和接收方处理要求。o有效载荷数据——扩展模型以适应组合模式算法。o填充以提高流量机密性——增加了能够在IP有效负载结束之后、填充字段开始之前添加字节的要求。o Next Header——增加了能够生成和丢弃虚拟填充数据包（Next Header=59）的要求o ICV——扩展了模型以适应组合模式算法。o算法——添加了组合保密模式算法。o将对强制算法的引用移动到单独的文档中。o入站和出站数据包处理——现在有两条路径：（1）单独的机密性和完整性算法，（2）组合的机密性模式算法。由于添加了组合模式算法，加密/解密和完整性部分已组合用于入站和出站数据包处理。
There is no version number in ESP and no mechanism enabling IPsec peers to discover or negotiate which version of ESP each is using or should use. This section discusses consequent backward-compatibility issues.
ESP中没有版本号，也没有使IPsec对等方能够发现或协商各自正在使用或应该使用的ESP版本的机制。本节讨论由此产生的向后兼容性问题。
First, if none of the new features available in ESP v3 are employed, then the format of an ESP packet is identical in ESP v2 and v3. If a combined mode encryption algorithm is employed, a feature supported only in ESP v3, then the resulting packet format may differ from the ESP v2 spec. However, a peer who implements only ESP v2 would never negotiate such an algorithm, as they are defined for use only in the ESP v3 context.
首先，如果ESP v3中没有使用任何新功能，则ESP数据包的格式在ESP v2和v3中是相同的。如果采用组合模式加密算法（仅在ESP v3中支持的功能），则生成的数据包格式可能不同于ESP v2规范。但是，仅实现ESP v2的对等方将永远不会协商此类算法，因为它们被定义为仅在ESP v3上下文中使用。
Extended Sequence Number (ESN) negotiation is supported by IKE v2 and has been addressed for IKE v1 by the ESN Addendum to the IKE v1 Domain of Interpretation (DOI).
IKE v2支持扩展序列号（ESN）协商，IKE v1解释域（DOI）的ESN补遗已针对IKE v1进行了说明。
In the new ESP (v3), we make two provisions to better support traffic flow confidentiality (TFC):
在新的ESP（v3）中，我们制定了两项规定，以更好地支持交通流机密性（TFC）：
- arbitrary padding after the end of an IP packet - a discard convention using Next Header = 59
- IP数据包结束后的任意填充-使用Next Header=59的丢弃约定
The first feature is one that should not cause problems for a receiver, since the IP total length field indicates where the IP packet ends. Thus, any TFC padding bytes after the end of the packet should be removed at some point during IP packet processing, after ESP processing, even if the IPsec software does not remove such padding. Thus, this is an ESP v3 feature that a sender can employ irrespective of whether a receiver implements ESP v2 or ESP v3.
第一个特性应该不会给接收器带来问题，因为IP总长度字段指示IP数据包的结束位置。因此，在IP数据包处理期间，在ESP处理之后，即使IPsec软件未删除此类填充，也应在某个点删除数据包结束后的任何TFC填充字节。因此，这是一种ESP v3功能，发送方可以使用该功能，而不管接收方是实现ESP v2还是ESP v3。
The second feature allows a sender to send a payload that is an arbitrary string of bytes that do not necessarily constitute a well-formed IP packet, inside of a tunnel, for TFC purposes. It is an open question as to what an ESP v2 receiver will do when the Next Header field in an ESP packet contains the value "59". It might discard the packet when it finds an ill-formed IP header, and log this event, but it certainly ought not to crash, because such behavior would constitute a DoS vulnerability relative to traffic received from authenticated peers. Thus this feature is an optimization that an ESP v3 sender can make use of irrespective of whether a receiver implements ESP v2 or ESP v3.
第二个特性允许发送方出于TFC目的在隧道内发送一个有效负载，该有效负载是一个不一定构成格式良好的IP数据包的任意字节字符串。当ESP数据包中的下一个报头字段包含值“59”时，ESP v2接收器将做什么，这是一个悬而未决的问题。当它发现格式错误的IP报头时，它可能会丢弃该数据包，并记录此事件，但它肯定不会崩溃，因为这种行为相对于从经过身份验证的对等方接收的流量而言，将构成DoS漏洞。因此，无论接收方是实施ESP v2还是ESP v3，ESP v3发送方都可以利用此功能进行优化。
The author would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827. Karen Seo deserves special thanks for providing help in the editing of this and the previous version of this specification. The author also would like to thank the members of the IPSEC and MSEC working groups who have contributed to the development of this protocol specification.
作者要感谢Ran Atkinson的贡献，他在最初的IPsec活动中发挥了关键作用，并编写了第一系列IPsec标准：RFCs 1825-1827。Karen Seo值得特别感谢，感谢您在编辑本规范和本规范先前版本时提供的帮助。作者还要感谢IPSEC和MSEC工作组的成员，他们为本协议规范的开发做出了贡献。
[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月。
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DH98]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[Eas04]第三届Eastlake，D.，“封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求”，RFC 4305，2005年12月。
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[Ken Arch]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[Pos81]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[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月。
[HC03] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress, November 3, 2002.
[HC03]Holbrook，H.和B.Cain，“IP的源特定多播”，正在进行的工作，2002年11月3日。
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Kau05]Kaufman，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[Ken-AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[Ken AH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[Kra01] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)", CRYPTO' 2001.
[Kra01]Krawczyk，H.，“保护通信的加密和认证顺序（或：SSL有多安全？），《加密》2001年。
[NIST01] Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2), "Security Requirements for Cryptographic Modules", Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
[NIST01]联邦信息处理标准出版物140-2（FIPS PUB 140-2），“加密模块的安全要求”，国家标准与技术研究所信息技术实验室，2001年5月25日。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[Syverson] P. Syverson, D. Goldschlag, and M. Reed, "Anonymous Connections and Onion Routing", Proceedings of the Symposium on Security and Privacy, Oakland, CA, May 1997, pages 44-54.
[Syverson]P.Syverson，D.Goldschlag和M.Reed，“匿名连接和洋葱路由”，安全和隐私研讨会论文集，加利福尼亚州奥克兰，1997年5月，第44-54页。
Appendix A: Extended (64-bit) Sequence Numbers
附录A：扩展（64位）序列号
A1. Overview
A1。概述
This appendix describes an extended sequence number (ESN) scheme for use with IPsec (ESP and AH) that employs a 64-bit sequence number, but in which only the low-order 32 bits are transmitted as part of each packet. It covers both the window scheme used to detect replayed packets and the determination of the high-order bits of the sequence number that are used both for replay rejection and for computation of the ICV. It also discusses a mechanism for handling loss of synchronization relative to the (not transmitted) high-order bits.
本附录描述了用于IPsec（ESP和AH）的扩展序列号（ESN）方案，该方案采用64位序列号，但在该方案中，每个数据包仅传输低阶32位。它包括用于检测重播分组的窗口方案和用于重播拒绝和ICV计算的序列号的高阶位的确定。它还讨论了处理相对于（未传输）高阶位的同步丢失的机制。
A2. Anti-Replay Window
A2。防重播窗口
The receiver will maintain an anti-replay window of size W. This window will limit how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. (No requirement is established for minimum or recommended sizes for this window, beyond the 32- and 64-packet values already established for 32-bit sequence number windows. However, it is suggested that an implementer scale these values consistent with the interface speed supported by an implementation that makes use of the ESN option. Also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) All 2^32 sequence numbers associated with any fixed value for the high-order 32 bits (Seqh) will hereafter be called a sequence number subspace. The following table lists pertinent variables and their definitions.
接收器将保持一个大小为W的反重播窗口。该窗口将限制一个数据包相对于迄今为止已通过身份验证的序列号最高的数据包的无序程度。（除了已经为32位序列号窗口建立的32和64数据包值外，没有为此窗口建立最小或建议的大小要求。但是，建议实现者根据使用ESN选项的实现所支持的接口速度来缩放这些值。此外下面描述的算法假设窗口宽度不大于2^31个数据包。）所有与高阶32位（Seqh）的任何固定值相关联的2^32序列号将在下文中称为序列号子空间。下表列出了相关变量及其定义。
Var. Size
Name (bits) Meaning
---- ------ ---------------------------
W 32 Size of window
T 64 Highest sequence number authenticated so far,
upper bound of window
Tl 32 Lower 32 bits of T
Th 32 Upper 32 bits of T
B 64 Lower bound of window
Bl 32 Lower 32 bits of B
Bh 32 Upper 32 bits of B
Seq 64 Sequence Number of received packet
Seql 32 Lower 32 bits of Seq
Seqh 32 Upper 32 bits of Seq
Var. Size
Name (bits) Meaning
---- ------ ---------------------------
W 32 Size of window
T 64 Highest sequence number authenticated so far,
upper bound of window
Tl 32 Lower 32 bits of T
Th 32 Upper 32 bits of T
B 64 Lower bound of window
Bl 32 Lower 32 bits of B
Bh 32 Upper 32 bits of B
Seq 64 Sequence Number of received packet
Seql 32 Lower 32 bits of Seq
Seqh 32 Upper 32 bits of Seq
When performing the anti-replay check, or when determining which high-order bits to use to authenticate an incoming packet, there are two cases:
在执行反重放检查时，或在确定用于验证传入数据包的高阶位时，有两种情况：
+ Case A: Tl >= (W - 1). In this case, the window is within one sequence number subspace. (See Figure 1) + Case B: Tl < (W - 1). In this case, the window spans two sequence number subspaces. (See Figure 2)
+ 案例A:Tl>=（W-1）。在这种情况下，窗口位于一个序列号子空间内。（见图1）+案例B:Tl<（W-1）。在这种情况下，窗口跨越两个序列号子空间。（见图2）
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th+1 *********
Th =======*****
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
图1——案例A
Th ====**************
Th ====**************
Th-1 ===
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
图2——案例B
A2.1. Managing and Using the Anti-Replay Window
A2.1。管理和使用防重播窗口
The anti-replay window can be thought of as a string of bits where `W' defines the length of the string. W = T - B + 1 and cannot exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and the top-most bit corresponds to T, and each sequence number from Bl through Tl is represented by a corresponding bit. The value of the bit indicates whether or not a packet with that sequence number has been received and authenticated, so that replays can be detected and rejected.
反重放窗口可以看作是一个位字符串，其中“W”定义了字符串的长度。W=T-B+1，值不能超过2^32-1。最下面的位对应于B，最上面的位对应于T，从Bl到Tl的每个序列号由对应的位表示。位的值指示是否已接收并验证了具有该序列号的数据包，以便可以检测并拒绝重播。
When a packet with a 64-bit sequence number (Seq) greater than T is received and validated,
当接收并验证64位序列号（Seq）大于T的数据包时，
+ B is increased by (Seq - T) + (Seq - T) bits are dropped from the low end of the window + (Seq - T) bits are added to the high end of the window + The top bit is set to indicate that a packet with that sequence number has been received and authenticated + The new bits between T and the top bit are set to indicate that no packets with those sequence numbers have been received yet. + T is set to the new sequence number
+ B增加（Seq-T）+（Seq-T）位从窗口的低端删除+（Seq-T）位被添加到窗口的高端+顶部位被设置为指示具有该序列号的数据包已被接收和验证+T和顶部位之间的新位被设置为指示尚未接收到具有这些序列号的数据包T设置为新的序列号
In checking for replayed packets,
在检查重播的数据包时，
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <= Tl, then check the corresponding bit in the window to see if this Seql has already been seen. If yes, reject the packet. If no, perform integrity check (see Appendix A2.2. below for determination of Seqh).
+ 在情况A下：如果Seql>=Bl（其中Bl=Tl-W+1）和Seql<=Tl，则检查窗口中的相应位，以查看是否已经看到该Seql。如果是，则拒绝该数据包。如果否，则进行完整性检查（关于Seqh的确定，请参见下面的附录A2.2）。
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <= Tl, then check the corresponding bit in the window to see if this Seql has already been seen. If yes, reject the packet. If no, perform integrity check (see Appendix A2.2. below for determination of Seqh).
+ 在情况B下：如果Seql>=Bl（其中Bl=Tl-W+1）或Seql<=Tl，则检查窗口中的相应位，以查看是否已经看到该Seql。如果是，则拒绝该数据包。如果否，则进行完整性检查（关于Seqh的确定，请参见下面的附录A2.2）。
A2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number
A2.2。确定序列号的高阶位（Seqh）
Because only `Seql' will be transmitted with the packet, the receiver must deduce and track the sequence number subspace into which each packet falls, i.e., determine the value of Seqh. The following equations define how to select Seqh under "normal" conditions; see Section A3 for a discussion of how to recover from extreme packet loss.
因为只有“Seql”将与分组一起发送，所以接收机必须推导并跟踪每个分组所落入的序列号子空间，即，确定Seqh的值。以下方程式定义了如何在“正常”条件下选择Seqh；有关如何从极端数据包丢失中恢复的讨论，请参见第A3节。
+ Under Case A (Figure 1): If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ 在案例A下（图1）：如果Seql>=Bl（其中Bl=Tl-W+1），那么Seqh=Th如果Seql<Bl（其中Bl=Tl-W+1），那么Seqh=Th+1
+ Under Case B (Figure 2): If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
+ 在情况B下（图2）：如果Seql>=Bl（其中Bl=Tl-W+1），那么Seqh=Th-1如果Seql<Bl（其中Bl=Tl-W+1），那么Seqh=Th
A2.3. Pseudo-Code Example
A2.3。伪代码示例
The following pseudo-code illustrates the above algorithms for anti-replay and integrity checks. The values for `Seql', `Tl', `Th' and `W' are 32-bit unsigned integers. Arithmetic is mod 2^32.
以下伪代码说明了上述反重播和完整性检查算法。“Seql”、“Tl”、“Th”和“W”的值是32位无符号整数。算术是mod 2^32。
If (Tl >= W - 1) Case A If (Seql >= Tl - W + 1) Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set bit corresponding to Seql Pass the packet on Else reject packet Else reject packet Else If (pass integrity check) Tl = Seql (shift bits) Set bit corresponding to Seql Pass the packet on Else reject packet Else Seqh = Th + 1 If (pass integrity check) Tl = Seql (shift bits) Th = Th + 1 Set bit corresponding to Seql Pass the packet on Else reject packet Else Case B If (Seql >= Tl - W + 1) Seqh = Th - 1 If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet Else Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet
If（Tl>=W-1）情况A If（Seql>=Tl-W+1）Seqh=Th If（Seql<=Tl）If（通过重放检查）If（通过完整性检查）If（通过完整性检查）设置对应于Seql的位pass the packet on Else拒绝包Else拒绝包Else If（通过完整性检查）Tl=Seql（移位位）设置位对应于Seql在Else上传递数据包拒绝数据包Else Seqh=Th+1 If（通过完整性检查）Tl=Seql（移位位）Th=Th+1设置位对应于Seql在Else上传递数据包拒绝数据包Else情况B If（Seql>=Tl-W+1）Seqh=Th-1 If（通过重放检查）If（通过完整性检查）设置与Else reject packet Else reject packet Else上的Seql Pass packet对应的位Seqh=Th If（Seql<=Tl）If（通过重放检查）If（通过完整性检查）设置与Else reject packet Else reject packet上的Seql Pass packet对应的位
Else If (pass integrity check) Tl = Seql (shift bits) Set the bit corresponding to Seql Pass packet on Else reject packet
Else If（通过完整性检查）Tl=Seql（移位位）在Else拒绝数据包上设置与Seql通过数据包对应的位
A3. Handling Loss of Synchronization due to Significant Packet Loss
A3。处理由于重大数据包丢失而导致的同步丢失
If there is an undetected packet loss of 2^32 or more consecutive packets on a single SA, then the transmitter and receiver will lose synchronization of the high-order bits, i.e., the equations in Section A2.2. will fail to yield the correct value. Unless this problem is detected and addressed, subsequent packets on this SA will fail authentication checks and be discarded. The following procedure SHOULD be implemented by any IPsec (ESP or AH) implementation that supports the ESN option.
如果单个SA上存在2^32或更多连续数据包的未检测到的数据包丢失，则发射机和接收机将丢失高阶位的同步，即第A2.2节中的等式。将无法生成正确的值。除非检测到并解决此问题，否则此SA上的后续数据包将无法通过身份验证检查并被丢弃。以下过程应通过支持ESN选项的任何IPsec（ESP或AH）实现来实现。
Note that this sort of extended traffic loss is likely to be detected at higher layers in most cases, before IPsec would have to invoke the sort of re-synchronization mechanism described in A3.1 and A3.2. If any significant fraction of the traffic on the SA in question is TCP, the source would fail to receive ACKs and would stop sending long before 2^32 packets had been lost. Also, for any bi-directional application, even ones operating above UDP, such an extended outage would likely result in triggering some form of timeout. However, a unidirectional application, operating over UDP, might lack feedback that would cause automatic detection of a loss of this magnitude, hence the motivation to develop a recovery method for this case. Note that the above observations apply to SAs between security gateways, or between hosts, or between host and security gateways.
请注意，在大多数情况下，在IPsec必须调用A3.1和A3.2中描述的重新同步机制之前，这种扩展流量丢失可能会在更高的层上检测到。如果所讨论的SA上的流量中有很大一部分是TCP，则源将无法接收ACK，并且在2^32个数据包丢失之前很久就停止发送。此外，对于任何双向应用程序，即使是在UDP之上运行的应用程序，这种延长的中断可能会触发某种形式的超时。但是，在UDP上运行的单向应用程序可能缺少反馈，从而导致自动检测到这种程度的丢失，因此需要为这种情况开发一种恢复方法。请注意，上述观察结果适用于安全网关之间、主机之间或主机与安全网关之间的SAs。
The solution we've chosen was selected to:
我们选择的解决方案用于：
+ minimize the impact on normal traffic processing
+ 尽量减少对正常流量处理的影响
+ avoid creating an opportunity for a new denial of service attack such as might occur by allowing an attacker to force diversion of resources to a re-synchronization process
+ 通过允许攻击者强制将资源转移到重新同步过程，避免造成新的拒绝服务攻击机会，例如可能发生的攻击
+ limit the recovery mechanism to the receiver -- because anti-replay is a service only for the receiver, and the transmitter generally is not aware of whether the receiver is using sequence numbers in support of this optional service, it is preferable for recovery mechanisms to be local to the receiver. This also allows for backward compatibility.
+ 将恢复机制限制在接收器——因为反重放是仅针对接收器的服务，并且发射器通常不知道接收器是否使用序列号来支持此可选服务，因此恢复机制最好是接收器本地的。这也允许向后兼容。
A3.1. Triggering Re-synchronization
A3.1。触发再同步
For each SA, the receiver records the number of consecutive packets that fail authentication. This count is used to trigger the re-synchronization process, which should be performed in the background or using a separate processor. Receipt of a valid packet on the SA resets the counter to zero. The value used to trigger the re-synchronization process is a local parameter. There is no requirement to support distinct trigger values for different SAs, although an implementer may choose to do so.
对于每个SA，接收器记录认证失败的连续数据包的数量。此计数用于触发重新同步过程，该过程应在后台或使用单独的处理器执行。收到SA上的有效数据包后，计数器将重置为零。用于触发重新同步过程的值是本地参数。不需要为不同的SA支持不同的触发器值，尽管实现者可以选择这样做。
A3.2. Re-synchronization Process
A3.2。重新同步过程
When the above trigger point is reached, a "bad" packet is selected for which authentication is retried using successively larger values for the upper half of the sequence number (Seqh). These values are generated by incrementing by one for each retry. The number of retries should be limited, in case this is a packet from the "past" or a bogus packet. The limit value is a local parameter. (Because the Seqh value is implicitly placed after the ESP (or AH) payload, it may be possible to optimize this procedure by executing the integrity algorithm over the packet up to the endpoint of the payload, then compute different candidate ICVs by varying the value of Seqh.) Successful authentication of a packet via this procedure resets the consecutive failure count and sets the value of T to that of the received packet.
当达到上述触发点时，选择一个“坏”数据包，使用序列号（Seqh）上半部分的连续较大值重试验证。这些值是通过每次重试递增一来生成的。重试次数应受到限制，以防这是来自“过去”的数据包或伪造数据包。极限值是一个局部参数。（因为Seqh值隐式地放在ESP（或AH）有效载荷之后，所以可以通过在数据包上执行完整性算法直到有效载荷的端点来优化该过程，然后通过改变Seqh值来计算不同的候选ICV。）通过此过程成功验证数据包将重置连续故障计数，并将T的值设置为接收数据包的值。
This solution requires support only on the part of the receiver, thereby allowing for backward compatibility. Also, because re-synchronization efforts would either occur in the background or utilize an additional processor, this solution does not impact traffic processing and a denial of service attack cannot divert resources away from traffic processing.
此解决方案只需要接收器部分的支持，从而允许向后兼容。此外，由于重新同步工作将在后台进行或使用额外的处理器，因此此解决方案不会影响流量处理，并且拒绝服务攻击无法将资源从流量处理中转移。
Author's Address
作者地址
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
美国马萨诸塞州剑桥莫尔顿街10号Stephen Kent BBN Technologies 02138
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。