发布时间：2026.01.07
源地址：https://blog.cloudflare.com/bgp-route-leak-venezuela/
随着有关美国逮捕委内瑞拉领导人尼古拉斯·马杜罗的消息不断展开，一份网络安全通讯分析了 Cloudflare Radar 数据，并注意到委内瑞拉在 1 月 2 日发生了一次路由泄露。
我们深入分析了数据。自 12 月初以来，发生了 11 起路由泄露事件，影响了多个前缀，泄露源均为 AS8048。尽管无法确定事件当天的具体情况，但这一系列路由泄露表明，委内瑞拉知名互联网服务提供商 CANTV（AS8048）网络的路由导出和导入策略存在不足。换言之，研究人员观察到的 BGP 异常可能与该 ISP 的技术操作不当有关，而非恶意行为。
在本文中，我们将简要介绍边界网关协议（BGP）及其路由泄露问题，随后深入分析所观察到的异常现象及其可能的成因。
背景：BGP 路由泄露
首先，让我们回顾一下什么是 BGP 路由泄露。BGP 路由泄露的行为类似于在高速公路上走错出口。虽然最终仍能到达目的地，但路径可能更为曲折，导致速度变慢和出现本可避免的延迟。
路由泄露在 RFC7908 中被正式定义为“路由公告超出其预定范围的传播”。预定范围是通过网络之间的双边业务关系来定义的。在 BGP 中，我们使用自治系统（AS）来表示网络之间的关系，这些关系可以是以下几种：
客户-提供商：客户支付提供商网络费用，以连接他们自己及其下游客户到互联网的其他部分
对等-对等：两个网络决定相互交换流量，面向彼此的客户，且无结算费用（无需支付）
在客户与提供商的关系中，提供商会向客户宣布所有路由。另一方面，客户只会宣传来自其自身客户和直接源自其网络的路由。
在对等关系中，每个对等方只会向对方宣传其自身的路由以及其下游客户的路由。
这些路由公告有助于引导流量按照预期的路径流动：从客户向上游的提供商网络，可能经过单一的对等连接，然后再可能返回到路径另一端的客户。
一个有效路径应符合无谷路由规则，如下所示：
路由泄露是违反无谷路由规则的行为，指的是一个自治系统（AS）从其提供商或对等体获取路由后，再将这些路由重新分发给另一个提供商或对等体。例如，BGP 路径绝不应经过“谷底”，即流量先上行到提供商，再下行到客户，随后又上行到另一个提供商。RFC7908 定义了多种类型的路由泄露，其中一种简单类型是类型 1：客户在两个提供商网络之间发生的发夹式路由泄露。 一个符合无谷路由规则的有效路径应避免出现流量在网络中“上下波动”的情况，例如先从客户上行到提供商，再下行到客户，最后又上行到另一个提供商。 路由泄露指的是自治系统（AS）错误地将从某个提供商或对等体学到的路由信息，转发给了另一个提供商或对等体，违反了无谷路由的原则。根据 RFC7908 的定义，路由泄露有多种类型，其中一种常见的类型是“类型 1”，即客户在两个提供商网络之间发生的发夹式路由泄露。
在上图中，AS64505 从其一个提供商处获取路由，并将这些路由重新分发给另一个提供商。这种行为出乎意料，因为我们知道提供商不应将其客户用作中间的 IP 传输网络。作为一个规模较小、骨干和网络连接较少的网络，AS64505 会因此承受过多流量，导致网络负担过重。这种情况可能迅速产生严重影响。
AS8048（CANTV）路由泄露
既然我们已经回顾了 BGP 中什么是路由泄露，接下来让我们来分析新闻通讯中提出的假设。该文章关注了 Cloudflare Radar 上涉及 AS8048 的几起路由泄露异常。在该泄露的 Radar 页面上，我们可以看到以下信息：
我们发现泄露源是 AS8048——CANTV，委内瑞拉的国有电话和互联网服务提供商。观察显示，路由信息从其供应商之一的 AS6762（意大利电信公司 Sparkle）被获取后，再分发给 AS52320（哥伦比亚网络服务提供商 V.tal GlobeNet）。这显然是一次路由泄露。
该通讯提到“BGP 弄虚作假”，并推测此类泄露可能被利用来收集对政府机构有用的情报。
虽然我们无法确定此次路由泄露的具体原因，但我们的数据表明其更可能是平凡的原因所致。这部分是因为 BGP 路由泄露时常发生，并且一直是互联网的一部分——大多数情况下并非出于恶意。
为了更深入了解，我们来仔细看看受影响的前缀和网络。此次泄露涉及的前缀均由 AS21980（Dayco Telecom，一家委内瑞拉公司）发起：
这些前缀也都属于同一个 200.74.224.0/20 子网，正如通讯作者所指出的。然而，更引人注目的是起源网络 AS21980 与泄露网络 AS8048 之间的关系：AS8048 是 AS21980 的提供商。
AS8048 与 AS21980 之间的客户-提供商关系在 Cloudflare Radar 和 bgp.tools 的 AS 关系推断数据中均有体现。我们还可以使用 BGPKIT 的 monocle 工具获得该 AS 关系的置信度评分，如下所示：
➜ ~ monocle as2rel 8048 21980 Explanation: - connected: % of 1813 peers that see this AS relationship - peer: % where the relationship is peer-to-peer - as1_upstream: % where ASN1 is the upstream (provider) - as2_upstream: % where ASN2 is the upstream (provider)
Data source: https://data.bgpkit.com/as2rel/as2rel-latest.json.bz2
╭──────┬───────┬───────────┬──────┬──────────────┬──────────────╮ │ asn1 │ asn2 │ connected │ peer │ as1_upstream │ as2_upstream │ ├──────┼───────┼───────────┼──────┼──────────────┼──────────────┤ │ 8048 │ 21980 │ 9.9% │ 0.6% │ 9.4% │ 0.0% │ ╰──────┴───────┴───────────┴──────┴──────────────┴──────────────╯
尽管只有 9.9%的路由收集器将这两个自治系统视为相邻，但几乎所有包含它们的路径都显示 AS8048 作为 AS21980 的上游提供商，这表明两者之间的供应商-客户关系具有高度可信度。
许多泄露的路由在前面都被大量添加了 AS8048，这意味着当其他网络接收到这些路由时，它们的吸引力可能会降低。前置（prepending）是指客户或对等方在出站通告中多次重复添加同一个自治系统（AS）编号，目的是试图将流量从某条特定线路转移到另一条线路。例如，AS8048 在泄露期间的许多路径看起来像这样：“52320, 8048, 8048, 8048, 8048, 8048, 8048, 8048, 8048, 8048, 23520, 1299, 269832, 21980”。
你可以看到，AS8048 多次向 AS52320 广告其自治系统号，因为通过 BGP 循环防止机制，路径实际上不会连续多次进出 AS8048。未添加前缀的路径示例如下：“52320,8048,23520,1299,269832,21980”。
如果 AS8048 有意图成为流量的中间人（MITM），为什么他们会让 BGP 广告变得不那么有吸引力，而不是更有吸引力？另外，既然你已经是下游自治系统的提供商，为什么还要泄露前缀来试图进行中间人攻击？这显得不太合理。
2026 年 1 月 2 日 15:30 至 17:45（协调世界时）期间，AS8048 的泄露信息在多个相隔约一小时的独立公告中陆续出现，这表明他们可能遇到了网络问题，具体表现为路由策略故障或基于网络收敛的意外情况。
值得注意的是，这些泄密事件发生在美国对委内瑞拉军事打击前超过十二小时。影响南美网络的泄密事件时有发生，基于时间点及我之前提到的其他因素，我们没有理由认为此次泄密与数小时后马杜罗被捕有关。
事实上，回顾过去两个月，我们可以看到许多由 AS8048 造成的泄漏事件与此次类似，这意味着这并不是一个新的 BGP 异常：
从 Cloudflare Radar 路由泄漏报警管道的历史记录中可以看到，AS8048 对于类型 1 的回环路由泄漏并不陌生。仅从 12 月初开始，就有 11 起路由泄漏事件是由 AS8048 造成的。
由此我们可以得出一个较为无辜的可能解释：AS8048 可能对至少一个其提供商 AS52320 配置了过于宽松的出口策略。正因如此，即使缺少直接客户的 BGP 路由，属于其客户的重分发路由仍被泄漏。如果他们对 AS52320 的出口策略仅匹配 IRR 生成的前缀列表，而没有匹配客户的 BGP 社区标签，例如，这就能解释为何 AS8048 会将通往 AS6762 的间接路径泄漏回上游。 意译： 回顾过去两个月的情况，我们发现 AS8048 发生了多起类似的路由泄漏事件，这表明这并非一种新的 BGP 异常现象。 从 Cloudflare Radar 路由泄漏报警系统的历史数据来看，AS8048 多次出现类型 1 的回环路由泄漏问题。仅 12 月以来，就有 11 次路由泄漏事件源自 AS8048。 基于此，我们可以推测一个较为合理的解释：AS8048 可能对其至少一位上游提供商 AS52320 设定了过于宽松的出口策略。正因如此，即使缺少直接客户的 BGP 路由，属于客户的重分发路由仍被错误地泄漏出去。举例来说，如果他们对 AS52320 的出口策略只依据 IRR 生成的前缀列表，而未考虑客户的 BGP 社区标签，就能解释为何 AS8048 会将通往 AS6762 的间接路由泄漏回上游。
这些类型的策略错误，如果所有路由供应商都支持，RFC9234 和 Only-to-Customer（OTC）属性将大大有助于解决，因为它们通过更紧密地将 BGP 与客户-提供商和对等-对等角色绑定在一起。我会在后续的博客文章中详细介绍 RFC9234 的更多技术细节。
源验证与路径验证的区别
这份通讯还特别指出，Sparkle（AS6762）未实施 RPKI（资源公钥基础设施）路由源验证（ROV）这一点“值得关注”。虽然 AS6762 似乎只部分部署了 ROV，并因此在 isbgpsafeyet.com 上被标记为“不安全”，但源验证并不能防止此次委内瑞拉发生的 BGP 异常。
将 BGP 异常区分为两类非常重要：路由源错误和基于路径的异常。了解两者的区别有助于找到相应的解决方案。路由源错误，通常称为 BGP 劫持，旨在通过 RPKI 路由源验证（ROV）来修复，确保前缀的发起者是其合法拥有者。而本文描述的 BGP 异常中，源 AS 是正确的 AS21980，只有路径异常，这意味着 ROV 在此无效。
基于此，我们需要路径验证。这正是 IETF 正在制定的草案标准——自治系统提供商授权（ASPA）所要实现的。其理念类似于 RPKI 路由源授权（ROA）和 ROV：创建一个 ASPA 对象，定义本 AS 授权的提供商（上游），所有人据此在不同视角点验证并拒绝路由泄露。举例来说，AS6762 是一个无上游的一级传输网络，他们会在 ASPA 签名对象中使用特殊保留的“AS0”成员，向外界表明其无上游，仅有横向对等和客户。随后，AS8048 的另一提供商 AS52320 会在路径中发现带有“6762”的客户路由时，通过 ASPA 验证流程拒绝该路由。
基于 RPKI 的 ASPA 正是有助于防止类似我们在委内瑞拉观察到的路由泄露事件的技术。
共同构建更安全的 BGP
我们认为有必要为 Cloudflare Radar 观察到的委内瑞拉 AS8048 BGP 路由泄露事件提供另一种解释。理解路由泄露是 BGP 历史上完全基于信任和精心执行的业务关系驱动意图的一个预期副作用，这一点非常重要。
虽然路由泄露可能出于恶意，但数据显示此次事件更可能是由于缺乏路由导出和导入策略所致，而这些策略本可以防止此类问题。因此，为了实现更安全的 BGP 和互联网，我们需要共同努力，推动基于 RPKI 的 ASPA 在广泛互联网中的应用。为此，RIPE 最近发布了相关对象的创建功能。这将是一项协作工作，就像 RPKI 在源验证中的应用一样，但这项努力值得付出，能够防止类似委内瑞拉的 BGP 事件发生。
除了 ASPA，我们还可以作为运营商实施更简单的机制，如 Peerlock 和 Peerlock-lite，这些机制能够对接收到的路径进行合理性检查，防止明显的路由泄露。其中一个特别有前景的举措是采用 RFC9234，该标准应与 ASPA 配合使用，通过建立 BGP 角色和新增的 Only-To-Customer（OTC）属性来防止路由泄露。如果你还没有向路由设备供应商询问将 RFC9234 的实现纳入其产品规划，请务必提出。你的参与能够带来显著的改变。