Summary

  • RPKI relying party 并非下载一个全球统一判决；它依据分布式仓库、所配信任锚、同步结果、验证规则和本地控制，生成带有时间边界的本地视图。
  • draft-su-sidrops-rpki-rp-requirements-00 新增的方向包括稳定导出验证缓存、说明同步与对象拒绝原因、保存可比较和可回放的历史输出。
  • Daniel Kade 提议使用“验证状态收据”，把执行版本、输入与缺失、缓存摘要、本地变更、向路由器交付的上下文和历史保存连接起来；这不是 IETF 要求，也不表示草案已经部署。

绿色把过程压成了一个像素

RPKI 的公开叙述往往从签名对象开始：证书约束号码资源，ROA 表达某个 AS 对前缀的起源授权，manifest 列出发布点的当前对象。到了运营界面，这些复杂关系又被压成一盏灯。两端都真实，但中间那段恰恰决定了某一网络实际得到什么。

全球 RPKI 数据分散在多个发布点。relying-party 软件选择信任锚，发现仓库，通过 RRDP、rsync 或其他受支持机制取回对象，处理证书与 CRL，执行通用及对象特定验证，再形成一份本地缓存。运营者还可能通过 SLURM 加入本地过滤或断言。之后，RPKI-to-Router 协议把派生结果交给路由器，路由器再运行自身策略。

因此，任何一层都不能自动替下一层作证。签名有效不等于所有仓库可达；一个当前 manifest 不等于所有发布点都被完整观察；缓存向路由器发出了 payload，不等于路由器安装、优选或传播了某条路由。绿色只能说明一个实现对自己当前状态的概括。

RFC 8210 对序列号的限制尤其关键。cache serial 只在特定协议版本和 session 中描述逻辑版本，不同缓存之间不可直接比较，重启后也未必延续。脱离 Session ID 与协议版本后，“序列号 417”并不是全局状态标识。

2026 年草案把运行状态写进要求

2026 年 6 月 12 日的 draft-su-sidrops-rpki-rp-requirements-00 试图更新 RFC 8897 这份汇总性参考。草案纳入了近年来关于信任锚后继密钥、RRDP 同源限制与失同步恢复、manifest、ROA、ASPA、RSC、TAK、CRL、缓存分发和本地控制的规范变化。

它的程序状态不能被放大。Datatracker 将其标为个人 Internet-Draft，没有 RFC stream、负责 AD 或 telechat 日期；文稿页眉写的是预期 Informational，并只在获批时更新 RFC 8897。对仍在推进的 SIDROPS 草案的引用被明确称为临时内容。这些事实不构成工作组采纳、IETF 共识、实现或部署证据。

即便如此，草案第 7 节提出了值得单独审视的运行要求：软件应该以稳定、机器可读的形式导出验证缓存；应该给出足以理解仓库抓取、同步、解析和对象验证失败的状态与诊断；还应该保存历史输出或等价审计记录，以便比较、回放和后续分析。

三者缺一不可。导出说明结果里有什么，诊断说明为什么某些材料不在其中，历史说明边界何时发生变化。

“当前”由多只时钟共同组成

证书、CRL、ROA 和 manifest 都有时间语义。RRDP 自己有 session、notification、delta、snapshot 与恢复路径。缓存到路由器的连接又有 refresh、retry 和 expire interval。验证主机的时钟也会影响时效判断。

所以，本地自洽并不等于全球同步。某个 RP 可能在一个仓库失效时保留可用状态；另一个已经通过 snapshot 完成恢复；第三个切换到 rsync；第四个套用了本地断言。它们都可能不含密码学错误，却在同一时刻给出不同 payload。

草案要求 RRDP 使用 RFC 9674 的同源检查，并建议采用 RFC 9697 的失同步检测与恢复。它还把 manifest 的失败条件说得很具体：无法取得、无效、过期、清单中文件缺失、哈希失败、对象位于错误发布点，都会改变 fetch 结果；CRL 还必须与有效且当前的 manifest 一起解释。

审计记录不能只保留成功对象数。仓库未达、恢复路径、拒绝类别和时间窗口都是决定本地视图的负证据。否则，一次较晚的成功刷新会覆盖两台验证器曾经不同的原因。

本地控制应当一直带着“本地”二字

RFC 8897 与 RFC 8416 允许 ISP 通过 SLURM 建立本地过滤和断言。它可以用来缓冲已知发布问题、限制不利影响，或表达一项有时限的运营例外。这种权力有正当用途，但没有改变全球仓库里的签名对象。

一旦界面把变更后的结果仍称为“RPKI 的答案”，责任就会错位。发布者或资源持有者可能被归因于一项运营者自己作出的例外。反过来，若本地转换有标识、批准人、有效期与摘要，它就可以被复核和撤销，而无需假装全球状态被改写。

这也解释了为什么两个绿色缓存不能仅凭颜色比较。软件版本、信任锚、同步路径、失败处理和 SLURM 政策都可能不同。输出一致也可能只是巧合；要证明可复现，必须保留输入、规则和过程。

一张“验证状态收据”应记录什么

这张收据不是草案定义的协议字段，而是 Daniel Kade 的编辑性治理建议。它的目的不是汇集所有日志，更不是公开私钥、凭证或不必要的拓扑。

第一部分标识执行：RP 产品与版本、验证 profile、配置摘要、启用对象类型、信任锚集合和关键时钟状态。配置发生实质变化，就开始新的决策 epoch。

第二部分记录获取：尝试过的发布点、各自所用同步协议、上次成功时间、本次观察、fallback 或恢复路径，以及有边界的失败原因。敏感细节可以分级保存，但“没有看到”不能被写成“验证通过”。

第三部分记录验证：manifest 和 CRL 状态，各类对象的接受与拒绝数量、拒绝原因、信任锚过渡状态、所用规范 profile，以及最终缓存的规范化摘要。没有规则版本，后来者无法真正回放。

第四部分把本地控制单列：政策标识、变更批准、有效期和转换摘要。第五部分连接交付：RPKI-to-Router 版本、Session ID、serial、导出时间、消费路由器范围及未覆盖项。最后保留前一状态引用、保存期限、责任系统和更正链。

一份紧凑收据无需公开每个内部细节。它可以在公共层只给出摘要、时间和结果类别，把更敏感材料留在受控审计域。分布式验证并不要求集中式监控。

有限，才使证据可信

收据不能证明每个发布对象在现实世界里正确，也不能证明路由器最终采取了某个动作。它不会让个人草案变成标准，不能自动裁定两个实现谁对，更不能替代本地例外的人工批准记录。

它能证明的是更窄也更有用的事实：在某个时间窗口，一次可识别的 RP 执行依据哪些材料与规则，产生了哪份本地缓存，并把它提供给哪些消费方。这样，事后讨论就不必从一张绿色截图反推整个系统。

RPKI 验证器本来就是持续运行的控制组件。持续运行意味着会刷新、失败、恢复、升级和改变配置。只要它的输出参与路由安全，这些变化就属于治理证据。绿色可以留在面板上，但它背后必须有可导出、可解释、可回放的轨迹。

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification
  3. Lu Heng — Why BTW Media Exists
  4. RPKI relying-party 要求草案第 00 版
  5. Datatracker 文档状态
  6. Datatracker 版本历史
  7. SIDROPS 工作组
  8. RFC 8897 — RPKI relying-party 要求
  9. RFC 6480 — 支持安全互联网路由的基础设施
  10. RFC 9286 — RPKI Manifest
  11. RFC 9674 — RRDP 同源策略
  12. RFC 9697 — 检测 RRDP Session 失同步
  13. RFC 9691 — RPKI 信任锚密钥
  14. RFC 8416 — SLURM
  15. RFC 8210 — RPKI-to-Router 协议第 1 版
  16. RFC 9582 — 路由起源授权
  17. RFC 9829 — RPKI CRL Number 扩展处理