2024 年 6 月 27 日发生的 Cloudflare 1.1.1.1 事件

2024 年 6 月 27 日，全球少数用户可能已经注意到 1.1.1.1 无法访问或性能降级。根本原因是边界网关协议 (BGP) 劫持和路由泄漏。

Cloudflare 是资源公钥基础设施 (RPKI) 的早期采用者，用它进行路由来源验证 (ROV)。借助 RPKI，IP 前缀所有者可以安全地存储和共享所有权信息，其他运营商可以将收到的 BGP 路由与以路由来源授权 (ROA) 形式存储的内容进行比较，以这种方式来验证 BGP 公告。如果网络正确地执行路由来源验证并通过 ROA 对前缀进行签名，BGP 劫持的影响将受到极大限制。尽管过去几年 RPKI 的采用率有所提高且 1.1.1.0/24 成为了已签名的资源，但在此次事件过程中，1.1.1.1/32 由 ELETRONET SA (AS267613) 始发并被多个网络接受，包括至少一个一级提供商，它接受 1.1.1.1/32 作为黑洞路由。虽然对总体用户比例的影响很低，例如，英国和德国受影响的用户比例不足 1%，在某些国家/地区，甚至没有用户注意到，但此次事件仍然导致 70 个国家/地区的 300 多个网络立即无法访问 DNS 解析器。

Cloudflare 在之前的文章中撰写并讨论过路由泄漏问题，但遗憾的是，目前只能广泛部署尽力而为的保障措施，例如提供商的互联网路由注册 (IRR) 前缀列表过滤。在 1.1.1.1/32 遭到劫持的同一时段内，1.1.1.0/24 被 Nova Rede de Telecomunicações Ltda (AS262504) 错误地泄漏给上游提供商。Peer-1 全球互联网交换中心 (AS1031) 进一步广泛传播了此次泄漏，这也加剧了客户在事件期间受到的影响。

我们对受到此次 1.1.1.1 事件影响的用户深表歉意，我们非常重视确保服务正常运行。虽然事件的根本原因在 Cloudflare 外部，但我们将继续改进现有的检测方法，以缩短响应时间；利用我们在互联网社群中的立场，进一步鼓励采用基于 RPKI 的劫持和泄漏防范机制，例如路由来源验证 (ROV)，适用于 BGP 的自治系统提供商授权 (ASPA) 对象。

2018 年，Cloudflare 推出了 1.1.1.1 公共 DNS 解析器服务。自发布以来，1.1.1.1 已成为最受欢迎的 IP 地址解析器之一，任何用户都可以免费使用。随着 IP 地址的普及和易于识别，带来了一些操作上的困难。困难源于实验室网络过去使用了 1.1.1.1 或将其作为测试 IP 地址，导致一些残留的意外流量或黑洞路由行为。因此，Cloudflare 对处理 BGP 错误路由流量的影响并不陌生，下面将介绍其中的两种影响。

部分困难源自 1.1.1.1 遭到潜在的路由劫持。例如，如果某个虚构的 FooBar Networks 将 1.1.1.1/32 分配给自己的某台路由器并在内部网络中共享此前缀，则其客户将难以路由到 1.1.1.1 DNS 服务。如果其在自己的直接网络范围之外广播 1.1.1.1/32 前缀，则可能造成更大的影响。之所以选择 1.1.1.1/32，而不是 Cloudflare 公告的 1.1.1.0/24 BGP，是因为最长前缀匹配 (LPM)。虽然路由表中的许多前缀都可以匹配 1.1.1.1 地址，例如 1.1.1.0/24、1.1.1.0/29 和 1.1.1.1/32，但 LPM 算法认为 1.1.1.1/32 才是“最长匹配”，因为它不仅与 1.1.1.1 地址匹配，而且具有最多的相同位数和最长的子网掩码。简而言之，我们将 1.1.1.1/32 称为 1.1.1.1“最具体”的可用路由。

流向 1.1.1.1 的流量不会通过 Anycast 路由到 Cloudflare 网络并登陆遍布全球的某一台 Cloudflare 服务器，而是会登陆 FooBar Networks 中 1.1.1.1 服务终止所在的设备，并且无法向客户端提供合法响应。这种情况被视为对 1.1.1.1 请求的劫持，可能是 FooBar Networks 内部的网络运营商有意为之或无心之失。

有时，我们面临的另一种 1.1.1.1 事件影响就是 BGP 路由泄漏。当某个网络成为上游提供商向其他提供商广播 BGP 公告时，即发生路由泄漏，因为该网络不应成为上游提供商。

以下是一个路由泄漏示例：客户将从一个提供商那里获知的路由转发给另一个提供商，从而导致第 1 类泄漏（请参阅 RFC7908 中的定义）。

如果无默认路由区 (DFZ) 内有足够多的网络接受路由泄漏，它可能会被广泛用于沿着_错误_路径转发流量。这通常会导致泄漏前缀的网络过载，因为这些网络没有为吸引当前的全球流量做好准备。我们曾谈论过一次大规模的路由泄漏事件导致大部分互联网瘫痪，当时宾夕法尼亚州的一家提供商将流量吸引到它通常从未中转过的全球目的地。尽管 Cloudflare 与全球各地 13,000 多个网络互连，但分配给泄漏路由的 BGP 本地优先级可能高于网络直接从 Cloudflare 接收的路由。这听起来事与愿违，但很遗憾，此类情况的确有可能发生。

要说明发生此类情况的原因，我们可以将 BGP 视为业务策略引擎以及互联网的路由协议。中转提供商拥有付费获取数据传输服务的客户，于是，从逻辑上讲，他们分配的 BGP 本地优先级高于专用连接或互联网交换 (IX) 对等互连，因此，付费连接的使用率最高。不妨把本地优先级看作是影响将流量优先发送到哪个传出连接的一种方式。不同的网络也可能选择优先使用专用网络互连 (PNI)，而不是互联网交换 (IX) 收到的路由。这样做的部分原因是可靠性，因为专用连接可以视为两个网络之间的点对点连接，无需担心中间的第三方托管结构。另一个原因则可能是性价比，就像您不辞辛劳地分配路由器端口并购买您自己与另一个对等路由器之间的交叉连接一样，您希望利用它来获得最佳投资回报。

需要指出的是，BGP 劫持和路由泄漏可能会发生在互联网上的任何 IP 和前缀，而不仅仅只是 1.1.1.1。但如前所述，1.1.1.1 是一个非常容易识别且曾经被盗用过的地址，因此，它比其他 IP 资源更容易遭到意外劫持或泄露。

在 2024 年 6 月 27 日发生的 Cloudflare 1.1.1.1 事件中，我们最终缓解了 BGP 劫持和路由泄漏共同造成的影响。

所有时间戳均采用世界协调时间 (UTC) 格式。

2024-06-27 18:51:00 AS267613 (Eletronet) 开始向对等网络、提供商和客户广播 1.1.1.1/32。1.1.1.1/32 与 AS267613 源 AS 一起广播

2024-06-27 18:52:00 AS262504 (Nova) 泄露 1.1.1.0/24，同样也接收 AS267613 的路由，然后泄露给上游的 AS1031（PEER 1 全球互联网交换中心），AS 路径为“1031 262504 267613 13335”

2024-06-27 18:52:00 AS1031（在 Nova 的上游）将 1.1.1.0/24 传播到各种互联网交换对等互连和路由服务器，从而扩大了泄漏的影响

2024-06-27 18:52:00 某个一级提供商接收了 AS267613 发送的 1.1.1.1/32 公告，将其作为远程触发的黑洞 (RTBH)，导致所有一级提供商客户的流量被重新定向

2024-06-27 20:03:00 针对不同国家/地区报告无法访问 1.1.1.1 的问题，Cloudflare 宣布发生了内部事件

2024-06-27 20:08:00 Cloudflare 禁用了 AS267613 的一个合作伙伴对等互连网络，后者在接收流向 1.1.1.0/24 的流量

2024-06-27 20:08:00 Cloudflare 团队就此事件与对等互连合作伙伴 AS267613 进行了沟通

2024-06-27 20:10:00 AS262504 泄漏 1.1.1.0/24，新的 AS 路径为“262504 53072 7738 13335”，此路径也由 AS1031 重新分配。沿着此路径可以将流量成功发送到 Cloudflare，但受影响的客户端出现高延迟问题

2024-06-27 20:17:00 Cloudflare 就关于 1.1.1.0/24 路由泄漏给其上游提供商的问题与 AS262504 进行了沟通

2024-06-27 21:56:00 Cloudflare 工程师禁用了 AS267613 的第二个对等互连网络，后者在从巴西以外的多个源接收原本要流向 1.1.1.0/24 的流量

2024-06-27 22:16:00 AS262504 再次泄漏 1.1.1.0/24，吸引一些流量流向位于巴西圣保罗、与 AS267613 对等互连的 Cloudflare 网络。因此，一些 1.1.1.1 请求返回出现高延迟，但似乎解决了 1.1.1.1/32 劫持和流量黑洞问题

2024-06-28 02:28:00 AS262504 彻底解决 1.1.1.0/24 的路由泄漏问题

客户受到的影响表现为以下两种方式之一：根本无法访问 1.1.1.1；能够访问 1.1.1.1，但每个请求都出现高延迟

由于 AS267613 在其网络中的某个位置劫持了 1.1.1.1/32 地址，因此，许多请求在其自治系统中的某些设备上均失败。在事件发生期间，服务时断时续，或出现震荡，尽管出现高延迟，但他们将针对 1.1.1.1 的请求成功地路由到 Cloudflare 数据中心。

通过观察事件发生期间的两个来源国家（德国和美国），受影响的 1.1.1.1 流量如下所示：

用户来源国家

请记住，总体而言，这可能代表每个来源国家的请求总数量相对较少，但通常情况下，针对 1.1.1.1 的请求不会从美国或德国路由到巴西。

Cloudflare 数据中心所在城市：

如图所示，1.1.1.1 的请求都到达了巴西的数据中心。峰值之间的缺口对应的是 1.1.1.1 请求在达到 AS267613 之前或期间被重新定向的时段，而这些峰值本身对应的则是流量被传送到 Cloudflare，但请求和响应均出现高延迟的时段。成功传输到 Cloudflare 对等互连位置 AS267613 的流量出现短暂激增，可能是因为其网络内的 1.1.1.1/32 路由不稳定，偶尔会让流量进入 Cloudflare 网络，而不是在中间路径的某个位置丢弃。

通常情况下，用户的 1.1.1.1 请求通过 BGP Anycast 路由到最近的数据中心。事件发生期间，AS267613 (Eletronet) 将 1.1.1.1/32 广播到对等网络和上游提供商，然后 AS262504 将 1.1.1.0/24 泄漏给上游提供商，从而彻底改变了多个眼球式网络的 BGP Anycast 常规路径。

使用公共路由收集器和 Monocle 工具，我们可以搜索行为异常的 BGP 更新。

我们从上图中看到，AS398465 和 AS13760 向路由视图收集器报告，它们在影响开始时收到了 AS267613 发送的 1.1.1.1/32。通常情况下，无默认路由区 (DFZ) 接受的最长 IPv4 前缀是 /24，但在本示例中，我们观察到多个网络使用 AS267613 发送的 1.1.1.1/32 路由进行转发，具体体现在重新定向流量，使其永远无法到达 Cloudflare 接入点 (POP)。AS267613 始发 1.1.1.1/32 就是一次 BGP 路由劫持。尽管仅对源 AS13335 (Cloudflare) 进行了路由来源授权 (ROA) 签名，且最长前缀为 /24，但它们依然广播包含源 AS267613 的前缀。

我们在 Cloudflare 查看 BGP 监测协议 (BMP) 数据时，甚至看到了 1.1.1.1/32 的 BGP 更新。我们从至少几个不同的路由服务器收到了自己关于 1.1.1.1/32 的 BGP 公告。值得庆幸的是，由于 AS 源和前缀长度无效导致 RPKI 无效和 DFZ 无效，Cloudflare 在导入时拒绝了这些路由。BMP 数据显示是预先制定的策略，也就是说，即使我们拒绝了该路由，也可以看到对等互连会话期间接收 BGP 更新的时间。

monocle search --start-ts 2024-06-27T18:51:00Z --end-ts 2024-06-27T18:55:00Z --prefix '1.1.1.1/32'

A|1719514377.130203|206.126.236.209|398465|1.1.1.1/32|398465 267613|IGP|206.126.236.209|0|0||false|||route-views.eqix
–
A|1719514377.681932|206.82.104.185|398465|1.1.1.1/32|398465 267613|IGP|206.82.104.185|0|0|13538:1|false|||route-views.ny
–
A|1719514388.996829|198.32.132.129|13760|1.1.1.1/32|13760 267613|IGP|198.32.132.129|0|0||false|||route-views.telxatl

因此，多个网络不仅接受了不应存在于全局路由表中的前缀，而且还接受了资源公钥基础设施 (RPKI) 无效路由。更糟糕的是，某个一级中转提供商接受了 AS267613 发送的 1.1.1.1/32 公告，将其作为远程触发的黑洞 (RTBH) 路由，导致丢弃通常会路由到 Cloudflare 的所有边缘流量。仅这一点就造成了广泛影响，因为在事件发生期间，所有利用该一级提供商路由到 1.1.1.1 的网络都无法访问 IP 地址。

对于那些不了解远程触发的黑洞 (RTBH) 的人来说，这是一种向提供商发出信号的方法，指明您希望在其网络中丢弃流量的一组目的地。它也是一种抵御 DDoS 攻击的直接方法。当您的特定 IP 或前缀受到攻击时，您可以告诉上游提供商，在流量到达网络端口之前将其丢弃，以吸收流向该目标 IP 地址或前缀的所有流量。此次事件的主要问题是 AS267613 未经授权将 1.1.1.1/32 作为黑洞。Cloudflare 应该拥有独家权利，利用 RTBH 来丢弃流向 AS13335 的流量，而这是我们在现实中永远不会做的事情。

现在看看 1.1.1.0/24 的 BGP 更新，多个网络收到了来自 AS262504 的前缀并且接受了它。

这里我们再次看一看 AS 路径。此时，AS13335 是公告末尾的源 AS。BGP 公告状态为 RPKI 有效，因为正确的源恰好就是 AS13335，但这属于 1.1.1.0/24 的路由泄漏，原因是该路径本身无效。

~> monocle search --start-ts 2024-06-27T20:10:00Z --end-ts 2024-06-27T20:13:00Z --prefix '1.1.1.0/24' --as-path ".* 267613 13335" --include-sub

.. some advertisements removed for brevity ..

A|1719519011.378028|187.16.217.158|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|187.16.217.158|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views2.saopaulo
–
A|1719519011.629398|45.184.147.17|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|45.184.147.17|0|0|1031:1031 1031:4209 1031:4259 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519036.943174|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|route-views.amsix
–
A|1719519037|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|rrc03
–
A|1719519087.4546|45.184.146.59|199524|1.1.1.0/24|199524 1031 262504 267613 13335|IGP|45.184.147.17|0|0||false|13335|162.158.177.1|route-views.fortaleza
A|1719519087.464375|45.184.147.74|264409|1.1.1.0/24|264409 1031 262504 267613 13335|IGP|45.184.147.74|0|0|65100:7010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519096.059558|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3
–
A|1719519128.843415|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3

查看示例路径“199524 1031 262504 267613 13335”，从功能角度而言，AS267613 是 AS13335 的对等网络，并且不应该与对等网络或上游提供商共享 1.1.1.0/24 公告，而只能与其客户 (AS Cone) 共享。AS262504 是 AS267613 的客户，也是路径中的下一个相邻 ASN，因此，到目前这个阶段为止，一切正常没有问题。1.1.1.0/24 出错的地方是 AS262504，因为此时它向上游的 AS1031 广播了前缀。而且，AS1031 将广播重新分发给自己的对等网络。

也就是说，AS262504 是泄露路由的网络。AS1031 接受了来自其客户 AS262504 的路由泄漏，并通过在全球多个对等位置分发路由造成了广泛影响。AS1031（Peer-1 全球互联网交换中心）广播自己是全球对等互连交换中心。Cloudflare 不是 AS1031 的客户，因此，1.1.1.0/24 不应被重新分发到 AS1031 的对等网络、路由服务器或上游提供商。AS1031 似乎并没有对客户 BGP 会话执行任何广泛的过滤，而是仅匹配了相邻的网络（在本示例中为 AS262504）并重新分配符合条件的所有内容。遗憾的是，AS1031 这种不负责任的行为，对 1.1.1.1 造成了直接影响，以及可能导致其他服务成为无人值守的路由传播的牺牲品。虽然最初泄露路由的网络是 AS262504，但在 AS1031 和其他网络接受了劫持或泄露的路由并且进一步分发公告后，事件的影响显著增大。

在本次事件的大部分时间里，AS262504 引发的泄露最终导致请求进入 AS267613，而 AS267613 在其网络内的某个地方丢弃了 1.1.1.1/32 流量。最终，AS262504 实际上通过将泄露路由给上游提供商，放大了无法访问 1.1.1.1 的影响。

为减轻路由泄露的影响，Cloudflare 禁用了 AS267613 在多个位置的对等互连。但问题并未彻底结束，因为 AS262504 仍然将陈旧路径泄露到圣保罗。尽管响应用户的往返时间较长，但到达圣保罗的请求能够得到处理。Cloudflare 一直在与本篇博客文章中提到的所有网络就 BGP 泄露和未来的预防机制进行沟通，以及与至少一家一级中转提供商进行沟通，该提供商接受了 AS267613 发送的 1.1.1.1/32，将其作为未经 Cloudflare 授权的黑洞路由，并造成了广泛影响。

RPKI 来源验证RPKI 最近达到了一个重要里程碑：50% 的部署采用路由来源授权 (ROA) 对前缀进行签名。虽然 RPKI 确实有助于限制遭到劫持的 BGP 前缀在整个互联网中的传播，但我们需要所有网络发挥各自的作用，特别是拥有大量下游自治系统 (AS) 的主要网络。在 1.1.1.1/32 劫持事件期间，多个网络接受并使用了 AS267613 公告的路由来进行流量转发。

RPKI 与远程触发的黑洞 (RTBH)此次事件造成的大部分影响，是因为一级提供商接受了 1.1.1.1/32 作为来自非 Cloudflare 的第三方的黑洞路由。这本身就是一种 1.1.1.1 劫持事件，而且是非常危险的行为。RTBH 是一个实用工具，许多网络在急需缓解大规模 DDoS 攻击时都会使用 RTBH。但问题是，针对 RTBH 的 BGP 过滤机制本质上比较松散，通常仅依赖于互联网路由注册机构中的 AS-SET 对象。依靠路由来源授权 (ROA) 进行 RTBH 过滤是不可行的，因为需要为 Cloudflare 这样规模庞大的网络创建数千个潜在的 ROA。不仅如此，创建特定的 /32 条目可能会导致某个单独的地址（例如 1.1.1.1/32）被某个冒充为 AS13335 的网络进行广播，成为互联网上通向 1.1.1.1 的最佳路由并造成严重影响。

AS-SET 过滤并不代表有权重新定向某个路由，例如 1.1.1.1/32。只有 Cloudflare 才能将自己有权操作的目的地重新定向。再说一遍，利用 RPKI 是解决 RTBH 会话中提供商过滤较为宽松的一个潜在方法。以 IETF 为例，已过期的 draft-spaghetti-sidrops-rpki-doa-00 提案指定了一个丢弃来源授权 (DOA) 对象，该对象将用于仅授权特定来源对前缀执行重新定向操作。如果对该对象进行了签名，并且对其执行了 RTBH 请求验证，则 AS267613 尝试对 1.1.1.1/32 执行未经授权的重新定向操作将被视为无效，而不会被一级提供商接受。

BGP 最佳实践只需按照 MANRS 所述的 BGP 最佳实践来操作，并拒绝无默认路由区 (DFZ) 中长度超过 /24 的 IPv4 前缀，即可减轻对 1.1.1.1 的影响。拒绝更广泛的互联网中的无效前缀长度，应该成为所有网络的标准 BGP 策略的一部分。

虽然目前对于 Cloudflare 来说，路由泄露并非不可避免，但由于互联网本质上依赖于信任实现互连，因此，我们将采取一些措施来限制此类事件的影响范围。

我们已经扩展了路由泄露检测系统的数据源，以覆盖更多网络，并且正在积极努力将实时数据纳入检测系统，以便在未来发生类似事件时做出更及时的响应。

我们会继续倡导将 RPKI 纳入基于 AS 路径的路由泄露防御机制。自治系统提供商授权 (ASPA) 对象与 ROA 类似，不同之处则在于它不是使用已获授权的源 AS 来签名前缀，而是使用允许传播其路由的提供商网络列表对 AS 本身进行签名。因此，对于 Cloudflare 而言，只有有效的上游中转提供商才会获得授权来广播 AS13335 前缀，例如 1.1.1.0/24 上游提供商。

在路由泄露示例中，AS262504（AS267613 的客户）与上游提供商共享了 1.1.1.0/24，如果 AS267613 对其授权提供商进行了签名，并且 AS1031 根据该列表验证了路径，那么 BGP ASPA 就可以发现此泄漏事件。不过，与 RPKI 来源验证方法类似，这将是一项长期工作，并且离不开网络，尤其是大型网络提供商，能够根据 ASPA 对象拒绝无效的 AS 路径。

在不同的采用阶段，确实存在一些 ASPA 的替代方法，可能值得注意。然而，并不能保证以下方法能够进入互联网广泛部署的阶段。

例如，RFC9234 的优点是在 BGP 功能和属性中使用对等角色的概念，并根据更新路径上的路由器配置，可以在前缀中添加“仅限发送给客户”(OTC) 属性，以防前缀（例如 1.1.1.0/24）沿着泄漏路径传播到上游提供商。它的缺点则是需要完成 BGP 配置，才能将各种角色分配给每个对等互连会话；以及仍然需要完全解决供应商的采用问题，才能使其在实际生产中得到应用并取得积极成果。

与解决路由泄漏的所有方法一样，需要互联网网络运营商之间密切合作才能取得成功。

Cloudflare 的 1.1.1.1 DNS 解析器服务同时遭遇了 BGP 劫持和 BGP 路由泄漏事件。虽然外部网络的行为不在 Cloudflare 的直接控制范围内，但我们打算在互联网社群和 Cloudflare 内部采取一切措施，加快检测问题的速度并减轻对用户的影响。

从长远来看，Cloudflare 将继续支持采用基于 RPKI 的来源验证以及 AS 路径验证。前者已在全球最大型的网络中广泛部署，而后者仍处于互联网工程任务组 (IETF) 的起草阶段。与此同时，若要核实互联网服务提供商 (ISP) 是否在强制执行 RPKI 来源验证，您可以随时访问 isbgpsafeyet.com 并_测试 ISP_。