RPKI 在加强全球路由安全中的作用

一个网络的路由配错了，远处的人也可能跟着断网。网站的服务器还在正常工作，用户却无法访问，或者流量被引向了错误的地方。RPKI 提供了一种办法，让接收通告的网络先核对其中的来源声明。

它能不能发挥作用，要看一整条链：持有者发布准确授权，软件核验证据，运营者把结果用于路由决策。看清这几步，也就能看清保护在哪里生效、又可能在哪里出错。

究竟在核对什么？

网络通过 BGP 交换可达信息。一组 IP 地址叫前缀，自治系统编号 ASN 用来标识参与路由的网络。路由来源授权 ROA 则说明：地址持有者允许哪个 ASN 成为这些前缀的路由起点。

验证软件先检查签名记录和证书，提供核验后的授权数据。路由器再拿通告的来源与前缀长度来比较，运营者决定怎样处理比较结果。发布记录、核验证据、决定采用哪条路线，是不同的工作。

三个结果，各有各的含义

• Valid：至少一条覆盖授权允许通告中的来源 ASN 和前缀长度。
• Invalid：有授权覆盖这个范围，但没有一条允许这组来源与长度。
• NotFound：当前使用的数据里，没有覆盖这条路由的授权。

RFC 6811定义了这些规则。没有覆盖授权，不是 Invalid；通过来源检查，也不是整条路径都已经被认证。

保护发生在接收网络作决定的地方

如果接收网络配置为拒绝 Invalid 路由，不符合授权的来源就可以在这里被挡住，避免继续经由这个网络传播。实际效果取决于记录、当时可用的数据和真正执行的政策。发布更多 ROA，与更多网络启用来源验证，是相关但不同的两件事。

RFC 8481明确区分赋予验证状态和采取行动。互联网上没有一个开关，能让所有网络立刻执行同一套政策。

错误泄漏出去的路由可能仍然保留获准的来源，伪造路径也可能保留这个值。因此，来源验证不能包办路由安全；运营者还需要其他控制措施，并了解通告如何传播。

证据系统本身，也需要维护

ASN 写错了，或者允许的前缀长度没覆盖计划中的通告，就可能让正常业务变成 Invalid。证书、发布仓库、验证软件的问题，也会影响路由器实际拿到的数据。缓存和更新时机不同，各网络看到的状态不一定同步。

运营准备包括精确授权、测试变更、监控验证器，以及处理过期或缺失数据的明确办法。增加第二台验证器，能解决多少问题，要看它真正分散了哪些故障来源，不能只数机器数量。RFC 7115讨论运营实践；RFC 8211分析证书和发布服务中的不利行动。

不能以保护为名，制造永久依赖

这也涉及制度设计。一个机构如果控制着关键证据，就可能影响它既不运营、也没有政治代表权的网络。卢恒在第 28 篇札记中提出，注册管理的职责应当是准确维护记录，而不是借此取得胁迫别人的权力。

他的第 64 篇札记（英文原作）要求走得更远：共同规则应尽量精简并能由参与者自行验证，记录可以迁移，未来变化由运行系统的人自愿采用。安全和替换失效协调者的能力，必须一起设计。

急迫性就在这里：用户已经断网以后，再去寻找谁掌握着哪条记录，讨论就成了服务危机。趁网络还能正常运行，把依赖关系追清楚。下一篇可以看一条记录的变化怎样变成一次路由拒绝（英文）。