资源公钥基础设施如何运作

验证需要持续维护证据：随着网络变化，证书、权限和发布系统必须保持一致。

你把一项服务迁移到新网络。服务器运行正常，地址也没有变化，但有些访客却再也无法访问。一个可能的原因小得出人意料：互联网的路由记录仍在授权旧网络宣布这些地址。

RPKI 把这项许可变成其他网络可以检查的东西。下面我们追踪它如何从地址持有者传到路由器，也说明 Lu Heng 为何认为，让这套机制持续运作，绝不能依赖让某一位管理者继续掌权。若想先看较短的介绍，可以从RPKI 保护什么开始。

1. 确立谁有权授权这些地址

一组 IP 地址称为一个前缀。宣布这个前缀的网络，会用自治系统号（ASN）标识自己。RPKI，即资源公钥基础设施，使用证书来确立谁可以为特定地址范围签发授权。

这些证书沿着一条链回溯到可信根。正如RFC 6480所述，这套层级关系遵循互联网号码资源的分配方式。它提供的是这套体系内部资源的证据；它并没有赋予证书机构对互联网使用者行使政治权力的授权。

2. 发布带签名的许可

地址持有者会发布路由起源授权（ROA）。它传达的信息很具体：这个 ASN 可以起源发布这个前缀。起源发布，指的是位于所公布路由起点的网络，而不是之后承载流量的每一个网络。

ROA 还可以设置最大前缀长度，也就是这段地址范围最多可以被拆分成多小的已公告范围。如果不设置这个可选项，它只允许公告所写明的前缀长度。这样可以防止“允许使用这段范围”悄悄变成允许所有可能的细分范围。RFC 9582定义了这项带签名的记录。

3. 把已发布记录变成经过验证的数据

带签名的记录会在发布仓库中提供。验证软件收集这些记录，检查证书链、签名、有效期和吊销信息，同时检查描述已发布对象的清单。单独一份可读文件并不够：支持它的证据也必须通过验证。

验证器会生成可用的授权数据，通常称为已验证 ROA 载荷（VRP）。其中包含前缀、获准的起源 ASN 和最大长度。路由器通过RFC 8210所述的 RPKI 到路由器协议，从可信缓存中接收这些结果。每次访客打开网页时，它们并不会向注册机构请求许可。

4. 将路由与许可进行比较

BGP 是网络发布路由所使用的协议。接收路由器会把某条路由的前缀和起源 ASN，与经过验证的授权进行比较。这就是路由起源验证（ROV）。

Valid：某项覆盖该前缀的授权同时允许这个起源和前缀长度。Invalid：存在覆盖该前缀的授权，但没有一项允许这组组合。NotFound：没有授权覆盖该前缀。这些是比较结果，不是对某人意图的裁决。运营者决定如何在路由政策中使用它们。参见RFC 6811。

回到服务迁移的场景。如果旧 ASN 仍获授权，而新的 ASN 没有，新的公告就可能是 Invalid。过滤 Invalid 路由的网络可能会拒绝它。解决办法是让授权变更与迁移协调进行，包括两个网络都需要获得许可的那段时间，而不是以为服务器运行正常就必然能够访问。RFC 7115讨论了运行层面的注意事项。

5. 让整条链持续运作

起源验证有助于拒绝虚假的起源声明。它不会验证每一跳、加密流量，也无法发现所有路由泄漏。一次泄漏可能仍然保留一个获授权的起源。其他路由保护措施依然必要。

证据也需要维护。证书会过期，许可和发布数据会变化。删除一项 ROA 不一定会立即造成中断：最终的验证结果取决于其他可用记录，而路由后果则取决于本地政策。RFC 8211考察了证书机构和仓库运营者的错误或不利行为可能如何影响这套系统。

Lu Heng 的提议：保留服务，替换管理者

在《笔记 70》中，Lu Heng 质疑一种常见的跳跃式推论：既然注册机构的服务不可或缺，那么它当前的运营者就必须不可替代。网络需要准确的记录和有效的安全机制，但这并不能证明某个机构永久控制这些资源的权利。

他的替代方案，是把连续性变成系统本身的属性：记录可以被独立审计，能够向合格的继任者完成经过测试的交接，并且可以转移管理，而不必迫使网络更换地址。他明确承认，RPKI 不可能靠复制一个目录就完成转移。在整个过渡期间，密钥、证书、发布机制和信任关系都必须保持一致。

这是他主张的一项设计要求，并不是说这种可移植性已经在所有地方可用。它同时回应问题的两面：轻率的替换可能扰乱验证；不可替代的守门人则可能把这种依赖变成权力。要让服务可靠、让管理者可替代，必须把两件事一起设计进去。

为什么要在危机前建立这种能力？

当争议触及证书链时，受到影响的人可能远远超出争议双方。客户并没有选择这场争论，却可能承担连接中断的代价。等到中断期间才临时设计继任流程，已经太晚，无法保护他们免受这种不确定性的影响。

Lu Heng 主张，应该预先建立连续性和离开的权利，同时避免让管理争议变成针对正常运行网络的武器。完整论述见《笔记 70：保护账本，而不是守门人》。