Sumário

  • Em 24 de junho de 2019, rotas otimizadas e mais específicas geradas dentro da rede da DQE Communications foram passadas através do cliente AS396531 e aceitas pela AS701 da Verizon. A Verizon então propagou os caminhos cobrindo milhares de redes. Como os roteadores preferem um prefixo de destino mais específico, tráfego substancial seguiu os caminhos vazados para links que não estavam dimensionados para carregá-lo; a Cloudflare relatou perda de cerca de 15% de seu tráfego global no pior momento do incidente.
  • O registro público de rotas suporta uma cadeia de falhas de controle, não um slogan de causa única. O gerador de rotas não manteve suas rotas de otimização locais, um cliente multihomed exportou rotas aprendidas do provedor para outro provedor, e uma grande rede de trânsito aceitou e espalhou rotas que não se encaixavam na autoridade de roteamento esperada do cliente. A Cloudflare podia detectar, comunicar e ajudar a retirar as rotas, mas não podia alterar unilateralmente a política de importação de outra rede.
  • O RPKI Route Origin Validation foi excepcionalmente adequado para a parte da Cloudflare deste evento porque as Autorizações de Origem de Rota da Cloudflare permitiam apenas que seus prefixos agregados tivessem um comprimento máximo declarado. As específicas vazadas excediam esse comprimento e, portanto, eram inválidas. Isso não torna o RPKI uma solução completa para vazamentos de rota: caminhos válidos por origem ainda podem violar relações comerciais, e é por isso que filtragem de cliente, limites de prefixo, papéis BGP, controles de caminho, monitoramento e contatos operacionais alcançáveis permanecem necessários.
  • A responsabilidade segue a capacidade de controle. Operadores que geram ou exportam rotas excepcionais devem contê-las e testá-las; provedores devem verificar o que os clientes podem anunciar; plataformas de nuvem devem publicar autoridade de rota, observar caminhos externos, coordenar rapidamente e divulgar o impacto ao cliente; clientes devem planejar a falha de dependência; e conselhos e reguladores devem exigir garantia de segurança de roteamento medida, não uma declaração genérica de que as melhores práticas do setor são seguidas.

Uma interrupção de roteamento, não uma falha dos servidores da Cloudflare

Às 10:34:25 UTC de 24 de junho de 2019, coletores públicos de BGP começaram a registrar rotas anormais e mais específicas para o espaço de endereços da Cloudflare. A última das rotas estudadas da Cloudflare desapareceu às 12:38:54 UTC. O mergulho profundo em rotas arquivadas da Cloudflare reconstrói esse intervalo a partir de dados do RIPE NCC e mostra um caminho notavelmente consistente: AS13335 da Cloudflare, um de seus provedores de trânsito, AS33154 da DQE Communications, AS396531 da Allegheny Technologies e AS701 da Verizon. Outras redes então aprenderam a rota através da Verizon.