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

较。（例如，如果ICV计算采用数字签名和单向散列，匹配过程更复杂。）

3.4.5 分组解密

在3.3.2节“分组加密”中，由于格式化的含意，在那里我们依据经常采用的加密讲述。需要
理解使用NULL加密算法提供“非机密性”。因此，接收方：

A. 采用SA指明的密钥、加密算法、算法模式和加密同步数据（如果存在）解密ESP有
效载荷数据、填充、填充长度和下一个头。
- 如果指明显式加密同步数据，例如IV，则从有效载荷字段得到加密同步数据，并按照
算法规范将其输入到解密算法中。
- 如果指明是隐式加密同步数据，例如IV，则构建本地版本IV，并按照算法规范将其输
入到解密算法中。

B.处理所有加密算法规范中指定的填充。如果采用默认的填充方案（参看2.4节），接收
方应该在把已解密数据传送给下一层之前，以及删除填充之前，检查填充字段。

C. 重新构建原始IP数据报，利用：reconstructs the original IP datagram from:
-传送模式—原始IP头和ESP有效载荷字段中原始上层协议信息
-隧道模式 – 隧道IP头+ESP有效载荷字段中整个IP数据报。

重新构建原始数据报的确切步骤依赖于模式（传送或者隧道），在安全架构文档中描述。最小
程度上，IPv6环境中，接收方应该确保已解密数据是8字节对齐，使下一个头字段标识的协议
更容易进行处理。

如果选择验证，确认和解密可以逐个或者并行实现。如果逐个实现，那么ICV验证应该首先
执行。如果并行执行，验证必须在已解密分组被传递进行更进一步处理之前完成。这种处理顺序
利于在解密分组之前，接收方迅速检测和重播分组或伪造分组拒绝，因此潜在地降低了服务拒绝
攻击的影响。

注意：如果接收方执行解密且与验证并行，小心避免对分
组访问和已解密分组重构可能的竞
争条件。

注意解密“失败”的几种情形：Note that there are several ways in which the decryption can "fail":

a. 已选择的SA可能不正确—由于SPI，目的

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

地址或者IPsec协议类型字段被篡改而错
误地选择了SA。如果这样的错误把分组映射到另一个现存的SA，则它们将无法辨别已被破坏
的分组，（c情况）。篡改SPI可以通过验证的使用而被检测出来。但是，由于IP目的地址或者
IPsec协议类型字段被篡改，SA不匹配仍然可能发生。

b. 填充长度或者填充值可能是错误的—不管是否进行验证，错误的填充长度或者填充
值可以被检测出来。

c. 已加密的ESP分组可能被破坏—如果SA选择进行验证，这可以检测出来。

在 (a) 或者 (c)情况下，解密操作的错误结果（一个非法IP数据报或者传送层帧）将不必要
被IPsec检测出来，这是后面协议处理的责任。

4. 审核

不是所有实现ESP的系统实现审核。但是，如果把ESP合并到一个支持审核的系统中，那么
ESP实现必须支持审核，必须允许系统管理员激活或者禁止ESP审核。大部分而言，审核的粒
度是本地的问题。然而，本规范中标识了几个可审核事件，对于这些事件中的每一个，定义了应
该包含在审核日志中的一组最少信息，当然也可以包含额外的信息。本规范中没有明确指出的额
外事件也可以产生审核日志表项。

这里没有要求接收方把任何信息传送给声称的发送方响应审核事件的检测，因为这样做可能
导致服务拒绝。

5. 一致性要求

要求与本规范一致性或者顺应性的实现必须实现ESP语法和这里描述的处理过程，它必须遵
照安全架构文档的所有要求。如果计算ICV使用的密钥手工分发，抗重播服务的正确提供要求
发送方计数器状态的正确维护，直到密钥更新，如果计数器溢出即将发生，有可能没有自动恢复
措施。因此一个顺应实现不应该与手工键入的SA联合来提供抗重播服务。一个顺应ESP实现必
须支持下列强制实现的算法：

- CBC模式的DES [MD97]
- HMAC - MD5 [MG97a]
- HMAC - SHA-1 [MG97b]
- NULL 验证算法
- NULL 加密算法

因为ESP加密和验证是可选的，对两个“NULL”算法的支持要求维护与协商这些服务的方
式的一致性。注意验证和加密可以单独是“NULL”，但是不允许两者同时是“NULL”。

6. 安全考虑事项

安全是这个协议设计的中心，因此安全考虑事项贯穿整个规范。使用IPsec协议额外的安全
相关内容在安全架构文档中讨论。

7. 与 RFC 1827的不同

本文档在几个重要方面不同与RFC 1827 [ATK95] 。主要的不同是，本文档试图为ESP指定
一个完整的框架和上下文，而RFC 1827提供了一个“shell”，通过转换的定义来完善。转换的增
加促进ESP规范重新完善为一个更全面的文

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

档，加入ESP上下文中提供的安全服务选项。因此，
之前在转换文档中定义的字段现在是该基础ESP规范的一部分。例如，用于支持验证（和抗重
播）的字段现在这里定义，即使该服务是可选项。

支持加密的填充字段和下一个协议验证的填充字段现在也在此定义。与这些字段定义一致的
分组处理也包含在文档中。.

致谢

Many of the concepts embodied in this specification were derived from
or influenced by the US Government's SP3 security protocol, ISO/IEC's
NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92,
IB93].

For over 3 years, this document has evolved through multiple versions
and iterations. During this time, many people have contributed
significant ideas and energy to the process and the documents
themselves. The authors would like to thank Karen Seo for providing
extensive help in the review, editing, background research, and
coordination for this version of the specification. The authors
would also like to thank the members of the IPsec and IPng working
groups, with special mention of the efforts of (in alphabetic order):
Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David
Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina
Yuan.

参考书目

[ATK95] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, August 1995.

[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols", Proceedings of the Sixth Usenix Unix Security
Symposium, July, 1996.

[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.

[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409 …… 此处隐藏：3522字，全部文档内容请下载后查看。喜欢就下载吧 ……