Instabilidade no roteamento da internet causada por bug no processamento de BGP
(blog.benjojo.co.uk)- Uma mensagem BGP corrompida propagada em 20 de maio de 2025 às 07:00 UTC provocou comportamento inesperado em duas implementações amplamente usadas, fazendo com que várias sessões BGP de conectividade com a internet fossem resetadas e causando instabilidade de roteamento ou breves perdas de conexão em algumas redes
- A atualização problemática incluía um BGP Prefix-SID Attribute que normalmente não é esperado em atualizações BGP da internet, e seu conteúdo interno estava corrompido, com todos os dados em
0x00 - IOS-XR/Nokia SR-OS com tolerância a erros baseada na RFC7606 filtraram isso, mas o JunOS repassou a mensagem e o Arista EOS resetou a sessão, o que pode ter afetado usuários Arista conectados a carriers de trânsito baseados em JunOS
- Nas observações do bgp.tools, AS9304, AS135338, AS151326 e AS138077 apareceram repetidamente, e é bastante provável que quem adicionou o atributo defeituoso tenha sido a Starcloud AS135338 ou a Hutchison AS9304
- Durante o incidente, a taxa média de mensagens em 10 segundos do route collector do bgp.tools saltou do normal de 20.000~30.000/s para mais de 150.000/s, mostrando que diferenças no tratamento de erros BGP podem realmente abalar a estabilidade dos caminhos da internet
Incidente de atualização BGP de 20 de maio de 2025
- Uma mensagem BGP propagada na terça-feira, 20 de maio de 2025, às 07:00 UTC, provocou comportamento inesperado em duas implementações principais de BGP frequentemente usadas para encaminhar tráfego da internet
- O impacto se espalhou à medida que muitas sessões BGP conectadas à internet foram encerradas automaticamente
- Foi confirmada instabilidade de roteamento em algumas redes
- No pior caso, pode ter havido breves perdas de conexão
A mensagem BGP problemática
- A atualização observada nas sessões fornecidas ao bgp.tools era um BGP Update relativamente comum para um /16, mas incluía o problemático BGP Prefix-SID Attribute
- Esse atributo era perigoso por dois motivos
- Não é um atributo esperado em atualizações BGP da tabela da internet
- Era um atributo corrompido, com todos os dados internos em
0x00
- A maioria das implementações, como IOS-XR/Nokia SR-OS, quando configuradas com “BGP error tolerance” baseada na RFC7606, filtrou corretamente isso sem causar problemas
- Na combinação de JunOS e Arista EOS, o resultado foi diferente
- O JunOS repassou a mensagem corrompida
- Equipamentos Arista EOS resetavam a sessão ao receber essa mensagem, aparentemente vinda de um equipamento JunOS
- Como muitos carriers de trânsito da internet usam hardware Juniper rodando JunOS, redes que operavam Arista EOS e estavam conectadas a roteadores upstream de trânsito baseados em JunOS podem ter perdido acesso à internet por algum tempo
- A duração é estimada em até cerca de 10 minutos
ASs candidatas a terem adicionado o atributo defeituoso
- Ao filtrar o arquivo do bgp.tools desse período, parece que vários ASs de origem estiveram envolvidos no incidente
- Isso sugere que o atributo pode ter sido adicionado não pela rede que originou o prefixo, mas por um carrier intermediário no caminho para a internet mais ampla
- Os quatro candidatos que apareceram repetidamente em todas as mensagens problemáticas foram os seguintes
- O bgp.tools observou o prefixo impactado no caminho
[…] 151326 138077 […]sem o atributo BGP defeituoso- Portanto, é bastante provável que quem adicionou o atributo defeituoso tenha sido a Starcloud AS135338 ou a Hutchison AS9304
- Alguns prefixos observados nas atualizações com o atributo incluído foram:
156.230.0.0/16138.113.116.0/24163.171.102.0/24163.171.103.0/24163.171.104.0/24
Caminho que se espalhou por internet exchanges
- O incidente ganhou escala porque a Hutchison/AS9304 estava conectada a muitos internet exchanges
- As mensagens problemáticas foram enviadas para route servers de IX, que normalmente rodam bird
- O Bird não oferece suporte a BGP SID, então não conseguiu filtrar a mensagem e a distribuiu como estava para vários internet exchanges de múltiplos terabits
- Como resultado, a confusão se espalhou além das sessões de trânsito da internet para uma área bem mais ampla
A natureza do BGP Prefix-SID
- O BGP Prefix-SID Attribute normalmente deveria aparecer apenas em sessões BGP internas
- Seu objetivo, definido na RFC8669, é ajudar a determinar qual caminho o tráfego deve seguir até um destino dentro de uma única rede
- O motivo de esse atributo ter vazado para a tabela global de roteamento pode ser o fato de uma sessão BGP externa ter sido configurada como se fosse uma sessão interna
Redes afetadas e métricas observadas
- É difícil afirmar com exatidão quem foi afetado, mas com base nos locais onde o churn foi muito alto em relação ao tamanho da rede logo após a primeira mensagem BGP problemática, estima-se que cerca de 100 redes tenham enfrentado o problema
- Exemplos com alto grau de confiança incluem:
- Em condições normais, o route collector do bgp.tools coleta cerca de 20.000~30.000 mensagens por segundo
- Durante este incidente, a taxa média de mensagens em 10 segundos ficou bem acima de 150.000/s
- Isso indica que houve perturbações consideráveis em muitos caminhos da internet
Diferenças no tratamento de erros entre fornecedores
- Embora a causa raiz ou o agente real que disparou o problema não estejam totalmente claros, o fato de a mensagem defeituosa ter se propagado em escala de internet mostra o risco do tratamento de erros em BGP
- Outros fornecedores detectaram o atributo defeituoso e suprimiram o anúncio da rota, mas a Juniper o propagou para peers
- Depois que a mensagem chegou a equipamentos Arista, a ausência de código de tolerância a erros BGP, ou uma falha nesse código, levou ao reset da sessão
- A documentação de tolerância a erros BGP do JunOS afirma que o JunOS não examina todas as partes da mensagem
- Esse comportamento fez com que o próprio JunOS evitasse um reset de sessão acionado remotamente, mas ao mesmo tempo repassasse a mesma mensagem para outros peers ou clientes
Implicações operacionais
- Esta outage foi curta, mas poderia ter causado impactos maiores
- À medida que mais serviços migram para IP, o alcance de uma falha na internet pode ir muito além da impossibilidade de acessar e-mail
- Falha em transmissões de TV
- Interrupção de chamadas para serviços de emergência
- Bugs desse tipo aumentam a possibilidade de causar ou agravar danos a vidas no mundo real
- Operadores de rede com a tabela de roteamento completa podem ajudar na depuração de incidentes futuros fornecendo feeds de dados ao bgp.tools
- Já existem 2570 sessões em operação fornecendo dados ao bgp.tools
- As instruções de configuração estão na documentação de configuração de data feed do bgp.tools
1 comentários
Comentários do Hacker News
A abordagem padrão é ser liberal ao aceitar e rigoroso ao enviar
As opções são filtrar mensagens quebradas, descartá-las, ignorar atributos quebrados mas encaminhá-los, ou quebrar por causa do atributo quebrado; na prática, o único comportamento realmente difícil de aceitar é a opção 4, o comportamento ao estilo Arista. O comportamento ao estilo Juniper, a opção 3, não é desejável, mas também não é catastrófico
Relendo, parece que a Arista ficou mais perto da opção 2 do que da 4, e em vez de travar completamente, aparentemente tratou isso como uma conexão inválida e a encerrou. Do ponto de vista do usuário não é bom, mas, em termos do debate, é relativamente aceitável
A forma mais comum é treat-as-withdraw, ou seja, tratar uma atualização de anúncio de rota como se fosse a retirada de uma rota anunciada anteriormente. Simplesmente descartar a mensagem corrompida não é aceitável, porque isso faz com que um estado antigo e possivelmente inválido continue sendo mantido
É uma ideia que vem da pré-história da internet dos anos 1980 e 1990, mas hoje é amplamente entendida como uma má ideia que levou à ossificação de protocolos e a inúmeros problemas de segurança
Agora muitos sistemas dependem desse comportamento e estão sofrendo as desvantagens dessa “funcionalidade”
À primeira vista, essa “funcionalidade” parece uma ideia muito ruim, porque faz com que informações desconhecidas se propaguem cegamente por sistemas que não entendem o impacto da informação que estão encaminhando. Mas também dá para argumentar que foi graças a isso que coisas como Large Communities puderam ser distribuídas mais rapidamente e de forma mais ampla, e que a própria implantação de novos recursos do BGP se tornou possível
Ainda me lembro de ter corrido como louco pela rede inteira tentando corrigir a CVE-2023-4481
Esse tipo de bug deve ser um verdadeiro pesadelo de tratar, e, por causa da forma como o BGP foi projetado e implementado, deve levar muito tempo para consertar esse comportamento
Faz décadas, mas já desenvolvi funcionalidades de BGP em um fabricante de equipamentos de telecomunicações
Ainda acho o BGP complexo demais, e as pessoas continuam adicionando novos recursos enquanto os fabricantes seguem implementando com base em RFCs ou drafts
Como não parece que o BGP vá ser aposentado, esse tipo de bug provavelmente continuará sendo descoberto repetidamente no futuro
Pessoalmente, eu achava assustadoramente complexo, mas para alguém isso dava lucro
A HGC Global Communications Limited, antes conhecida como Hutchison Global Communications Limited, é uma provedora de serviços de internet de Hong Kong
https://en.wikipedia.org/wiki/HGC_Global_Communications
Nossos chassis IOS XR também receberam alguns desses pacotes, e isso coincidiu com um alto volume de anúncios de rotas BGP. Sinceramente, não sei que equipamento a rede upstream usa
Isso me faz pensar se o protocolo BGP está realmente sendo fuzzado de forma adequada. Talvez seja uma área tão crítica que todos tenham medo de tentar quebrá-la
Escrever um fuzzer de BGP pode até ser fácil, mas diagnosticar a causa de um crash parece ser muito difícil
Acho que nunca tinha aprendido sobre BGP até ouvir falar que ele causa problemas. É essencial para a internet, como o TCP/IP, mas enquanto TCP/IP aparece na faculdade, na carreira e em muitos livros, quase nunca tive contato com BGP na faculdade, no trabalho ou em livros
Dá para aprender TCP/IP em projetos de brincadeira em casa, mas com BGP eu nem saberia por onde começar. Como alguém pode aprender BGP em casa?
O texto menciona o bird, e outra implementação muito popular é o FRR (free range routing). É bem simples subir dois containers Docker e criar uma sessão BGP entre eles, por exemplo propagando uma rota estática configurada internamente
Se você gosta de tutoriais guiados, https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ é bem bom e se estende a temas um pouco mais avançados. Tudo de que você precisa para acompanhar é software livre
Para praticamente qualquer tecnologia de rede, a forma mais fácil de ganhar experiência prática provavelmente é o GNS3
[1]: https://wiki.dn42.us/home
Uma forma de experimentar é esta: https://www.eve-ng.net/
Outra forma é criar algumas máquinas virtuais com várias interfaces de rede, montar redes entre elas e usar um daemon de roteamento BGP
https://bird.network.cz/
https://www.nongnu.org/quagga/
são algumas opções
Usamos um pacote Python que simulava vários AS, mas não lembro qual era
Para testar BGP, você pode usar um simulador de rede, como o autor deste texto. Na disciplina usamos o gini[1], que acho que foi feito por um pós-graduando do professor, e o autor aparentemente usou o gns3, que parece uma versão do ns3 específica para Cisco. Usei o ns3 uma vez e a curva de aprendizado era bem íngreme. O simulador gini tem uma interface mais básica, mas provavelmente é menos poderoso
[1] https://citelab.github.io/gini5/
[2] https://docs.gns3.com/docs/
Parece que o BGP seria muito mais estável se vários fabricantes de hardware tivessem concordado com uma forma padrão de lidar com esse tipo de situação
O verdadeiro problema é que cada fabricante quer lock-in e por isso não padroniza?
Dito isso, meu entendimento de BGP é superficial e limitado, e eu não sou especialista
Diante do impacto desse tipo de bug, é surpreendente que não exista um suite de testes de interoperabilidade mantido por um consórcio
Talvez até exista, mas esse problema específico pode não estar incluído no suite. Nesse caso, também é surpreendente que não se criem casos de teste por fuzzing ou geração automática para explorar todos os erros de pacote possíveis. Mesmo que a execução do suite levasse horas ou dias, tudo bem
O autor deste texto aparentemente criou um fuzzer com algum nível de cobertura e parece já ter encontrado problemas parecidos antes. É surpreendente que os fabricantes não adotem esse trabalho de forma mais ativa
Vários fornecedores já tiveram esse bug no passado: https://www.kb.cert.org/vuls/id/347067
Houve CVE-2023-4481 (Juniper), CVE-2023-38802(FRR), CVE-2023-38283(OpenBGPd) e CVE-2023-40457(EXOS)
Na época, a Arista não foi afetada
Fico pensando se já existiu algo tão grande quanto o encanamento da internet e com uma complexidade acidental tão bizantinamente emaranhada