什么是 RPKI？路由安全入门指南
RPKI 核对的是谁获准宣布一组 IP 地址，不是整条路径都安全。用配送的例子理解它的作用、边界，以及卢恒对管理权的追问。
网站的服务器好好的，访问者却打不开页面。问题可能出在远处：另一个网络报错了通往这些地址的路线，把流量引向了错误的地方。原因可能是一次配置失误，也可能是蓄意劫持。
RPKI，中文常称资源公钥基础设施，帮助网络核对一项具体声明：这个网络，获准宣布这些 IP 地址吗？看懂这项检查，还能继续追问：检查所依据的记录由谁管理，管理记录又应该给它多大的权力？
先从一句“我能送到那里”说起
互联网把许多独立运营的网络连接起来。它们通过 BGP 交换路由通告，告诉彼此哪些地址范围可以到达。这样的地址范围叫前缀；参与路由的自治系统用 ASN，也就是自治系统编号，来标识。
可以把通告想成承运商说：“这个街区，我能送到。”其他承运商需要判断这句话是否可信。BGP 通告本身，并不能证明被列为路由起点的网络，确实获得了发布这个前缀的授权。
谁发授权，谁来核对？
RPKI 为互联网号码资源提供证书体系。地址持有者可以发布经过签名的路由来源授权，简称 ROA，说明哪个 ASN 获准作为某个前缀的路由起点。它还可以限制通告中允许使用的最大前缀长度。RFC 9582定义了这种授权记录。
发布自己的授权，和检查别人发来的路由，是两件事。验证软件先检查证书及签名记录，把核验后的授权数据交给路由器。路由器再把收到的路由通告与这些数据比较；运营者决定比较结果怎样影响自己的路由政策。这叫路由来源验证，简称 ROV。
回到配送的比喻：核对的是谁获准服务这个街区，并不是保证每次配送、沿途每个环节都安全。
三个结果，不是简单的“安全”或“危险”
- Valid：至少有一条有效授权覆盖这个前缀，并允许通告中的来源 ASN 和前缀长度。
- Invalid：有授权覆盖这个前缀，但没有任何一条允许这组来源与长度。
- NotFound：当前验证数据中，没有覆盖这个前缀的授权。
NotFound 不等于发现了攻击。Invalid 也不能单独告诉你，是有人攻击还是管理员配错了。它们是按规则进行比较的结果；RFC 6811说明了这套规则。
它能保护什么，不能保护什么？
来源验证可以帮助网络拒绝未经授权的来源，但不会检查途中经过的每个网络，也不会加密访问者的通信。一条被错误传播的路由，仍可能保留正确的来源，所以不能指望这项检查挡住所有路由泄漏。
对运营者来说，准备工作要从实际通告入手：哪些前缀由哪些 ASN 发布，授权是否对应，验证软件是否持续正常工作。打开一个路由器选项，并不意味着此后不用维护。RFC 7115讨论了相关运营注意事项。
保存证据的人，也会形成权力
常用的 RPKI 信任层级沿着号码资源的分配关系建立，区域互联网注册机构位于信任根的位置。验证因此不仅依赖密码学，也依赖签发证书、发布记录的机构和服务。
记录被修改或撤回，可能改变验证结果，但并不等于某个网络必然立即从整个互联网消失。还要看其他有效授权，以及各网络采用的路由政策。RFC 8211讨论了证书机构和发布服务出错或采取不利行动的影响。解决一种风险的机制，也可能带来新的依赖。
卢恒的主张：保护网络，约束守门人
在第 28 篇札记中，卢恒提出了一条鲜明的边界：维护地址簿，不能变成惩罚使用者的权力。他不反对准确记录；他反对管理者借必要服务取得额外支配权。一个自行聚集的小群体，不会仅凭运营协调服务，就获得对跨洲网络的政治代表权。
在第 64 篇札记（英文原作）中，他进一步提出：共同规则只应覆盖唯一性、协作和安全真正需要的部分，证据应让参与者自行核验，记录和证明应能迁移。未来的改变，要由实际运行系统的人选择采用。
这是他提出的重构方向，并不是说替代体系已经到处可用。它仍须保证记录兼容、验证可靠。目标是同时解决两件事：防止虚假的来源声明，也防止掌握证据的机构变得不受约束、无法替换。
为什么不能等到断网再考虑？
客户每天都在依赖熟悉的地址。如果直到记录改变或消失，运营者才发现自己没有退出路径，讨论就已经变成了正在发生的服务危机。
卢恒要求把连续运行、独立核验和更换服务方的能力提前写进系统设计。想继续了解这条思路，可以读授权怎样一步步到达路由器，再回到他的原作，理解为什么安全和可替代性必须一起设计。