摘要

  • RFC 2401 将有序的安全策略数据库与安全关联数据库分开：前者决定流量应被丢弃、绕过还是获得 IPsec 保护，后者保存单向活动关联的参数。
  • 规则和关联都不是某个报文的收据。出站报文仍需真正执行指定的 AH 或 ESP 处理；入站报文则既要通过密码处理，还要验证实际使用的关联及其顺序符合适用策略。

判断一条受保护通信是否真的发生，至少需要三张收据。第一张来自策略：这个方向、这些选择器和这个顺序究竟要求什么。第二张来自状态：相应的安全关联是否存在并仍然有效。第三张来自报文：它是否匹配那条规则，是否实际经过所要求的处理，入站时又是否通过了策略复核。

RFC 2401 于 1998 年 11 月发布，首次把互联网协议安全架构系统地合在一起。它为 IPv4 和 IPv6 描述了 IP 层访问控制、无连接完整性、数据源认证、防重放、机密性以及有限的流量保密。它没有把这些能力混成一句“已经安全”。AH、ESP、传输或隧道模式、算法与密钥管理程序可以按不同需求组合，所形成的证明边界也各不相同。

第一张收据的制度来源是安全策略数据库 SPD。它在效果上必须覆盖全部入站和出站 IP 流量，包括不使用 IPsec 的流量。每个条目以地址和上层字段等选择器定义范围，并按总顺序排列。匹配后只有三种处置：丢弃、绕过 IPsec，或应用 IPsec。若要求保护，条目还要说明协议或协议组合、模式、算法与嵌套关系。

因此，策略不是一袋彼此独立的规则。一个范围很宽的条目若排在更窄条目前面，就可能先行决定报文命运。方向也不能省略：出站的选择与处理要求，不能被当成入站核验的镜像。要证明策略事实，既要知道规则文字，也要知道版本、装载位置、方向、选择器和实际命中的顺序。

第二张收据来自安全关联数据库 SAD。RFC 2401 中的安全关联是单工的，只服务一个方向；双向保护通常需要两个关联。一个关联由安全参数索引 SPI、目的地址以及 AH 或 ESP 协议标识共同识别。对应条目可以保存序列号和防重放状态、算法与密钥、寿命、模式以及路径 MTU 等参数。

这些状态对运行必不可少，却不能回答报文结果。SAD 中有一行记录，只能说明某组关联参数可用；它不证明某个报文选择了该关联，更不证明对端收到、应用授权或业务完成。稍早的 RFC 2367 通过 PF_KEY 让应用能够管理这类密钥与关联状态；RFC 2401 则把状态放回更长的报文处理契约中。

出站路径把前两张收据接到第三张。实现先让报文匹配 SPD。丢弃意味着路径终止；绕过意味着不施加 IPsec 而继续普通发送；保护规则则选择合适的现有安全关联，或发起创建所需的关联或组合。随后，AH 或 ESP 操作必须按策略规定的次序真正发生，报文才进入转发或发送阶段。配置意图和活动状态仍位于变换之前，不能代替变换本身。

入站路径还有一次常被忽视的复核。目的地址、安全协议与 SPI 先用于找到关联。协议处理可以验证完整性与来源、执行防重放，并在相应服务下解密。但密码处理成功并不等于最终授权。

IPsec 头部处理之后，所得报文还要匹配入站 SPD。实现必须检查实际用过的安全关联及其顺序是否满足该策略。若某个候选策略对不上，就要继续考虑其他适用条目。只有策略核验成功，报文才能交给传输层或继续转发。用某个关联通过密码验证，与依照适用策略获得许可，是两张不同的收据。

AH 与 ESP 也不能被一句“IPsec 加密”抹平。1998 年版本的 AH 提供无连接完整性和数据源认证，并可提供防重放，但不提供机密性。ESP 可以提供机密性，也可以选择提供认证与完整性，其覆盖字段又与 AH 不同。绕过则明确表示没有 IPsec 保护。不同路径可以合法地产生不同安全主张。

RFC 2401 也承认架构以外的依赖。整体安全仍取决于实现质量、操作系统保护、随机数来源和管理实践。它也不是今天的部署手册：RFC 3168 后来更新了显式拥塞通知的处理，RFC 4301 又在 2005 年取代它，调整了策略数据库、选择器、分片处理和对端授权等设计。

它留下的历史意义更为克制，也更持久：策略意图、已安装状态与报文执行属于不同现实层。借用 Lu Heng 关于运行代码、局部验证与现实层次的分析，制度文本只有经过可执行系统才产生可观察效力；这是后来的分析视角，并非 RFC 的自我表述。由此可形成一条十一级证据链：策略来源与版本、规则装载、按序匹配、保护要求、有效关联、实际变换或验证、入站策略复核、送至网络或传输边界、对端接收、应用处理、服务结果。前一层永远不能自动证明后一层。

来源