Cloudflare 路由泄露回应：可验证修复比安抚更重要

摘要

• 2019 年 6 月，一次涉及一个小型网络、一个路由优化器和 Verizon 的 BGP 路由泄露，导致 Cloudflare 及其他服务的可达性中断。Cloudflare 的公开回应正确强调了其直接网络之外的路由安全失败。
• 新的视角是可验证修复与安抚。路由泄露后，提供商客户需要的不仅仅是自信的解释，他们还需要证据表明路由起源权威、上游过滤、验证和监控已得到改进。
• 在公开记录中，Cloudflare 并非原始泄露者，但它对其自身的路由权威、RPKI 倡导、客户沟通、监控、传输压力和残留风险的公开解释拥有实际控制权。
• Verizon 和泄露网络控制了高杠杆的传播点。因此，问责图分离了起源、放大器、受影响提供商、验证网络和客户，而不是将互联网视为无名的意外。
• 持久教训是，路由事件应留下可衡量的产物：ROA、无效路由拒绝、过滤变更、对等要求、公共路由数据、事件时间线以及关于提供商行动哪些可以、哪些不能保证安全的客户指导。

证据记录及其使用方式

本文使用 Cloudflare 的公开事件分析作为第一方受影响提供商的说明，外部路由和行业来源提供路由安全背景，RFC 或政府指南提供当前 BGP、RPKI 和路由泄露控制。后续标准用于构建可验证修复框架，而非作为对 2019 年参与者的追溯性法律义务。

安抚不等于修复

路由泄露会导致可预测的公共沟通问题。受影响提供商希望安抚客户，表明中断是由其直接控制之外的原因造成的。这可能是真的。2019 年 6 月，Cloudflare 的公开分析确定了涉及 Verizon 和一个小型网络使用的路由优化器的路由传播行为。Cloudflare 是受影响提供商，而不是错误路由信息的原始来源。但客户购买的不仅仅是责任分配。他们购买的是可达服务。路由事件发生后，安抚必须转化为修复证据。

修复证据回答了安抚无法回答的问题。受影响提供商是否为其前缀发布了准确的路由起源授权？其传输提供商是否拒绝无效或未经授权的路由？提供商本身是否拒绝来自他人的无效路由？它是否基于路由卫生状况对同行施加压力或进行选择？客户能否看到公共路由数据是否支持事后分析？提供商是否披露了其控制之外的残留风险？事件发生后哪些控制措施发生了变化？

Cloudflare 的回应之所以有趣，是因为该公司已经将自己定位为路由安全倡导者。它发布了 RPKI 的解释，并呼吁关注路由过滤和验证的必要性。这种倡导是有价值的。问责问题在于如何使其可验证。提供商可以说路由系统需要改进。客户需要知道提供商自己做了什么：ROA、验证策略、传输要求、监控、客户沟通和事件演练。

这种区别并非吹毛求疵。互联网路由是一个信任系统，拥有许多私人关系。客户无法检查每个传输过滤器或对等策略。因此公共证据至关重要。路由收集器、RPKI 存储库、MANRS 参与、事件时间线和提供商声明都成为直接检查的替代品。公共证据越强，客户就越不需要依赖品牌信任。

安抚也有保质期。事件发生后立即安抚客户可能有效。几个月后，重要的问题是互连弱点是否减小。一次路由泄露如果只留下一篇博客文章，其对互联网的教益不如一次留下可验证的验证、更好的过滤和公共问责压力的泄露。标题教训是修复必须是可检查的。

泄露有起源、放大器和受害者角色

路由事件常被描述为互联网普遍故障。这种语言过于模糊，无法问责。有用的路由泄露地图分离了角色。一个网络泄露或发起了有问题的路由信息。另一个具有更广泛覆盖范围的网络接受并传播了它。受影响提供商（如 Cloudflare）看到其流量被重定向或可达性受损。其他网络则接受、拒绝或观察了该路由。客户经历了服务故障，却无法控制这些路由决策中的任何一个。

这种角色地图防止了两个错误。第一个错误是将每次可达性失败归咎于受影响提供商。Cloudflare 无法控制 Verizon 的路由接受或小型网络的路由优化器。第二个错误是，由于泄露起源于别处，完全免除受影响提供商的责任。Cloudflare 仍然控制着自己的路由权威、自己的验证姿态、自己的监控、自己的客户沟通以及自己对网络合作伙伴的商业压力。问责是分布的，而不是消散的。

Verizon 的角色很重要，因为放大器决定了影响范围。小型网络的不良路由如果在上游被过滤，则可以保持较小。主要传输提供商的传播可以使其全球化。这就是为什么上游过滤不是可选的礼貌。对于销售覆盖范围的网络来说，这是一项安全义务。提供商拥有的覆盖范围越大，它就必须越谨慎地验证其传播的内容。

路由优化器的角度也是一个关于自动化的警告。优化 BGP 决策的工具可以创建高杠杆的路由变更。如果允许这些工具在提供商关系之间泄露路由，它们可以将商业流量工程变成公共中断。自动化不会减少问责；它增加了对约束、路由策略测试和监控的需求。

Cloudflare 的受影响提供商角色承担着不同的义务：使外部控制失败可见，准确解释，并将事件转化为更强的路由安全要求。这是一种合法的问责形式。即使提供商没有造成原始泄露，它也可以帮助修复生态系统。关键是要使修复可衡量。

RPKI 改变了证据标准

RPKI 之所以重要，是因为它将路由权威的一些问题转化为密码学上可验证的数据。资源持有者可以发布路由起源授权，说明哪个自治系统被授权发起一个前缀以及最大长度是多少。执行路由起源验证的网络可以对接收到的路由进行分类，并在策略要求时拒绝无效起源。这并不能解决所有路由泄露，但它改变了可以被证明的内容。

对于 Cloudflare 来说，RPKI 不仅仅是一项技术修复。它是一个问责工具。如果公司为其前缀发布准确的 ROA，客户和其他网络可以检查部分权威记录。如果网络拒绝无效路由，一些错误起源的公告就会变得不那么危险。如果 Cloudflare 进行测量并倡导采用，它就会对仍然接受无效权威的网络施加压力。修复变得不那么依赖于私人保证。

RPKI 不是魔法盾牌。路由泄露可能涉及一条仍然起源有效的路由，因为原始起源 AS 仍然被授权，而路径关系是错误的。这就是为什么 RFC 7908 路由泄露分类和后来的机制（如 BGP 角色）很重要。路由起源验证回答谁可以发起；路由泄露预防还询问路由是否应该在特定关系之间传播。可验证的修复必须包括起源验证和关系感知过滤。

这个细微差别对于诚实的客户沟通很重要。提供商不应暗示 RPKI 使所有路由事件成为不可能。它应该解释 RPKI 可以防止什么，不能防止什么，以及需要哪些补充控制。这样客户才能理解残留风险。夸大控制是另一种形式的安抚而非修复。

RPKI 的公共价值在于它创造了产物。ROA 可以检查。无效路由拒绝可以衡量。采用情况可以跟踪。网络运营商可以被问及为什么他们验证或不验证。这些产物给客户提供了比事件后道歉更坚实的东西。Cloudflare 的路由安全倡导在与此类可检查证据结合时最为有力。

MANRS 式规范将私人路由转变为公共期望

MANRS 之所以重要，是因为路由安全不能由单个提供商解决。发起网络、接受的上游、传播的对等体和验证的下游都影响着结果。自愿规范，如过滤、反欺骗、协调和全球验证，使私人互连行为作为公共期望可见。它们不保证合规，但它们定义了负责任的运营商应该能够展示的内容。

对于 2019 年 6 月的事件，MANRS 的视角是直接的。泄露之所以有害，是因为错误的路由信息逃出了关系边界并被广泛传播。过滤客户公告和维护准确的路由信息是核心预防职责。协调和联系就绪一旦泄露发生就很重要。验证在接收路由的网络中很重要。系统需要所有这些控制，因为没有一个单一层次能抓住所有失败。

因此，Cloudflare 的回应应部分根据它如何利用其市场地位来推动这些规范来判断。它是否要求传输提供商有更好的路由卫生？它是否宣传了过滤的作用？它是否使路由安全的采用更容易或更可见？它是否支持公共教育，以便客户理解为什么他们提供商的上游选择很重要？这些行动可以将一次中断转化为生态系统压力。

客户也可以在采购中使用 MANRS 式的问题。提供商是否过滤客户路由？是否验证 RPKI？是否维护准确的路由对象？是否有 24 小时路由安全联系人？是否参与公认的路由安全倡议？是否在路由出错时发布事件报告？购买边缘安全的客户应该询问路由安全，因为边缘只能通过路由系统到达。

关键不是自愿规范取代法规或合同。关键是路由行为常常介于私人合同和公共损害之间。MANRS 式的期望为客户和同行提供了一种询问该行为的词汇。可验证的修复依赖于能够被测试的词汇。

公共 BGP 证据是事件记录的一部分

路由泄露在基础设施事件中是不寻常的，因为外部人员可以观察到其重要部分。RouteViews、RIPE RIS 和其他收集器不揭示私人路由器意图，但它们可以从许多观察点显示公告、撤销、AS 路径和时间。这些公共证据有助于验证或挑战事件叙述。它们也有助于受影响提供商解释发生了什么，而无需要求客户凭信心接受每一个说法。

Cloudflare 的公开分析使用了路由证据来展示中断是如何发展的。这是良好实践。路由泄露事后分析应包括足够的公共路由数据，以使机制清晰：哪些前缀受到影响，涉及哪些 AS 路径，时间如何变化，传播何时停止，以及哪些缓解措施起作用。目标不是用 BGP 表淹没读者，而是使因果故事可审计。

公共证据还可以防止模糊的指责。如果提供商说上游泄露了路由，路由记录应支持该说法。如果上游说已经修复了过滤，后续路由行为应与修复一致。如果网络说它拒绝无效的 RPKI 路由，公共测量应在广义上测试这一点。路由安全声明越可测量，留给仅靠声誉修复的空间就越小。

客户应要求以可用形式提供事件后的路由证据。简短叙述对高管有帮助。技术附录对网络团队有帮助。时间线对事件管理人员有帮助。变更控制列表对风险所有者有帮助。客户不需要成为 BGP 专家也能理解提供商是否已经从解释转向修复。

公共路由证据有局限性。它可能无法捕捉每一个私人对等体、策略决定或内部警报。它可能很嘈杂。它可能需要专家解读。但其局限性不是忽略它的理由。在路由问责中，不完整的公共证据仍然比仅仅私人保证更好。

传输提供商问责是高杠杆点

2019 年 6 月的事件再次表明，传输提供商具有很高的杠杆作用。一个小型网络可能会泄露。一个路由优化器可能会行为不当。但一个主要传输提供商可以决定该路由是否被广泛信任。该提供商的客户过滤器、前缀限制、路由验证和关系策略是公共安全控制，因为它们决定了错误信息传播多远。

这就是商业激励可能失效的地方。传输提供商在覆盖范围、性能和价格上竞争。过滤和验证需要运营工作，并可能产生客户摩擦。如果市场不奖励路由卫生，提供商可能会投资不足，直到事件造成声誉成本。因此，客户和受影响网络应将路由卫生作为供应商选择和同行压力的一部分。

Cloudflare 对放大点的公开批评发挥了有用的市场功能。它指出了高杠杆的失败。但点名只是开始。可验证的修复需要证据表明传输策略已经改变，无效或未经授权的路由被拒绝，客户路由集合得以维护，路由泄露触发快速遏制。部分证据可能来自公开承诺；部分来自测量；部分来自合同要求；部分来自未来事件缺席加上审计。

受影响提供商也有杠杆作用。大型边缘网络可以选择传输关系，设置对等偏好，发布路由安全要求，并教育客户关于提供商卫生的状况。它不能强迫互联网上的每个网络进行验证，但它可以围绕自己的互连改变激励。如果提供商销售安全性和可靠性，路由安全采购是产品的一部分，而不仅仅是网络团队的幕后工作。

更广泛的政策教训是，上游过滤应被视为与覆盖范围相关的职责。网络销售的覆盖范围越全球化，它就能通过接受不良路由造成更大的公共损害。该职责应在规范、合同、审计和事件报告中可见。

路由故障下客户连续性有局限性

客户经常问，在提供商中断后他们本可以采取什么不同的措施。在影响主要边缘提供商的路由泄露中，答案可能令人不安：实时情况下能做的不多，除非客户预先构建了独立的交付路径。如果公共互联网将流量从提供商的合法路径重定向开，客户的源站可能健康但仍然无法通过预期的边缘到达。DNS 故障切换在某些架构中可能有帮助，但它可能受到缓存、证书设置、源站容量和备用提供商就绪度的限制。

这并不意味着客户无能为力。他们可以对关键服务进行分类，维护备用状态页面，对选定的工作负载使用多 CDN 或直接源站回退，从不同网络进行监控，并避免将所有公共通信渠道放在同一提供商之后。但这些措施需要规划。在路由泄露期间，临时凑合通常是不够的。

因此，Cloudflare 对客户的问责部分在于解释。它应告知客户哪些风险可以通过 RPKI、路由监控和传输选择来降低，哪些风险需要客户架构。一个暗示可以吸收所有互联网路由故障的提供商将招致误信。一个解释残留风险的提供商能帮助客户做出更好的连续性决策。

客户合同和风险评估应反映这一点。服务水平承诺可能无法涵盖路由泄露的全部运营影响。信用不会保持服务可达。客户应询问关键工作负载是否需要交付多样性，该多样性是否真正独立，以及紧急通信渠道是否能在相同的路由故障中幸存。答案可能因工作负载而异，但问题对于高影响服务是强制性的。

路由泄露事件还表明，依赖风险在故障发生前可能是不可见的。客户可能不知道哪些传输关系或路由策略决定了他们通过提供商的可达性。这就是为什么提供商透明度很重要。客户无法管理提供商拒绝使其可读的内容。

可验证修复需要清单

一个可信的路由泄露修复记录应有可观察的要素。第一，路由传播、检测、缓解和恢复的精确时间线。第二，角色图，标识起源、放大器、受影响前缀和验证网络（如果已知）。第三，路由起源证据：ROA、maxLength 选择和验证姿态。第四，过滤证据：客户路由集合控制、无效路由拒绝和路由泄露预防方法。第五，协调证据：联系人、升级和与负责任网络的沟通。第六，关于残留风险和可能的连续性设计的客户指导。

这样的清单将使 2019 年 6 月的事件不仅仅是一个叙述。Cloudflare 提供了大量的公开解释和倡导。下一个问责步骤是将每个声明与持久的产物联系起来。如果 RPKI 是答案的一部分，展示采用情况。如果上游过滤是答案的一部分，阐明对上游的期望。如果公共路由收集器支持时间线，包含足够的数据以供检查。如果客户需要架构变更，直接说明。

这个清单也保护了受影响提供商。当提供商能够展示它发布了 ROA、验证了路由、监控了公共 BGP、选择了负责任的传输并快速升级时，客户可以看到残留风险来自更广泛的路由生态系统。没有这些证据，客户可能只听到安抚。证据是提供商最强的辩护，当它确实不是故障源时。

可验证的修复应该能够在不同事件中重复使用。相同的结构可以适用于影响 CDN、云提供商、银行、政府门户或软件存储库的泄露。细节不同，但问责要素保持不变：路由权威、传播控制、验证、监控、协调和客户连续性。

清单也应随着技术发展而更新。RFC 9234 中的 BGP 角色和仅对客户机制解决了关系感知的泄露预防，这是 RPKI 起源验证单独无法解决的。提供商不应将其修复模式冻结在 2019 年可用的控制上。真正的修复计划会在更好的机制变得可部署时采用它们。

倡导与采购结合时更强

Cloudflare 经常利用其公共平台倡导更好的路由安全。倡导很重要，因为路由安全是集体行动的工作。但当倡导与采购和运营承诺相结合时，它变得更加有力。提供商可以在撰写关于 RPKI 的文章的同时，选择反映相同价值观的合作伙伴、同行和传输安排。它可以要求客户关心，同时展示自己在网络采购中的关心。

这种配对很重要，因为路由安全的采用可能遭受搭便车动态。如果负责任的网络进行验证，但不负责任的网络仍然传播不良路由，每个人仍然暴露。大型提供商可以通过使路由卫生成为商业关系的一部分来改变激励。一个传输提供商如果因过滤薄弱而面临失去重要客户的风险，就有更强的理由改进。一个无法维护路由对象的同行会受到更多审查。一个拒绝无效路由的网络可以宣传这种成熟度。

客户可以加强同样的激励。他们可以询问边缘提供商使用哪些传输提供商，是否验证 RPKI，是否维护类似 MANRS 的控制，以及如何应对泄露。并非每个细节都会公开，但重复的买方压力会改变对话。路由安全应成为可靠性采购的一部分，而不是一个边缘网络工程话题。

Cloudflare 的受影响提供商地位使其有信誉推动这一议程。它经历了损害，并可以向广泛受众解释。问责的标准是继续将这种信誉转化为可测量的生态系统压力。一篇有说服力的博客文章是有用的；一个改变的路由市场更好。

同样的原则适用于每个销售安全可达性的提供商。如果产品承诺包括让客户保持在线和受保护，那么路由安全采购就是产品工作。中断期间，网络运营与客户信任之间的边界是人为的。

路由泄露暴露了边缘冗余的局限性

Cloudflare 运营着一个庞大的全球边缘网络，但路由泄露事件表明，物理和软件冗余并不能消除对域间路由的依赖。提供商可以拥有许多数据中心、许多服务器和复杂的流量管理，但当互联网相信了一个错误路径时，它仍然会受到影响。提供商资产内部的冗余是必要的，但这与路由独立性不同。通往边缘的公共路径是服务的一部分。

这对客户期望很重要。客户经常购买边缘服务，因为他们认为规模能创造免疫力。规模创造了容量和许多恢复选项，但它也创造了更多的互连关系和对他者路由决策的更多暴露。如果主要传输提供商传播了不良路由，全球边缘可能会以特定方式在全球范围内被错误到达。客户需要理解，提供商内部韧性和互联网外部路由卫生是不同的层面。

Cloudflare 的公共沟通可以通过区分服务韧性和路由生态系统风险来缩小这一期望差距。事后分析应说明哪些部分在 Cloudflare 控制之下，哪些不在，以及哪些缓解措施跨越了边界。RPKI 发布是一座桥梁。无效路由拒绝是另一座。传输选择和互联策略是另一座。公共 BGP 监控是另一座。对于高关键性工作负载，客户端多提供商交付可能又是一座。没有这种分层解释，客户可能要么过度信任提供商，要么错误地将每次外部路由故障归咎于它。

边缘冗余的教训也影响事件演练。提供商不仅应测试数据中心丢失和软件回归，还应测试路由劫持、路由泄露、无效起源接受和传输提供商行为不当的场景。这些演练应包括客户沟通，因为路由事件对非网络团队来说是混乱的。客户看到来自某些地区的间歇性错误时，可能不知道问题是源站健康、DNS、CDN 软件、ISP 过滤还是路由传播。提供商快速解释层面是韧性的一部分。

因此，最好的修复证据包括场景覆盖。提供商是否测试了路由泄露检测？是否排练了传输升级？是否验证了 ROA 准确性？是否监控了可疑的 AS 路径？是否为路由事件准备了面向客户的语言？这些问题将路由从仅专家领域转变为可问责的服务义务。

错误路径创造信任债务

路由泄露是一个信任债务事件。它揭示了网络接受了一条不应该被接受的路径，或者在路由不应该经过的关系中传播了路由。债务在中断期间由受影响提供商和用户支付，但如果潜在的信任假设没有得到修复，它会在之后继续存在。安抚可以平息一时。修复则偿还债务。

信任债务是累积的。每次公共路由泄露都告诉客户，互联网可达性依赖于他们看不到的控制。如果回应只是叙述，信任会减弱，因为下一次事件感觉不可避免。如果回应产生了可衡量的改进，信任可以恢复，因为系统变得更可检查。RPKI 采用、路由过滤承诺和公共路由监控不仅仅是技术卫生；它们是重建信任的工具。

Cloudflare 的角色很复杂，因为它既是路由信任失败的受害者，也是互联网信任服务的销售者。这种双重角色提高了标准。客户期望公司不仅恢复，还要解释互联网弱点并倡导可信的修复。当 Cloudflare 发布路由安全解释文章时，它正在将自己的事件转化为公共教育。下一步是展示这些教育的哪些部分在其网络和商业关系中得到了实施。

信任债务也属于放大网络。一个接受并传播不良路由的传输提供商损害了超出其直接客户的信心。债务应跟随其进入未来的采购和同行对话。它是否改变了过滤器？是否验证了更多路由？是否加入或达到了路由安全规范？是否透明地报告？如果没有，市场没有理由相信同样的行为不会重演。

对于客户，信任债务应出现在风险登记册中。如果关键服务依赖一个暴露于全球路由事件的提供商，风险应命名故障模式和控制。它不应隐藏在通用的互联网中断语言之下。具体性允许修复被衡量。

最大长度是一个治理决策

RPKI 修复不仅取决于创建 ROA，还取决于谨慎创建。ROA 授权一个起源 AS，并可以设置最大前缀长度。这个最大长度很重要。如果太宽泛，它可能授权更具体的公告，削弱保护。如果太窄，合法的流量工程或紧急解聚合可能变为无效。因此，路由起源证据需要治理，而不仅仅是复选框发布。

对于全球边缘提供商，maxLength 决策应与文档化的路由实践挂钩。哪些前缀通常被公告？哪些更具体的用于流量工程？哪些可能在紧急情况下使用？哪些绝不应该出现？谁批准变更？ROA 在发布前如何测试？错误能多快纠正？这些是运营问题，具有客户影响。

2019 年 6 月路由泄露的讨论使这一点具体化，因为路由泄露和劫持经常利用更具体的路由偏好或传播错误。RPKI 可以使某些错误起源无效，但如果 ROA 过于宽松，它也会创造虚假的安全感。因此，可验证的修复必须包括证据表明路由权威是准确且维护良好的。陈旧或草率的 ROA 记录不是修复。它是一个新的风险来源。

客户不需要逐行检查每个 ROA，但成熟客户和公共观察者应能看到提供商有纪律的 RPKI 姿态。公共工具可以检查存在性和有效性。提供商声明可以解释策略。事件报告可以描述路由起源验证是否有帮助或本可以有帮助。这就是技术产物成为治理产物的地方。

路由权威也与客户入职相交。如果 CDN 或边缘提供商公告客户拥有的前缀或支持自带 IP 安排，ROA 协调成为客户风险的一部分。提供商和客户必须对齐起源授权、maxLength 和紧急程序。不匹配可能导致无效路由或削弱保护。可验证的修复应覆盖这些客户边缘情况，而不仅仅是提供商拥有的前缀。

关系泄露需要关系证据

RPKI 起源验证回答一个特定问题：这个起源 AS 是否被授权用于这个前缀？路由泄露经常问一个不同的问题：这条路由是否应该从一个关系传递到另一个？一条路由可以起源有效但仍然被泄露。这就是为什么关系感知控制，如路由过滤、BGP 角色和仅对客户机制，很重要。可验证的修复必须解决关系层面。

在 2019 年 6 月的事件中，有害模式涉及路由在网络之间的传播，而该路由本不应以那种规模扩散。确切的私人策略对客户不完全可见，因此公共修复证据必须描述控制类别。提供商是否要求客户特定的前缀过滤器？是否对邻居角色进行分类？是否根据商业关系限制路由传播？是否维护准确的 IRR 和 RPKI 数据？是否监控与正常关系不一致的路径异常？

RFC 9234 很重要，因为它代表了将关系角色编码到 BGP 泄露预防中的标准跟踪尝试。它晚于事件，因此不应将其用于以未来机制评判 2019 年的行为。它应用于提高当前的修复标准。提供商不应停留在事件发生时常见的控制上。他们应询问哪些更新的机制现在可以降低同一类风险。

关系证据比起源证据更难发布，因为商业关系可能敏感。尽管如此，提供商可以披露政策承诺，而不暴露每个私人条款。他们可以声明客户路由根据预期前缀进行过滤，无效的 RPKI 路由被拒绝，同行和客户关系被分类，路由泄露触发警报，以及传输提供商根据路由卫生进行评估。他们还可以支持行业规范，使此类声明具有可比性。

客户的价值在于清晰度。如果提供商说它有 RPKI 但对路由泄露只字未提，客户可能会高估保护。如果它区分起源验证和关系过滤，客户会收到更诚实的风险图景。诚实的风险图景是修复的一部分。

事件语言应避免扁平化因果关系

路由事件技术密集，密集的事件容易扁平化。公司可能会说发生了路由泄露，上游造成了它，服务受到影响，以及修复正在进行。这种语言可能真实但不充分。扁平化的语言隐藏了谁拥有什么控制、哪些控制失败以及哪些控制发生了改变。可验证的修复文化使用精确的因果关系。

精确的因果关系应分离泄露源、优化器或自动化机制、放大网络、受影响前缀、验证或非验证接收者、检测路径和客户可见症状。它还应在公共证据不完整时说明不确定性。这有助于客户信任报告，因为它不假装每个私人细节都已知。它也防止受影响提供商利用上游失败作为对所有客户影响的笼统解释。

Cloudflare 的事件分析比一般声明更强，因为它命名了路由行为并解释了为什么上游过滤很重要。更广泛的标准应是，每个主要路由事件都包含足够的因果结构，以便客户更新控制。安全团队应能问：RPKI 本有帮助吗？路由泄露预防本有帮助吗？多提供商交付本有帮助吗？我们的提供商监控迅速吗？我们自己的状态通信幸存了吗？

语言还影响公共激励。如果报告将路由事件描述为不可避免的互联网怪象，运营商改善的压力就较小。如果报告描述了确切的缺失过滤或验证失败，负责任网络面临审查。关键不是为公开羞辱而羞辱，而是使故障模式足够具体，以便市场奖励修复。

精确性应延伸到恢复声明。提供商应区分路由撤销、路由传播收敛、服务恢复、客户可见恢复和事件后监控。这些里程碑可能不同。路由可能在缓存、会话或客户监控恢复正常之前就被纠正。客户需要这种细微差别来编写自己的报告。

修复标准是公开证明

Cloudflare 2019 年 6 月路由泄露的回应很有价值，因为它使一个无形的路由故障对广大受众变得可理解。但文章的问责标准高于解释。受影响提供商、放大传输提供商和更广泛的路由社区应留下公开证明，证明弱点已被减少。证明可以是部分的。可以是技术性的。可以分布在 RPKI 存储库、路由收集器、MANRS 承诺、提供商策略和事件报告中。但它必须超越信心。

Cloudflare 控制着该证明的重要部分：自己的路由权威、监控、公共教育、验证姿态、客户指导和商业压力。Verizon 和泄露网络控制着其他部分：过滤、路由策略纪律和传播。客户只控制预先建立的连续性选项和采购压力。这种控制地图解释了为什么仅安抚是不够的。每个参与者必须在其控制的点上展示修复。

持久的教训是，互联网可达性不是自动执行的信任。它是一组通过 BGP、DNS、注册中心、合同和对等关系交换的运营承诺。当这些承诺失败时，回应必须是可检查的。一个扰乱全球边缘提供商的路由泄露应产生更好的关于谁能发起、谁能传播、谁验证、谁监控和谁能恢复的公共记录。

Cloudflare 在泄露后最好的贡献不仅仅是说另一个网络造成了问题。它是使路由安全问题可见。每个提供商的下一步是也使修复可见。客户不应被迫在相信品牌和理解路由之间做出选择。他们应能看到安抚已变成更安全路由的证据。