摘要

  • 9月30日提交的 draft-acee-lsr-ospfv3-deprecate-ah-00 建议在 OSPFv3 认证中弃用 IPsec AH，新实现不再加入 AH，旧实现可为兼容保留，并引导运营者转向空加密 ESP 或既有的 OSPFv3 认证尾部。Datatracker 将其列为活跃的个人 Internet-Draft、IESG 状态 I-D Exists，并非已批准的 RFC 4552 修订。
  • 草案明确，同一 OSPFv3 链路上的路由器必须认同一套认证机制。RFC 7166 则说明认证参数不一致会导致邻接无法建立，其一种宽松过渡模式还可能接收未经认证的数据。迁移的验收单位因而是整条链路，而不是单台设备的配置单。

假设一条多接入链路上有数台正在互认的 OSPFv3 路由器。维护人员先在其中一台关闭 AH，换上新的认证设置，变更单上也许已经显示“完成”；其余设备却仍按旧方式处理 Hello 报文。邻接能否保留，并不能从那台设备的配置页面推断。个人草案把 AH 退役提上议程，而这个跨设备的交接问题决定了提议能否安全落地。

草案的身份需要先说清楚。Datatracker 记录的是个人提交、活跃 Internet-Draft、I-D Exists；文件抬头出现“Link State Routing Working Group”，并写着“Updates: 4552 (if approved)”。后一句的条件不能删掉。它表达作者希望将来修改 RFC 4552 的方向，不意味着工作组已经采纳、IESG 已批准，或现行标准已改变。

现有标准也并非只剩 AH。RFC 4552 自2006年起便要求符合该规范的 OSPFv3 实现支持 ESP，同时只把 AH 列为可选。RFC 7166 于2014年规定了不依赖 IPsec 的 OSPFv3 认证尾部。新稿不是发明两种替代物，而是提议把 AH 从今后的 OSPFv3 选择中撤下：新实现“SHOULD NOT”实现 AH，已有实现可为向后兼容继续支持，但应向运营者提示弃用；ESP 方面原有要求不变。

“空加密”尤其容易被误读。ESP 的 NULL encryption 不提供保密性，但不等于丢掉完整性和身份验证；认证尾部同样需要相应的密钥与安全关联配置。草案称保留独立 AH 代码路径、配钥和操作程序徒增复杂度，并称 AH 采用有限。这是作者的理由；本次核查的一手文本没有给出 OSPFv3 实网采用比例，不能将它改写成已测得的部署统计。

风险集中在链路切换。草案第4节要求同链路路由器在认证机制上保持一致，提出维护窗口内同步准备新机制及密钥；只有实现确实支持在过渡期接纳多种机制时，才可能分阶段推进。RFC 7166 的迁移章节进一步指出，安全关联 ID、认证类型或摘要不匹配，会使邻接建立失败。该 RFC 为认证尾部提供一种可选过渡模式，却同时允许接收未携带认证尾部的报文，并警告过渡期可能暴露于未经认证的数据。它不是 AH 与认证尾部之间普遍适用的“无损桥梁”。

所以，“邻居恢复在线”与“全过程受保护”要分别证明。前者需要观察 Hello 接收、邻接状态及收敛；后者需要说明每一步究竟校验了哪些报文、哪些设备持有有效密钥、宽松接收窗口何时打开及关闭。即便使用新机制，草案也提醒：持有合法密钥的受损路由器不因此被排除。本文没有实网事故、厂商功能覆盖率或现有 AH 部署量证据；也不把这个提案说成已经实施的禁令。

来源