Cloudflare diz que recente interrupção está ligada ao incidente de sequestro de BGP

cloudflare-diz-que-recente-interrupcao-esta-ligada-ao-incidente-de-sequestro-de-bgp

A Cloudflare relata que seu serviço de resolução de DNS, 1.1.1.1, ficou recentemente inacessível ou degradado para alguns de seus clientes. Segundo a empresa, essa interrupção aconteceu devido a uma combinação de sequestro do Border Gateway Protocol (BGP) e um vazamento de rota.

Esse incidente, ao qual a Cloudflare culpa pela interrupção, ocorreu na semana passada e afetou 300 redes em 70 países. Apesar desses números, a empresa diz que o impacto foi “bastante baixo” e em alguns países os usuários nem perceberam.

Detalhes do incidente que causou interrupção do Cloudflare

A Cloudflare diz que às 18:51 UTC (15h51 no horário de Brasília) de 27 de junho, a Eletronet SA (AS267613) começou a anunciar o endereço IP 1.1.1.1/32 para seus pares e provedores upstream. Este anúncio incorreto foi aceito por diversas redes, incluindo um provedor de Nível 1, que o tratou como uma rota Remote Triggered Blackhole (RTBH).

cloudflare-diz-que-recente-interrupcao-esta-ligada-ao-incidente-de-sequestro-de-bgp
Imagem: Cloudflare

O sequestro ocorreu porque o roteamento BGP favorece a rota mais específica. O anúncio do AS267613 de 1.1.1.1/32 foi mais específico do que o 1.1.1.0/24 do Cloudflare, levando as redes a rotear incorretamente o tráfego para o AS267613. Consequentemente, o tráfego destinado ao resolvedor de DNS 1.1.1.1 da Cloudflare foi bloqueado/rejeitado e, portanto, o serviço ficou indisponível para alguns usuários.

Um minuto depois, às 18:52 UTC (15h52 no horário de Brasília) a Nova Rede de Telecomunicações Ltda (AS262504) vazou erroneamente 1.1.1.0/24 para o AS1031, que o propagou ainda mais, afetando o roteamento global.

cloudflare-diz-que-recente-interrupcao-esta-ligada-ao-incidente-de-sequestro-de-bgp
Imagem: Cloudflare

Esse vazamento alterou os caminhos normais de roteamento BGP, fazendo com que o tráfego destinado a 1.1.1.1 fosse roteado incorretamente, agravando o problema de sequestro e causando problemas adicionais de acessibilidade e latência. A Cloudflare identificou os problemas por volta das 20:00 UTC (17h no horário de Brasília) e resolveu o sequestro aproximadamente duas horas depois. O vazamento de rota foi resolvido às 02:28 UTC.

Esforço da empresa para resolver o problema

A primeira linha de resposta da Cloudflare foi interagir com as redes envolvidas no incidente e, ao mesmo tempo, desabilitar sessões de peering com todas as redes problemáticas para mitigar o impacto e impedir a propagação de rotas incorretas.

A empresa explica que os anúncios incorretos não afetaram o roteamento da rede interna devido à adoção da Resource Public Key Infrastructure (RPKI), o que levou à rejeição automática das rotas inválidas.

As soluções de longo prazo apresentadas pela Cloudflare em seu relatório incluem:

  • Melhorar os sistemas de detecção de vazamentos de rotas incorporando mais fontes de dados e integrando pontos de dados em tempo real.
  • Promover a adoção da Infraestrutura de Chave Pública de Recursos (RPKI) para Validação de Origem de Rota (ROV).
  • Promover a adoção dos princípios das Normas Mutuamente Acordadas para Segurança de Roteamento (MANRS), que incluem a rejeição de comprimentos de prefixo inválidos e a implementação de mecanismos de filtragem robustos.
  • Incentivar as redes a rejeitar prefixos IPv4 maiores que /24 na Default-Free Zone (DFZ).
  • Defensor da implantação de objetos ASPA (atualmente elaborados pela IETF), que são usados para validar o caminho AS em anúncios BGP.
  • Explorar o potencial de implementar RFC9234 e Autorização de Origem de Descarte (DOA).