现在，我们将介绍 Cloudflare Radar 的路由泄漏数据和 API，让任何人都能获得整个互联网上的路由泄漏信息。我们构建了一个全面的系统，可获取公共来源的数据，以及 Cloudflare 基于我们巨大的全球网络总结的互联网观点。该系统现在正通过 API，在 Cloudflare Radar 的 ASN 页面上提供路由泄漏数据。
本篇博客文章包括两部分。首先讨论了 BGP 和路由泄漏问题，然后详细介绍我们的路由泄漏检测系统，以及它如何为 Cloudflare Radar 提供信息。
关于 BGP 和路由泄密
域间路由，即在网络间交换可达性信息，对互联网的安全和性能至关重要。边界网关协议 (BGP) 实际上是路由协议，交换各组织和网络间的路由信息。BGP 的核心基础是假设交换的信息均真实无误、值得信任，但不幸的是，就当前的互联网而言，这个假设不再有效。在许多情况下，网络可能会犯错或故意谎报可达性信息，并传播到互联网其他地方。这类事件会对互联网的正常运行造成重大干扰。这种破坏性事件有多种类型，包括路由泄漏。
我们认为，路由泄漏是指路由公告的传播超出了其预定范围 (RFC7908)。过去的许多著名事件告诉我们，路由泄漏可能会造成重大破坏，影响数百万互联网用户。例如，2019 年 6 月，美国宾夕法尼亚州一个小型网络的错误配置 (AS396531 - Allegheny Technologies Inc) 意外地将一个 Cloudflare 前缀泄露给了 Verizon，Verizon 又将错误配置的路由传播给其他对等点和客户。结果，互联网的大部分流量都挤压在一个小型网络有限的链接容量中，导致网络拥塞，受影响 IP 范围的大部分 Cloudflare 流量均被阻止。
2018 年 11 月发生了一起类似事件，尼日利亚 ISP (AS37282-Mainone) 违反无谷底原则，意外泄露了大量 Google IP 前缀给其对等点和提供商，导致 Google 服务大范围不可用。
这些事件不仅说明路由泄漏会造成严重影响，也说明小型区域网络的错误配置会产生滚雪球效应，影响全球互联网。
及时发现和纠正路由泄漏至关重要，但往往只有用户开始报告明显的泄漏影响时才会发现泄漏。检测和防止路由泄漏极具挑战，因为 AS 业务关系和 BGP 路由策略通常未公开，而且受影响的网络往往远离路由泄漏根源。
过去几年中提出了许多解决方案来防止泄露的路由继续传播。这类建议包括 RFC9234和 ASPA，让 BGP 可以使用两个互联 AS 网络之间的关系类型来注释会话，以限制和预防路由泄露。
实施 BGP 角色类似信号的另一个建议是使用 BGP 社区——BGP 公告中用于编码元数据的可传递属性。虽然从长远来看，这些建议可能有用，但它们尚处于非常初步的阶段，预计无法在短期内大规模采用。
在 Cloudflare，我们开发了一个系统来自动检测路由泄漏事件，并将通知发送到多个渠道，以提高可见性。随着我们继续努力为公众提供更相关的数据，我们很高兴地宣布，今天将启动一个开放数据 API 专门提供我们的路由泄漏检测结果，并将结果集成到 Cloudflare Radar 页面。
路由泄漏的定义和类型
介绍我们的系统设计之前，我们先快速了解一下什么是路由泄漏，以及为什么必须检测路由泄漏。
我们参考了已发布的 IETF RFC7908 文件 《BGP 路由泄漏的问题定义和分类》，来定义什么是路由泄漏。
> 路由泄漏是指路由公告的传播超出了其预定范围。
_预定范围_的具体定义通常是指基于自治系统 (AS) 之间业务关系的域间路由策略。这些业务关系大致分为四类：客户、中继提供商、对等点和兄弟，但可能还有其他更复杂的安排。
在客户-提供商关系中，客户 AS 与另一个网络达成了协议，将其流量传递到全球路由表。在对等关系中，两个 AS 同意自由进行双边流量交换，但只在他们自己的 IP 和客户的 IP 之间交换。最后，属于同一管理实体的 AS 视为兄弟关系，它们之间的流量交换通常不受限制。下面的图片说明了三种主要的关系类型如何转化为出口策略。
通过对 AS 级关系的类型及其对 BGP 路由传播的影响进行分类，我们可以定义传播过程中前缀发起公告的多个阶段。
上行：这一阶段的所有路径段都是客户到提供商
对等互连：点对点路径段
下行：这一阶段的所有路径段都是提供商到客户
遵循无谷底路由原则的 AS 路径将包括上行、对等互连、下行等阶段，所有阶段均为可选阶段，但必须按照该顺序。符合无谷底路由的 AS 路径的示例如下。
在 RFC7908 文件《BGP 路由泄漏的问题定义和分类》中，作者定义了六种路由泄漏类型，我们在系统设计中参考了这些定义。下面分别介绍每种路由泄漏类型。
第 1 类：带有完整前缀的发夹弯
> 多宿主 AS 从上游 ISP 获得了一条路由，并简单地将其传播给另一个上游 ISP（这个弯基本上就像一个发夹）。更新中的前缀和 AS 路径都不会改变。
包含提供商-客户和客户-提供商段的 AS 路径为第 1 类泄漏。例如：AS4→AS5→AS6 属于第 1 类泄漏。
第 1 类泄漏是最广为人知的路由泄漏类型，会产生严重影响。在许多情况下，客户路由比对等点或提供商路由更可取。在这个示例中，AS6 可能更愿意通过 AS5 而非其他对等点或提供商路由发送流量，导致 AS5 无意中成为一个中继提供商。这可能会大大影响与泄漏前缀有关的流量的性能，而如果泄漏的 AS 配置无法处理大量的流量涌入，则会导致中断。
2015 年 6 月，区域 ISP Malaysia Telekom (AS4788) 将来自提供商和对等点的超过 170,000 条路由泄露给了另一个提供商 Level3（AS3549，现名 Lumen）。Level3 接受了这些路由，并将它们进一步传播到其下游网络，进而给全球网络造成了严重问题。
第 2 类：ISP-ISP-ISP 横向泄漏
第 2 类泄漏的定义为将从对等点获得的路由传播给另一对等点，创建两个或多个连续的点对点路径段。
例如：AS3→AS4→AS5 属于第 2 类泄漏。
这类泄漏的示例包括依次出现三个以上的非常大型的网络。非常大型的网络（例如 Verizon 和 Lumen）不会相互从对方购买中继，如果路径中依次出现三个以上的此类网络，往往表明存在路由泄漏。
然而，在现实世界中，多个小型对等网络交换路由并相互传递的情况并不罕见。这类网络路径存在合法的商业理由。与第一类相比，我们不太担心这类路由泄漏。
第 3 类和第 4 类：提供商路由到对等点；对等点路由到提供商
这两类泄露涉及到从一个提供商或对等点向另一个对等点或提供商（而不是向客户）传播路由。下面介绍这两类泄漏：
在前面提到的例子中，Google 的对等点尼日利亚 ISP 不小心将其路由泄露给了其提供商 AS4809，这属于第 4 类路由泄漏。由于通过客户的路由通常比其他路由更可取，因此，大型提供商 (AS4809) 通过其客户（即泄漏的 ASN）将其流量重新路由到 Google，压垮了这家小型 ISP，并导致 Google 瘫痪了一个多小时。
路由泄漏总结
现在，我们已经了解了 RFC7908 中定义的四类路由泄露。这四类路由泄漏的共同点是，它们都是使用 AS 关系（即对等点、客户和提供商）定义的。我们根据路由来自哪里和传播到哪里，对 AS 路径传播进行分类，总结泄漏类型。结果如下表所示。
路由来自/传播到
| Routes from / propagates to | To provider | To peer | To customer |
|---|---|---|---|
| From provider | Type 1 | Type 3 | Normal |
| From peer | Type 4 | Type 2 | Normal |
| From customer | Normal | Normal | Normal |
到提供商
到对等点
到客户
来自提供商
第 1 类
第 3 类
正常
来自对等点
第 4 类
第 2 类
正常
来自客户
正常
正常
正常
整个表格可以总结为一条规则：来自非客户 AS 的路由只能传播给客户。
注：第 5 类和第 6 类路由泄露的定义为前缀重发和公布私有前缀。第 5 类与前缀劫持更密切相关，我们的系统下一步计划将解决此类泄漏，而第 6 类泄漏则不在此限。有兴趣的读者可以参考 RFC7908 第 3.5 和 3.6 节了解更多信息。
Cloudflare Radar 路由泄漏系统
现在我们知道了什么是路由泄漏，接下来谈谈我们的路由泄漏检测系统是如何设计的。
从非常高的层面来看，我们的系统可以分为三个不同的组成部分。
原始数据收集模块：负责从多个来源收集 BGP 数据并向下游消费者提供 BGP 消息流。
泄漏检测模块：负责确定给定的 AS 级路径是否为路由泄漏，估计评估的置信水平，汇总并提供进一步分析事件所需的所有外部证据。
存储和通知模块：负责提供对检测到的路由泄漏事件的访问权限，并向有关方发送通知。这也可以包括构建一个仪表板，以方便访问和搜索历史事件，并提供对事件进行高级分析的用户界面。
数据收集模块
我们考虑了三类数据输入：
历史：BGP 将过去某个时间范围内的文件存档a. RouteViews 和 RIPE RIS 存档文件
半实时：文件一旦可用 BGP 便会立即存档，仅有 10-30 分钟的延迟。a. RouteViews 和 RIPE RIS 档案中的数据代理会定期检查新文件（例如：BGPKIT 代理）。
实时：真正的实时数据源a. RIPE RIS Liveb. Cloudflare 内部 BGP 来源
对于当前版本，我们使用检测系统的半实时数据源，即来自 RouteViews 和 RIPE RIS 的 BGP 更新文件。为了保证数据的完整性，我们对这两个项目的所有公共采集器（共 63 个采集器和 2400 多个采集器对等点）的数据进行了处理，并实施了一个能够在数据文件可用时处理 BGP 数据的管道。
为索引和处理数据文件，我们部署了一个本地 BGPKIT Broker 实例，并启用了传递消息的 Kafka 功能，以及一个基于 BGPKIT Parser Rust SDK 的自定义并发 MRT 数据处理管道。数据收集模块处理 MRT 文件，并将结果转换为每天超过 20 亿条 BGP 消息（大约每秒 30,000 条消息）的 BGP 消息流。
路由泄漏检测（Route Leak Detection）
路由泄漏检测模块是在各个 BGP 公告层面起作用。检测组件一次调查一条 BGP 消息，并估计给定 BGP 消息是路由泄漏事件导致的的可能性。
我们的检测算法主要基于无谷底模型，我们认为该模型可以捕捉到大多数值得注意的路由泄露事件。如前所述，使用无谷底模型检测路由泄漏的误报率低，关键是因为有准确的 AS 级关系。虽然并不是每个 AS 都会公布这些关系类型，但使用公开观察的 BGP 数据推断关系类型已有超过 20 年的研究经验。
虽然研究已证明，最先进的关系推理算法高度准确，但即使很小的误差范围仍然会导致路由泄漏检测不准确。为了减轻这些历史问题，我们综合了多个数据源来推断 AS 级关系，包括 CAIDA/UCSD 的 AS 关系数据和我们内部构建的 AS 关系数据集。在两个 AS 级关系之上，我们在每个前缀和每个对等点级别构建了一个更精细的数据集。改进后的数据集让我们能够回答一些问题，例如对于收集器对等点 X 观察到的前缀 P，AS1 和 AS2 之间的关系是什么。如果网络中多种不同关系，因不同前缀和地理位置而异，该数据集可消除大部分歧义，从而帮助我们减少系统中的误报次数。除 AS 关系数据集外，我们还应用了 IHR IIJ 的 AS Hegemony 数据集来进一步减少误报。
路由泄漏的存储和展示
处理完每条 BGP 消息后，我们将生成的路由泄漏条目存储在数据库中，以便长期存储和浏览。我们还汇总了各个路由泄漏的 BGP 公告，并将短时间内来自同一泄漏 ASN 的相关泄漏归纳为路由泄漏事件。然后，Web UI（API或警报）等各种下游应用程序便可使用这些路由泄漏事件。
Cloudflare Radar 检测路由泄漏
Cloudflare 的目标是帮助构建更好的互联网，包括分享我们在监测和保障互联网路由方面的成果。今天，我们将发布路由泄漏检测系统的公开测试版。
从今天开始，用户前往 Cloudflare Radar ASN 页面，就可以看到影响该 AS 的路由泄漏列表。我们认为，如果距离泄漏点 AS 仅一个跃点（无论方向如何，无论是之前还是之后），AS 便会受到影响。
可通过 https://radar.cloudflare.com/as{ASN} 直接访问 Cloudflare Radar ASN 页面。例如，可以访问 https://radar.cloudflare.com/as174 查看 Cogent AS174 的概述页面。ASN 页面现在有一个专门的路由泄漏卡，显示在选定时间范围内检测到的与当前 ASN 相关的路由泄漏。
用户还可以开始使用我们的公共数据 API 来查找关于任何给定 ASN 的路由泄漏事件。我们的 API 支持按时间范围和所涉 AS 筛选路由泄漏结果。下图为最近更新的 API 文档站点上的路由泄漏事件 API 文档页面。
更多路由安全功能即将推出
我们还有许多关于路由泄漏检测的计划。随着时间的推移，Cloudflare Radar 将陆续推出全局视图页面、路由泄漏通知、更高级的 API、自定义自动化脚本和历史存档数据集等更多功能。您的反馈和建议可以帮助我们继续改进检测结果，向公众提供更好的数据，因此对我们非常重要。
此外，我们将继续推进互联网路由安全方面的其他重要课题，包括全球 BGP 劫持检测（不局限于我们的客户网络）、RPKI 验证监测、开源工具和架构设计，以及集中式路由安全网络网关。我们的目标是向社区提供路由安全的最佳数据和工具，共同构建更好、更安全的互联网。
同时，我们的开发人员 Discord 服务器上开设了 Radar 室。欢迎加入与我们交流；团队渴望收到大家的反馈，乐意回答大家的问题。
请访问 Cloudflare Radar，了解更多互联网见解。您也可以在 Twitter 上关注我们，了解 Radar 的最新消息。