Resumo

  • A BGPMon relacionou problemas de acesso a serviços do Google em 12 de março de 2015 a um vazamento de rotas em que prefixos originados pelo Google foram aprendidos pela Hathway AS17488 e vazados para a Airtel AS9498 [1].
  • A janela observada foi curta, de 08:58 UTC a 09:14 UTC, mas a BGPMon disse que 336 prefixos IPv4 do Google foram afetados [1].
  • O RFC 7908 depois citou o vazamento Hathway-Airtel como exemplo de propagação de prefixos de peer para provedor de trânsito, com interrupção de serviços do Google na Europa e na Ásia [2].
  • O artigo não presume intenção maliciosa, perdas internas nem contagem de usuários. A superfície de responsabilidade é mais estreita: filtros de cliente, validação de relação, política de exportação, alarmes e evidência de reparo.

O que aconteceu

A BGPMon descreveu o evento como uma interrupção de serviços do Google vista por relatos de usuários e por dados de roteamento. A análise mostrou que muitos caminhos para prefixos do Google mudaram entre 08:58 UTC e 09:14 UTC para incluir a Airtel AS9498 na Índia [1].

O detalhe importante é que os prefixos continuavam originados pelo Google AS15169. Portanto, não era um sequestro simples de origem, no qual outra rede fingia ser o Google. O problema estava no meio do caminho de relação. A BGPMon escreveu que o Google fazia peering com a Hathway AS17488, que a Hathway vazou as rotas para seu provedor de trânsito Airtel AS9498, e que a Airtel propagou os anúncios para peers em pontos de troca de tráfego [1].

Essa diferença define a correção. Uma origem correta não prova que o caminho de relação está correto. Uma rede pode aprender uma rota para uso limitado, mas não deve transformá-la automaticamente em trânsito para outros peers ou provedores.

Por que importa

O incidente mostra que uma plataforma do tamanho do Google pode ser afetada por decisões de roteamento fora de sua própria rede. O Google detinha e originava os prefixos. Ainda assim, se uma rota aprendida em uma relação limitada é passada para trânsito e preferida por outras redes, usuários podem perder a rota normal sem que o erro inicial esteja dentro da política do Google.

Isso também é transferência de custo. Um filtro permissivo de cliente pode parecer conveniente, porque reduz exceções manuais. Mas, se um grande provedor de trânsito amplia a rota, o custo de diagnóstico, suporte e disponibilidade passa para redes e usuários que não controlavam aquela relação.

A lição para RPKI é que validação de origem não basta. Se a origem permanece Google AS15169, uma checagem apenas de origem pode passar mesmo quando o caminho está errado. A responsabilidade está no caminho: quem aprendeu a rota, quem podia exportá-la, quem a preferiu e qual evidência impede a repetição da mesma classe de vazamento.

A camada técnica

O modelo simples é um livro de políticas de rota. Um operador deve saber quais prefixos cada cliente, peer ou provedor pode enviar, e para quais vizinhos cada rota pode ser exportada. Uma rota aprendida de um peer normalmente não deveria virar trânsito para outro peer ou provedor. Uma rota aprendida de cliente precisa ser confrontada com autorização de prefixos, objetos IRR/RPKI, caminhos históricos e autorização explícita.

A BGPMon situou o caminho em torno de Google AS15169, Hathway AS17488 e Airtel AS9498. Também afirmou que a Airtel propagou os anúncios para peers em pontos de troca de tráfego, e que algumas redes podem ter preferido o caminho da Airtel porque rotas de clientes podem ter preferência maior do que rotas de peering [1]. O ponto de controle fica entre local preference, economia cliente/provedor e higiene de exportação.

Uma evidência de reparo confiável incluiria listas de prefixos autorizados, route maps, limites max-prefix, etiquetas de relação, objetos IRR/RPKI, alarmes de vazamento, primeiro e último avistamento, withdraws e confirmação pós-reparo em coletores públicos.

Quem foi afetado

A BGPMon disse que os relatos indicavam principalmente usuários europeus e indianos, e o RFC 7908 usou linguagem mais ampla sobre interrupção de serviços do Google na Europa e na Ásia [1][2]. A Vice usou o episódio para explicar como o sistema global de roteamento pode transformar escolhas de caminho em interrupções visíveis para usuários [3].

Essas fontes sustentam um enquadramento de alcançabilidade. Elas não sustentam números inventados de usuários, perdas financeiras ou a afirmação de que todos os serviços do Google ficaram indisponíveis globalmente. A evidência pública mais forte é o AS path, a contagem de prefixos e a janela temporal.

O que observar

O primeiro sinal é se os operadores conseguem nomear a classe de falha: filtro de prefixos de cliente, exportação de rota aprendida de peer, local preference, objeto de rota, exceção temporária ou alarme ignorado. Dizer apenas que o roteamento foi corrigido não prova mudança de controle.

O segundo sinal é a adoção de controles sensíveis à relação. O RFC 7908 definiu o problema; BGP Roles, Only-to-Customer e modelos semelhantes a ASPA movem o setor para uma representação mais verificável de provedor, cliente e peer.

O terceiro sinal é reconciliar coletores públicos com telemetria interna. Um evento visível por dezesseis minutos deve poder ser comparado com logs de BGP, contadores, alertas, relatos de clientes e withdraws.

Fontes

[1] BGPMon, "What caused the Google service interruption?", https://www.bgpmon.net/what-caused-the-google-service-interruption/

[2] RFC 7908, "Problem Definition and Classification of BGP Route Leaks," https://www.rfc-editor.org/rfc/rfc7908.txt

[3] Vice, "Anatomy of a Globe-Spanning Google Outage," https://www.vice.com/en/article/anatomy-of-a-globe-spanning-google-outage/