摘要

  • RFC 9986 使用 ISAAC 以每页 256 个值的方式提供认证输出；生成下一页是不可逆操作，会销毁当前页。
  • 若校验某个报文必须跨页，接收端须先复制完整 ISAAC 状态。输出匹配，才采用新状态；不匹配，就恢复旧副本。
  • 这种模式证明的是已处于 Up 状态的真实对端仍在发送连续性信号，不是整份报文内容或端到端业务健康。运行记录既要证明成功提交，也要证明失败恢复，同时不得泄露密钥与可重建的生成器状态。

一个尚未可信的报文，先要求校验器向前走

BFD 靠高频控制报文快速发现相邻转发设备之间的故障。频率越高，每个报文都执行最昂贵的完整性认证，越容易压垮资源有限的设备。RFC 9985 因此把两类动作分开：会改变状态的重要动作走强认证；已是 Up 的会话，则可以用较低成本的方式维持连续性。

RFC 9986 为后一条路径定义了 Meticulous Keyed ISAAC。共享秘密、会话 Seed 和 BFD 判别符材料共同初始化伪随机流。ISAAC 每次给出一页 256 个 32 位输出。在同一页里，根据序列号寻找相应 Auth Key 几乎不费力；一旦索引越过页尾，就要运行混合函数，生成下一页。

真正的控制边界藏在这里。生成新页不是一次可以无痕试看的查询，它会销毁当前页。可触发这一步的报文，此刻仍未证明自己。如果接收端先推进唯一的生成器状态，再发现 Auth Key 不匹配，那么“拒绝”已经太晚：校验器为了审查可疑输入，消耗了继续识别合法输入所需的过去。

RFC 9986 给出的顺序非常严格：只要预期输出的计算会创建新页，接收端就必须先保存完整 ISAAC 状态副本。计算结果匹配，旧副本可以丢弃，新页正式成为当前状态；结果不匹配，则恢复副本，把修改后的候选状态丢弃，或与正式状态隔离后暂存。

信任成立之前，校验必须可撤销。

丢包允许有限前看，不等于任意跳跃

接收端之所以会寻找未来位置，不一定遇到了攻击。控制报文可能丢失，下一次实际收到的序列号自然会比上次接受的值大几步。差值告诉接收端应该在 ISAAC 页中检查哪个输出；若输出吻合，双方就能越过丢失的报文重新同步。

这项容错有明确围栏。已知最近接收序列后，新值必须落在“上次值加一”到“上次值加三倍 Detect Mult”的范围内，并按 32 位循环数空间处理。超出范围直接丢弃；落在范围内，才有资格触发对应位置的计算。恰好是这个被允许的前看，可能跨过 256 值页边界。

因此，只有“认证成功/失败”的日志远远不够。可审计记录应保留：此前接受的序列、收到的序列、Detect Mult、计算出的窗口、页基址和索引，以及这次是否需要混合生成新页。成功路径要显示“先完成检查点，再混合，再匹配，再提交”；失败路径要显示“先完成检查点，再混合，再失配，再恢复到完全相同的旧状态指纹”。

这里的“状态指纹”必须不可用于重建伪随机流。秘密密钥与原始 ISAAC 状态不能进入公开台账。证据的职责是说明动作顺序与结果，而不是把下一份合法答案交给观察者。

识别真实发送者，不等于认证整份报文

ISAAC 格式携带 Auth Key ID、序列号、Seed 和 32 位 ISAAC 输出。接收端会拒绝错误的认证类型、模式、长度、密钥 ID、序列范围、Seed 或 Auth Key。

但该 Auth Key 并不包含 BFD Control 报文的摘要或哈希。RFC 9986 明确说明：报文本身的内容没有被完整认证。正确输出只能证明，生成这条连续性信号的是掌握相同秘密的真实发送方；它不能替代对全部字段的完整性校验。

所以，这条低成本路径只能用于已经 Up 的会话，也不能宣告 BFD 状态变化。建立状态、切换状态和周期性的更强确认，要回到计算成本更高、覆盖整份报文的认证模式。生产环境已有文章专门讨论 RFC 9985 的“低成本维持不等于变化授权”。本文不重复它；这里研究的是，即便连续性校验本身被允许，校验器跨越单向内部状态时仍须保留退路。

BFD 的结论范围同样有限。一个经过认证的 Up 信号，不足以证明应用可用、路由正确、客户能访问服务，也不能证明某份业务负载走完端到端路径。把相邻会话的答案扩展成全局健康证明，会让快速机制承担它从未拥有的权力。

一项主动写出自身边界的实验

Ashesh Mishra 是 RFC 9986 的五位作者之一，其他作者为 Alan DeKok、Mahesh Jethanandani、Sonal Agarwal 与 Jeffrey Haas。Mishra 也出现在 2017 年的前身草案、RFC 9985，以及一项更早的 BFD 完整性检查优化专利中。这些公开记录表明他长期参与同一工程问题，但不能把集体成果改写成个人发明史。

RFC 9986 属于 IETF Experimental 文档，不是互联网标准。它对 ISAAC 的评价相当克制：选择该算法，是为了照顾缺少适当密码硬件加速的设备；相关密码分析有限；一旦硬件加速可用，ISAAC 就没有优势；它也不适合被推广到其他 IETF 协议。

密钥分发不在文档范围内。会话中途不能直接更换 Meticulous Keyed ISAAC 的 Auth Key ID，因为协议没有定义重新同步办法；轮换密钥需要管理性地停用会话，再重新播种。强弱模式使用不同密钥可以隔离一部分泄露风险，却也增加两端配置不一致、从强模式切到轻模式后立即掉线的可能。

RFC 没有替运营者做掉这些决定。它只划出共同机制的最小边界，把剩余控制与相应责任留给真正能操作它的人。

最重要的测试，不是正常通过，而是失败后还能继续

最能说明实现质量的场景，是把一个无效报文放在页边界之后，同时让它仍处于允许的丢包窗口。测试工具先对非公开状态取不可逆指纹，再注入错误 Auth Key，并核对四个动作：检查点已完成、混合随后发生、比较失败、旧指纹原样恢复。然后立刻发送真正合法的下一报文，确认它仍能通过。

同样的故障注入还应覆盖错误 Seed、错误密钥 ID、错误模式与长度，窗口内外的序列跳跃，以及 32 位计数回绕。测量页内稳态校验、检查点、混合和恢复的内存与延迟；再用连续的无效未来报文测试 CPU、内存与候选状态是否无上限增长。

公开运行记录可以包含软件版本、会话和工单标识、非秘密 Key ID、序列窗口、页基址与索引、模糊化检查点指纹、耗时与提交/恢复结果。它还应标明上一次强认证和密钥轮换重启演练。足够证明行为，但不足以伪造下一份凭据，才是合格的可审计性。

把每一份权力放回它真正控制的表面

沿着 Lu Heng 对 agency 的判断，这项机制可以清晰拆开。RFC 作者定义互操作不变量；实现者决定完整状态副本如何表示、怎样保护；运营者选择密钥、强认证周期和重启窗口；对端运行代码决定某个具体值是否匹配。任何一方都不能替另一方承诺结果。

这也是“最小初始规范”的价值：标准要求“销毁前保存、失败后恢复”，却不强迫所有设备采用同一内存布局。未来决定仍可本地化，但必须服从可测试的底线。

最终收据来自 running code。文本中的 MUST 只能说明正确分支应该存在，无法证明某款设备极少触发的跨页失败分支真的恢复了状态。故障注入、前后指纹和随后合法报文的接受，才能完成证明。

校验器不应只因为一份未可信输入要求查看未来，就获得不可逆地处置合法过去的权力。先保留，再试算，最后才前进——这是快路径得以可信的最小纪律。

来源