摘要

  • RFC 9674 要求 RRDP 通知引用的 Snapshot、Delta 以及 HTTP 重定向目标，与通知文件保持相同 scheme、host 和 port。
  • “同一家机构”“同一张证书”“文件哈希一致”都不能替代 origin 比较；跨源目标即使可达，也必须被拒绝。
  • 同源通过只是第一张收据，后面还有 RRDP 格式与会话、文件哈希、证书与 CRL、manifest、签名对象、验证缓存、路由器会话、策略和真实流量。

变更单写着“仍是同一个仓库”。域名没变，证书也没变，只是把服务从 443 切到 8443。运维视角里，这像一次端口迁移；在 RFC 9674 的权限模型里，通知文件却已被要求指向另一个 origin。

如果 RRDP 客户端跟随这个目标，最终可能收到正确文件，哈希也可能完全相符。但会话仍不能被接受。这里被拒绝的不是字节，而是通知文件没有权力触发的取回位置。

Origin 不是资产标签

RFC 6454 用 scheme、host、port 划分 origin。只看 host 会漏掉协议和端口带来的安全差异；只看母域名会把不同主机误当成同一主体；只看组织归属，则把可核验的协议边界换成了合同或 CMDB 标签。

RFC 8182 让资源证书 SIA 中的 rpkiNotify 指向 Update Notification File。通知声明 session、serial、当前 Snapshot 与可用 Delta。最初规范要求 HTTPS，也要求客户端核对引用文件的 SHA-256，却没有明确禁止通知跨源引用或 HTTP 响应跨源重定向。

RFC 9674 补上两侧责任。仓库服务器不得把 Snapshot、Delta uri 放到不同 origin，也不得通过重定向越界。Relying Party 必须逐一比较；引用越界时拒绝通知，重定向越界时拒绝会话，并应记录检测结果。

这个机制借用了 Web origin 概念，却不是把浏览器制度搬进 RPKI。文章不讨论 cookie、脚本或 CORS。它只问一件窄而重要的事：通过证书发现的通知文件，能够让验证器向哪个协议主体发出后续请求。

200 状态码删掉了最重要的路径

RFC 9110 把重定向描述为用户代理为了完成请求而采取的进一步行动。若监控系统只保存最终响应，301、302、307 或 308 经过的 Location 就会从审计记录中消失。

对网页可用性来说，终点成功也许可满足指标。对 RRDP 合规性来说，是否有权走到终点正是核心问题。正确记录应保留 SIA URI、归一化 origin、通知内每个引用、每一跳状态与目标，以及跟随前的比较结果。

文件哈希不能替这个授权。哈希可以证明终点返回的字节等于通知承诺的字节，却不能消除客户端和第三方服务器承担的资源消耗。RFC 9674 针对的风险之一，正是某个仓库借跨源引用或重定向把大量客户端请求导向另一个仓库。

反过来也一样：同源只说明请求没有越过该权限边界，不说明 XML 合法、session 正确、serial 前进或文件哈希一致。

同源之后才轮到 RRDP 完整性

RFC 8182 还要求通知格式和 schema 正确。session_id 必须与通知位置共同解释，不能单独充当全局身份。Delta 链需要连续，Snapshot 与 Delta 的字节必须匹配通知里的哈希，文件内部 session 与 serial 也要符合当前状态。

Delta 被拒绝时可以转向 Snapshot；Snapshot 也被拒绝时，RRDP 无法继续。规范允许 Relying Party 尝试证书 SIA 中列出的其他仓库访问方式。那是新的取回链，不是对已失败会话的追认。

更关键的是，RFC 8182 明确把 RPKI 对象验证留在范围之外。RFC 6480 把资源证书 PKI、签名对象和分布式仓库分成三个组件。RFC 6487 规定证书、CRL 与路径验证。RFC 9286 又让 manifest 以自身编号、时间以及文件名/哈希清单约束当前发布物。

所以一个同源、哈希一致的 Snapshot 仍可能携带不能通过证书、CRL、manifest 或对象签名检查的材料。“从允许的位置拿到了承诺的包”与“包里存在可接受的权威声明”不是一件事。

验证缓存也不是路由器状态

RFC 7115 所说的 validated cache，是 Relying Party 实际按规则验证过的对象集合。RFC 8210 再定义缓存向路由器传递 payload 的协议，并拥有独立的版本、session 和 serial。RFC 6811 给出前缀源验证状态，最终还要交给本地路由策略。

这条链不能被一个“RPKI 绿色”图标压平。至少要分别保存：通知来源、origin 比较、HTTP 路径、RRDP 哈希与序列、对象验证结果、输出的 VRP/Router Key 集合、缓存—路由器会话、路由策略、选路和流量观测。

跨源日志也不等于攻击归因。它能证明 URI 违反当前规则，却不能独自证明恶意、入侵或利用。同源日志同样不能证明仓库诚实、对象新鲜或路由正确。

历史观察不能自动续期

RFC 9674 报告，在它检查的 2021 年 10 月至 2024 年 10 月档案中，没有发现通知文件跨源 URI；在另一段 2024 年窗口里，一个 RRDP 服务器使用了同源重定向。这组证据用来说明新要求当时不会让常见操作突然失效。

它不是 2026 年全球部署调查。写作和运营报告都必须保留样本、时间与问题本身。把“那段档案中没观察到”改写成“现在不存在”，就是把有边界的证据变成没有边界的权力。

最小初始规范 的价值在这里很清楚：共同规则只守住 origin，不替所有部署作决定。现实层级 要求把组织标签、URI、字节、验证对象与路由结果分开。运行代码优先 则要求在谈及运行效果前，拿出具体 RP、缓存与路由器的执行收据。

RFC 9674 没有把 origin 变成真相源。它只是让通知文件不能悄悄扩大自己的取回权力。这条窄边界越清楚，越不该被拿来替代后面的所有证据。

来源