RFC2406-IP 封装安全有效载荷 (ESP)(2)

收方没有选择激活一个特定SA的抗重播服务，它也总是存在。序列号字段由接收方处理，即发
送方必须总是传输这个字段，但接收方不需要对其操作（参看下面“入站分组处理”中序列号确
认的讨论）。

发送方的计数器和接收方的计数器在一个SA建立时被初始化为0。（使用给定SA发送的第
一个分组的序列号1；序列号如何产生的细节参看3.3.3节）如果激活抗重播服务（默认地），传
送的序列号必须决不允许循环。因此，在SA上传送第2的32次方个分组之前，发送方计数器
和接收方计数器必须重新置位（通过建立新SA和获取新密钥）

2.3 有效载荷数据Payload Data

有效载荷数据是变长字段，它包含下一个头字段描述的数据。有效载荷数据字段是强制性的，
它的长度是字节的整数倍。如果加密有效载荷的算法要求加密同步数据，例如初始化向量（IV），
那么这个数据可以明确地装载在有效载荷字段。任何要求这样明确的、每分组同步数据的加密算
法必须指出同步数据的长度、结构和位置，这是指定ESP中算法如何使用的某个RFC的一部分。
如果这种同步数据是隐式的，派生数据的算法必须是RFC的一部分。

注意关于确保IV存在时（实际）密文对齐：

o 对于一些基于IV模式的操作，接收方把IV作为密文的开始，直接把IV传给算
法。这些模式中，（实际）密文是否开始对齐对于接收方并不重要。
o 某些情况下，接收方从密文中单独读入IV。此时，算法规范必须解决（实际）密
文对齐如何实现。

2.4 填充(供加密使用)

几种因素要求或者激活填充字段的使用:

A.如果采用的加密算法要求明文是某个数量字节的倍数，例如块密码（block cipher）
的块大小，使用填充字段填充明文（包含有效载荷数据、填充长度和下一个头字段，以及填充）
以达到算法要求的长度。

B.不管加密算法要求如何，也可以要求填充字段来确保结果密文以4字节边界终止。
特别是，填充长度字段和下一个
头字段必须在4字节字内右对齐，如上图所示的ESP分组格式，
从而确保验证数据字段（如果存在）以4字节边界对齐。

C.除了算法要求或者上面提及的对齐原因之外，填充字段可以用于隐藏有效载荷实际长度，支持（部分）
信息流机密性。但是，包含这种额外的填充字段占据一定的带宽，因而小心使用

RFC2406-IP 封装安全有效载荷 (ESP)

。

发送方可以增加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协议号集当中选择。下一个头字段是强制性的。

2.7 验证数据(对于ESP的验证，但是不包含本字段的验证)

验证数据是可变长字段，它包含一个完整性校验值（ICV），ESP分组中该值的计算不包含验
证数据本身。字段长度由选择的验证函数指定。验证数据字段是可选的，只有SA选择验证服务，
才包含验证数据字段。验证算法规范必须指定ICV长度、验证的比较规则和处理步骤。


3. 封装安全协议处理

3.1 ESP 头定位

类似于AH，ESP 有两种使用方式：传送模式或者隧道模式。前者仅在主机中实现，提供对
上层协议的保护，不提供对IP头的保护。（传送模式中，注意安全架构文档中定义的“堆栈中的
块”或者“线路中的块”实现，入站和出站IP

RFC2406-IP 封装安全有效载荷 (ESP)

分片可能要求IPsec实现执行额外的IP重组/分片，
以便遵照这个规范，提供透明IPsec支持。当存在多个接口时，在这些实现内部执行这些操作要
特别小心。）

传送模式中，ESP插在IP头之后，上层协议之前，例如TCP，UCP，ICMP等，或者在任何
已经插入的IPsec头之前。IPv4中，意指把ESP放在IP头（和它包含的任何其他选项）之后, 但
是在上层协议之前。（注意术语“传输”模式不应该曲解为把它的应用限制在TCP和UDP中。
例如ICMP报文可能使用“传输”模式或者“隧道”模式发送。）下面数据报图示了典型IPv4分
组中ESP传送模式位置，以“表示出外形上尖锐对照”为基础。（“ESP尾部”包含所有填充，
加填充长度和下一个头字段。）


ESP应用前
----------------------------
IPv4 |原始IP头 | | |
|(所有选项) | TCP | 数据 |
----------------------------

ESP应用后
-------------------------------------------------
IPv4 |原始IP头 | ESP | | | ESP | ESP|
|(所有选项 )| 头部| TCP | 数据 | 尾部 |验证|
-------------------------------------------------
|<----- 已加密 ---->|
|<------ 已验证 ----->|

IPv6中，ESP被看作端到端的有效载荷，因而应该出现在逐跳，路由和分片扩展头之后。
目的选项扩展头既可以在ESP头之前，也可以在ESP头之后，这由期望的语义决定。但是，因
为ESP仅保护ESP之后的字段，通常它可能愿意把目的选项头放在ESP头之后。下面数据报图
示了典型IPv6分组中ESP传送模式位置。
ESP应用前
--------------------------------------
IPv6 | | 如果有 | | |
| 原始IP头 |扩展头 | TCP | 数据 |
--------------------------------------

ESP应 …… 此处隐藏：2919字，全部文档内容请下载后查看。喜欢就下载吧 ……