摘要

  • 独立监测显示,2015 年 6 月 12 日 08:43 UTC 左右,Telekom Malaysia 的 AS4788 开始爆发大量 BGP 通告。BGPMon 报告约 179,000 个前缀被通告,而 RFC 7908 后来将该事件引用为重大的路由泄露案例,其中 Level 3 接受并传播了约 179,000 个前缀。[2][10]
  • 不同的分析报告不同的路由计数,因为它们使用不同的收集器、时间窗口和定义。Geoff Huston 的分析讨论了大约 2,500 条新出现的路由,并检查了一组 22,577 受影响的路由。这些数字不能负责任地合并为一个错误的精度。[1][2]
  • Level 3 的 AS3549 不仅仅是观察 AS4788 的通告。它接受并传播了这些通告,通过一个主要的全球传输网络扩大了破坏范围。ThousandEyes 在多个 Level 3 存在点测量到了严重的丢包和终端路径。[2][3]
  • 证据支持关系策略泄露:从对等体学习的路由似乎已向上游传输提供商重新通告。确切的 Telekom Malaysia 路由器配置、路由映射、命令、软件和审批链在此文档中未公开。[1]
  • 责任按控制划分。AS4788 控制其出口策略和路由映射生命周期。AS3549 控制其从客户那里接受的内容、应用的容量和路径检查,以及是否传播接受的路由。下游网络控制自己的导入策略和监控。
  • 普通的 RPKI 路由源验证不是此事件的完整答案。大多数泄露的路径保留了合法的起源。源授权可以是有效的,而路径违反了客户、对等体或提供商的出口意图。[1][15][16]
  • 后来的标准澄清了可能的控制。RFC 8212 将显式的导入和导出策略作为 eBGP 的默认要求,而 RFC 9234 增加了感知关系的 BGP 角色和仅向客户属性。它们是回顾性的控制指南,并非 2015 年合规违规的证明。[11][12]
  • 可信的修复声明需要的不只是恢复。它需要通告集的冻结重建、预期的会话策略、前后配置证据、针对同一泄露类别的测试、独立的路由观察,以及证明出口方和接受方都能遏制再次发生的证据。

路由通告成为他人流量的权威

BGP 通常被介绍为告知互联网网络位置的协议。这种描述准确但不完整。BGP 通告也是一种运营权威的声明。

当一个自治系统告诉另一个自治系统某个前缀可通过其到达时,接收方可以优先选择该路径并进一步通告。其他网络随后可以将流量导向被通告的路径。路由不保证通告网络有足够的容量,不保证路径符合商业关系,也不保证每个中间运营商有意提供传输。BGP 分发可达性信息和 AS 路径数据;策略决定了网络接受和重复哪些声明。[8]

正是这个策略层使得 2015 年 Telekom Malaysia 事件具有全球意义。

独立消息来源称,6 月 12 日约 08:43 UTC 开始出现大量通告爆发。Telekom Malaysia 的 AS4788 向 Level 3 的 AS3549 通告了大量路由。Level 3 接受了这些路由并传播给对等体和客户。流量随之改变路径。在路由策略下,通过 AS3549 和 AS4788 的路径可能显得有吸引力,即使互连无法安全承载由此产生的流量。丢包和延迟上升,远在 Telekom Malaysia 自身客户基础之外的服务也变得难以或无法访问。[2][3]

该事件并非伪造证书、域名入侵或最简单的虚假路由源。许多受影响的前缀仍然终止于其合法的起源自治系统。有害的变化是 AS4788 将自己插入作为未曾预料向该方向出口的路由的中转。一个路径在句法上有效、无环且源有效,同时可能违反其学习时的经济和运营关系。

这种区别对问责很重要。如果问题仅描述为“Telekom Malaysia 泄露了路由”,责任似乎止于出口网络。但 BGP 传播在每个会话上都是双向的。一方通告;另一方决定接受、优先选择并进一步通告什么。大型传输网络比孤立客户具有更大的传播能力。这种能力带来了相应的过滤和证据义务。

核心问题并非哪个运营商首先犯错,而是在错误变成其他网络的故障之前,有多少独立控制手段具有实际能力阻止它。

时间线在边缘清晰,在网络内部不完整

BGPMon 报告称 AS4788 在 08:43 UTC 开始宣布大量路由。其监测发现 BGP 更新消息急剧增加,同时出现丢包。分析描述约 179,000 个通告前缀,并以受影响的 Facebook 前缀为例,说明路径经过 AS3549 和 AS4788 后到达合法起源。[2]

ThousandEyes 独立描述了相同的大致序列。它观察到通过 Telekom Malaysia 和 Level 3 的新路径,严重的丢包,以及在阿姆斯特丹、芝加哥、法兰克福、伦敦、洛杉矶、西雅图和华盛顿等地的终端路由。它表示 Level 3 在约 10:45 UTC 停止接受这些路由,服务开始恢复正常。[3]

BGPMon 报告约 10:40 开始改善,约 11:15 广泛清除。这些时间应保留归属。路由收集器、主动测量平台、传输运营商和最终用户不会在同一时刻观察到相同事件。过滤器可以停止新通告,而陈旧路径仍在其他地方被选择。撤销可能不均匀传播。拥塞可能在控制平面触发器移除后仍然存在。因此,恢复是一个序列,而非一个通用时间戳。

RIPE Atlas 后来利用该事件分析核心基础设施的重大故障如何影响端到端连接。它发现了流量绕过压力下的基础设施以及端到端故障的证据。作者明确说明了代表性:即使多样化的全球测量系统也只能观察到有限的路径和目的地。[4]

公开时间线有强大的外部记录和薄弱的内部记录。

外部观察者可以识别大致开始时间、改变的路径、路由更新数量、丢包、延迟和大致的恢复。他们无法看到私有的路由映射、运营商终端、批准的更改、配置的前缀限制、警报队列,或者 Telekom Malaysia 与 Level 3 之间的决策对话。

这一差距应塑造文章的语言。

可以说 AS4788 发出了路由,AS3549 接受并传播了它们,全球可达性受损。可以说模式与将对等体学习的路由导出到上游提供商一致。但不能确定确切的命令、路由器、员工、变更单或软件缺陷,除非有经过认证的运营商记录。

Geoff Huston 的分析在讨论路由策略失败时使用了概率性措辞,并在某些段落中出现了明显的 AS 编号印刷变体。Telekom Malaysia 的网络是 AS4788。文章不应将明显的 AS4877 或 AS4778 引用转化为额外的参与者,或利用它们制造关于内部设备的确定性。[1]

完整的问责记录会将外部时间线与内部证据联系起来:

  • 最后一个已知良好的出口策略;
  • 提议和规范化的变更;
  • 每个路由器或会话接收到变更的时间;
  • 为导出选择的前缀数量和类型;
  • 路由数量和关系违规的警报;
  • AS3549 处的接受和最大前缀状态;
  • 升级联系人和消息;
  • 停止传播的命令或自动化操作;
  • 显示撤销和收敛的收集器证据;
  • 证明修复后的策略拒绝相同路由类别的测试。

没有这一链条,恢复是可见的,但机构学习仍然难以验证。

前缀计数描述不同的视角,而非一个争议事实

大型互联网事件往往吸引一个令人难忘的数字。这里,这种直觉可能使记录不够准确。

BGPMon 写道,AS4788 开始宣布约 179,000 个前缀,后来提到约 176,000 个泄露的前缀。RFC 7908 引用了约 179,000 个前缀的“大规模 Telekom Malaysia 路由泄露”。ThousandEyes 描述了全球路由表的一大部分。[2][3][10]

Huston 的分析使用了事件的不同视图。它显示了涉及数千个新出现和撤销路由的净路由表变化,然后检查了一组 22,577 个特定受影响的路由。[1]

这些数字可以共存,因为 BGP 事件不只一个自然单位。

观察者可以计数每条 UPDATE 消息、每个通过意外路径宣布的唯一前缀、每个在收集器上新出现的前缀、每个改变的最佳路径、每个更具体的路由、每个在选定时间仍然存在的路由、或者每个受影响的起源。收集器接收不同的馈送。一个路由可以被宣布、撤销和重新宣布。有些路径在一个收集器可见,而在另一个则不可见。完整表和过滤后的受影响集回答不同的问题。

负责任的编辑选择是保留测量定义。

文章可以说 BGPMon 和 RFC 7908 在其重建中描述了大约 179,000 个泄露的宣布或前缀。可以说 Huston 的独立分析检查了 22,577 个路由集,并观察到数千个路由表的添加和撤销。它不应平均这些值、选择最大的以增强戏剧性、或将其中一个呈现为用户影响的完整普查。

同样的纪律适用于受影响的服务。BGPMon 和 ThousandEyes 识别了涉及主要平台和金融服务的例子。这些例子说明了范围和连带影响。它们并不确定每个前缀都经历了相同的丢包、每个服务都不可用、或每个用户都通过 AS4788 路由。

当保留其定义时,计数值成为问责证据:

  • 通告计数测试出口量是否异常;
  • 唯一前缀计数测试声称的路由权威广度;
  • 改变的最佳路径计数测试有多少网络选择了泄露;
  • 收集器可见性测试传播;
  • 流量和丢包测试运营损害;
  • 受影响的客户和应用计数测试业务影响;
  • 撤销持续时间测试遏制。

每个度量应有所有者、阈值和保留记录。传输提供商可能接受客户正常的几千个前缀集,但对突然的数量级变化进行隔离。路由监控系统可能会检测到违反客户锥期望的路径,即使原始前缀数量低于静态限制。公开的事后分析可能会解释这两个度量,而不是提供一个标题总数。

错误的精度不仅是写作问题。它可能隐藏哪个控制失败了。

关系策略是 BGP 可达性背后的无形结构

互联网不是一个平坦的网格,每个自治系统都向其他系统提供免费传输。网络购买传输、出售传输并在关系下进行对等,这些关系塑造了路由策略。

一个简化的运营规则如下:

  • 从客户学到的路由可以通告给客户、对等体和提供商;
  • 从对等体学到的路由可以通告给客户,但通常不通告给另一个对等体或提供商;
  • 从提供商学到的路由可以通告给客户,但通常不通告给另一个提供商或对等体。

这些规则产生了熟悉的“无谷”模型。路径可以从客户爬升到提供商,最多跨越一个对等关系,然后下降到客户。一条先下降再爬升的路径可能表明网络正在提供非预期的传输。[1][10]

真实的商业关系更为复杂。两个网络在不同地点、地址族或服务中可能有不同角色。部分传输、付费对等、路由服务器和区域安排并不总是适合单一标签。这种复杂性是记录和测试策略的理由,而不是忽视它的理由。

Huston 的重建表明,AS4788 似乎从交换点对等体收集路由,并重新通告给上游传输网络。在该模型中,横向学到的路由被“上坡”导出。然后 Level 3 接受并传播了这些路径。[1]

协议本身不能从 AS 路径推断每个私密的商业关系。一组合法的 AS 号码并不表明一条路由在合同和运营上是否被允许通过它们。该知识必须编码在本地策略、发布的路由对象、协商的角色、社区、客户锥数据或其他验证系统中。

这就是路由泄露仍然困难的原因。路由器可以从经过身份验证的对等体接收有效的 BGP UPDATE,看到合法的起源,构建无环的 AS 路径,但仍然接受违反预期关系的路由。

因此,运营问责要求网络在可能的情况下使其期望可机器检查:

  • 分类每个 eBGP 会话和每个例外策略;
  • 定义期望从对等体获得的前缀和客户路径;
  • 根据路由学习方式约束导出;
  • 将提议的策略与预期关系进行比较;
  • 拒绝或隔离无法解释的扩展;
  • 保留例外的人工可读解释;
  • 针对代表性完整表条件测试策略。

公开事件显示了当关系意图保持隐含或执行无效时会发生什么。一条路由可以在任何人阅读工单之前跨越一个会话并成为全球性的声明。

AS4788 控制出口,但 AS3549 控制接受和传播

Telekom Malaysia 对离开 AS4788 的通告集拥有最直接的控制。出口网络应知道它起源了哪些路由、从客户学到的、从对等体或提供商的、以及哪些类别可以发送给每个邻居。

这种控制在配置激活之前就开始了。

变更应被编译成路由器将强制执行的实际前缀和 AS 路径策略。审查应将结果与预期的客户锥、路由计数和关系规则进行比较。测试环境或离线评估器应通过策略输入代表性路由并显示将被导出的内容。独立检查应标记为另一个非客户会话选择的从对等体或提供商学到的路由。

公开记录并未确定 AS4788 是否存在此类控制,是否发生了常规配置更改,或者是否触发了潜伏状态。它确定了输出:一个庞大、不安全的路由集被导出。

Level 3 的控制边界是独立的,对全球传播同样重要。

AS3549 选择从 AS4788 接收的路由是否有资格、如何优先选择以及在哪里通告。主要的传输提供商拥有任意第三方不具备的客户特定知识。它可以知道预期的前缀数量、注册的客户路由、观察到的历史、客户锥关系和会话目的。它可以应用:

  • 显式的导入策略;
  • 根据经过身份验证的路由数据导出的前缀列表;
  • AS 路径和客户锥约束;
  • 最大前缀阈值;
  • 路由长度和 bogon 检查;
  • 感知关系的泄露检测;
  • 对异常进行隔离或降低优先级策略;
  • 对异常扩展进行人工批准。

BGPMon 的叙述称 Level 3 接受了这些通告并将其通告给对等体和客户。然后这些路由吸引了流量,并导致了 Level 3 和主要对等点的拥塞。[2]

这并不意味着上游可以保证每个客户的路由都是正确的。静态过滤器可能过时。多宿主客户可以合法更改通告。紧急路由可以扩展集合。复杂策略可能使客户锥难以计算。过于严格的过滤器可能自身导致故障。

但这些成本并未消除提供商的主体性。它们定义了工程问题。

具有全球传播能力的传输提供商应能回答:

  • 对于此客户,正常的路由数量和路径形状范围是多少?
  • 哪些更改需要预先协调?
  • 接受的集合是否包含其他主要对等体或提供商在客户之后的路由?
  • 是否存在最大前缀阈值,并且是否针对实际基线设置?
  • 会话是否有禁用或削弱检查的例外?
  • 哪个警报首先触发?
  • 谁可以在不等待客户的情况下抑制路由?
  • 在调查期间如何保护附带流量?

问责遵循这种限制损害的实际能力。AS4788 的出口错误和 AS3549 的接受并不是互斥的解释。它们是同一传播链中连续的控制失败。

传输集中将策略错误转化为共同损害

并非每个路由泄露都会导致全球事件。破坏范围取决于泄露在哪里被接受、路径变得多么有吸引力、传播多广,以及接收网络是否有容量承载重定向的流量。

Level 3 是主要的全球传输提供商。一旦 AS3549 传播了这些路径,远离马来西亚的网络和客户可以选择它们。通常遵循直接、区域性或更好供应路径的流量被拉向通过 Level 3 和 AS4788 的路径。[2][3]

随之出现了两种损害机制。

第一种是直接的路径改变。目的地前缀可能获得通过 AS3549 和 AS4788 的选定路径。然后数据包向 Telekom Malaysia 传输,即使它不被打算为那个目的地提供全球传输。互连可能饱和,数据包可能被丢弃,延迟可能上升。

第二种是附带拥塞。服务本身不必选择泄露的路径就能受到影响。如果它依赖 Level 3 的容量或拥塞的存在点,异常流量负载可能损害其正常路由。ThousandEyes 描述了例子,其中服务自身的路由保持不变,但 Level 3 内部的拥塞降低了可用性。[3]

第二种机制很重要,因为它将问责透镜扩展到泄露前缀列表之外。共享的传输基础设施可以将损害传递给那些路由策略并非直接错误的客户。容量、隔离和流量工程成为遏制问题的一部分。

网络不能为全球表的任意部分突然选择它们而配置每条链路。经济限制是真实的。但传输提供商可以设计控制,以便异常路由集首先不获得该流量权威。

因此,该事件将路由安全与集中风险联系起来。高度连接的传输网络在正常情况下改善了可达性。同一连接在 unsafe 路由被接受和传播时放大了策略失败。规模既是韧性资产,也是破坏范围倍增器。

负责任的操作应将传播范围视为风险变量:

  • 小型本地客户通告可以使用正常的自动处理;
  • 客户突然通告来自许多不相关大型网络的路由应需要隔离或验证;
  • 将改变多个区域路径的更改应触发由外而内的测量;
  • 提供商应知道哪些存在点和互连将接收重定向的流量;
  • 遏制应可能在不必要地禁用健康客户路由的情况下进行。

目标不是消除自动化。而是使自动化与其授予的权威成比例。

最大前缀控制有帮助,但不是完整的策略

最大前缀限制是针对大规模泄露的直观防御。如果客户正常宣布有界集,突然发送巨大的表,提供者可以警告、拒绝新路由或关闭会话。

BGPMon 建议,异常路由数量也可能触发 Level 3 与其他大型网络会话上的最大前缀限制,从而产生更多的搅动和路径变化。[2]

该观察揭示了简单阈值的价值和危险。

在客户边缘,校准良好的最大前缀控制可以在广泛传播前阻止不可信的扩展。在下游会话中,相同的机制可能在坏路由已经进入主要提供商后反应,可能丢弃整个会话并将流量转移到别处。限制可以遏制一个路径的同时 destabilizing 另一个。

有效的限制需要上下文:

  • 客户的正常聚合和更具体的前缀;
  • 预期增长;
  • 维护和紧急场景;
  • 独立的 IPv4 和 IPv6 行为;
  • 拒绝的路由是关闭失败还是保留最后一个已知良好集;
  • 硬停止前的警报升级;
  • 带有过期时间的回滚安全过程;
  • 在真实流量下测试响应。

路由计数也不能检测每个泄露。客户可能泄露少量极具吸引力的更具体路由。它可能从强大的对等体导出路由而不大幅增加总数量。它可能用类似大小的未授权集替换合法的客户路由。

因此,最大前缀只是其中一层。前缀所有权、客户锥验证、AS 路径关系、路由源标签和异常检测解决不同的故障形式。

事后记录应说明哪些层存在,而不仅仅是“过滤已改进”。事件后添加的最大前缀阈值如果运营商发布了基线、阈值逻辑、响应模式以及使用重建的通告集进行的测试,那就是有意义的证据。

RPKI 源验证不会解决路径策略失败

路由安全讨论经常使用 RPKI 作为 BGP 事件的通用答案。这种简写在这里是危险的。

资源公钥基础设施允许互联网数字资源的持有者创建加密可验证的语句。路由源授权标识哪个自治系统被授权发起一个前缀,受授权的 prefix-length 规则约束。路由源验证可以通过将接收到的通告的前缀和源 AS 与这些授权进行比较来分类。[15][16]

2015 年 AS4788 事件在很大程度上是一个路径策略泄露,而不是简单的未授权源。

对于许多泄露的路由,合法源仍然在 AS 路径的末端。AS4788 将自己插入作为中转,并将路由通告给一个它不被期望的关系。源验证器可以看到授权的源并将其分类为有效,即使该路由违反了对等体/提供商的出口意图。

Huston 的分析直接指出了这一点。在他检查的路由集中,只有少数涉及 AS4788 作为源出现,而这些东西可能通过普通的 ROA 过滤来解决。大多数问题涉及中转信息。[1]

这并不使 RPKI 不重要。源验证可以阻止未授权源、意外的错误起源和许多劫持。它可以减少一类虚假可达性。它还提供经过身份验证的资源信息,可以支持更广泛的控制。

但这意味着控制声明必须精确。

“我们部署了 ROV”并不证明保护了具有有效源但无效关系路径的路由。网络需要额外的信息,关于谁可以为谁提供传输,以及哪些路径与策略一致。RPSL、客户锥数据、社区、BGP 角色、仅向客户属性、ASPA 相关工作以及运营商特定的过滤器以不同的成熟度解决了该问题的一部分。

负责任的信息是多层的:

  • RPKI 验证源权威;
  • 显式的导入和导出策略约束会话;
  • 感知关系的控制约束路径传播;
  • 监控检测静态数据遗漏的异常;
  • 运营协调遏制预防未能阻止的事情。

混淆这些层会产生虚假的保证和薄弱的事后学习。

路由注册表可以发布意图,但过时的意图不是控制

路由策略规范语言旨在描述互联网路由注册表中的路由策略。RPSL 和 RPSLng 可以表达导入和导出策略、自治系统集合、路由集合和相关意图。[13][14]

原则上,提供商可以使用经过身份验证和维护的策略数据为客户生成过滤器。客户可以发布它期望通告的前缀和 AS 关系。对等体可以将观察到的路由与声明的意图进行比较。

Huston 的分析解释吸引力和局限性。注册表数据可能不完整、过时、跨数据库重复或对会话特定关系过于粗粒度。复杂策略可能难以表达和维护。一些注册表历史上允许第三方条目而权限较弱。[1]

错误的教训是路由注册表是无用的。正确的教训是,只有当注册表对象的所有权、新鲜度、范围和使用可验证时,它才是证据。

成熟的过滤流程应记录:

  • 使用的注册表和对象;
  • 认证和维护权限;
  • 最后一次成功刷新;
  • 将 AS 集合扩展为具体前缀和路径;
  • 注册表之间的冲突;
  • 本地例外;
  • 生成的过滤器差异;
  • 路由器部署结果;
  • 监控发布策略与观察策略之间的差异。

MANRS 将路由安全定义为集体的运营责任。其运营商行动强调过滤通告、维护协调联系人以及发布其他人可以验证的信息。当前实施指南讨论了前缀和 AS 路径粒度,并推荐了防止客户学习或中间路由被导出到不适当的非客户对等体的控制。[17][18]

这些当前的文档在现有形式下晚于 2015 年事件。它们应作为控制框架使用,而不是追溯性的法律证据。

该事件显示了为什么框架很重要。一个仅为一个路由器配置所知的策略对另一个网络来说很难验证。发布但从未编译成过滤器的策略只是文档。从过时数据编译的过滤器可能拒绝有效的路由或接受无效的路由。问责需要从声明的意图到部署的行为到观察到的路由的链。

默认拒绝改变失败模式

2017 年发布的 RFC 8212 更新了 BGP 行为,使得 eBGP 会话上的路由在未配置显式策略的情况下既不导入也不导出。[11]

这是一个看似重要的设计选择。

宽松的默认使初始配置期间的可达性变得容易。这也意味着缺失的策略可能悄然变成“接受一切”或“宣布一切”。运营商必须在会话承载路由之前记住添加每个保护规则。

默认拒绝姿态改变了失败模式。缺失的策略导致无路由交换,这是可见且局部的,而不是非预期的全球传播。运营商仍然可以编写错误的显式策略。RFC 8212 也说明了这点。该控制不能解决语义错误、过时的过滤器或故意的例外。

然而,它编码了一个合理的问责原则:全球可达性应需要肯定的策略决定。

对于客户-传输会话,该决定应可审查:

  • 可以接受哪些前缀;
  • 预期哪些起源和客户路径;
  • 可以导回哪些路由;
  • 例外如何批准;
  • 策略数据不可用时会怎样;
  • 哪个系统拥有回滚;
  • 什么证据证明部署。

如果每个相关的 eBGP 边缘都使用了严格的默认和正确的显式策略,缺失的过滤器将失败关闭。公开证据不能显示类似 RFC 8212 的行为是否本可以防止这个具体事件,因为它没有暴露实际的 2015 年配置。RFC 仍然是一个有用的回顾性测试:路由交换是否需要显式的、有界的双边权威?

BGP 角色和仅向客户处理关系信息

2022 年发布的 RFC 9234 标准化了 BGP 角色和仅向客户属性。邻居可以协商角色,如提供商、客户、对等体、路由服务器和路由服务器客户端。传播的路由可以携带有助于强制执行预期关系方向和检测泄露的信息。[12]

这种机制针对 AS4788 事件中可见的差距。合法的源和无环路径不揭示从对等体学到的路由是否可以发送给提供商。关系信息在协议交换中使该策略更明确。

该标准仍然取决于正确的配置和部署。网络必须准确分配角色。复杂关系需要小心。部分采用限制了保护。遗留路由和设备仍然存在。没有协议特性消除了对监控和运营协调的需求。

价值在于双方可以比较期望。单方面的本地标签如果没有即时反馈可能是错误的。协商的角色可以在两端意见不一致时导致会话建立失败或标记路径。仅向客户属性可以帮助识别不应传播到另一个提供商或对等体的路由。

再次,这是后来的指导。说 AS4788 或 AS3549 未能在 2015 年使用 2022 年标准在历史上是不准确的。

该事件反而提供了测试用例:

  • 从对等体学到的路由能否在没有可检测的策略违规的情况下导出到上游?
  • 上游能否识别出客户的路径包括预期客户关系之外的路由?
  • 任何一方能否在全局传播之前阻止该路由?
  • 证据是否区分策略例外和意外泄露?

现代角色感知机制应针对重建的 AS4788 类路由集进行评估,而不仅针对匹配干净拓扑的合成示例。

监控必须将路由与意图比较,而不仅仅是可用性

可用性监控在用户开始失去可达性后检测损害。路由监控可以更早地识别控制平面异常。

2015 年的公开记录通过几种形式的观察得以保存:

  • BGPMon 处理更新流并识别通告爆发;
  • RouteViews 和 RIPE RIS 保留了原始 BGP 档案;
  • ThousandEyes 结合了路由和网络测量;
  • RIPE Atlas 提供了主动端到端测量;
  • 独立分析师比较了路径、前缀计数和时间安排。[2][3][4][5][6]

这些系统看到了不同的片段。这种多样性是优势。单一提供商的内部视图可能错过其路由在其他地方的样子。主动探测可以看到丢包,但不能看到导致丢包的策略。路由收集器可以看到 AS 路径,但不能看到每个流量路径或私密会话。

现代检测系统可以使用拓扑、AS 关系、路由历史和异常传播来寻找路由泄露。Cloudflare 描述了公开的路由泄露检测作为表面异常路径的一种方式,而 RIPE Atlas 文档支持从分布式探测进行可重复测量。[19][20]

检测应与行动挂钩。

一个说“路由计数增加”的警报,如果没有所有者拥有阈值或能够抑制路由,则是弱的。有用的事故路径定义了:

  1. 预期的关系和路由集;
  2. 异常条件;
  3. 置信度和假阳性处理;
  4. 有权隔离的运营商;
  5. 安全的遏制行动;
  6. 外部确认;
  7. 证据保留;
  8. 事后审查。

第一响应并不总是需要丢弃整个会话。提供商可以降低优先级、隔离意外路由、保留最后一个已知良好的接受集,或仅拒绝客户锥之外的路径。正确的行动取决于路由器的能力和客户设计。

监控还应区分预防和检测。在全局传播后发布路由泄露警报是有价值的公开证据。它不能证明提供商有传播前控制。问责报告应说明哪个阶段检测到事件,哪个阶段停止了它。

安全的路由策略更改需要当前字节证据

路由配置在到达路由器之前通常经过模板、数据库、自动化、策略编译器和特定于供应商的语法。人类审阅者可以批准一种表示,而设备接收另一种。

证据链应在每个阶段绑定当前字节:

  • 源策略或更改请求;
  • 规范化的关系和前缀数据;
  • 生成的路由映射或策略语言;
  • 设备特定配置;
  • 候选配置差异;
  • 已提交的配置哈希;
  • 产生的公告和接受的路由集;
  • 外部收集器观察。

这很重要,因为“策略已审查”是模糊的。审查了哪个版本?自动化作业是否在审批后扩展了 AS 集?过时的注册表快照是否产生了过滤器?手动紧急命令是否绕过了正常流程?所有路由器是否收到相同的输出?

负责任的更改系统应在这些绑定存在差异时失败。

在部署之前,它应通过编译的策略重放代表性路由。对于 AS4788 类条件,测试应包括:

  • 客户起源的路由;
  • 客户锥路由;
  • 对等体学到的路由;
  • 提供商学到的路由;
  • 包含大型传输网络的路由;
  • 意外的更具体;
  • 突然的全表规模输入;
  • 混合有效和无效的公告。

测试应断言正面和负面行为。有效的客户路由必须继续通过。对等体和提供商学到的路由不得向上游逃逸。接受提供商应独立拒绝与客户预期角色不一致的路径。

部署后,路由收集器或 looking glasses 应验证可观察的结果。单独的配置哈希不能证明路由器只通告了预期的路由。控制平面状态、设备错误以及与其他策略的交互可能改变有效行为。

这种当前字节纪律不是为官僚而官僚。它是组织如何证明正在讨论的代码、策略和路由是产生或防止了损害的那些对象。

恢复不等于验证的修复

公开来源显示,路由被撤销或停止接受,服务在接下来的几个小时内恢复。那是运营恢复。

修复问一个更难的问题:同一类别的路由能否再次逃逸?

可信的补救计划会从 RouteViews、RIPE RIS 和内部日志中冻结一个代表性的事件集。它会识别每个路由的预期关系,并在测试环境中重现出口和进口决策。

对于 AS4788,测试将验证从对等体或提供者学到的路由不能被选择向 AS3549 导出,除非有明确的、经过审查的例外。对于 AS3549,测试将验证客户不能在没有隔离的情况下宣布预期客户锥之外的路径或超过合理容量。

然后计划会生成证据:

  • 修复前的失败测试;
  • 策略或系统更改;
  • 修复后的通过测试;
  • 设备和软件版本;
  • 部署覆盖范围;
  • 警报和遏制演练;
  • 外部路由观测;
  • 例外清单和有效期;
  • 持续监控的所有权。

修复还应测试降级条件。如果注册表数据不可用会怎样?系统是失败关闭、使用最后一个已知良好集还是接受一切?如果异常检测器下线会怎样?运营商能否通过独立的管理路径隔离会话?最大前缀停止是保存关键客户路由还是全部丢弃?

公开披露不需要暴露私密商业条款或可利用配置。它可以说明失败类别、受影响的策略边界、添加的控制、测试方法、部署覆盖和验证日期。

没有这些证据,“我们修复了过滤器”是关于意图的声明。有了它,客户和对等体可以评估运营商是否改变了允许全局传播的系统。

问责不应退化为个人指责

互联网路由泄露通常变成一个关于工程师输入错误命令的故事。这里的公开记录没有确定那个故事。即使单个行动触发了事件,全球影响需要多个系统和组织决策。

运营商设计配置界面。它选择更改是生成还是手写。它定义对等体和提供商关系。它决定哪些测试是强制性的,是否需要第二审查员,策略传播多快,以及回滚是否独立。

传输提供商决定在客户通告中放置多少信任,哪些过滤器在经济和运营上可行,以及什么异常将触发遏制。领导层决定路由安全工作是否有人员、维护窗口和中断收入流量的权限。

个人指责可以掩盖这些控制。它也可以阻碍披露。更好的问责模型问:

  • 谁有能力阻止路由离开?
  • 谁有能力拒绝它?
  • 谁有能力限制其传播?
  • 谁能独立检测损害?
  • 谁能撤销或隔离?
  • 谁保留了证据?
  • 谁有权资助和验证补救?

这些问题可以识别责任,而不声称公开来源未证明的意图或疏忽。

它们还能防止责任溶解为“互联网是去中心化的”。去中心化意味着没有单一运营商控制每个路径。它并不意味着每个运营商缺乏对自己通告、会话和传播决策的控制。

客户和对等体可以合理要求什么

大多数客户不能审计传输提供商的 router。对等体不能看到每个私密更改过程。他们仍然可以要求与依赖关系相适应的证据。

在事件之前,运营商可以发布:

  • 准确的路由联系人;
  • 注册的前缀和自治系统;
  • 路由和 AS 集合;
  • 高级别的对等和过滤策略;
  • RPKI 覆盖;
  • 对相关角色和验证机制的支持;
  • 状态和事件频道。

在事件期间,它可以沟通:

  • 受影响的路由或会话类别;
  • 通告是否仍在传播;
  • 遏制行动;
  • 已知区域和服务;
  • 测量不确定性;
  • 恢复证据;
  • 下次更新时间。

在事件之后,它可以提供:

  • 来源和接受边界;
  • 路由计数定义;
  • 带有来源的时间线;
  • 失败的控制;
  • 遏制损害的控制;
  • 可测试的补救;
  • 剩余限制。

客户也应测试自己的暴露。多宿主并不保证独立性,如果两个提供商依赖同一上游。备用路由可以存在,但在本地偏好下丢失。更具体的通告可以覆盖预期的多样性。流量可以避免泄露的路径,但在共享传输提供商中遭受拥塞。

独立路由监控、RIPE Atlas 测量和 looking-glass 检查可以揭示部分暴露。[4][5][6][20]

责任是成比例的。关键公共服务或金融平台应比低影响个人网站更深入地理解上游集中。但没有客户能完全补偿传输提供商接受和传播大规模不安全路由集的情况。

公开记录不能证明什么

来源集支持强大的网络问责分析,但不支持完整的内部事后分析。

它不能证明:

  • 确切的 Telekom Malaysia 路由器或位置;
  • 确切的配置命令或模板;
  • 触发器是计划变更、过时状态、自动化故障还是人为错误;
  • 软件或硬件版本;
  • AS4788 和 AS3549 之间的私密关系条款;
  • 任何一方的确切导入、导出和最大前缀设置;
  • 第一个内部警报和运营商响应;
  • 私密协调消息;
  • 跨所有收集器的一个协调前缀计数;
  • 受影响用户或财务损失的完整普查;
  • 法律责任或合同违约;
  • 任何一方部署的持久补救。

数据包也不应将后来的控制转化为历史要求。RFC 8212 于 2017 年发布,RFC 9234 于 2022 年,当前 MANRS 实施指南反映了后来的运营工作。它们定义了有用的现代测试。它们不证明 2015 年存在哪些配置或义务。[11][12][18]

同样,当前的 RIPEstat 数据是当前的网络资源上下文,不是冻结的 2015 年注册表快照。[7]

这些边界使结论更可信。可观察的失败足以识别分散的控制。缺失的内部记录本身就是问责差距,但它不是发明一个的许可。

可复用的上游过滤问责测试

该事件支持任何在有意义规模下运行 BGP 的客户、传输提供商或对等体的实践测试。

1. 为每个会话定义关系。
在策略不同的粒度上记录提供商、客户、对等体、路由服务器和例外角色。

2. 将预期路由绑定到经过身份验证的证据。
维护前缀、起源、客户锥、AS 集合和例外,具有所有权、新鲜度和来源。

3. 在部署前编译策略。
显示导入和导出策略将接受的具体路由和路径。审查有效行为,而不仅仅是模板文本。

4. 在缺少显式策略时失败关闭。
不应因过滤器缺失或数据检索失败而使 eBGP 路由获得全局权威。

5. 测试关系违规。
针对客户和上游会话重放从对等体和提供商学到的路由。验证无效方向在出口方和接收方都被拒绝。

6. 校准容量控制。
根据正常行为、合理增长和紧急情况设置最大前缀和异常阈值。定义安全遏制而不只依赖全会话关闭。

7. 分离源和路径验证。
使用 RPKI 进行源权威,但不要将 ROV 描述为关系有效传播的证明。添加路径和客户锥控制。

8. 从外部监控。
使用独立收集器和主动测量将观察到的路由和可达性与预期策略进行比较。

9. 为遏制指定所有者。
识别谁可以在正常更改时间之外隔离路由、降低优先级、恢复最后一个已知良好集或重置会话。

10. 保留当前字节证据。
绑定批准的策略、生成的配置、部署的字节、路由状态、警报、决策和外部观察。

11. 用原始事件类别证明修复。
通过会议双方运行重建的泄露,并显示它在哪里停止。测试语义变体,而不仅仅是保存的前缀列表。

12. 发布足够的信息以便依赖网络验证。
解释控制边界、路由计数定义、补救和剩余不确定性,而不暴露敏感的私密条款。

这个测试并不承诺路由泄露消失。它使预防、遏制和证据义务在每个可以授予路由进一步权威的网络中明确。

结论

2015 年 6 月 12 日 Telekom Malaysia 路由泄露展示了本地路由策略如何迅速成为全球基础设施损害。

AS4788 发出了非常大的路由集。AS3549 接受并传播了它们。流量转移到通过 Level 3 和 Telekom Malaysia 的路径。丢包、延迟和可达性故障跨区域蔓延,影响了直接改道的服务和暴露于共享传输网络中拥塞的用户。独立路由收集器和测量平台保存了公开轮廓。[1][2][3][4]

该事件不能负责任地解释为一个网络的一个坏通告。出口和导入是分开的控制。客户有责任只通告授权的路由。传输提供商有责任与其接受和传播这些路由的能力相称。对等体和下游网络有额外的监控和导入控制。没有一层能保证完美,但每一层可以防止一个错误获得更多传播。

RPKI 源验证有价值且不足以应对这种路径策略失败。路由注册表可以发布意图,但仍可能过时。最大前缀控制可以控制容量,但仍可能错过较小的泄露。后来的默认拒绝和感知关系标准改善了控制模型,但不会追溯证明 2015 年违规。持久的答案是分层的:显式策略、经过身份验证的路由数据、关系检查、校准的限制、独立监控、快速遏制和可复现的修复。

风险跟随通告可以获得的传播范围。问责遵循谁能够限制该传播,谁选择传播它,以及谁能证明相同的失败类别现在会在其他人流量成为测试之前停止。

来源

  1. https://labs.ripe.net/author/gih/more-leaky-routes/
  2. https://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/
  3. https://www.thousandeyes.com/blog/route-leak-causes-global-outage-level-3-network
  4. https://labs.ripe.net/author/emileaben/does-the-internet-route-around-damage-a-case-study-using-ripe-atlas/
  5. https://archive.routeviews.org/bgpdata/2015.06/UPDATES/
  6. https://data.ris.ripe.net/rrc00/2015.06/
  7. https://stat.ripe.net/AS4788
  8. https://www.rfc-editor.org/rfc/rfc4271.html
  9. https://www.rfc-editor.org/rfc/rfc7454.html
  10. https://www.rfc-editor.org/info/rfc7908
  11. https://www.rfc-editor.org/rfc/rfc8212.html
  12. https://www.rfc-editor.org/rfc/rfc9234.html
  13. https://www.rfc-editor.org/rfc/rfc2622.html
  14. https://www.rfc-editor.org/rfc/rfc4012.html
  15. https://www.rfc-editor.org/rfc/rfc6480.html
  16. https://www.rfc-editor.org/info/rfc6811
  17. https://manrs.org/netops/
  18. https://manrs.org/specifications/MANRS-007/01/
  19. https://blog.cloudflare.com/route-leak-detection-with-cloudflare-radar/
  20. https://atlas.ripe.net/docs/