摘要

  • TEAS 工作组的 RSVP 加密认证 v2 草案正处于工作组最后征询，截止 2026 年 9 月 30 日；第 02 版于 9 月 27 日提交，尚不是正式 RFC。
  • 如果旧安全关联已到期而新的仍有效，草案要求直接丢弃使用旧关联的消息；如果所有适用关联都已到期，则允许用最后一组进行认证，并提出连续性例外。
  • 例外不是允许未经认证的 RSVP 消息，也不意味着到期密钥重新获得正常授权。它把报警、替换与退出例外状态的责任留给运营者。

先看一条正在经过路由器的 RSVP 消息。它带有密钥标识和完整性对象，接收端要找出对应的安全关联，核验消息认证值及防重放序号。只要新关联已经生效，旧关联到期就应有实际后果：草案规定，此时使用旧关联的消息无须进行密码学计算，直接丢弃。新的凭据既然存在，旧的不能继续与它平起平坐。

棘手的是新关联没有到位的另一种情况。草案写道，若消息到达时没有任何有效的替代关联，可用已到期的旧关联进行验证。第 5.4 节进一步处理所有适用安全关联均已到期的“异常情形”：系统应通知网络管理员，并应暂把最后一组关联视为无限期有效，直到延长其寿命、由管理操作删除，或配置新的关联。消息仍要通过认证检查；被暂时放宽的是关联的时间边界，而不是认证本身。

这个差别决定了治理问题的形状。“这条消息确实由已知密钥认证”与“这把密钥仍处于批准的使用期内”并非同一个判断。草案试图避免两种坏结果：把控制平面突然切断，或在故障时退回不认证状态。它选择保留服务，却也明说全部到期是应尽力避免的状态。运营方不能把这个折中当作正常轮换策略。

为减少落入例外的机会，草案要求实现能够为每个受保护接口或邻居同时保存并使用至少两组安全关联。新旧关联的有效期应有重叠，以吸收设备之间的时钟差异。接收端可凭发送方地址与密钥标识选择具体关联。这样的设计要求并不证明任何现实网络已经正确配置第二把密钥，也不证明切换曾成功。

时间线同样有边界。TEAS 于 9 月 16 日开启工作组最后征询，9 月 21 日的一份安全领域早期审阅认为第 01 版对异常情形的权衡已有充分解释。9 月 27 日出现第 02 版。比较 IETF 官方两份文本，主要差异是引文、编辑性修订及拟建 IANA 登记表的说明；“最后一组到期关联”的例外并非新版才发明。早期审阅者的“Ready”意见也不是 IESG 批准或实网安全测试。

草案的“算法无关”又是另一条容易混淆的线。基础机制本身没有规定所有实现必须使用某一特定算法；拟建登记表暂把 HMAC-MD5 列为 SHOULD，同时标注其为旧方式、将来应弃用。HMAC-SHA2 另有工作组草案。登记表草案、算法建议、某台设备装了什么，与这台设备能否按时换密钥，是四种不同证据。

一份可操作的本地记录，应当能说明何时首次报警、哪些邻居使用最后一组关联、例外期间有哪些已认证消息被接收、谁批准继续运行，以及经测试的新关联何时真正接替。这里的记录建议是 Daniel Kade 的编辑分析，不是 TEAS 已写入的硬性要求。关键不在于否认维持服务的价值，而在于避免一条临时通道无声地变成永久凭据。

来源