什么是 RPKI，它为何重要
互联网网络中的流量依据 BGP（Border Gateway Protocol）进行路由。BGP 假设每个 自治系统（AS） 在宣告其控制的 IP 前缀时都是诚实的。这种信任模型较为薄弱。恶意通告、配置错误或蓄意攻击都可能宣告其并不控制的前缀，从而导致 前缀劫持 或 路由泄漏。
为了增强安全性，人们开发了 Resource Public Key Infrastructure（RPKI）。这是一套密码学系统，允许 IP 前缀持有者声明哪个 AS 可以为其前缀发起路由通告。其他网络可以根据这些声明验证 BGP 更新。
RPKI 的核心组成部分是 路由起源授权（ROA）。ROA 表明某个 AS 获准宣告指定前缀，还可以包含最大前缀长度。当 BGP 更新到达时，执行 Route Origin Validation（ROV） 的网络会把收到的通告与现有 ROA 比较，并将其分类为 有效、 无效 或 未知。
目前只支持 起源验证；要验证完整的 AS 路径，也就是数据包经过的确切路径，则需要 BGPsec，但这一机制更加复杂，部署范围也很有限。
简而言之， RPKI 提供了一种更可靠地确认谁获准宣告哪些 IP 地址块的方法，为全球路由增加了一道保护屏障。
历史、标准与治理
RPKI 及其配套标准由一个工作组制定，即 SIDR（Secure Inter-Domain Routing） 该工作组隶属于 IETF。
主要参考文件包括：
RFC 6480：RPKI 架构
RFC 6482/6483：ROA 配置文件与验证
RFC 6810：RPKI-to-Router 协议
每个 RIR （区域互联网注册管理机构）都可以被视为一个 信任锚。它们向 Local Internet Registries（LIRs） 或其他资源持有者签发资源证书，以反映 IP 前缀和 AS 号的分配。这些证书形成一套层级结构，为签发 ROA 提供基础。
运营商可以选择运行自己的 证书颁发机构 ，也可以委托使用一项 托管 RPKI 服务 ，服务由 RIR 提供。
在使用端，路由器从 依赖方验证器获取已经验证的数据。这些验证器通过相关协议，从分布式 RPKI 存储库收集 ROA 信息，例如 rsync 或 RRDP（RPKI Repository Delta Protocol）。
不过，并不存在一个负责强制采用的单一组织。RPKI 的有效性在很大程度上取决于 网络效应：采用起源签名和验证的网络越多，每一位参与者获得的价值就越大。
RPKI 对路由安全的益处
防止明显的劫持和配置错误
其主要优势之一是 检测未经授权的起源通告。如果某个网络尝试宣告其无权使用的前缀，执行 ROV 的对等网络可以把该通告标记为无效，并丢弃或降低其优先级，从而减少前缀劫持的风险。
许多路由事故也源于简单的 配置错误或“手滑”。RPKI 有助于缓解这些问题。
控制损害范围
由于路由相互依赖，一个行为异常的网络可能在自身范围之外造成大面积中断。RPKI 通过尽早拒绝无效起源，帮助 控制损害。
传递信任与责任信号
拥有 公开注册的 ROA 可以提高透明度。其他运营商可以看到哪些前缀已经签名，从而体现 运营纪律与良好的网络规范。
为未来改进和路径验证奠定基础
虽然目前 RPKI 主要关注 起源验证，但它为更先进的路由安全机制奠定了基础，包括 BGPsec 路径验证以及 ASPA（AS Path Authorization）等扩展。
从长期看，全球 RPKI 基础设施可以 提高攻击者实施路由劫持的成本 ，并增强对域间路由的整体信任。
当前采用情况与挑战：部署统计和差距
采用 ROA 的覆盖率有所提高，但仍不完整。根据近期测量，大约 40–50% 的 IPv4 前缀 拥有有效 ROA；IPv6 的比例相近或略高。
然而， 在路由器上主动执行 ROV 的网络更少 。例如，Cloudflare 持续提供关于 “起源签名”与“起源验证”采用情况的数据。
签名与验证之间的差异构成 关键缺口：只有双方都积极参与，保护机制才会发挥作用。
运营顾虑：误报与连接中断
部分运营商犹豫的原因之一是 担心误报：配置错误的 ROA 可能把合法通告标记为无效，导致路由被意外丢弃。
运营商还可能担心， 强制拒绝无效路由 会使其无法访问某些目的地。应对这些风险需要 周密规划、渐进部署和备用策略。
依赖方和存储库漏洞
近期研究发现了 RPKI 验证器软件中的漏洞 。例如， CUREanalysis 发现的缺陷可能导致 路由投毒 或使验证逻辑失效。
另一类攻击Stalloris展示了攻击者如何 阻断从存储库获取数据，迫使路由器在不安全状态下运行。
2024 年的一项系统性研究指出， 全球 56% 的 RPKI 验证器 至少存在一项有记录的漏洞。
为缓解这些问题而提出的一项方案是 Byzantine-secure relying party（BRP），其目标是 分散验证并提高韧性。
策略碎片化与实施不一致
关于 ROA 与验证 的逻辑在 RFC 中包含含糊或规定不足的情况，导致不同实现出现 行为差异 。
一些网络严格执行过滤，一些只做监控，还有一些根据前缀类别进行部分执行。
由于路由具有全球性， 不一致的策略会削弱安全收益。如果只有部分路由器丢弃无效路由，恶意通告仍可能通过更宽松的路径传播。
可扩展性、自动化与工具
一些运营商把 易用性、复杂度和工具不足 列为障碍。ROA 管理自动化、验证器缓存同步以及与路由平台集成，仍然充满挑战。
此外， 依赖 rsync 同步存储库被部分专家视为不安全或效率低下，因此有人提议 优先使用 RRDP。
一些网络会推迟 签发 ROA ，直到验证得到广泛采用；但这会 延续采用缓慢的局面。
运营商部署 RPKI 的最佳实践
从监控模式开始
先以被动方式部署 ROV ，只标记无效路由而不丢弃。在正式执行策略前，先监控非预期的无效情况。
谨慎设计 ROA
采用保守的 maxLength 设置。避免前缀范围过宽或限制过严，以免意外使合法通告失效。
渐进执行与备用路由
只有在充分观察并准备好备用路由后，才开始拒绝无效路由。应逐步执行验证。
稳健的验证器基础设施
使用 多个验证器实例，选择可靠软件，监控缺口，并考虑采用 BRP等高韧性系统。
保持 ROA 和验证器数据最新
频繁同步，监控存储库故障，并在数据过时时确保有相应缓解措施。
与对等网络和上游协调
鼓励路径上的其他参与者执行验证。更多网络参与会增强整体收益。
关注 MANRS 等社区倡议
诸如 路由规范指南 等标准可以补充 RPKI 的采用。
定期审计和更新
定期检查 ROA。AS 所有权变更、合并或 IP 重新分配都需要及时更新。
“网络效应”困境与激励
一个主要障碍是， 只有许多网络都执行验证时，收益才会显现。如果运营商进行了签名，但其对等方没有验证，它获得的保护就会更少。相反， 强制执行验证 可能会中断与不合规网络的连接，从而拖慢部署。
有人认为， 监管或行业激励 可能有所帮助。另一些人则从经济角度指出，提供 “安全传输” 服务的网络运营商可以在执行 ROV 时收取溢价。内容提供商还可以出于安全考虑，要求托管提供商 符合 ROV 。
此外还有 法律方面的担忧。一项有关法律障碍的研究指出，只要 RIR 遵循 IETF 标准，法院通常不会认定 RPKI 证书存在缺陷。
主要限制与残余风险
即使具备 完美的起源验证，RPKI 也无法阻止所有 BGP 攻击：
路径操纵：RPKI 不验证每一个 AS 跳点；攻击者仍可伪造 AS 路径。这需要通过 BGPsec解决，但该机制目前基本尚未部署。
降级攻击与存储库干扰：如果攻击者阻断 RPKI 存储库或阻止验证器访问，网络可能退回不安全的路由方式。
验证器软件漏洞：近期 CURE 审计表明，错误可能导致 错误验证或路由投毒。
策略执行不完整或不一致：如果互联网的一部分既不签发 ROA，也不执行相关策略，无效路由仍可能通过 宽松路径。
运营错误：ROA 配置错误或未及时更新都可能造成 附带损害。
因此，RPKI 是一项 重要改进，但并非完整解决方案。只有与其他措施结合时，它才能充分发挥价值，例如 路由过滤、对等网络层面的规范，以及最终实现的完整路径验证系统。
前行方向：还需要完成什么
验证器韧性与去中心化：广泛采用稳健架构，例如 BRP，以减少对单点故障的依赖。
改进工具与自动化：提供更高效的界面、与路由系统的集成、告警，以及用于管理 ROA 生命周期的工具。
社区协调与激励：对等网络、 IXP 和运营商签署相互协议，甚至把符合 ROV 作为互联条件。
提高认知与培训：许多 ISP 和网络团队仍然不熟悉 RPKI。
部署补充标准： ASPA、 BGPsec 及相关标准需要继续成熟并实现真正采用。
如果这些要素能够协同， 互联网路由基础设施 将随着时间推移更有能力抵御劫持和泄漏。
常见问题：RPKI 与路由安全
路由被宣布为“无效”意味着什么？
如果 BGP 通告依据 ROV 被判定为无效，也就是没有任何 ROA 覆盖它，或起源 AS 不匹配，路由器可以 丢弃它、降低其优先级或为其设置较低的偏好。一个前缀可以拥有多个 ROA 吗？
可以。同一个前缀可以存在 多个 ROA ，并对应不同的有效起源 AS。验证逻辑必须谨慎处理 并集或冲突。RPKI 能保证完整的路由安全吗？
不能。RPKI 只提供 起源保证，不验证完整路径。攻击者仍可 伪造 AS 路径 或制造其他异常。如果验证器数据过时或无法访问，会发生什么？
路由器可能会 把通告视为未知 ，也就是允许其通过。但如果连接出现故障，这一机制可能被利用为降级攻击向量。小型网络或内容提供商如何采用 RPKI？
它们可以使用 托管 RPKI 服务 ，相关服务由其 ISP 或 RIR 提供。即使不运行自己的验证器，它们仍然可以 签发 ROA 并表明起源授权。
