Instabilidade no roteamento da internet causada por bug no processamento de BGP

 (blog.benjojo.co.uk)
1 pontos por GN⁺ 2025-05-29 | 1 comentários | Compartilhar no WhatsApp
  • Um bug no processamento de mensagens BGP causou, em 20 de maio de 2025, uma grande instabilidade de roteamento e interrupções na conectividade com a internet em algumas redes
  • A causa do problema foi um BGP Prefix-SID Attribute malformado, que provocou reações excepcionais nas principais implementações de BGP, especialmente JunOS e Arista EOS
  • Alguns carriers de trânsito, incluindo Hutchison e Starcloud, retransmitiram a mensagem causadora, ampliando o impacto
  • O incidente provocou reset em massa de sessões BGP e instabilidade em mais de 100 redes
  • O caso destacou falhas na tolerância a erros de BGP entre vendors e a necessidade de melhorias

27 de maio de 2025

Instabilidade global no roteamento da internet causada por bug no processamento de BGP

Na terça-feira, 20 de maio de 2025, às 7h (UTC), uma mensagem BGP começou a se propagar, causando comportamento inesperado em duas grandes implementações de BGP frequentemente usadas para processar tráfego da internet.

Com isso, várias “sessões BGP de conectividade com a internet” foram encerradas automaticamente, provocando desde instabilidade de roteamento mínima até, no pior caso, interrupções de conectividade temporárias em algumas redes.

A mensagem BGP problemática

  • A análise das sessões coletadas pelo bgp.tools mostrou que a mensagem BGP Update que causou esse fenômeno parecia normal, mas continha um BGP Prefix-SID Attribute corrompido com dados internos preenchidos com 0x00
  • A maioria das implementações de BGP (IOS-XR, Nokia SR-OS) filtra isso corretamente de acordo com RFC7606 (tolerância a erros de BGP), mas o problema surgiu na interação entre JunOS e Arista EOS
    • O JunOS mantém e encaminha a mensagem corrompida, e o Arista EOS redefine a sessão BGP ao receber essa mensagem
  • Em ambientes com muito hardware Juniper (JunOS), quando conectado ao Arista EOS, pode haver interrupção do acesso à internet por até cerca de 10 minutos

Quem enviou a mensagem problemática

  • A análise do arquivo do bgp.tools nesse período mostra o envolvimento de várias origens AS

  • Isso sugere que não foi a rede que gerou o prefixo, mas sim um carrier de trânsito no caminho que adicionou o Attribute incorreto

  • Os principais AS relacionados ao problema são:

    • AS9304 (Hutchison Global Communications Limited)
    • AS135338 (Starcloud Information Limited)
    • AS151326 (DCConnect Communication Pte. Ltd.)
    • AS138077 (PT Abhinawa Sumberdaya Asia)

  • Pelos dados do bgp.tools, é bastante provável que quem realmente adicionou o Attribute tenha sido a Starcloud (AS135338) ou a Hutchison (AS9304)

  • Alguns dos Prefixes mais representativos pelos quais o Attribute se propagou foram 156.230.0.0/16, 138.113.116.0/24 etc.

  • Como a Hutchison/AS9304 está conectada a diversos internet exchanges (IX), a mensagem também foi propagada para route servers que usam bird

  • O Bird não oferece suporte a BGP SID e, sem filtragem, enviou a mensagem para muitos IXs, ampliando a confusão em escala de rede

O que é BGP Prefix-SID?

  • O BGP Prefix-SID Attribute normalmente deveria ser usado apenas em sessões BGP internas e serve para definir o caminho até um destino dentro de uma mesma rede (RFC8669)
  • Uma possível causa para o vazamento desse Attribute para a tabela global de roteamento é que uma sessão BGP externa tenha sido configurada como se fosse uma sessão interna

Quem foi afetado

  • É difícil identificar exatamente as vítimas, mas o problema foi observado em cerca de 100 redes que apresentaram churn enorme após a mensagem BGP inicial
  • Em condições normais, os route collectors do bgp.tools coletam de 20 mil a 30 mil mensagens por segundo, mas no momento do incidente registraram média de mais de 150 mil a cada 10 segundos
  • Esse número sinaliza que houve falha grave em uma ampla faixa de rotas da internet

Responsabilidade dos vendors e implicações

  • Embora a causa raiz não esteja totalmente confirmada, o fato de uma mensagem com erro ter se espalhado em escala de internet prova que os problemas existentes no tratamento de erros de BGP são um risco real
  • Outros vendors filtraram o Attribute problemático, mas a Juniper o permitiu de forma indireta e o encaminhou para equipamentos Arista, provocando reset de sessão devido a falhas no código de tolerância a erros de BGP
  • A documentação oficial do JunOS também declara que “não inspeciona a mensagem inteira”
  • Com esse desenho, o JunOS evita risco de reset remoto da própria sessão, mas continua com a possibilidade de encaminhar mensagens problemáticas para outros peers ou clientes

Conclusão

  • Este incidente foi curto, mas indica que pode se tornar muito mais grave se a escala aumentar

  • À medida que os serviços migram cada vez mais para IP, o impacto de falhas na internet pode ir além de simplesmente impedir consumidores de acessar e-mail e se espalhar para casos como falha em transmissão de TV e indisponibilidade de chamadas para serviços de emergência

  • Isso reforça a necessidade de implementações confiáveis de tolerância a erros de BGP por parte dos vendors, já que existe a possibilidade real de até perdas de vidas humanas

  • Foi indicado que operadores de rede podem participar da análise dos dados do bgp.tools (link fornecido)

Leituras relacionadas

1 comentários

 
GN⁺ 2025-05-29
Comentários do Hacker News

  • Em geral, o princípio de "ser liberal ao receber e conservador ao enviar" é conhecido como a abordagem padrão

    • Existem opções como descartar mensagens corrompidas (drop, filtro), ignorar apenas o atributo e encaminhar mesmo assim (break), ou até derrubar a própria conexão (como a Arista)

    • Eu achava que a quarta opção (o jeito da Arista) era realmente um comportamento difícil de aceitar

    • A terceira (Juniper) também não é desejável, mas não me parece um problema fatal

    • Edit: relendo, vi que a Arista não era a quarta, mas a segunda opção (encerrar a conexão)

    • No fim, ela só considerou a conexão inválida e a fechou; pensando na experiência do usuário, não parece uma grande decisão, mas ainda é aceitável

    • O RFC 7606 (tratamento de erro aprimorado para mensagens BGP UPDATE) já existe e especifica concretamente como lidar com mensagens corrompidas

      • O método mais comum é treat-as-withdraw (tratar como se a rota tivesse sido withdrawn)
      • Se a mensagem corrompida for simplesmente ignorada, o problema é que o estado anterior pode continuar mantido mesmo quando na prática já não é válido

    • O princípio de "ser liberal ao receber e conservador ao enviar" é justamente o chamado "robustness principle" ou "lei de Postel"

      • É uma ideia que vem dos primórdios da internet, nos anos 1980 e 1990
      • Mas hoje o setor reconhece amplamente que isso foi uma forma errada de pensar
      • Esse princípio causou enrijecimento de protocolos e incontáveis problemas de segurança

    • Houve vários problemas na rede em geral explorando características do funcionamento do BGP, aproveitando que equipamentos locais podem encaminhar atributos que eles mesmos não conhecem

      • Agora estamos vendo na prática as desvantagens dessa "funcionalidade"

    • O autor também aponta isso no texto relacionado

      • Essa "funcionalidade" faz o sistema repassar sem senso crítico dados que ele próprio não entende, o que parece uma ideia surpreendentemente ruim
      • Mas, por outro lado, ela permitiu que recursos novos como Large Communities se espalhassem rapidamente e viabilizou a adoção de novas funções no BGP

    • Eu não concordo com essa abordagem

      • Acho muito melhor ser estrito e explícito tanto no que se aceita quanto no que se anuncia

  • Ainda lembro da correria insana para aplicar patches do bug CVE-2023-4481 pela rede inteira

    • Esse tipo de bug vai continuar sendo um pesadelo de lidar no futuro
    • Pela forma como o BGP foi projetado e implementado, temo que corrigir esses comportamentos ainda leve bastante tempo

  • Já trabalhei desenvolvendo recursos de BGP em um fornecedor de equipamentos de telecomunicações (isso foi há bastante tempo)

    • Ainda acho o BGP complexo demais

    • As pessoas continuam adicionando novos recursos, e os vendors seguem implementando de acordo com padrões e drafts

    • Como o BGP parece que nunca vai desaparecer, dá a sensação de que esses bugs vão continuar reaparecendo sem parar

      • Antigamente, operadoras como a AT&T e vendors como Juniper e Cisco forçavam o uso de BGP para recursos ligados a MPLS e VPN, levando o sistema a um nível profundo de complexidade
        • Era complexo demais, mas alguns ganharam muito dinheiro com isso

  • HGC Global Communications Limited (renomeada de Hutchison Global Communications Limited, abreviada como HGC) é um provedor de serviços de internet de Hong Kong

  • Parece que o BGP seria muito mais estável se os vários vendors de hardware seguissem os padrões de forma alinhada nesses casos

    • Fico me perguntando se o problema real é que cada vendor evita padronização para manter os clientes presos ao próprio ecossistema (lock-in)
    • Dito isso, já adianto que meu entendimento de BGP é superficial

  • Não sei se sou só eu, mas nunca tinha ouvido falar de BGP até escutar que ele tinha causado algum problema

    • É um protocolo essencial para a internet, como o TCP/IP, mas enquanto TCP/IP apareceu muito na escola, na carreira, em livros etc., BGP nunca surgiu para mim
    • Dá para praticar e aprender TCP/IP em casa, mas não faço ideia de como alguém pode "brincar com BGP em casa"

      • Se houver algum jeito de praticar BGP em casa, eu gostaria de saber

      • Dá para fazer isso com um roteador real que tenha implementação de BGP (alguns baratos, como equipamentos da Mikrotik) ou com implementações open source

        • O texto menciona o bird e também o FRR (Free Range Routing), que é muito popular
        • Você pode subir dois contêineres Docker, estabelecer uma sessão BGP e propagar rotas estáticas, por exemplo
        • Se quiser um tutorial, o guia neste link está muito bem organizado e pode ser seguido com software gratuito

      • O DN42 é um playground para praticar tecnologias de roteamento

        • Mas exige investimento de tempo, então não é algo para experimentar casualmente
        • Eu também trabalho bastante com redes, mas roteamento WAN ainda me confunde
        • O GNS3 é a forma mais fácil de praticar diretamente qualquer tecnologia de rede
        • Wiki do DN42

      • Na minha disciplina de redes na graduação não vimos BGP, mas em uma matéria da pós-graduação eu aprendi BGP

        • Usamos um pacote em Python que conseguia simular vários AS, mas não lembro o nome exato

      • Na aula de redes que fiz na graduação, BGP só foi mencionado rapidamente no quadro

        • Para praticar BGP, dá para usar simuladores de rede, como o autor fez
        • Na nossa disciplina usamos um simulador chamado gini, um programa feito por um pós-graduando da universidade do professor
        • O gns3 que o autor usou parece um tipo de ns3 focado em Cisco
        • O ns3 tinha muita coisa para aprender e parecia difícil
        • O gini tem uma interface mais simples, mas o desempenho é inferior
        • Página do projeto gini
        • Documentação oficial do gns3

      • Dá a sensação de que só dá para realmente "praticar" BGP administrando uma rede grande conectada ao tráfego real da internet

        • Em casa, o máximo que dá para mexer é com simuladores de rede

  • No passado, vários vendors também tiveram bugs parecidos com o descrito no texto principal

  • Já recebemos pacotes parecidos nos nossos chassis com IOS XR

    • Ao mesmo tempo, houve muita propaganda de rotas BGP

    • Não sei exatamente qual era o equipamento upstream

    • Isso me fez questionar se o protocolo BGP está mesmo sendo testado adequadamente com fuzzing

    • Como é um protocolo tão importante, talvez ninguém se atreva a provocar falhas de propósito

    • Escrever um fuzzer para BGP seria fácil, mas diagnosticar os crashes pode ser extremamente difícil

      • (autor do post)

  • Isso faz pensar se já existiu outro sistema tão vasto e tão carregado de complexidade acidental quanto o backbone da internet

  • Dado o impacto desse tipo de bug, me surpreende não existir um consórcio operando algo como uma suíte de testes de interoperabilidade

    • Ou talvez exista, e isso só signifique que esse caso ficou fora do escopo dos testes
    • Parece óbvio gerar automaticamente todos os tipos possíveis de erro de pacote e usar fuzzers ou máquinas para criar vários casos de teste e aumentar a cobertura
    • Mesmo que a execução leve dias
    • O autor do texto de fato criou e usou um fuzzer, e encontrou problemas parecidos várias vezes
    • Acho curioso que os vendors não demonstrem interesse mais ativo por pesquisas importantes como essa