摘要

  • IETF 于 2026 年 8 月 28 日就 RPKI 发布引擎及 RRDP、rsync 仓库的 Best Current Practice 草案开启最后征求意见，截止 9 月 11 日。它目前仍是待审草案，不是已批准的 BCP。
  • 草案要求，新 RRDP 通知不得早于其引用的 snapshot 与 delta 对外可见。多后端服务要么让连续请求停留在同一份一致视图，要么先把数据送达所有节点，再在任何节点放出通知。
  • 看到新 session 或 serial，只能证明某个端点返回了一份索引；它不能证明所有字节可取、对象通过 RPKI 验证、依赖方输出改变、路由器采用结果或数据包改道。

一次同步从正常响应开始。依赖方拿到新的 notification，serial 比上次大，里面给出一个 delta 地址。下一次请求被负载均衡器送往另一台后端。那台机器已经有 notification，却还没有 delta，于是返回 404。稍后，一条没有排空的 keepalive 连接又把客户端带到旧节点，serial 看起来倒退了。

这个场景不需要伪造签名。发布服务只需让“我已经有了”的声明跑在内容前面，就足以制造分裂视图。

IETF 的8 月 28 日最后征求意见因此不只是容量调优。现行发布服务草案要求 notification 必须最后出现。意见期到 9 月 11 日；截至写作时，IESG 尚未批准该 BCP，草案也没有指称任何具体运营者发生了这类事故。

索引不能比被索引的内容更早成为事实

RFC 8182把 notification、snapshot 和 delta 分开。notification 给出 session、serial 与同步所需的引用。它一旦公开，就不再只是内部元数据，而是对外宣告这些引用已经可用。

单机可以按“写数据、再替换通知”的顺序完成。多机环境有两种主要做法。一种维持请求亲和性，让同一客户端沿着同一节点的时间线继续取文件；另一种实施全局可见顺序：先让所有节点拿到 snapshot 与 delta，再让任何节点拿到新 notification。两种办法的共同目标，是不允许新索引与旧存储被拼成一次会话。

这里的“所有节点”不能只看源站。CDN 缓存、边缘节点与负载均衡路径都是公开服务的一部分。未来路径在文件生成前若被缓存为 404，新内容出现后仍可能被挡住。notification 缓存过久会让客户停在旧状态。已经被移出池的机器若继续接受持久连接，又会在新旧 session 之间制造跳转。

部署系统显示“同步完成”，只能说明控制器记录了预期状态。真正的证据来自外部探针：它们经过客户实际使用的 DNS、CDN、负载均衡与连接复用路径，取得同一个 notification 所引用的全部内容。

顺序错误会把小请求放大成全量下载

delta 失败后，依赖方可能请求更大的 snapshot；snapshot 再失败，就回退到 rsync。下一轮重试 RRDP 时，它还可能从 snapshot 开始。一个过早通知，于是把一次增量同步变成多批客户端的全量恢复。

所以带宽上升并不自动代表采用率或正常需求。它也可能是后端不一致、缓存错误或重复恢复。草案建议从网络外部运行 canary RP，观察意外 snapshot 回退，并把容量、内存、磁盘 I/O 与日志结合起来。有效记录至少要有 session、serial、后端、URI、响应码、字节数和耗时。

草案还建议，snapshot 与 delta 即使不再被最新 notification 引用，也继续保留两小时。这给慢速客户端下载和竞态留下余地，但它只保护旧引用。保留昨天的完整内容，无法弥补今天的 notification 抢跑。

把 delta 生成频率控制在每分钟不超过一次，同样是减负措施。合并多个 publisher 的变化可以缩短 notification、减少请求，却不改变发布顺序：批次内容仍应先于批次索引。

“发布成功”必须拆成多个说话者

最前端是 CA。它生成签名对象，通过 RFC 8181 交给 publication engine。变更前执行 list 可以发现双方状态差异；在一个 multi-element query 中提交多项 PDU，可以减少本应原子发生的变化只完成一半。

此后，每张回执的权限都不同。CA 本地清单表达意图；RFC 8181 响应说明引擎接受了什么；notification 说明一个端点宣告了什么；HTTP 下载说明交付了哪些字节；RP 的证书、manifest、CRL 与对象验证说明本地接受了什么。VRP 是否送达路由器、策略是否采用、FIB 是否改变、数据包是否经过新路径，还要分别观察。

一个可下载对象可能没有出现在当前 manifest，可能哈希不符，可能证书或 CRL 失败。一个有效 ROA 也只表达前缀与源 AS 的授权边界，并不证明 BGP 当前存在该路由。把这些结论压成一个绿色状态，正是 Heng Lu 所说的现实层混淆。

rsync 部分给出同一治理原则的另一种实现。如果仓库在客户端读取过程中逐个改文件，客户可能得到新旧混合的“幻读”。草案建议先构建完整新目录、修正时间戳，最后一次性切换符号链接。RRDP 用 notification-last，rsync 用完整快照切换；两者都要求状态完成后才宣布状态。

serial 递增不是新鲜度证明

serial 在一个 session 内提供顺序，不提供真实时间。旧内容也能按递增编号连续发布；新编号引用的对象也可能验证失败。反过来，从旧备份恢复并发生内容倒退时，开启新 RRDP session 反而是诚实做法。

草案要求内容回退后重置 session，并通知依赖该服务的 CA 进行完整重新同步。这项动作明确承认旧连续性已经结束。它不会自动重建丢失的 ROA、近期新增 publisher 或即将过期的 manifest，但会让重建过程留下可解释边界。

Heng Lu 的运行代码优先要求在真正提供服务的位置验证。配置说“所有节点一致”只是符号状态；外部请求才是运行状态。他对形式控制与实际控制的区分，则追问谁能冻结 notification、清除坏缓存、排空旧连接、重置 session、保住前一份一致视图并解释验证输出变化。

notification-last 不是路由安全的终点。它只是建立一个可靠起点：当服务公开“这里有新状态”时，它所引用的字节已经确实存在。

Sources