摘要

  • RFC 2411 把 IPsec 规范拆成七类责任区，让架构、ESP、AH、算法、DOI 和密钥管理不再反复复制同一套规则。
  • 这张路线图只能指出应该查哪份文件；它不能证明某个版本已被实现、某组算法已被协商、两端 SA 已被安装，更不能证明业务流量已经成功。

RFC 2411 最值得记住的部分，是一张没有数据包的图。

图的顶端是 Architecture。下方分出 ESP 与 AH。两侧挂着加密算法和认证算法文档。中间的 DOI 让各个部分用共同编号互相指认。底部是密钥管理。箭头把它们连成一套看似整齐的机器。

这并不是写给图书管理员的分类表。它在回答一个协议工程问题：当系统需要不断加入新算法时，哪份文件有权定义哪条规则？

如果每份新算法草案都重新解释 ESP、AH、密钥和编号，第一份看起来完整，第二份显得方便，到了第十份就会出现细小而致命的分歧。某个默认值被漏掉，某个填充规则沿用旧版，某个安全警告换了表述。每份文件单独看都像是合理摘要，放到同一条协商链里却不再描述同一个系统。

RFC 2411 把这种风险称为“草案爆炸”。它的修复方式不是再写一份更大的总规范，而是限制每类文档的职责。

架构文档拥有共同概念、安全要求和系统机制。ESP 与 AH 文档拥有各自的数据包格式与一般处理规则。加密算法文档只说明某种算法如何接入 ESP。认证算法如果在 ESP 与 AH 中行为相同，就只写一份。DOI 保存可协商项目的共同编号与参数。密钥管理文档负责生成和管理密钥材料。

这不是权力金字塔。DOI 给算法一个数字，不代表 DOI 能判断算法是否安全；路线图把 ESP 画进方框，也不代表路线图能替 ESP 规定数据包。每个文档只有一块有限的控制面，互操作性来自这些控制面的组合。

密钥材料展示了这种分工为何不是形式主义。

密钥管理协议必须知道需要产生多少材料，才能满足所选加密和认证算法。但它不应内置所有算法的细节。密钥长度、多密钥顺序、奇偶位处理、弱密钥规则，应由相应算法文档定义。密钥管理只承担“产生足够而且足够强”的责任。架构文档则解释，当 ESP 同时需要保密与认证时，怎样从一块材料中抽取多把密钥。

到了内部实现边界，RFC 2411 停了下来。

整块密钥材料可以交给内核，由内核完成文中所谓的 “slicing and dicing”；也可以先由密钥管理进程切分，再分别下发。只要协议结果一致，这个位置属于实现选择。

共同规范定义外部必须相同的结果。内部工作放在哪个进程，不因文件作者能够发言就自动成为共同规则。

这是“本地未来决策”最朴素的工程版本。它不是允许实现改变线上语义，而是拒绝把与互操作无关的内部布局纳入中央控制。

对于可选参数，路线图采取了相反方向的约束。能合理固定的值，应该固定。每增加一项协商自由，就会增加提案组合、代码路径和两台合规设备找不到共同选择的概率。名义上的灵活性可能降低实际互通率。

必须保留的选项，也不能留成空白。算法文档需要说明为何不能固定，给出默认值或范围，并交代它对字段、填充与处理的影响。“可配置”不是规范；被解释、被约束、能被验证的可配置性才是。

RFC 2411 为未来算法文档列出的项目非常接近一份运行审计表：最小、最大和推荐密钥长度；随机数来源；弱密钥；刷新周期；性能；输入输出格式；填充；算法之间的交互；已知攻击；常见实现错误；验证程序与测试向量。

路线图本身不提供这些证据。它要求离机制最近的文档把证据接口说清楚。

这也决定了路线图不能被当作合规收据。RFC 2411 列出一类算法文档，只能证明这类责任被安排过。产品声称支持该文档，只能证明一个声明。协商日志显示双方选中了某个提案，也不能证明两端内核都完成了安装。单端 SA 存在，不代表对端状态正确。计数器开始增长，也不一定代表应用收到了预期结果。

路线图收据、源规则收据、实现收据、协商收据、安装收据、数据包收据和业务结果收据，不能互相借用。

RFC 2411 自己对这条边界很诚实。它是 Informational，明确不制定互联网标准。安全章节要求读者遵循架构、ESP、AH 与算法文档中的具体规则。它提醒许多加密算法若缺少认证并不安全，但这仍是一条查证路径，不是一张部署证书。

2011 年，RFC 6071 取代了它。此时 IPsec 与 IKE 相关 RFC 已经分布在原工作组、衍生工作组和使用 IPsec 的其他协议中。新路线图把自己称为一个“快照”，注明算法要求只反映 2011 年 2 月的状态，后来文件可以改变它，并明确规定：如果路线图与其他 RFC 冲突，以其他 RFC 为准。

健康的摘要会说明自己何时失效，也会说明谁有更高证据权重。

RFC 6071 同时记录了一件容易被制度语言掩盖的事：新版 IPsec 已经让旧版过时，但旧版仍广泛存在于实现中；IKEv2 已取代 IKEv1，IKEv1 仍在生产网络里运行。“过时”改变文档关系，不会自动卸载代码。“仍在运行”描述资产现状，也不会让旧规范重新成为推荐方案。

文档地图本身也发生了变化。组合模式算法获得独立位置。强制实现算法被移到单独文档，让密码建议能以不同速度更新。IKEv2 把 IKEv1 时代分散在 ISAKMP、Oakley 与 DOI 的内容重新整合，因为过度分散也会产生互相矛盾的文本。

因此，历史教训不是“文件越少越好”或“模块越多越好”。正确边界取决于变化速度、专业责任和互操作边界。ESP 数据包格式可能长期稳定，密码算法判断却必须随着攻击、硬件和部署环境变化。把两者锁在同一更新周期，会让任何一方拖住另一方。

RFC 8221 延续了这一思路。它单独更新 ESP 与 AH 的算法实现要求和使用建议，承认今天的安全算法可能在明天变弱。IANA 注册表继续保留稳定编号，让机器不会因名称混乱而失去互通；注册存在却不等于被推荐、被启用或被选中。RFC 9395 后来废止 IKEv1 和一批旧算法，也没有删除解释这些系统为何仍会出现在现场的历史记录。

RFC 2411 的历史价值，就在于它把“规则应该放在哪里”当成互联网工程的一部分。共同规则只留在共同层，专门规则靠近专门机制，内部选择在不影响互通时留给实现。它让扩展不必重写整个体系，也让一份旁支文档更难通过重复而取得不属于它的权威。

但文档仍然只是符号层。发布不是采用，编号不是认可，声明不是实现，协商不是安装，安装不是结果。

RFC 2411 给规则安排了住址。只有运行代码与实际数据包，才能证明谁真的住了进去。

来源