资源公钥基础设施（RPKI）的工作原理

你把服务迁到另一家网络，服务器运行正常，IP 地址也没变，却有一部分访客无法访问。可能的原因很小，也很关键：路由授权仍然指向旧网络，没有允许新网络宣布这些地址。

RPKI 让这份授权可以被其他网络核验。我们沿着它从地址持有者到路由器的过程，看看各环节分别做什么，也看看卢恒为什么坚持：维持必要服务，不该等于永远保留同一个管理者。若还不熟悉基本概念，可以先读RPKI 入门介绍。

第一步：确认谁能作出授权

一组 IP 地址称为前缀。宣布这个前缀的网络，用自治系统编号 ASN 表明自身身份。RPKI 使用资源证书，确认谁可以为相应地址范围签发授权。

这些证书形成通往信任根的验证链，其层级沿着号码资源的分配关系建立。RFC 6480介绍了基本架构。这是体系内关于资源的证据，不是给证书机构颁发一份代表互联网使用者的政治授权。

第二步：发布一份签名许可

地址持有者发布路由来源授权 ROA。它说明：这个 ASN 可以作为这个前缀的路由起点。这里的“起点”，是路由通告中声明的来源网络，不是数据以后经过的所有网络。

ROA 还可以规定最大前缀长度，也就是允许把地址范围细分到什么程度后再通告。没有填写这项可选值时，只允许所列前缀本身的长度。因此，获准发布一个范围，不等于自动获准发布任意更细的子范围。记录格式见RFC 9582。

第三步：把公开记录变成可用的验证数据

签名记录保存在发布仓库中。验证软件获取这些对象，检查证书链、签名、有效期和撤销信息，也会核对描述仓库对象的清单。下载到一个文件，不等于支持这个文件的证据已经有效。

核验后，软件输出路由器可以使用的数据：前缀、获准的来源 ASN、最大长度，通常称为 VRP。路由器通过 RPKI-to-Router 协议从可信缓存取得它们；RFC 8210描述了这一环节。并不是每有一个人打开网页，路由器就要去登记机构请求一次许可。

第四步：路由器比较，运营者决定怎样使用结果

BGP 负责在网络之间交换路由通告。接收方把通告中的前缀和来源 ASN，与核验后的授权比较，这就是路由来源验证。

有覆盖前缀的授权，且允许相应来源与长度，结果是 Valid；有覆盖授权，但没有一条允许这组组合，是 Invalid；没有覆盖授权，是 NotFound。这些结果并不判断当事人的动机。运营者决定如何把结果用于路由政策，规则可见RFC 6811。

回到更换网络的例子：如果仍只授权旧 ASN，新网络的通告可能被判为 Invalid，并被过滤这类通告的网络拒绝。迁移计划因此要包括授权的更新，以及是否需要一段同时授权新旧网络的过渡期。不能只检查服务器是否开机。RFC 7115讨论了运营上的注意事项。

第五步：让整条证据链持续可用

来源验证帮助拒绝虚假的来源声明，却不验证每一跳、不加密流量，也抓不住所有路由泄漏：一条不该被传播的路由，仍可能带着正确的来源。

证据本身也需要维护。证书会过期，授权会变化，发布服务必须可用。删除一条 ROA，不一定立即引起中断；要看其余记录如何影响验证结果，再看各网络的政策如何处理。RFC 8211分析了证书机构和仓库运营者的错误或不利行动可能造成的影响。

卢恒的方案：服务不能断，管理者可以换

在第 70 篇札记中，卢恒质疑了一个常见推论：登记服务很重要，所以当前提供服务的机构就必须永远存在。网络确实需要准确记录和可靠安全服务；这不等于某个机构取得了永久控制网络的权利。

他要求把连续运行做成系统本身的能力：记录可以独立审计，接替过程经过预先测试，登记管理可以交给合格的继任者，而不是逼运营商更换全部地址。他也特别指出，RPKI 的交接不是复制一个文件夹；密钥、证书、发布和依赖方的信任必须在过渡中保持一致。

这是一项设计要求，不是宣称现实中已经可以随时迁走。草率交接可能破坏验证；完全不能更换的管理者，又可能利用这种依赖扩张权力。服务可靠和管理者可替代，必须一起实现。

为什么现在就要准备接替机制？

争议一旦触及证书链，后果可能落在不曾参与争议的客户身上。等到故障发生才临时讨论谁接手、怎样接手，已经把不确定性转嫁给正在使用网络的人。

卢恒主张提前建立连续运行和退出机制，让行政争议不能被用来威胁正常工作的网络。继续读第 70 篇札记：保护记录，而不是保护守门人的权力。