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

# 谁在运行那些微型 RPKI 服务器？ | APNIC 博客 来源: https://blog.apnic.net/2026/07/15/whos-running-all-those-tiny-rpki-servers/ 边界网关协议 (BGP) 缺乏内置的信任机制，使得互联网路由层容易遭受意外或恶意的前缀劫持。资源公钥基础设施 (RPKI) 通过让地址空间持有者以加密方式授权哪个自治系统 (AS) 可以宣告其前缀，来解决这个问题，该授权通过路线来源授权 (ROA) 实现，并经由以五个区域互联网注册机构 (RIR) 为锚点的信任链发布。 虽然大多数 ROA 由 RIR 直接发布，但还有一长串规模较小、独立运营的发布服务器（由云提供商、ISP、爱好者、教育机构和 RPKI 即服务 (RPKIaaS) 公司运营）也为全球 RPKI 数据集做出了贡献。在这篇文章中，我们调查了谁在运营这些小型服务器以及原因。 ## 什么是 RPKI，为什么你应该关心？ 每次你打开一个网站，你的流量都会在 BGP 的引导下跳转数十个路由器。BGP 是互联网的粘合剂：它告诉路由器应该将数据包发送到哪里，以到达地球上的任何 IP 地址。问题在于，BGP 是为一个网络相互信任、不当行为仍不常见的时代设计的。任何网络都可以（意外地或恶意地）宣告它拥有一个它实际上并不控制的 IP 前缀。这被称为路由事件，它可能导致你的流量被悄悄重定向到错误的目的地。 RPKI 是互联网（之一）针对这个问题的解决方案。它的工作原理是让 IP 地址块的合法所有者加密签署一个 ROA；这是一个小型记录，说明：“IP 前缀 X 被授权由自治系统编号 (ASN) Y 宣告。”实施路由来源验证 (ROV) 的路由器随后使用这些已签署的记录来检查传入的 BGP 公告，并丢弃不匹配的公告。 整个系统建立在以五个区域互联网注册机构 (RIR) 为锚点的信任链上：ARIN（北美）、RIPE NCC（欧洲/中东/中亚）、APNIC（亚太地区）、LACNIC（拉丁美洲）和 AFRINIC（非洲）。这些机构向网络分配 IP 地址空间，并运行顶级 RPKI 认证机构 (CA)。ROA 对象可以直接从 RIR 服务器发布，也可以从较小的独立发布服务器发布。 ## 小型 RPKI 发布服务器 大多数 ROA 对象由五个 RIR 发布，这些机构资源充足、专业维护且全球信任。但与这些巨头并存的，是一长串由云提供商、爱好者、教育机构、互联网服务提供商 (ISP) 和 RPKIaaS 公司运营的小型发布服务器。在这篇文章所述的研究中，我们检查了这些“小型”服务器，以了解我们可以从它们身上学到什么，它们为何运营，以及它们最初存在的原因。 ## 定义“小型” 第一个方法论挑战是定义什么使服务器成为“小型”。我们使用了一个直接的、基于 ROA 数量的定义： > 如果服务器宣布少于 1,300 个 ROA 对象，则将其归类为“小型”。 这个阈值是通过检查所有已知 RPKI 服务器上 ROA 数量的经验累积分布函数 (ECDF) 来选择的。分布高度偏斜：少数大型提供商（五个 RIR 和 Amazon Web Services (AWS)）占据了大部分 ROA。1,300 个 ROA 的截断点捕捉到了这些大型参与者与其余服务器之间的自然断裂点。 **一个值得注意的排除项：** AWS RPKI 存储库增量协议 (RRDP) 服务器。亚马逊构建其 RPKI 发布基础设施的方式不同寻常。它们的架构与其他小型服务器有明显区别，因此未纳入研究范围。这种构建方式是否具有运营优势，仍有待未来研究探讨。 ## 为什么有人会运行自己的 RPKI 服务器？ 小型服务器的存在自然引出一个问题：何必呢？RIR 已经作为会员服务的一部分提供了发布服务。答案是，独立运营有几个合理的理由；下表列出了一些示例。 **理由****解释****RPKIaaS**将 RPKI 作为托管服务提供，具有统一的 REST API，使客户能够自动化资源管理，而无需直接与 RIR 门户交互或处理多个 API。**跨 RIR 简化**拥有来自多个 RIR（例如 ARIN 和 RIPE）的 IP 分配的组织，可以从单一界面更新其所有 ROA，而无需在每个注册机构维护账户。**研究与教育**学术机构和爱好者可以运行 Krill（NLnet Labs 的开源 CA 软件）来试验 RPKI、测试配置或为部署研究做出贡献。**运营控制**完全控制发布计划、对象签名和基础设施，适用于具有严格安全要求或自定义路由设置的组织。**乐趣/学习**运行自己的 RPKI 服务器是加深你对互联网路由基础设施理解的合理方式。数据集中许多最小的服务器似乎是个人或爱好设置。表 1 — 运营独立 RPKI 发布服务器的理由。## 数据集：IP 空间统计 使用 Routinator API（版本 0.15.1），我们获取了截至 2026 年 4 月 23 日来自每个符合条件的发布服务器的所有 ROA 对象。生成的数据集包含 2,467 个唯一 ROA，覆盖 1,163 个唯一 AS 的 3,778 个前缀。表 2 总结了关键数字。 Valid (有效): 存在至少一个经过验证的 ROA 载荷 (VRP) 覆盖所宣告的前缀（相同或更少特定，在最大长度内），且来源 AS 匹配。 Invalid (无效): 存在一个 VRP 覆盖该前缀空间，但 VRP 中的部分信息不正确，或对象已过期。 Unknown (未知): 未找到 VRP，或者找到了不正确的 VRP 且已被丢弃。 **指标****值****备注**具有 ROA 覆盖的 IPv4 前缀**1,409**覆盖约 698,000 个独立地址具有 ROA 覆盖的 IPv6 前缀**2,369**覆盖天文数字般的地址范围IPv4 在互联网中的占比**0.0162%**微小但不可忽视的一部分分析的 ROA 对象总数**3,778**跨越 1,163 个唯一 AS有效 ROA 对象**3,444 (91%)**通过加密验证无效 ROA 对象**48 (1.2%)**未通过加密验证未知**286 (7.6%)**排除在进一步分析之外使用 maxLength 的 ROA**53.98%**设置的 maxLength 小于前缀的设定比特位数使用 maxLength 但无 BGP 覆盖的 ROA**19.6%**可能面临子前缀劫持风险表 2 — 小型 RPKI 服务器数据集的关键统计（2026 年 4 月 23 日收集的数据）。有几个数字很突出。覆盖的 IPv4 空间（698,000 个地址，占所有 IPv4 地址的 0.016%）和 IPv6 空间（地址或百分比）看起来都很小，但这远非无关紧要。该数据集包括托管政府服务（例如 `gov.ai`，安圭拉政府的官方域名）以及人们日常依赖的其他服务的前缀。这些服务器的故障不会破坏互联网，但可能会悄悄使部分互联网对于某些用户而言无法验证。 没有未知的 ROA 对象具有活跃的 BGP 公告。这是个好消息，因为这表明相关前缀容易受到 BGP 劫持的影响。 ## 数字背后：服务器概览 表 3 浓缩了研究中的每服务器统计信息。每行代表一个发布服务器，列显示前缀计数、有效性细分、maxLength 使用情况、BGP 可达性和 Firehol 阻止列表重叠。下面显示了几行作为示例。 服务器前缀有效无效未知最大长度BGP %有风险Fireholr.magellan.ipxo.com776755183164100%1034cloudie-repo.rpki.app5045040042480.8%1472rpki.admin.freerangecloud.com4764760048100%280rpki.sub.apnic.net390254281089198.2%274krill.47272.net3883880014396.6%690rpki.roa.net1561560094100%730rsync.rp.ki1501500010498.7%810krill.peering.ee.columbia.edu133129041100%10rpki-01.pdxnet.uk1211210081100%40ca.nat.moe99009964100%750repo.rpki.space7979003375.9%138krill.accuristechnologies.ca454500388.9%10rpki.axivora.net440044897.7%60rpki.cc4242001492.9%70rpki.apernet.io371801910100%60 表 3 — 分析的 RPKI 发布服务器浓缩概览（按前缀数量排序的前 15 个）。‘有风险’ = 已授权子前缀没有对应 BGP 公告的 maxLength ROA。 在本节的其余部分，我们将指出一些表现出奇怪行为的服务器，并描述它们表现出的不常见行为。 ### r.magellan.ipxo.com: 最大且最复杂 拥有 776 个前缀，由公司 IPXO 运营的 Magellan 服务器是数据集中最大的。所有 776 个都是 IPv4，并且 100% BGP 可达，但由于设置了宽泛的 maxLength 而没有完全 BGP 覆盖授权范围，因此有 103 个被标记为有风险。 ### repo.rpki.space: 垃圾邮件基础设施 在仅有的 79 个前缀中，有 8 个 Firehol 级别 1 阻止列表匹配，`repo.rpki.space` 立即脱颖而出。检查此服务器的 BGP Tools DNS 记录发现，邮件域名密度很高，强烈表明垃圾邮件发送基础设施托管在相关前缀上。垃圾邮件运营商运行自己 RPKI 服务器的一个潜在原因是——RIR 有活跃的滥用预防程序，拥有独立的发布服务器在移除链中增加了一个额外的步骤；为滥用举报者增加了一层运营摩擦。 ### ca.nat.moe: 99 个未知对象 该服务器是一个显著异常值：其全部 99 个 ROA 对象的状态均为未知有效性，意味着所有 99 个都未能通过加密验证。尽管如此，在有效对象中，100% BGP 可达，64 个使用了 maxLength。 ### rpki-01.pdxnet.uk: maxLength 谜题 该服务器将近一半的前缀设置了 maxLength 为 32（IPv4）或 128（IPv6）——即最大可能的前缀长度。这意味着宣告范围内的每个 IP 地址都正式获得了授权。实际上，这并不可利用：BGP 不接受比 /24（IPv4）或 /48（IPv6）更具体的前缀，而底层前缀已经处于这些限制。这种不寻常配置的原因仍未得到解释。 ## IP 空间从何而来？ 最有趣的结构性发现之一涉及小型服务器宣告的前缀的 RIR 来源。当一个组织在自己的服务器上发布 ROA 时，一个自然的期望可能是它拥有跨 RIR 的分配（来自多个注册机构的 IP 空间），这将使单一发布点变得方便。数据讲述了一个更微妙的故事。 服务器ARINRIPEAPNICLACNICAFRINICr.magellan.ipxo.com✓cloudie-repo.rpki.app✓✓rpki.admin.freerangecloud.com✓✓✓rpki.sub.apnic.net✓✓✓krill.47272.net✓✓rpki.roa.net✓✓✓✓rsync.rp.ki✓✓✓krill.peering.ee.columbia.edu✓rpki-01.pdxnet.uk✓✓ca.nat.moe✓repo.rpki.space✓✓krill.accuristechnologies.ca✓✓rpki.axivora.net✓rpki.cc✓rpki.apernet.io✓✓rpki-repo.as207960.net✓rpki.sunoaki.net✓rpki.pudu.be✓✓ 表 4 — 每个发布服务器的 RIR 来源存在情况（浓缩的前 18 个服务器）。勾选标记表示该服务器 ROA 集中至少存在一个来自该 RIR 的前缀。 相当大比例的服务器仅宣告来自单个 RIR（主要是 RIPE）的前缀。对于仅从 RIPE 获取前缀的服务器而言，运行自定义服务器最令人信服的理由之一（避免管理多个 RIR 账户）并不适用。 ## maxLength 问题 数据集中超过一半的 ROA 对象（53.98%）使用了 maxLength 参数来授权宣告比 ROA 中列出的前缀更具体的子前缀。RFC 9319 明确不鼓励这种做法。 一个针对 `103.0.0.0/22` 且 maxLength 为 /24 的 ROA 不仅授权了 /22；它还授权了该区块内的每个 /23 和 /24，即 `103.0.0.0/24` 到 `103.0.3.0/24`，无需为每个子前缀单独创建 ROA。从 BGP 的角度来看，最具体的匹配前缀获胜。因此，如果控制授权 ASN 的攻击者（原则上）宣告了 `103.0.0.0/24`，每个依赖方都会将其标记为有效。宽泛的 ROA 已经授权了劫持（如果没有更快的竞争性 BGP 公告，并且该公告是 RPKI 有效的）。 在设置了宽泛 maxLength 的 ROA 中，大约 80% 已经有现有的 BGP 公告覆盖了更具体的子前缀，这意味着在大多数情况下实际风险是有限的。 然而，剩余的 19.6% 没有 BGP 公告覆盖授权的子前缀。这些代表潜在的风险配置：使用 ASN 合法来源的子前缀劫持可以不受挑战地通过 RPKI 验证（同样，如果没有更快的竞争性 BGP 公告，并且该公告是 RPKI 有效的）。 修复方法原则上很简单——为你打算宣告的每个前缀创建一个单独的 ROA，并将 maxLength 设置为等于前缀长度本身。缺点是这会显著增加 ROA 数量——恰恰与 maxLength 旨在提供的聚合优势相反。 ## BGPsec BGPsec 是一种方法，用于验证宣告的 BGP 路由是否已由其路径中的每个 AS 进行了加密验证。这意味着 BGPsec 验证宣告路径中的每个 AS 是否都同意该路径是有效的。尽管 BGPsec 自 2017 年以来已标准化，但我们发现（不仅在数据集中）BGPsec 根本没有部署（只有一个 AS 宣告其路由密钥），Lisa Bruder 在她的博文中也指出了这一点：BGPsec – 如果你愿意，你能运行它吗？ ## 来自一位运营者的话 我们已经联系了其中一家较大的运营者（Axivora，它运营 `rpki.cc`、`krill.accuristechnologies.ca` 和 `rpki.folf.systems`），以了解他们为何运行自己的 RRDP 通知服务器，并得到了以下回复： > 简短的回答是，我们最初开始运行自己的 RPKI 发布基础设施，是因为我们（现在仍然是）互联网爱好者，想要了解该系统实际上是如何工作的。 Axivora 仍然租用两个专用的 IPv6 PA /40 分配用于教育和研究目的。在这些前缀内，他们将较小的分配委托给希望拥有自己独立地址空间的个人。他们为他们处理创建相应 ROA 和 IRR 记录的后勤工作，并消除了他们运营自己 ASN 的需求。 运行自己发布基础设施的初衷是为了更好地理解 RPKI 生态系统，并了解 ROA 如何通过互联网传播。 如今，他们所有的商业前缀都使用 RIPE 的 PaaS 服务，但他们仍然继续运营自己的发布服务器，用于研究、教育和实验目的。 > 而且，坦