Cloudflare、2019 年 6 月路由泄漏与网络边界之外的问责

摘要

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

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

2019 年 6 月 24 日 10:34:25 UTC，公开的 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 以及许多其他受影响网络的全球转接通道。被更具体宣告吸引来的流量进入了一条容量不足或策略不容许的通道。数据包被延迟或丢弃。有时，路由泄漏可以通过一条低效的路径传递流量；但在这里，规模使这条路径成为了瓶颈。

互联网工程任务组（IETF）的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 或其他泄漏网络的信息。因此，基于客户的前缀和 AS 路径过滤器本可以拒绝这些宣告。RFC 7454 中的 BGP 运营与安全指导发布于 2015 年，建议在每个边界对接收和宣告的路由实施策略、实施客户前缀控制、AS 路径过滤和最大前缀限制。

下游和对等体的拒绝。从 Verizon 接收到这些路由的网络也有机会拒绝它们。由于 Verizon 是一个大型转接网络，许多接收网络对其宣告给予了很大的信任。部分使用始源验证的网络本可以因 RPKI 无效而拒绝受影响的 Cloudflare 更具体路由。其他网络则可以使用路由泄漏启发式方法或对等体策略。然而，在主要提供商分发错误路由之后，要求每个远程网络去捕捉该错误，其效率低于在最初的客户会话上就该拒绝它。在离策略违规最近的地方进行预防，可以限制传播，避免全局收敛将配置错误变成分布式中断。

这些层次之间的独立性不足。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，运营了分布式网络，检测到了事件，协调了撤回，解释了路由记录，并披露了合同后果。它仍欠客户清晰的状态更新、恢复努力、合同中规定的财务补救，以及对剩余路由风险的真实说明。一个提供者不能保证互联网的其他部分会验证它的路由；但它可以保证使验证成为可能、监控发生的情况，并以证据进行响应。

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

这就是网络弹性超越边缘的样子：不是独立于其他网络，那在互联网中是不可能的，而是对任何单一路由所能消耗的未经验证的信任施加严明的限制。