摘要

  • RSVP 认证 v2 草案规定：若最后一个适用的安全关联也已过期，系统应通知网络管理者，并在被延长、删除或替换之前继续把它当作无限期有效。
  • 这不是在宣称过期密钥没有风险，而是在两种更坏结果之间保持运行：既不退回无认证状态，也不因日历越线而骤然破坏现有资源预留。
  • 真正证明轮换完成的不是“新密钥已录入”，而是替代关联已激活、重叠期充分、时钟可信、所有接收方握手完成，并且终止例外的管理动作留下记录。

最值得警惕的密钥失效，往往不是让网络立即报错的那一种，而是让一切照常工作的那一种。

2026 年 9 月 27 日发布的 RSVP Cryptographic Authentication Version 2 -02 正处于 IETF TEAS 工作组最后征求意见阶段，目标是可能成为 Proposed Standard。它仍是一份 Internet-Draft，不是 RFC，也不能证明任何厂商或网络已经部署。若最终获批，它将取代 RFC 2747 与 RFC 3097 的相关认证规则。

草案第 5.4 节直接把本文关注的场景称为“病理情况”：所有适用于一段 RSVP 通信的安全关联都已过期。回到不认证的 RSVP 不可接受；但突然扰乱正在运行的预留，又可能诱发更大范围的网络故障。于是草案给出的 SHOULD 级建议是，一边向网络管理者发出“最后一个 RSVP 安全关联到期”的通知，一边把最后一个关联视为无限期有效，直至管理系统延长它、删除它，或配置新的关联。

这段规则在 -01 中已经存在，不能说成 -02 新增。真正的新闻点是：包含这项取舍的文本已经来到当前审议节点。评审者面对的不是简单的密码学优劣，而是一个把失效时间从自动执行线改写为告警与本地决策线的设计。

为什么会作出这种选择，要先看清密钥究竟保护什么。RSVP 由 RFC 2205 定义，并由 RFC 3209 扩展到流量工程。新草案用 INTEGRITY 对象逐跳认证 RSVP 消息。这里的发送方和接收方是当前一跳两端的 RSVP 系统，并不必然是应用意义上的端点。

INTEGRITY 对象包含 48 位 Key Identifier、64 位序列号与认证数据。接收方用 Key Identifier 加发送地址找出精确的安全关联。关联还记录密码变换、认证密钥、接口或对端范围，以及起止时间。关联是单向的，往返两个方向可以使用不同密钥。

因此，通过认证的消息只证明一个有边界的事实：持有相应密钥的某个逐跳对端，在某个接收方认可的新鲜序列位置上生成了消息。它不加密 RSVP 内容；它不证明应用拥有申请资源的权利；它也不证明准入策略、数据平面转发或最终服务交付。消息有效、控制决策和运行结果属于不同现实层。

序列号把重启问题带进了认证链。发送方必须在密钥生命周期内维持唯一且单调递增的 64 位序列。接收方重启后若不知道当前位置，旧消息就可能重新显得“新鲜”。草案因此要求实现支持 Integrity Handshake，并建议默认启用。接收方发出不可预测的 cookie，发送方把该 cookie 与当前序列号放入受保护的响应。挑战报文本身不受保护并不构成同样风险，因为只有经认证返回的 cookie 才有意义。

每个 RSVP 会话必须二选一：使用该握手，或把序列状态保存在稳定存储中。RFC 4086 与 RFC 8937 提供随机数方面的背景，却不会自动告诉运营者哪些接收方已经实际完成握手。

密钥轮换也不是一个瞬间，而是一段重叠。实现必须至少支持两个并行安全关联，并应支持更多。新关联应在旧关联结束之前开始，重叠长度至少是双方时钟不确定性的两倍；草案指出五分钟在许多情况下足够。每个接收方都必须在新关联上完成握手。

所以，“新密钥已经配置”不能作为完成证据。新关联还必须覆盖同一个通信表面，按可信时钟进入有效期，被发送方采用，能被接收方正确选择，并拥有安全的初始序列。少一个环节，日历到点都可能把网络推入最后密钥例外。

时间本身也成为安全依赖。如果起止时间由时钟判断，时钟必须足够同步，草案还建议对时间分发机制进行认证。RFC 5905 定义 NTPv4，却不能证明某个生产环境的时源当前健康。审计记录需要实际偏差与不确定性，而不只是“已配置 NTP”。

正常情况下，过期规则相当严格：如果消息使用已过期关联，而另一个适用关联仍有效，接收方必须在进行密码运算之前就丢弃该包，并应以限速方式记录安全错误。这样，对端无法在替代路径已经可用后继续挑选旧密钥。

最后密钥场景却得到相反结果。若没有任何适用的有效关联，接收方应像它尚未过期一样，用旧关联验证消息。草案同时拒绝两个失败模式：不允许悄悄降级到无认证状态，也不愿仅因时间戳跨线就自动牺牲运行中的预留。

这是典型的 fail-operational 安全。优点是维持最后一个已知、可认证的邻接关系；危险是例外几乎不可见。网络没有坏，工单就容易降级；工单一旦失去负责人，“临时”状态便可能永久存在。

“无限期”因此不是修辞。草案只列出三个出口：延长原关联、由管理系统删除它、或配置新关联。它没有提供自动宽限期。协议也不会替机构决定旧密钥还能容忍多久、谁来接受剩余风险、哪些服务可以继续，以及何时受控中断反而更安全。这些是本地决定，但绝不是可以不作的决定。

密钥管理本身仍在草案范围之外。实现必须支持手工分发；手工录入的关联可以被设为永久，但文本不建议这样做。密码算法通过 IANA RSVP Cryptographic Transform 注册表保持可演进，旧 HMAC-MD5 编码仍保留兼容路径，而 RFC 6151 说明了为什么 MD5 时代的安全保证需要谨慎解读。算法敏捷不能替代把新秘密安全交给正确对端的过程。

最小可用证据集应围绕转换链，而不是围绕“过期”标签。至少记录 Key Identifier 与发送地址、接口和对端范围、密码变换、配置的起止时间、继任关联、重叠窗口、时钟偏差、预期接收方、逐个接收方的握手结果、第一次在过期后接受的消息、告警的送达与确认，以及最终结束例外的管理动作。事故记录不必保存密钥本身，但必须保存状态来源。

这套记录能拆开仪表盘常混为一谈的四件事：密钥被创建，新关联进入有效期，接收方证明了当前序列位置，以及旧关联不再是唯一可用选择。只有最后一项，才真正说明轮换已经闭环。

Heng Lu 的运行代码优先提供了准确的阅读方式：时间戳是符号，包处理状态才是运行现实。最小初始规范解释了共享协议为何可以保持窄小，同时把升级与恢复留给本地决策。现实层则提醒我们，“已过期”这个名称不等于信任关系已经事实上终止。

这份草案没有掩盖二者的距离。它保持认证路径继续运行，同时明确抬手求助。最后一把密钥过期时，协议并没有替组织解决治理问题；它只是把问题交给了必须作出决定的人。

来源