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

日期/时间、源地址、目的地址、序列号和（IPv6中）明文信息流ID 。
讨论：
从删除和保存ICV值（验证数据字段）开始。下一个检查除去验证数据字段之后的ESP
整个长度。假如由于验证算法的块大小而要求隐式填充，把0填充的字节直接附加到下一个头字
段之后的ESP分组尾部。执行ICV计算，采用算法规范定义的比较规则来把结果与保存的值比
较。（例如，假如ICV计算采用数字签名和单向散列，匹配过程更复杂。）
3.4.5分组解密
在3.3.2节“分组加密”中，由于格式化的含意，在那里我们依据经常采用的加密讲述。需要
理解使用NULL加密算法提供“非机密性” 。因此，接收方：
1.采用SA指明的密钥、加密算法、算法模式和加密同步数据（假如存在）解密ESP有
效载荷数据、填充、填充长度和下一个头。
-假如指明显式加密同步数据，例如IV ，则从有效载荷字段得到加密同步数据，并按照
算法规范将其输入到解密算法中。
-假如指明是隐式加密同步数据，例如IV ，则构建本地版本IV ，并按照算法规范将其输
入到解密算法中。
2.处理所有加密算法规范中指定的填充。假如采用默认的填充方案（参看2.4节），接收
方应该在把已解密数据传送给下一层之前，以及删除填充之前，检查填充字段。
3.重新构建原始IP数据报，利用：reconstructstheoriginalIPdatagramfrom:
-传送模式—原始IP头和ESP有效载荷字段中原始上层协议信息
-隧道模式–隧道IP头 ESP有效载荷字段中整个IP数据报。
重新构建原始数据报的确切步骤依靠于模式（传送或者隧道），在安全架构文档中描述。最小
程度上， IPv6环境中，接收方应该确保已解密数据是8字节对齐，使下一个头字段标识的协议
更轻易进行处理。
假如选择验证，确认和解密可以逐个或者并行实现。假如逐个实现，那么ICV验证应该首先
执行。假如并行执行，验证必须在已解密分组被传递进行更进一步处理之前完成。这种处理顺序
利于在解密分组之前，接收方迅速检测和重播分组或伪造分组拒绝，因此潜在地降低了服务拒绝
攻击的影响。
注重：假如接收方执行解密且与验证并行，小心避免对分组访问和已解密分组重构可能的竞
争条件。
注重解密“失败”的几种情形：Notethatthereareseveralwaysinwhichthedecryptioncan"fail":
a.已选择的SA可能不正确—由于SPI ，目的地址或者IPsec协议类型字段被篡改而错
误地选择了SA 。假如这样的错误把分组映射到另一个现存的SA ，则它们将无法辨别已被破坏
的分组，（c情况）。篡改SPI可以通过验证的使用而被检测出来。但是，由于IP目的地址或者
IPsec协议类型字段被篡改， SA不匹配仍然可能发生。
b.填充长度或者填充值可能是错误的—不管是否进行验证，错误的填充长度或者填充
值可以被检测出来。
c.已加密的ESP分组可能被破坏—假如SA选择进行验证，这可以检测出来。
在(a)或者(c)情况下，解密操作的错误结果（一个非法IP数据报或者传送层帧）将不必要
被IPsec检测出来，这是后面协议处理的责任。
4.审核
不是所有实现ESP的系统实现审核。但是，假如把ESP合并到一个支持审核的系统中，那么
ESP实现必须支持审核，必须答应系统治理员激活或者禁止ESP审核。大部分而言，审核的粒
度是本地的问题。然而，本规范中标识了几个可审核事件，对于这些事件中的每一个，定义了应