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 对客户的问责部分是解释性的。它应告诉客户，哪些风险是 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 会有所帮助吗？路由泄露预防会有所帮助吗？多提供商交付会有所帮助吗？我们的提供商是否迅速监控？我们自身的状态沟通是否幸存？

语言也影响公共激励。如果报告将路由事件描述为不可避免的互联网怪异现象，运营商提升的压力就更小。如果报告描述了确切缺失的过滤器或验证故障，负责的网络就面临审视。目的不在于为了公开羞辱而羞辱，而在于使故障模式具体化，以便市场能够奖励修复。

精确性应延伸到恢复声明。提供商应区分路由撤回、路由传播收敛、服务恢复、客户可见恢复以及事后监控。这些里程碑可能不同。一条路由可能在缓存、会话或客户监控恢复正常之前就已纠正。客户需要这种细微差别以用于他们自身的报告。

排版

排版是安排字体以使书面语言清晰可读、易读且视觉吸引人的艺术和技巧。它涉及选择字体、字号、行长、行距和字间距。

• 排版起源于 15 世纪约翰内斯·古腾堡发明的活字印刷。
• 关键元素包括字体选择、字距、字间距和行距。
• 良好的排版能增强可读性，并在设计中传达情绪或基调。

修复标准是公开证明

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

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

持久的教训是：互联网可达性并非自我执行的信任。它是通过 BGP、DNS、注册机构、合同和对等关系交换的一组运营承诺。当这些承诺失效时，应对必须是可检查的。一次扰乱全球边缘提供商的路由泄露，应当产生一份更好的公开记录，说明谁可以发起、谁可以传播、谁验证、谁监控，以及谁可以恢复。

泄露之后，Cloudflare 的最佳贡献不是简单地说另一个网络造成了问题，而是使路由安全问题变得可见。对于每一个提供商，下一步是也使修复变得可见。客户不应在选择相信一个品牌和理解一条路由之间徘徊。他们应该能够看到证据，证明安抚已经变成了更安全的路由。