大规模的路由泄露影响了互联网的主要部分，包括cloudflare发生了什么？今天协调世界时10:30，互联网有一个小心脏病发作。宾夕法尼亚州北部的一家小公司通过主要的互联网运输提供商Verizon（AS701）成为许多互联网路线的首选路径。这就相当于Waze在附近街道上沿着一条高速公路走了一段路——结果导致Cloudflare上的许多网站和许多其他提供商无法从互联网的大部分地方访问到。这不应该发生，因为Verizon不应该将这些路由转发到互联网的其他部分。为了了解原因，请阅读好吧，我们曾在博客上写过这些不幸的事件，因为它们并不罕见。这一次，这种破坏在全世界都能看到。今天使问题恶化的是诺森公司的"BGP优化器"产品的参与。这个产品有一个功能，可以将接收到的IP前缀拆分成更小的、有贡献的部分（称为更多细节）。例如，我们自己的IPv4路由104.20.0.0/20变成了104.20.0.0/21和104.20.8.0/21。这就好像把交通导向"宾夕法尼亚"的路标换成了两个路标，一个是"宾夕法尼亚州匹兹堡"，一个是"宾夕法尼亚州费城"。通过将这些主要的IP块分割成更小的部分，一个网络就有了一种机制来引导网络中的流量，但这种划分决不应该向全世界宣布。当它是由今天的停机。至解释下一步发生了什么，这里有一个关于互联网的基本"地图"是如何工作的快速摘要。"因特网"字面意思是一个网络，它是由称为自治系统（AS）的网络组成的，每个网络都有一个唯一的标识符，即AS号。所有这些网络都是通过一种称为边界网关协议（BGP）的协议互连的。BGP将这些网络连接在一起，并构建互联网"地图"，使流量能够从，比如说，从你的ISP到另一端的一个流行网站地球仪。使用网络交换路由信息：如何从任何地方到达它们。这些路线既可以是特定的，类似于在你的GPS上找到一个特定的城市，也可以是非常一般的，比如把你的GPS指向一个州。这就是出问题的地方今天。安宾夕法尼亚州的互联网服务提供商（AS33154-DQE Communications）在他们的网络中使用了BGP优化器，这意味着他们的网络中有很多更具体的路由。特定路线凌驾于更一般的路线之上（在Waze类比中，去白金汉宫的路线比去伦敦的路线更具体）。DQE向客户公布了这些特定路线（AS396531-Allegeny Technologies Inc.）。所有这些路由信息随后被发送到他们的另一个运输供应商（AS701-Verizon），后者接着告诉整个互联网关于这些"更好"的路线。这些路线被认为是"更好的"，因为它们更细粒度，更具体。泄漏应该在Verizon停止。然而，与下面列出的众多最佳实践相反，Verizon的过滤能力不足导致了一个重大事件，影响了许多互联网服务，如Amazon、Linode和Cloudflare。这意味着Verizon、Allegeny和DQE突然不得不面对大量试图通过网络访问这些服务的互联网用户。这些网络都没有适当的设备来应对这种急剧增加的流量，造成服务中断。即使他们有足够的容量DQE，Allegeny和Verizon也不允许说他们拥有通往Cloudflare、Amazon、Linode等的最佳路线。在事件发生期间，我们观察到损失，在事件最严重的时候，占全球15%的份额交通。交通在事件。怎么了这个漏洞能被阻止吗？这次泄密有多种可能避免：BGP会话可以配置为接收前缀的硬限制。这意味着如果前缀的数量超过阈值，路由器可以决定关闭会话。如果Verizon有这样一个前缀限制，这就不会发生。最好有这样的限制。Verizon没有像Verizon这样的限制。除了草率或懒惰之外，没有什么好理由可以让他们没有这样的限制，网络运营商可以通过实施基于IRR的过滤来防止这种泄漏。IRR是Internet路由注册，网络可以向这些分布式数据库添加条目。然后，其他网络运营商可以使用这些IRR记录为与对等方的BGP会话生成特定的前缀列表。如果使用了IRR滤波，那么所涉及的网络中没有一个会接受错误的更多细节。令人震惊的是，Verizon在他们与Allegheny Technologies的BGP会话中似乎没有实现任何这种过滤，尽管IRR过滤已经存在（并且有很好的文档记录）超过24年了。IRR过滤不会增加Verizon的成本，也不会以任何方式限制他们的服务。再说一次，我们能想到的唯一解释为什么它没有到位是草率或懒惰我们去年在全球实施和部署的RPKI框架就是为了防止这种类型的泄漏而设计的。它支持对原始网络和前缀大小进行过滤。Cloudflare声明的前缀签名的最大大小为20。然后RPKI指示不应接受任何更具体的前缀，无论路径是什么。为了使该机制发挥作用，网络需要启用BGP源站验证。许多像AT&T这样的供应商已经在他们的网络。如果Verizon使用了RPKI，他们会发现广告中的路由是无效的，而这些路由可能会被自动删除路由器。Cloudflare鼓励所有网络运营商立即部署RPKI！使用IRR、RPKI和prefix limit防止路由泄漏所有上述建议都很好地浓缩成MANRS（双方同意的路由安全规范）是如何解决的。Cloudflare的网络团队联系了相关网络AS33154（DQE Communications）和AS701（Verizon）。我们很难联系到任何一个网络，这可能是由于事件发生的时间，因为当时美国东海岸航线泄漏的时间还很早开始了。截图在发送给Verizon的电子邮件中，我们的一位网络工程师很快就与DQE通信部门取得了联系，经过一段时间的延迟，他们能够让我们与能够解决问题的人取得联系。DQE通过电话与我们合作，停止向Allegheny Technologies Inc.宣传这些"优化"路线。我们感谢他们的帮助。一旦这样做了，互联网稳定下来，事情又回到了正常。截图不幸的是，尽管我们试图通过电子邮件和电话联系到Verizon，但在撰写本文时（事发后8个多小时），我们没有收到他们的回音，也没有收到他们的回复我们是否意识到他们正在采取行动解决问题。在Cloudflare，我们希望这样的事件永远不会发生，但不幸的是，互联网的当前状态对防止此类事件的发生几乎无能为力。现在是业界通过RPKI这样的系统采用更好的路由安全的时候了。我们希望主要的提供商能够效仿Cloudflare、Amazon和AT&T，开始验证路由。尤其是，我们正看着你，威瑞森-而且还在等你的回答。尽管如此这是由我们无法控制的事件造成的，我们对中断表示抱歉。我们的团队非常关心我们的服务，在发现这个问题几分钟后，我们在美国、英国、澳大利亚和新加坡都有工程师在线。