摘要

  • Job Snijders 与 RIPE NCC 的 Ties de Kock 合著了 2024 年 12 月发布的 IETF RFC 9697。
  • 验证器保存已见过的序号与哈希值；旧序号的哈希一旦改变，就应报警并用最新完整快照重新同步。

1774 号抽屉里换了东西

RFC 9697 举了一个简洁的例子。仓库通知从序号 1774 更新到 1775，本来只是日常前进。可新通知里，旧序号 1774 对应的哈希值也变了；1773 的哈希值倒仍是原样。抽屉标签没换，里面的文件换了。这是标准中的演示数据，并非一次被证实的生产事故。Job Snijders 和合著者 Ties de Kock 要解决的，就是验证器怎样识别这种伪装成“过去没有变”的变化。

RPKI 仓库存放帮助网络核验路由来源的签名对象。RRDP 把仓库更新拆成增量文件。验证器先拿一份完整快照，以后只下载缺少的增量；更新通知列出会话、序号和文件哈希。静态文件方便网页缓存，也省去了每次搬运整个仓库的开销。前提是同一会话、同一序号的旧增量始终是同一份东西。

两台验证器在不同时间取文件，可能各自收下了不同版本的 1774，却都显示相同的会话和最新序号。只看这两个数字的仪表盘会说“一切一致”，本地仓库却已经分叉。Snijders 与 de Kock 的办法很朴素：记住上次成功获取通知时每个增量的序号和哈希；下次把两份通知中重叠的序号逐一对照。旧序号变了指纹，就报警，并从最新快照重新建立完整状态。

Snijders 对分发链条的麻烦并不陌生。他在 2021 年讲述 OpenBSD rpki-client 的文章里写过另一种竞态：负载均衡后面的服务器尚未同步，一台宣布的新增量，另一台还拿不出来。那是服务器之间的时间差；RFC 9697 处理的是旧增量在同一序号下改了内容。两件事各有病因，却都提醒运营者：签名对象的可信度，还要经过一条会搬运文件的链路。

分叉会传导到路由判断。RFC 指出，失同步的缓存可能漏掉有效载荷，也可能继续保留证书机构想撤回的载荷。原本应被判为有效的路由，可能长时间落到 unknown 或 invalid。仓库会话可持续数月。昨天的指纹值得留在本子里，今天再核一遍。