Resumo

  • O evento delimitado é o vazamento BGP de 25 de maio de 2023 associado ao AS37468, descrito pela MANRS e pelo Internet Society Pulse [1][2].
  • BGP distribui alcançabilidade, mas não prova automaticamente que um vizinho tinha autorização para repassar cada caminho recebido.
  • RPKI e ROA ajudam a validar a origem de prefixos, mas não validam todo o caminho AS nem a relação que permite a exportação [14][15].
  • AFRINIC RDAP, bgp.tools e PeeringDB ajudam a fixar a identidade de rede. São registros de evidência, não veredictos de culpa [4][5][6].
  • Uma conclusão confiável exige conjunto pretendido de exportação, anúncios reais, decisões dos vizinhos, observações RouteViews/RIPE RIS, estado RPKI/IRR e controle preventivo testável.

O que aconteceu

Para o usuário, o problema pode aparecer como lentidão em uma aplicação ou instabilidade em um site. Na camada de rede, o serviço de destino pode estar saudável, mas o caminho escolhido para chegar até ele pode ter mudado. Se uma rede anuncia uma rota fora do escopo correto e um vizinho aceita essa informação, outros sistemas autônomos podem propagar ou selecionar um caminho ruim.

As fontes públicas não mostram o comando interno, a lista completa de prefixos, todos os fluxos afetados ou todos os logs dos vizinhos. Elas também não provam intenção. Por isso, a análise precisa evitar exageros. O ponto de responsabilidade é mais específico: quais controles de exportação, importação, relacionamento e observação deveriam ter impedido ou limitado a propagação?

Por que a validação de caminho é diferente da origem

Um ROA em RPKI pode indicar que um AS está autorizado a originar um prefixo. Essa é uma evidência forte quando a origem está errada. Porém, um vazamento de rotas pode preservar uma origem plausível e ainda assim atravessar uma relação indevida. A pergunta passa a ser se o caminho deveria ter sido recebido, aceito ou anunciado para outro vizinho.

A RFC 7908 descreve vazamentos de rotas como erros de propagação. A RFC 8212 reforça políticas explícitas de importação e exportação. A RFC 9234 propõe papéis BGP e o atributo Only-to-Customer para sinalizar relações. Esses documentos não provam a configuração da Angola Cables em 25 de maio de 2023, mas indicam as evidências que uma investigação deve buscar.

Identidade AS37468 e registros

O AS37468 ancora o caso em uma superfície técnica real. bgp.tools mostra contexto de roteamento, AFRINIC RDAP registra o recurso autnum e PeeringDB ajuda a orientar a superfície de interconexão declarada [4][5][6]. Esses registros são livros de evidência. Eles não revelam, sozinhos, qual rota foi aceita por qual vizinho.

Um registro não configura um roteador. Uma página no PeeringDB não é um log BGP. A realidade operacional é formada por políticas em execução, rotas exportadas, aceitação por vizinhos e observação pública. Os registros ajudam a organizar a prova em torno de um recurso e de um operador identificáveis.

Observação pública

RouteViews e RIPE RIS fornecem uma visão externa do plano de controle [7][8]. Eles não veem tudo. Um coletor registra o que seus peers enviam. Uma rota visível em um ponto não prova seleção universal, e uma rota ausente não prova inexistência em outro lugar. Mesmo assim, esses sistemas são infraestrutura de responsabilidade.

Uma linha do tempo útil deve mostrar quando a rota apareceu, quais caminhos AS foram vistos, quando houve retirada e se a anomalia voltou. Essa linha deve ser comparada aos logs internos. Se o operador declara uma correção, a visão externa precisa ser compatível com a retirada. Caso contrário, a conclusão permanece fraca.

O que a correção deve demonstrar

A correção deve começar pelo conjunto de rotas que AS37468 pretendia exportar. Em seguida, deve comparar esse conjunto ao Adj-RIB-Out real durante o evento. A diferença indica a superfície do defeito. Também é necessário saber quais vizinhos receberam, rejeitaram, aceitaram ou repassaram as rotas.

A prevenção deve ser testável: listas de exportação mais estritas, filtros gerados de forma conservadora, política default-deny em eBGP, limites maximum-prefix, validação RPKI, papéis BGP e monitoramento de coletores são exemplos. A pergunta final não é apenas quando o caminho ruim sumiu, mas qual controle impede que ele reapareça.

Conclusão

O incidente mostra que a confiabilidade do roteamento depende de camadas conectadas. Registros dão identidade, BGP mostra o estado em execução, coletores preservam observações públicas e logs operacionais explicam causa e reparo. Quando essas camadas são preservadas, o próximo caminho ruim tem maior chance de falhar fechado antes de chegar ao usuário.

Fontes

  1. https://manrs.org/2023/05/bgp-route-leak-at-angola-cables-slows-connectivity-for-many-australians/
  2. https://pulse.internetsociety.org/en/news/2023/05/bgp-route-leak-at-angola-cables-slows-connectivity-for-many-australians/
  3. https://seclists.org/nanog/2023/May/368
  4. https://bgp.tools/as/37468
  5. https://rdap.afrinic.net/rdap/autnum/37468
  6. https://www.peeringdb.com/net?asn=37468
  7. https://www.routeviews.org/routeviews/
  8. https://ris.ripe.net/docs/
  9. https://www.rfc-editor.org/rfc/rfc4271
  10. https://www.rfc-editor.org/rfc/rfc7908
  11. https://www.rfc-editor.org/rfc/rfc7454
  12. https://www.rfc-editor.org/rfc/rfc8212
  13. https://www.rfc-editor.org/rfc/rfc9234
  14. https://www.rfc-editor.org/rfc/rfc6811
  15. https://www.rfc-editor.org/rfc/rfc8893
  16. https://www.rfc-editor.org/rfc/rfc9319
  17. https://manrs.org/isps/guide/
  18. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/