谁在运营那些小型RPKI服务器？

背景

Border Gateway Protocol (BGP) 是互联网的“粘合剂”，它指导路由器将数据包发送到全球任意 IP 地址。然而，BGP 在设计之初假设所有网络相互信任，缺乏内置的认证机制。这使得互联网路由层容易遭受意外或恶意的前缀劫持（prefix hijack）：任何网络都可以（有意或无意地）声称自己拥有实际上并不控制的 IP 前缀，导致用户流量被静默重定向到错误目的地。

Resource Public Key Infrastructure (RPKI) 正是为了解决这一问题而提出的方案。它允许 IP 地址空间的合法持有者通过密码学方式签署一条 Route Origin Authorization (ROA)，该记录明确声明：“IP 前缀 X 仅允许由自治系统编号 Y 进行宣告”。部署了 Route Origin Validation (ROV) 的路由器会利用这些签名记录检查收到的 BGP 更新，并丢弃不匹配的宣告。

整个 RPKI 体系依赖于一条信任链，其锚点是全球五大区域互联网注册机构（RIRs）：ARIN（北美）、RIPE NCC（欧洲/中东/中亚）、APNIC（亚太）、LACNIC（拉丁美洲）和 AFRINIC（非洲）。这些机构负责分配 IP 地址空间，并运行顶级 RPKI 认证机构（CA）。ROA 对象可以直接从 RIR 的服务器发布，也可以由更小型的独立发布服务器发布。

虽然大多数 ROA 对象由五家 RIR 直接发布，但有一长尾小型、独立运行的发布服务器（由云服务商、ISP、爱好者、教育机构以及 RPKI as a Service 公司运营）也对全球 RPKI 数据集做出了贡献。本文旨在调查这些小型服务器由谁运营、为何运营。

核心内容

定义“小型”服务器

研究面临的首要方法挑战是如何界定“小型”服务器。研究者采用了一个基于 ROA 数量的直接定义：如果一个服务器宣告的 ROA 对象少于 1300 个，则将其归类为“小型”。这个阈值是通过观察所有已知 RPKI 服务器的 ROA 计数经验累积分布函数（ECDF）得出的。分布严重倾斜：少数大型提供商（五家 RIR 和 Amazon Web Services）占据了绝大多数 ROA。1300 ROA 的截断点恰好捕捉了这些大型角色与其他服务器之间的自然分界。

一个显著例外：Amazon Web Services 的 RPKI RRDP 服务器。亚马逊构建其 RPKI 发布基础设施的方式不寻常，其架构与其他小型服务器明显不同，因此被排除在研究范围之外。这种构建是否具有运营优势仍是一个待解答的问题。

为何有人要运行自己的 RPKI 服务器？

小型服务器的存在自然引出一个问题：为什么还要费心自己运行？RIR 作为会员服务的一部分已经提供了发布功能。答案是存在几条合理的独立运营理由。下表列举了几个例子（原文提供了表格，此处概括主要理由）：

• 对 RIR 发布服务的不信任：部分组织希望完全控制自己的 ROA 发布，避免依赖 RIR 的可用性或信任模型。
• 对 RIR 功能不满：例如需要更灵活的 ROA 管理、更快的更新速度，或自定义的验证流程。
• 测试与教育：爱好者、大学或研究机构为了学习 RPKI 内部机制而搭建实验性服务器。
• 商业服务：RPKIaaS 公司为客户提供托管式 RPKI 基础设施，需要自己运行发布服务器。
• 规避滥用举报：垃圾邮件运营者可能通过独立服务器增加 RIR 下架链路的摩擦。

数据集：IP 空间统计

研究者使用 Routinator API（版本 0.15.1）在 2026 年 4 月 23 日 从每个符合条件的发布服务器获取了所有 ROA 对象。最终数据集包含 2467 个唯一 ROA，覆盖 3778 个前缀，涉及 1163 个唯一 AS。关键数字如下：

| 指标 | 数值 | |------|------| | 覆盖的 IPv4 地址数 | 698,000（占全部 IPv4 地址的 0.016%） | | 覆盖的 IPv6 地址数 | （原文未给出具体数字，仅提及“看起来很小但并非微不足道”） | | 包含政府服务的前缀 | 例如 gov.ai（安圭拉政府官方域名） | | 未知 ROA 对象（未通过加密验证） | 所有未知对象均无活跃 BGP 宣告——这是好消息，否则这些前缀将面临 BGP 劫持风险。 |

服务器概况与异常案例

下表（原文中 Table 3 的摘要）展示了部分服务器的统计信息。我们重点讨论几个表现出异常行为的服务器。

r.magellan.ipxo.com：最大且最复杂

由 IPXO 公司运营的 Magellan 服务器拥有 776 个前缀，是数据集中最大的小型服务器。全部为 IPv4，100% BGP 可达，但其中 103 个前缀 被标记为“有风险”（At-Risk），原因是其 maxLength 设置过于宽泛，未对授权范围内的全部子前缀进行 BGP 宣告覆盖。

repo.rpki.space：垃圾邮件基础设施

该服务器仅 79 个前缀，却命中了 8 个 Firehol level 1 黑名单。进一步检查 BGP Tools DNS 记录发现，该服务器涉及大量邮件域名，强烈暗示这些前缀托管了垃圾邮件发送基础设施。垃圾邮件运营者自己运行 RPKI 服务器的潜在原因：RIR 有活跃的滥用预防程序，独立发布服务器为下架过程增加了一道操作阻力，给滥用举报者制造额外摩擦。

ca.nat.moe：99 个未知对象

该服务器是显著的异常值：其全部 99 个 ROA 对象 的验证状态均为“未知”（unknown），意味着所有 99 个都未能通过密码学验证。尽管如此，在这些（有效对象的）统计中，100% BGP 可达，且 64 个使用了 maxLength。

rpki-01.pdxnet.uk：maxLength 谜题

该服务器宣布其几乎一半的前缀的 maxLength 设置为 32（IPv4）或 128（IPv6）——即最大可能前缀长度。这意味着所宣告范围内的每一个 IP 地址都被正式授权。实际上，这无法被利用：BGP 不接受比 /24（IPv4）或 /48（IPv6）更具体的路由，而底层前缀本身已经处于这些限制边界上。这种不寻常配置的原因仍不清楚。

IP 空间的来源

最有趣的结构性发现之一涉及小型服务器宣告前缀的 RIR 来源。当组织决定独立运营一个小型 RPKI 发布服务器时，他们通常从自身的 IP 地址分配中选取前缀。数据表明，这些前缀绝大多数来自 RIPE NCC 和 ARIN 分配的空间，其次是 APNIC，LACNIC 和 AFRINIC 比例较小。这一分布与互联网基础设施运营商的全球分布大致相符，但具体比例仍有待进一步分析（原文在此处因截断未能完整展开）。

关键要点

• 定义标准：研究将“小型” RPKI 发布服务器定义为宣告 ROA 对象少于 1300 个的服务器，以区别于五家 RIR 和 AWS 这样的大型参与者。
• 数据规模：截至 2026 年 4 月 23 日，共发现 2467 个 ROA（来自小型服务器），覆盖 3778 个前缀，涉及 1163 个 AS；IPv4 空间覆盖约 0.016%，虽小但包含政府服务等关键资源。
• 关键异常案例：
  • r.magellan.ipxo.com：最大（776 前缀），但存在 maxLength 过度授权问题。
  • repo.rpki.space：高比例 Firehol 黑名单命中（8/79），与垃圾邮件基础设施强相关。
  • ca.nat.moe：全部 99 个对象验证失败，但仍有 100% BGP 可达，说明存在 ROA 签名但未被路由验证系统正确接受。
  • rpki-01.pdxnet.uk：设置最大前缀长度（/32 或 /128），实际无法被 BGP 利用，原因未知。
• **IP