1. Introduction (简介)
1. Introduction
本文档假设读者熟悉 "Security Architecture for the Internet Protocol" [Ken-Arch] 中描述的术语和概念, 以下简称为安全架构文档。特别是, 读者应该熟悉 Encapsulating Security Payload (封装安全负载, ESP) 和 IP Authentication Header (IP 认证头部, AH) 提供的安全服务定义, Security Associations (安全关联) 的概念, ESP 与 AH 结合使用的方式, 以及 ESP 和 AH 可用的不同密钥管理选项。
关键词 MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, 和 OPTIONAL 在本文档中出现时, 应按照 RFC 2119 [Bra97] 中描述的方式进行解释。
Encapsulating Security Payload (ESP) 头部旨在为 IPv4 和 IPv6 [DH98] 提供多种安全服务的组合。ESP 可以单独应用, 与 AH [Ken-AH] 结合使用, 或以嵌套方式使用 (参见安全架构文档 [Ken-Arch])。安全服务可以在一对通信主机之间, 一对通信安全网关之间, 或安全网关与主机之间提供。有关如何在各种网络环境中使用 ESP 和 AH 的更多详细信息, 请参见安全架构文档 [Ken-Arch]。
ESP 头部插入在 IP 头部之后和下一层协议头部之前 (传输模式), 或插入在封装的 IP 头部之前 (隧道模式)。这些模式将在下面更详细地描述。
ESP 可用于提供机密性, 数据源认证, 无连接完整性, 反重放服务 (一种部分序列完整性形式), 以及 (有限的) 流量流机密性。提供的服务集取决于在 Security Association (SA) 建立时选择的选项以及实现在网络拓扑中的位置。
ESP 允许使用仅加密来提供机密性。但是, 应该注意的是, 一般来说, 这只能提供针对被动攻击者的防御。仅使用加密而没有在其上层的强完整性机制 (无论是在 ESP 中还是通过 AH 单独提供) 可能会使机密性服务在某些形式的主动攻击下变得不安全 [Bel96, Kra01]。此外, 在加密之前应用的底层完整性服务 (如 AH) 并不一定能保护仅加密的机密性免受主动攻击者的攻击 [Kra01]。ESP 允许仅加密的 SA, 因为这可能提供相当好的性能并仍然提供足够的安全性, 例如, 当更高层独立提供认证/完整性保护时。但是, 本标准不要求 ESP 实现提供仅加密的服务。
数据源认证和无连接完整性是联合服务, 以下统称为 "integrity" (完整性)。(使用此术语是因为, 在每个数据包的基础上, 执行的计算直接提供无连接完整性; 数据源认证是通过将用于验证完整性的密钥绑定到 IPsec 对等体的身份而间接提供的。通常, 此绑定是通过使用共享对称密钥来实现的。) 仅完整性的 ESP 必须作为服务选择选项提供, 例如, 它必须可在 SA 管理协议中协商, 并且必须可通过管理接口配置。仅完整性的 ESP 在许多情况下是 AH 的一个有吸引力的替代方案, 例如, 因为它在许多实现中处理速度更快且更适合流水线处理。
尽管机密性和完整性可以独立提供, ESP 通常会同时使用这两种服务, 即, 数据包将在机密性和完整性方面受到保护。因此, 涉及这些服务的 ESP 安全服务组合有三种可能:
- confidentiality-only (仅机密性) (可以支持)
- integrity only (仅完整性) (必须支持)
- confidentiality and integrity (机密性和完整性) (必须支持)
只有在为 SA 选择了完整性服务时, 才能为该 SA 选择反重放服务。此服务的选择完全由接收方决定, 因此无需协商。但是, 为了以可互操作的方式使用扩展序列号功能, ESP 确实要求 SA 管理协议能够协商此功能 (参见下面的第 2.2.1 节)。
流量流机密性 (TFC) 服务通常只有在以隐藏通信方的最终源地址和目的地址的方式使用 ESP 时才有效, 例如, 在安全网关之间的隧道模式下, 并且只有在 IPsec 对等体之间有足够的流量流动 (无论是自然的还是由于生成伪装流量的结果) 以隐藏特定的个人订阅者流量流的特征时才有效。(ESP 可以用作更高层 TFC 系统的一部分, 例如 Onion Routing [Syverson], 但此类系统超出了本标准的范围。) ESP 中存在的新 TFC 功能以向后兼容的方式促进了伪流量的高效生成和丢弃以及真实流量的更好填充。
第 7 节简要回顾了本文档与 RFC 2406 之间的差异。