组织：中国互动出版网（/）
RFC文档中文翻译计划（/compters/emook/aboutemook.htm）
E-mail：
译者：sword（sword ）
译文发布时间：2001-5-11
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group S. Kent
Request for Comments: 2406 BBN Corp
Obsoletes: 1827 R. Atkinson
Category: Standards Track @Home Network
November 1998
IP 封装安全有效载荷(ESP)
(RFC 2406 IP Encapsulating Security Payload (ESP))
本文档状态：
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Plea 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.
版权声明
Copyright (C) The Internet Society (1998). All Rights Rerved.
目录列表
1. 介绍 (2)
2. 封装安全有效载荷分组格式 (3)
2.1 安全参数索引 (4)感谢母亲的句子
2.2 序列号 (4)
2.3 有效载荷数据 (5)
2.4 填充（供加密使用） (5)
2.5 填充长度 (7)
2.6 下一个头 (7)
2.7 验证数据 (7)
3. 封装安全协议处理 (7)
3.1 ESP头定位 (7)
3.2 算法 (10)
3.2.1 加密算法 (10)
3.2.2 验证算法 (10)
3.3 出站分组处理 (10)
3.3.1 SA查找 (11)
3.3.2 分组加密 (11)
3.3.3 序列号产生 (12)
3.3.4 完整性校验值计算 (12)
3.3.5 分片 (13)
3.4 入站分组处理 (13)
十年之后
3.4.1 重组 (13)
3.4.2 SA查找 (13)
3.4.3 序列号确认 (14)
3.4.4 完整性校验值确认 (15)
3.4.5 分组解密 (16)
4. 审核 (17)
5. 一致性要求 (18)
6. 安全考虑事项 (18)
7. 与RFC 1827的不同 (18)
致谢 (19)
参考书目 (19)
Disclaimer (20)
作者信息 (21)
版权声明 (22)
1. 介绍
封装安全有效载荷头在IPv4和IPv6中提供一种混合的安全服务。ESP可以单独应用，与IP
验证头(AH)结合使用，或者采用嵌套形式，例如，隧道模式的应用(参看"Security Architecture for the Internet Protocol" [KA97a]，下面使用“安全架构文档”代替)。安全服务可以在一对通信主机之间，一对通信的安全网关之间，或者一个安全网关和一台主机之间实现。在各种网络环境中如何使用ESP和AH的详细细节，参看安全架构文档。
ESP头可以插在IP头之后、上层协议头之前(传送模式)，或者在封装的IP头之前(隧道模式)。下面将详细介绍这些模式。
ESP提供机密性、数据源验证、无连接的完整性、抗重播服务(一种部分序列完整性的形式)
和有限信息流机密性。提供的这组服务由SA建立时选择的选项和实现的位置来决定，机密性的选择与所有其他服务相独立。但是，确保机密性而不保证完整性/验证(在ESP或者单独在AH中) 可能使信息
易受到某种活动的、破坏机密性服务的攻击(参看[Bel96])。数据源验证和无连接的完整性(下面统一称作“验证”引用它们)是相互关联的服务，它们作为一个选项与机密性(可选择的) 结合提供给用户。只有选择数据源验证时才可以选择抗重播服务，由接收方单独决定抗重播服务的选择。（尽管默认要求发送方增加抗重播服务使用的序列号，但只有当接收方检查序列号，服务才是有效的。）信息流机密性要求选择隧道模式，如果在安全网关上实现信息流机密性是最有
效的，这里信息聚集能够掩饰真正的源-目的模式。注意尽管机密性和验证是可选的，但它们中必须至少选择一个。
假定读者熟悉安全架构文档中描述的术语和概念。特别是，读者应该熟悉ESP和AH提供的安全服务的定义，SA定义，ESP可以和验证（AH）头结合使用的方式，以及ESP和AH使用
的不同密钥管理选项。（至于最后一项，ESP和AH要求的当前密钥管理选项是通过IKE进行的
幼儿教师资格证报考要求
手工建立密钥和自动建立密钥[HC98]。）
关键字MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY，和OPTIONAL, 当它们出现在本文档时，由RFC2119中的描述解释它
们的含义[Bra97]。
2. 封装安全有效载荷分组格式
ESP头紧紧跟在协议头（IPv4，IPv6，或者扩展）之后，协议头的协议字段（IPv4）将是50，或者协议的下一个头(IPv6，扩展)字段[STD-2]值是50。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| 安全参数索引(SPI) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| 序列号| |erage
肉酱怎么做+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| 有效载荷数据* (可变的) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | 填充(0-255 bytes) | |erage*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | 填充长度| 下一个头| v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| 验证数据(可变的) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*如果加密同步数据，例如初始化向量（IV，参看2.3节），包含在有效载荷字段中，通常它本身并不加密，虽然常常把它作为密文的一部分。
爵迹预告片
下面小节定义了头格式中的字段。“可选项”意味着如果没有选择它，该字段被忽略。即它既不被包含在传送的分组中，也不会在完整性校验值(ICV，参看2.7)计算中出现。建立SA时决定是否选择某个选项，因此ESP分组的格式对于给定的SA是确定的，整个SA存活期间也是确定
的。相对而言，“强制性”字段总是出现在ESP分组格式中，对所有SA均如此。
2.1 安全参数索引SPI
SPI是一个任意的32位值，它与目的IP地址和安全协议（ESP）结合，唯一地标识这个数据报的SA。从1至255的这组SPI值是由Internet Assigned Numbers Authority (IANA)保留给将来
使用的；除了分配的SPI值的使用由RFC指定，否则，一般IANA不会分配保留的SPI值。通
常在建立SA时目的系统选择SPI（详细内容请参看安全架构文档）。SPI字段是强制性的。
SPI的值为0是保留给本地、特定实现使用的，不允许在线路上发送。例如，密钥管理实现可以使用SPI的0值表示当IPc实现要求它的密钥管理实体建立新SA，但SA仍然没有建立时，“没有SA存在”。
2.2 序列号Sequence Number小鹿斑比主要内容
这个无符号的、32位字段包含一个单调递增的计数器值（序列号）。它是强制性的，即使接收方没有选择激活一个特定SA的抗重播服务，它也总是存在。序列号字段由接收方处理，即发送方必须总是传输这个字段，但接收方不需要对其操作（参看下面“入站分组处理”中序列号确认的讨论）。
发送方的计数器和接收方的计数器在一个SA建立时被初始化为0。（使用给定SA发送的第一个分组的序列号1；序列号如何产生的细节参看3.3.3节）如果激活抗重播服务（默认地），传送的序列号必须决不允许循环。因此，在SA上传送第2的32次方个分组之前，发送方计数器和接收方计数器必须重新置位（通过建立新SA和获取新密钥）
2.3 有效载荷数据Payload Data
有效载荷数据是变长字段，它包含下一个头字段描述的数据。有效载荷数据字段是强制性的，它的长度是字节的整数倍。如果加密有效载荷的算法要求加密同步数据，例如初始化向量（IV），那么这个数据可以明确地装载在有效载荷字段。任何要求这样明确的、每分组同步数据的加密算法必须指出同步数据的长度、结构和位置，这是指定ESP中算法如何使用的某个RFC的一部分。如果这种同步数据是隐式的，派生数据的算法必须是RFC的一部分。
注意关于确保IV存在时（实际）密文对齐：
o 对于一些基于IV模式的操作，接收方把I V作为密文的开始，直接把IV传给算法。这些模式中，（实际）密文是否开始对齐对于接收方并不重要。
o 某些情况下，接收方从密文中单独读入IV。此时，算法规范必须解决（实际）密文对齐如何实现。
2.4 填充(供加密使用)
仙女弹琴几种因素要求或者激活填充字段的使用。
o 如果采用的加密算法要求明文是某个数量字节的倍数，例如块密码（block cipher）
的块大小，使用填充字段填充明文（包含有效载荷数据、填充长度和下一个头字段，以及填充）以达到算法要求的长度。
o 不管加密算法要求如何，也可以要求填充字段来确保结果密文以4字节边界终止。特别是，填充长度字段和下一个头字段必须在4字节字内右对齐，如上图所示的ESP分组格式，从而确保验证数据字段（如果存在）以4字节边界对齐。
o除了算法要求或者上面提及的对齐原因之外，填充字段可以用于隐藏有效载荷实际长度，支持（部分）信息流机密性。但是，包含这种额外的填充字段占据一定的带宽，因而小心使用。
发送方可以增加0至255个字节的填充。ESP分组的填充字段是可选的，但是所有实现必须
支持填充字段的产生和消耗。
a. 为了确保加密位是算法块大小（上面第一个加重号）的倍数，填充计算应用于除IV之外的有效载荷数据、填充长度和下一个头字段。
b. 为了确保验证数据以4字节边界对齐（上面第二个加重号），填充计算应用于包含IV的有效载荷数据、填充长度和下一个头字段。
如果需要填充字节，但是加密算法没有指定填充内容，则必须采用下列默认处理。填充字节使用一系列（无符号、1字节）整数值初始化。附加在明文之后的第一个填充字节为1，后面的填充字节按单调递增：1,2,3,…。当采用这种填充方案时，接收方应该检查填充字段。（选择这种方案是由于它相对简单，硬件实现容易。在没有其他完整性措施实施情况下，如果接收方检查解密的填充值，这种方案粉碎了某种形式的“剪切和粘贴”攻击，提供有限的保护。）
任何要求填充字段但不同于上述默认方法的加密算法，必须在一个指定ESP中算法如何使用的RFC中定义填充字段内容（例如，0或者随机数）和所有要求接收方对这些填充字节的处理。这种情况下，填充字段的内容将由相应算法RFC中定义和选择的加密算法和模式决定。相关的
算法RFC可以指定接收方必须检查填充字段或者接收方必须通知发送方接收方如何处理填充字段。
2.5 填充长度Pad Length
填充长度字段指明紧接其前的填充字节的个数。有效值范围是0至255，0表明没有填充字节。本人择业意愿
填充长度字段是强制性的。
2.6 下一个头
下一个头是一个8位字段，它标识有效载荷字段中包含的数据类型，例如，IPv6中的扩展头或者上层协议标识符。该字段值从Internet Assigned Numbers Authority (IANA)最新“Assigned Numbers”[STD-2] RFC 定义的IP协议号集当中选择。下一个头字段是强制性的。
