Resumo

  • O texto publicado pela LACNIC em 28 de julho começa com um atributo BGP Prefix-SID malformado, código 40, observado em 20 de maio de 2025 e uma rajada superior a 150 mil atualizações em dez segundos.
  • Segundo o relato, IOS-XR e SR OS descartaram o atributo, Junos o propagou, EOS reiniciou sessões e route servers de vários IXPs o retransmitiram.
  • A RFC 8669 exige descartar e registrar um Prefix-SID malformado, mas a norma não revela a versão, o ajuste de tolerância a erros ou a política herdada ativa em cada roteador real.
  • Uma matriz pública deveria vincular os mesmos bytes sanitizados à versão exata, configuração efetiva, tipo de fronteira, ação, hash da mensagem de saída e efeito nas tabelas de rotas.

O dado mais importante são os três verbos

A LACNIC publicou em 28 de julho uma análise sobre classes de problemas de roteamento que não cabem na validação criptográfica de origem. A abertura escolhe um objeto concreto. Em 20 de maio de 2025, um BGP UPDATE carregava um atributo Prefix-SID corrompido. Prefix-SID é opcional e transitivo; seu código é 40.

O caminho descrito não respondeu de forma uniforme. Cisco IOS-XR e Nokia SR OS teriam descartado o atributo. Junos deixou a mensagem seguir. Roteadores Arista, ao recebê-la, reiniciaram sessões BGP. Route servers de vários pontos de troca também a repassaram. Em dez segundos, diz o artigo, houve mais de 150 mil atualizações, com flapping de rotas associadas a redes como Starlink, Disney, Zscaler e ByteDance. A Arista alterou o comportamento no EOS 4.28.11 e posteriores.

O mérito da descrição é separar mecanismos. O evento não precisa ser chamado de sequestro de prefixo nem de vazamento de rota. Um prefixo pode ter origem autorizada e ainda carregar outro atributo com codificação capaz de ativar um caminho de erro no próximo parser. RPKI responde a uma pergunta diferente.

O limite aparece quando o nome do fornecedor vira sinônimo de estado operacional. Cisco, Nokia, Juniper e Arista não identificam a versão do parser, o patch, a opção de tratamento revisado de UPDATE nem o resultado da herança de templates. Também não dizem se a sessão era interna, de cliente, de trânsito, de peer ou de route server.

A regra é precisa, o parque não é automático

A RFC 8669 define o atributo Prefix-SID como uma coleção de TLVs. Quando o atributo é curto demais, traz comprimento inválido ou permite que um TLV ultrapasse o limite declarado, o receptor deve descartar o atributo e registrar o erro. A ação corresponde ao Attribute discard da RFC 7606.

Essa é a referência normativa. Ela permite avaliar conformidade, mas não comprova o que cada equipamento instalado fez em uma data específica.

O relato contemporâneo de Ben Cox preserva uma condição útil: IOS-XR e SR OS filtraram o objeto, supondo que os sistemas estivessem configurados para tolerância a erros da RFC 7606. A frase da LACNIC é mais categórica e diz que as duas plataformas fizeram o que a RFC determina. Os resultados podem coincidir; a primeira redação, porém, mantém a configuração dentro da cadeia de prova.

Não se trata de transformar concisão em erro. Uma reportagem precisa resumir, uma pesquisa precisa padronizar nomes e um incidente distribuído quase nunca chega com um replay perfeito. A resposta produtiva é adicionar a condição, não apagar a conclusão.

A discussão na NANOG no dia do evento mostra por quê. Ela relaciona o comportamento do EOS ao bug 899981 e aponta correções nas séries 4.28.11, 4.29.8, 4.30.6 e 4.31.2. Os participantes também perguntam se a mudança produziria uma resposta limpa para a mensagem exata. Uma apresentação posterior da Arista no JANOG 57 repete a comparação entre IOS XR, SR OS, Junos e EOS e cita as mesmas versões. É uma reconstrução forte, mas ainda não é um ensaio único, com o mesmo vetor e parâmetros declarados, em todas as famílias.

O número de mensagens não mede o número de quedas

O pico acima de 150 mil é relevante porque mostra amplificação. Sua unidade deve permanecer intacta: a fonte apresenta uma taxa de mensagens vista por um coletor, calculada sobre dez segundos. Não são 150 mil prefixos únicos, sessões, roteadores, redes ou indisponibilidades.

Os nomes das redes também não formam um inventário de software. Observar flapping em rotas ligadas a Starlink, Disney, Zscaler ou ByteDance não prova qual versão cada organização usava, se todas receberam os mesmos bytes do mesmo vizinho ou se o impacto para usuários foi equivalente.

A intenção do AS de origem continua desconhecida. O próprio artigo admite explicações não maliciosas: redistribuição mal configurada, script executado duas vezes ou falha de software. Uma categoria de ameaça serve para organizar a análise; não transforma este caso em ataque deliberado.

Uma ficha que possa ser repetida

A LACNIC pode tornar o exemplo operacional sem controlar código de fornecedor ou política de operadora. Basta publicar uma matriz versionada, baseada em um vetor de teste sanitizado e idêntico.

Cada linha começa pelo hash imutável do UPDATE e pela versão do vetor. Depois vêm código 40, flags, comprimento declarado e erro TLV. Em seguida: plataforma, release exata, identificador da correção e configuração efetiva depois da herança de grupo, template e vizinho.

A relação é outra coluna. Uma rede pode tratar o atributo de maneira diferente em iBGP, diante de cliente, trânsito, peer ou route server. A expressão route server não identifica uma pilha ou um filtro universais.

O resultado deve distinguir reset, desativação de AFI/SAFI, treat-as-withdraw, descarte do atributo, aceitação ou outra ação. Se a mensagem sair, publica-se o hash dos bytes sanitizados de saída; se não sair, registra-se a não propagação. Por fim, a linha conecta a ação ao estado da sessão e às mudanças em Adj-RIB-In, Loc-RIB e FIB no ambiente controlado.

Nada disso exige revelar IPs de peers, clientes, credenciais, topologia privada ou configuração completa. Capturas brutas podem ter acesso restrito. O vetor, método, estado de perdas, resultado agregado, correções e data do novo teste podem ser públicos.

A divisão de autoridade permanece clara. As RFCs definem a ação. Fabricantes implementam e corrigem. Operadores escolhem software e política. Quem opera route server decide o que atravessa o serviço. A LACNIC preserva o registro técnico e o método; não passa a governar os roteadores.

O que não está demonstrado

As fontes não mostram que a LACNIC originou o UPDATE, operou um route server afetado ou poderia ter interrompido a sequência. Não fornecem o universo de sessões, uma população de usuários ou uma duração única. Também não provam comportamento eterno de qualquer fabricante.

O episódio não reduz o valor de RPKI dentro de seu escopo. ROV verifica autorização de origem para um prefixo. A segurança sintática de atributo opcional transitivo pertence a outro controle. Misturar os dois apenas inflaria a autoridade esperada da infraestrutura criptográfica e esconderia responsabilidade local.

A notícia é mais específica: a LACNIC publicou uma comparação que merece durar além do próximo upgrade. Os verbos estão claros. A versão seguinte precisa registrar em quais releases e configurações cada verbo foi verdadeiro.

Fontes