Cloudflare、2019 年 6 月的路由泄漏以及网络边界之外的责任追究

摘要

• 2019 年 6 月 24 日，DQE Communications 网络内部生成的优化、更具体路由通过客户 AS396531 传递，并被 Verizon 的 AS701 接受。Verizon 随后传播了覆盖数千个网络的路径。由于路由器倾向于更具体的目的地前缀，大量流量沿着泄漏路径流入未经调整以承载它的链路；Cloudflare 报告称，在事件最严重时，其全球流量损失约 15%。
• 公开路由记录表明这是一系列控制失效，而非单一原因的口号。路由生成器未能将优化路由限定在本地，一个多宿主客户将提供商学到的路由导出给另一个提供商，而一家主要中转网络接受并传播了不符合客户预期路由权限的路由。Cloudflare 能够检测、沟通并帮助撤回路由，但无法单方面更改其他网络的导入策略。
• RPKI 路由源验证对此次事件的 Cloudflare 部分尤为适用，因为 Cloudflare 的路由源授权仅允许其聚合前缀达到声明的最大长度。泄漏的更具体前缀超出了该长度，因此是无效的。这并不意味着 RPKI 是完整的路由泄漏解决方案：源有效的路径仍可能违反商业关系，这就是客户过滤、前缀限制、BGP 角色、路径控制、监控和可联系的操作联系人依然必要的原因。
• 责任跟随控制能力。生成或导出异常路由的运营商必须加以限制和测试；提供商必须核实客户可宣告的内容；云平台必须发布路由权限、观察外部路径、快速协调并披露客户影响；客户必须为依赖关系失败做好规划；董事会和监管机构应要求提供可衡量的路由安全保证，而非仅仅声称遵循行业最佳实践。

路由中断，而非 Cloudflare 服务器故障

协调世界时 2019 年 6 月 24 日 10:34:25，公共 BGP 收集器开始记录到 Cloudflare 地址空间的异常、更具体路由。所研究的最后一条 Cloudflare 路由于 12:38:54 UTC 消失。Cloudflare 的存档路由深入分析利用 RIPE NCC 数据重演了该时段，并显示出一条非常一致的路径：Cloudflare 的 AS13335、其中转提供商之一 DQE Communications 的 AS33154、Allegheny Technologies 的 AS396531，以及 Verizon 的 AS701。其他网络随后通过 Verizon 学习到该路由。

该路径之所以重要，是因为中断并非始于 Cloudflare 数据中心故障或应用部署。Cloudflare 的机器持续宣告其常规聚合路由。全球路由系统只是学习了同一地址空间中更小块的竞争路由。这些更小块在许多网络的路由决策中胜出，将数据包引向非预期路径。在请求到达 Cloudflare 边缘之前，便出现了拥塞和丢包。

Cloudflare 的事件说明报告称，在最严重时大约损失了 15%的全球流量。这是公司测量值，而非经独立审计的普遍中断百分比。它描述的是 Cloudflare 流量，而非整个互联网的 15%。尽管如此，独立观察支持了大体机制及跨服务影响。ThousandEyes 在其网络路径分析中报告称，用户在大约两小时内难以访问 Cloudflare 前端服务及部分 AWS 服务，而 Catchpoint 的事件回顾记录了大约 10:30 UTC 时多个指名在线服务的性能问题。

路由可用性与服务器可用性之间的区别对责任追究至关重要。一家平台可以在众多国家运行健康的服务器，但如果路由控制平面将流量导向别处，它仍然无法访问。客户体验到的只有一种结果：超时、错误和不可用的应用。然而，工程原因决定了哪些控制措施可以防止损失，以及哪一方可以操作这些措施。

Cloudflare 的状态记录中，首先描述了网络性能问题，随后识别出可能的路由泄漏，之后称责任网络已修复。公开的状态更新副本显示，调查通知时间为 11:02 UTC，识别时间为 11:36 UTC，修复后监控于 12:42 UTC 开始。BGP 存档在首次状态通知前已显示出异常路由。这一差异并不证明 Cloudflare 对已知事件疏忽了 28 分钟。这是一个有用的问责问题：自动化系统何时检测到异常流量，工程师何时确定外部路由为原因，以及公司何时有足够信心通知客户？

没有公开证据表明此次事件中存在恶意意图、流量检查或 Cloudflare 系统受损。路由泄漏可能创造拦截机会，但此处观察到的服务损害是沿非预期路径的拥塞和丢包。因此，本文将此事视为可用性和路由完整性失效。它并未将路由泄漏可能的安全属性转化为流量被读取的指控。

本地优化如何变成全球路由

互联网是自治系统间的协议，而非集中调度的网络。每个自治系统使用边界网关协议（BGP）告知相邻系统它可以到达哪些 IP 前缀，以及通过怎样的 AS 路径。核心协议在RFC 4271中赋予了运营商相当大的策略自由。这种灵活性支持商业对等互联、付费中转、多宿主、流量工程和本地偏好。但这也意味着，从邻居收到的路由并不附带普遍证明，表明路径中的每个 AS 都有意让该宣告传播如此之远。

事件发生前，DQE 使用了 Noction 的 BGP 优化产品。此类产品可以度量路径性能，并注入更具体的路由，以影响选定流量走哪条链路。在 Cloudflare 公布的示例中，常规的104.20.0.0/20宣告被分为104.20.0.0/21和104.20.8.0/21。这两个/21 覆盖了与/20 相同的地址范围，但每个都指定了更小的目标块。

在受控网络内部，更具体路由可以是合法的流量工程工具。危险在于范围。这些路由本来旨在影响 DQE 的内部决策。DQE 将它们宣告给 AS396531。AS396531 同时连接 DQE 和 Verizon，并将学习到的路由导出给 Verizon。Verizon 从其客户处接受并进一步传播。一条本地指令变成了全球声明。

Noction 的6 月 26 日事件响应承认其平台生成了更具体路由，并描述了三种复合条件：在其客户网络内生成、通过下游 ASN 泄漏至一家主要提供商，以及三个自治系统均过滤不足。Noction 辩称创建更具体路由是常见做法，而非固有缺陷，并强调了提供商过滤。该回应之所以相关，是因为它确认了优化器的作用，同时质疑了单一责任方的说法。它并非独立的事后分析，也未公开 DQE 部署的确切配置、变更记录或测试证据。

Qrator Labs 的独立路由分析将开始时间与 AS396531 和 Verizon 之间 BGP 会话在 10:35 UTC 后不久重新建立关联起来。其说明称 AS396531 丢失了过滤器，并导出了从 DQE 学到的路由。这为事件为何在此时发生提供了一个合理的触发解释，但现有公开记录并未包含 AS396531、DQE 或 Verizon 的路由器配置或日志。稳妥的结论更为狭窄：可观察的路径证明路由跨越了这些 AS 边界；运营商说明指出了丢失或不足的过滤器；确切的内部变更序列仍属非公开。

这一区分防止了三种常见错误。第一，不应将 DQE 描述为 BGP 意义上 Cloudflare 地址空间的源头。观察到的 AS 路径仍然以 Cloudflare 的 AS13335 结尾。DQE 的优化器创建并传播了一条保留了合法源头的更具体路径。第二，Verizon 并未发明这些路由，但其接受和全球传播极大地扩展了其影响范围。第三，Cloudflare 的网络并未选择 AS396531 作为优选路径。远程网络根据收到的广告做出转发决策。

为何更具体路由击败了距离和任播

对于非专业人士来说，此事件听起来可能像是路由器选择了更短的 AS 路径。但决定性的优先选择发生在更早的阶段。互联网转发使用最长前缀匹配：覆盖最具体目标块的路由会胜出覆盖更宽泛块的路由。RFC 4632，即无类别域间路由规范，描述了这种最长匹配行为及其与聚合路由和更具体路由的关系。

假设某台路由器知道 Cloudflare 的104.20.0.0/20可通过一家常规提供商到达，同时也通过 Verizon、AS396531 和 DQE 学习到104.20.0.0/21。一个位于第一个/21 内的目的地会同时匹配两条宣告。/21 更为具体，因此即使其 AS 路径更长或在操作上不合理，它也会胜出。正常的路径属性在通往相同前缀的路由中做出选择；它们不会让一个正常的/20 击败一个被接受的/21。

这就是 Cloudflare 的任播覆盖未能自动绕开问题的原因。任播允许多个 Cloudflare 位置宣告相同的前缀，让 BGP 选择合适的实例。它提供地理分布，并能够吸收个别站点或链路的故障。但泄漏的/21 比 Cloudflare 的常规/20 宣告更具体。全球路由系统在比较哪个 Cloudflare 任播位置最近之前，便可能优先选择/21。失败路由背后的冗余并未恢复流量。

非预期路径还集中了负载。AS396531 及其连接并非为 Cloudflare、Amazon、Linode 及众多其他受影响网络提供全球中转而设计。被更具体宣告吸引的流量进入了一条容量或策略不足的通道。数据包被延迟或丢弃。路由泄漏有时可通过低效路径发送流量；但在此事件中，规模使该路径变成了瓶颈。

互联网工程任务组的RFC 7908 路由泄漏分类将路由泄漏定义为超出宣告预期范围的传播。2019 年 6 月的事件结合了该分类出于分析目的而分开的特征。它涉及多宿主网络将从提供商学到的路由导出给另一提供商，类似于典型的发夹弯模式，以及从未打算全球传播的内部有用更具体路由。标签不如被违反的不变量重要：Verizon 的一家客户看似为超出其合法客户锥的前缀提供中转，而 Verizon 接受了这一表象。

时间线与扩大的问责窗口

随着事件从预防转向检测和恢复，责任也在变化。以下时间线使用了公开路由数据和运营商归属声明；它并未用假设的内部行动填补空白。

最重要的时期始于首个时间戳之前。如果董事会从 10:34 开始审查，它将聚焦于告警和通话。如果从优化器路由被授权用于生产时开始，它就能检查设计安全、路由范围、故障关闭默认值、对等策略、变更审查和独立传播测试。事件响应缩短了持续时间。预防性控制决定了是否存在需要响应的事件。

四次过滤机会均朝同一方向失效

路由跨越了数道边界，每道边界都有不同的阻止机会。将这些机会视为层次，可明确责任，而不必假装所有各方控制力相等。

优化器及源网络限制。DQE 控制了 Noction 产品生成更具体路由的环境。仅供本地决策使用的路由需要一道不依赖每个下游行为正确的导出屏障。可选方案包括严格的导出策略、专用路由上下文、每个出口理解的显式团体属性、来自外部收集器的自动化检查，以及与非预期传播绑定的切断开关。Noction 表示其进行了部署测试，并讨论了NO_EXPORT的使用，但也辩称NO_EXPORT并不适合每种多 AS 设计。该众所周知团体属性在RFC 1997中定义：承载它的路由不应在联盟边界之外宣告。在此事件中，它是否被使用、保留、移除或从未附加，公开资料未予证实。

多宿主客户导出控制。AS396531 不应将一家提供商的全部或优化路由提供给另一家提供商，除非它有意作为中转网络运营。叶节点或企业网络可应用简单的出站规则：仅宣告自己的授权前缀和明确批准的客户前缀。默认拒绝比试图识别每条不得离开的路由更为可靠。RFC 8212于 2017 年发布，规定了在未配置明确导入或导出策略时，默认拒绝外部 BGP。它无法阻止运营商附加错误的宽松策略，但能消除因策略缺失导致的一类意外传播。

提供商客户导入控制。Verizon 拥有最高杠杆的阻止点。中转提供商知道哪个会话是客户会话，并应知晓该客户被授权发起或中转的内容。Cloudflare 的深入分析发现，与该客户关联的路由注册信息并不包含 Cloudflare 的 ASN 或其他泄漏网络的 ASN。因此，基于客户的前缀和 AS 路径过滤本可拒绝这些宣告。2015 年发布的RFC 7454 BGP 运营和安全指南建议了在每个边界对接收和宣告路由的策略、客户前缀控制、AS 路径过滤以及最大前缀限制。

下游和对等体拒绝。从 Verizon 接收路由的网络也有机会拒绝它们。由于 Verizon 是一家大型中转网络，许多接收者给予其宣告相当的信任。部分使用路由源验证的网络本可将受影响的 Cloudflare 更具体路由作为 RPKI 无效路由拒绝。其他网络则可使用路由泄漏启发式规则或对等策略。然而，要求每个远端网络在一家主要提供商分发后捕捉错误，不如在原始客户会话上拒绝高效。在最靠近策略违反处预防，可在全局收敛将配置错误变为分布式中断之前限制传播。

这些层次独立程度不足。DQE 的优化、AS396531 的导出和 Verizon 的导入均依赖于正确的路由策略配置。如果每一层都是手动宽松的，或基于不完整的客户记录构建的，那么三道控制可能同时失效。因此，成熟的保证计划会从管理域外部测试结果。它不会仅凭配置审查就接受路由已被限制在本地。

RPKI 本可阻断这些路由，但它并非全部答案

Cloudflare 在 2018 年已开始签署路由并部署验证，如其RPKI 部署记录所述。路由源授权（ROA）指出哪个自治系统可以发起某前缀，以及可选地，它可以宣告的最具体前缀长度。Cloudflare 称其相关路由授权 AS13335，最大长度为/20。泄漏的/21 保留了 AS13335 作为源，但超过了授权的最大长度。因此，根据路由源验证，它们是无效的。

该逻辑在RFC 6811中被正式化。如果经过验证的 ROA 负载覆盖了前缀，源 ASN 匹配，且路由前缀长度不超过 ROA 的最大值，则接收的路由有效。当存在覆盖的授权，但没有一个满足所有所需属性时，则为无效。RIPE NCC 的源验证说明有效地区分了有效、无效和未知状态，并强调网络运营商仍需决定对这些状态应用何种策略。

Cloudflare 创建 ROA 的行为是必要但不充分的。ROA 是公开的证据，而非远程执行命令。Verizon 或其他接收网络必须检索经过验证的 RPKI 数据，对客户路由应用验证，并拒绝无效路由。Cloudflare 可以拒绝进入其网络的无效路由，但这并不能阻止第三方网络沿他处选择的路由发送发往 Cloudflare 的流量。路由安全具有对等结构：地址持有者发布授权，而其他运营商使其生效。

对于此次事件，RPKI 是一项特别强大的预防控制，因为优化器改变了前缀长度。将这一成功条件推广到所有路由泄漏则是错误的。如果 AS396531 泄漏了 Cloudflare 的常规/20，同时保留 AS13335 在路径末尾，源验证可能会认为该路由有效。但该路由仍会违反预期的提供商-客户拓扑。RPKI 源验证回答了谁可以发起某个前缀以及长度多少。它并不证明 AS 路径中的每个中转关系都经过授权。

这一界限并非对 RPKI 的批评。这正是将其与其他控制措施配合部署的原因。NIST 的SP 800-189 指南将 RPKI 和 BGP 源验证与前缀过滤及更广泛的域间韧性实践相结合。它将路由泄漏、劫持、流量绕行、拒绝服务和性能下降视为相关的运营风险，需要层次化应对。2019 年 6 月的事件是一个异常具体的证明：一层可以拒绝确切的错误前缀，而基本的客户过滤即使没有密码学，也可以拒绝不合理的权限路径。

maxLength中也存在治理教训。过于宽松的 ROA 可能使未经授权的更具体路由看起来有效；过于严格或过期的 ROA 则可能导致合法路由被拒绝。ROA 覆盖范围、最大长度、过期时间、密钥和存储库健康状态以及计划中的路由变更都需要变更控制。一张显示 ROA 存在的仪表盘，并不证明它们准确描述了生产意图。

2019 年后的路径策略控制

此次中断后，标准和政策格局继续发展。不应将后续控制措施描述为运营商本可在 2019 年 6 月部署的成品，但它们展示了业界如何试图将以往隐含的假设编码化。

RFC 9234于 2022 年发布，引入了 BGP 角色和仅至客户（OTC）属性。相邻网络可以声明关系为提供商、客户、对等体、路由服务器或路由服务器客户端。角色协议和 OTC 处理允许路由器检测某些跨越关系边界并处于不允许方向的宣告。在 2019 年路径的简化版本中，一条从提供商学习并发送给另一提供商的路由，其携带的证据应与客户专用导出不一致。BGP 角色将部分商业拓扑知识从运营商惯例转换为协议可见状态。

Peerlock 提供了另一种聚焦路径的方法。2020 年的论文《Flexsealing BGP Against Route Leaks》研究了这种由运营商部署的机制，包括其阻止受保护大型网络出现在不应出现位置的路径的能力。Peerlock 在此论文之前及 2019 年 6 月事件之前便已存在，但其部署依赖于双边知识和配置。它证明了实用的路径过滤是可能的，但并非证明存在通用的现成控制措施。

自治系统提供商授权（ASPA）旨在让 AS 通过 RPKI 系统发布可验证的提供商关系。它很有前景，因为许多路由泄漏属于路径合理性失败而非源失败。但它也需要谨慎措辞：ASPA 的标准和部署状态在演进，部分覆盖会产生未知路径。它应被视为一种额外的验证信号，而非回溯性证据，表明 2019 年的参与者违反了当时强制性的加密路径标准。

检测方面也已成熟。Cloudflare 后来描述了其Radar 路由泄漏检测服务，该服务利用路由关系和观察到的路径标记可能的泄漏。监控减少了知晓协调的时间，但不能阻止路由器接受该路由。如果修复途径是人工电话链，两小时的事件仍可造成全球损害。检测必须与演练过的行动相衔接：识别受影响前缀、在安全处应用防御策略、联系授权运营商、发布客户状态、通过独立收集器验证撤回，以及观察流量恢复。

因此，有用的控制模型是累积性的：

1. 通过 IRR 对象和 ROA 发布准确的路由权限。
2. 从可信数据生成客户导入过滤器并安全刷新。
3. 默认拒绝缺少明确策略的路由。
4. 强制执行客户锥、AS 路径、前缀长度和最大前缀期望。
5. 在每个相关的外部入方向拒绝 RPKI 无效宣告。
6. 添加关系感知控制，如 BGP 角色、OTC、Peerlock 以及随着成熟度提高的 ASPA 验证。
7. 从独立的外部观察点观察传播。
8. 保持持续测试的运营联系人和路由撤回权限。

没有哪一项可以替代其他项。它们的价值来自不同的失效模式。

在不虚构法律责任裁定的情况下分配责任

公开技术记录支持责任分析，但它不包含法院判决、监管命令或完整的合同集，在 DQE、AS396531、Verizon、Noction、Cloudflare 和受影响客户之间分配法律责任。在本文使用的记录中未找到公开的 Verizon 根因报告。因此，以下分配是运营层面的：谁控制了哪项防护措施，谁能减少哪项风险。它并非损害赔偿的百分比分配。

DQE Communications。DQE 控制了优化路由生成的网络及其到达 AS396531 的关系。其最高价值职责是限制路由范围、测试外部可见性、维护正确的导出策略，并在联系后停止宣告。Cloudflare 赞扬 DQE 人员协助撤回了路由。快速合作缩短了持续时间；但这并不能抹去预防控制失效。

AS396531。该多宿主网络是提供商之间的桥梁。其朝向 Verizon 的可观察宣告，使其看起来为通过 DQE 学到的路由提供了可达性。一个非中转企业应导出一个狭窄的允许列表，而非学到的完整表。公开记录未指明移除或绕过过滤的工程师、厂商或变更，因此个体指责将是推测。组织责任在于允许一次会话恢复将路由暴露于该企业权限之外的设计。

Verizon。Verizon 面向客户的导入策略是最具后果的未行使控制。一家接受客户数千条路由的大型中转网络，应核实授权前缀、预期源和路径，以及前缀数量。路由存档显示 Verizon 传播了该路径。Cloudflare 称相关 IRR 数据和 RPKI 验证本可拒绝它，并报告事件期间难以联系到 Verizon。没有 Verizon 的内部记录，无法说明过滤器是缺失、过时、误用、绕过还是以其他方式失效。每种可能性都指向与其提供商规模相称的保证和事件协调职责。

Noction。一个能够创建全球优选更具体路由的路由优化器，若限制失效，则存在可预见的严重后果失效模式。产品责任包括安全默认值、显著的风险警告、部署验证、路由标记、外部泄漏测试、回滚，以及使侵入模式难以在未经验证边界时启用的控制措施。Noction 的回应称其在部署期间测试了传播，且过滤器仍是强制性的。该声明引发下一个审计问题：产品是否在对等或会话变更后持续验证限制，还是仅在调试时？一次性测试无法无限期地证明动态路由环境的安全。

Cloudflare。Cloudflare 既未生成也未传播非预期路径，且无法配置 Verizon 的客户会话。但它向客户出售了建立在全球路由基础上的可用性和安全服务。因此，其责任在于剩余控制：准确的 ROA、多样化的互联、外部路由监控、快速诊断、可联系的对等联系人、客户沟通、缓解选项和透明的信息披露。它还有义务不过度宣称其架构所能承受的。任播和大型全球网络可以减轻许多故障，但若无验证网络的帮助，无法击败一条被全球接受的更具体路由。

其他网络。接受 Verizon 路由的对等体和下游网络，在了解 AS396531 客户授权方面并不处于平等地位，但它们可以部署 RPKI 验证和路径控制。它们的决策影响了自身用户，在某些情况下也影响了进一步传播。当大型中转网络正确行事时，系统更安全；然而，接收网络仍对其安装的路由负责。

这种分配避免了那种方便但无益的说法，即 BGP 基于信任，因此无人负责。信任通过配置、注册、合同和运营实践来实现。它们是可控的。协议的开放性解释了故障为何会扩散；它并不能为提供商不筛选客户路由开脱。

Cloudflare 的商业责任经受住了外部原因的考验

外部触发并不会免除云提供商对客户的义务。Cloudflare 修订后的 2019 年S-1 表格注册声明称，6 月的路由泄漏对其流量及其他提供商的流量造成了重大中断。它警告称路由泄漏可能损害声誉和信心，描述了可能导致积分或退款的服务水平承诺，并指出 6 月的路由泄漏和另一起 7 月的中断触发了部分此类义务。当时，Cloudflare 预计这些事件不会对运营结果或财务状况产生重大影响。

该披露前，SEC 员工意见要求公司根据服务水平承诺，说明 6 月路由泄漏的合理预期财务影响。这段交流是责任从网络运营中心转移到公司报告的一个简明实例。一起事件可以同时是外部引发的、运营显著的、合同上需要补偿的，并且对提供商财务上不重大的。

该文件未披露受影响客户的数量、总积分、退款、损失交易或客户级停机时间。它还将 6 月的路由泄漏与 Cloudflare 内部原因导致的 7 月 2 日 Web 应用防火墙中断一并讨论。这些事件不应合并。6 月事件检验了对外部路由的依赖。7 月事件检验了内部软件变更控制。两者均影响了可用性，但预防的所有者和证据不同。

对客户而言，服务积分并不等同于业务恢复。一家小型在线商家可能损失订单，一家通信服务商可能损失会话，而一家企业可能在月度订阅积分计算之前就已消耗员工工时。合同补救措施只分配了直接提供商费用的一小部分，而非全部社会或客户停机成本。因此，云提供商应报告的不只是合同正常运行时间：还应包括按地区和网络划分的可达性、流量损失、检测时间、识别时间、沟通时间以及稳定恢复时间。

董事会应就对等互联和中转风险提出什么问题

路由通常被视为低于董事会监督层面的专业问题。2019 年 6 月的事件显示了这种划分为何过于简单。一家主要提供商的一条 BGP 导入策略改变了许多云服务的访问，触发了客户义务，引发了投资者披露，并暴露了正式云厂商合同之外的集中度。董事会无需选择路由器语法。但它需要证据表明管理层知道可用性在何处依赖于另一自治系统的行为。

一套有用的董事会材料始于暴露面，而非合规声明：

每项指标的分母都很重要。声称 RPKI 已部署在核心路由器上，并不能揭示未经验证的边缘会话是否可以向同一网络注入路由。声称客户过滤器是自动化的，并不能显示源注册表是否完整、紧急例外是否持续存在，或者新 BGP 会话是否继承了策略。声称联系人在数据库中，并不能证明有人能在当地时间 06:30 接听并有权处理。

测试应包括受控的负面案例。提供商可以尝试宣告未经授权的实验前缀、超过其 ROA 许可的更具体前缀、过多的路由数量，以及违反声明客户关系的路径。预期结果应在接收策略和独立收集器上被观察到。测试需要防护措施，以免自身成为泄漏，但回避所有实际测试将使最高风险的行为得不到验证。

不靠简单的多提供商建议实现客户韧性

客户经常听到应通过购买第二个 CDN、第二个 DNS 提供商或第二个云来避免依赖。多样性可以有所帮助，但路由故障并不尊重产品标签。两家提供商可能共享中转、交换点、光纤、路由收集器，或相同的未经验证的接入网络。一条泄漏的更具体路由也可能在客户的 DNS 或应用故障切换逻辑有机会生效前，就将流量吸引走。

正确的设计始于服务路径。哪个提供商负责 DNS？TLS 密钥和安全策略保存在哪里？源站能否安全接受直接流量？能否在不造成安全绕过的情况下转移流量？DNS 缓存改变有多快？客户端是否保持连接？辅助提供商是否拥有当前的配置和容量？组织能否在移动流量前区分上游路由故障和源站故障？

对于某些服务，跨独立路由提供商的主-主交付是合理的。对于其他服务，复杂性、不一致的安全策略、缓存行为和增加的攻击面可能会超过两小时可用性提升的收益。一项可防御的决策记录了关键性、经测试的恢复时间、共享依赖关系、成本和残余风险。它不会统计厂商名称就宣称结果是弹性的。

客户还可以利用采购杠杆。他们可以要求云或网络提供商提供 ROA 覆盖、ROV 策略、客户过滤器控制、MANRS 参与情况、事件联系实践、外部监控和匿名测试结果。MANRS 网络运营商行动提供了一个实用框架：过滤、反欺骗、协调以及发布其他方可验证的信息。成员身份或符合性是信号，而非完美运行的证明，但这些行动将路由安全转化为买家能够理解的问题。

最重要的合同问题往往不是正常运行时间百分比。而是当流量因外部路由而无法到达健康服务时，提供商能提供哪些证据和协助。快速、具体的状态沟通有助于客户避免对健康源站进行破坏性更改。事后路由数据帮助他们协调自己的观察。狭窄起草的不可抗力或第三方条款可能会限制赔偿，但它不应终止提供商诊断和沟通的运营义务。

从自愿规范到风险管理证据

2019 年 6 月的事件发生在一个路由安全基本上自愿的环境中。最佳实践并非不为人知。前缀和 AS 路径过滤、IRR 数据、最大前缀控制、RPKI 和运营商联系注册机构均已存在。但采用和保证程度参差不齐，尤其是在一个网络必须承担部署成本而收益却遍及整个互联网的情况下。

这种集体行动问题后来引起了政府更明确的关注。美国国家网络总监办公室 2024 年的《加强互联网路由安全路线图》描述了 BGP 在常见操作中无法验证源权限、消息完整性、远程路径信息或违反相邻商业策略的宣告。它呼吁加强路由源安全的采用，特别是在主要提供商和政府承包服务中。该路线图是政策指引，而非针对 2019 年参与者的裁定。

美国联邦通信委员会 2024 年的安全互联网路由通知建议了宽带提供商的 BGP 风险管理计划和报告，并征求了超越 RPKI 源验证的措施意见。它明确承认路径安全需要进一步工作。同样，这并不为 2019 年 6 月创建追溯责任。它展示了一种治理转变，从询问提供商是否原则上支持 RPKI，转向要求维护计划、覆盖数据、证明和进展。

监管本身也有风险。ROA 注册的百分比目标可能奖励宽泛、宽松的授权。申报要求可能变成与路由器策略脱节的文书工作。公开详细的防御配置可能引发安全担忧。因此，有效的监督应聚焦于结果和受控证据：准确的授权、拒绝覆盖、经测试的客户策略、例外治理、检测速度、联系人准备状态和事件学习。机密监管访问可能适用于敏感细节，而聚合采用率和事件指标保持公开。

路由安全公域也跨越国界。Verizon 的传播影响了全球用户和服务；Cloudflare 在多个地区的工程师参与了响应；路由权限通过区域注册机构分布；接收者应用自己的策略。国家规则可以改善其管辖范围内提供商的行为，但可互操作的标准和运营商规范才能使这种改善传导开去。

公开记录中仍缺失的证据

Cloudflare 的深入分析具有非同寻常的可复现性：它标识了 RIPE NCC 数据，提供了命令，并展示了观察到的路径和时间戳。这种透明度支持了对路由时间线的高度信心。但它并未回答所有问责问题。

如果相关运营商公布以下记录，将实质性地改善分析：

• DQE 的优化器配置、生成前缀策略、导出映射、团体处理以及部署前后的外部传播测试。
• AS396531 附加到 DQE 和 Verizon 会话的 BGP 策略、会话中断和恢复时间线、配置变更、路由数量，以及提供商学习路由可被导出的原因。
• Verizon 的客户导入记录、IRR 或前缀列表来源、AS 路径策略、最大前缀设置、RPKI 验证状态、告警、操作员响应时间线，以及全球传播的解释。
• Noction 的部署检查清单、持续限制防护措施、告警行为以及事件后做出的产品变更。
• Cloudflare 首次内部检测时间戳、告警来源、考虑的缓解决策、联系对等体的升级时间线、按网络和地域划分的客户影响，以及纠正措施验证。
• 可量化归因于 6 月路由泄漏而非另外的 7 月中断的服务积分、退款、支持负载和客户流失。

它们的缺失并不会使事件变得不可知。公开 BGP 宣告是网络之间相互告知的证据。流量测量是服务影响的证据。SEC 文件是公司披露和预期重要性的证据。运营商博客是归属解释的证据。原则在于将这些证据类别分开。

同样重要的是，不要将缺失的公开记录与缺失的内部记录混淆。Verizon、DQE、AS396531 和 Noction 可能进行了广泛却从未公布的审查。Cloudflare 可能持有未包含在博文中的详细遥测数据。当证据保持私有时，公共问责会减弱，但本文不能推断没有发生任何学习。

路由韧性的持久问责标准

2019 年 6 月的中断被铭记，是因为一个小网络看似成为了通往互联网大部分地区的路由。其更深层次的教训在于，规模并没有产生相应的怀疑。一家主要中转提供商从一家客户接收了异常的声明并分发了它们；许多网络接受了结果；流量按照协议规则流入了一条不合理的路径；恢复取决于找到能够撤回宣告的人员。

若使用当时可用的控制措施，该事件本可预防。DQE 本可以限制优化路由。AS396531 本可以仅导出授权前缀。Verizon 本可以通过注册、路径、前缀计数和 RPKI 证据过滤客户宣告。接收网络本可以拒绝 RPKI 无效的 Cloudflare 更具体路由。更好的监控和联系人就绪状态本可以缩短事件。后来的标准使某些关系假设更容易传递信号，但它们并未使运营纪律成为可选的遗留关切。

Cloudflare 的角色比受害者或所有者更为复杂。它是可达性受外部决策损害的目的地。它已经发布了适合拒绝泄漏更具体路由的 ROA，运营着分布式网络，检测到了事件，协调了撤回，解释了路由记录，并披露了合同后果。但它仍应向客户提供清晰的状态、恢复努力、合同约定的财务补救，以及关于残余路由风险的真实说明。提供商无法承诺互联网的其余部分都会验证其路由；它可以承诺使验证成为可能，监控发生的情况，并以证据进行响应。

因此，最终的问责标准并非零路由泄漏。没有全球网络可以保证每个自治系统都会正确配置每个会话。标准在于每一方是否在其控制范围内降低了风险，从外部测试了这种降低，限制了不可避免错误的爆炸半径，通过演练过的协调路径进行响应，并提供了足够的证据供客户和监督者验证改进。

这就是超越边界的网络韧性：不是独立于其他网络——这在互联网上是不可能的——而是对任何单条路由能够消耗多少未经验证的信任，施以纪律约束。