Resumo

  • O incidente de 25 de agosto de 2017 deve ser lido como uma falha de política interdomínio: o Google exportou rotas aprendidas de pares para a Verizon, a Verizon as aceitou e as propagou, e anúncios mais específicos atraíram tráfego para caminhos que não deveriam funcionar como trânsito.
  • A responsabilidade técnica depende de separar relógios: a correção de configuração atribuída ao Google em cerca de oito minutos não equivale à retirada completa das rotas, à convergência global nem à recuperação percebida por clientes japoneses, que aparece em janelas diferentes nos avisos da NTT Communications e da KDDI.

O vazamento BGP de 25 de agosto de 2017 envolvendo Google, Verizon e redes japonesas é mais útil quando tratado como um caso de controle de roteamento do que como uma narrativa ampla sobre indisponibilidade. A pergunta de responsabilidade não é apenas “quem caiu”, nem “qual empresa pediu desculpas”. A pergunta operacional é mais precisa: quais limites de exportação, importação, propagação e verificação permitiram que rotas aprendidas em uma relação fossem anunciadas em outra, aceitas por uma grande rede de trânsito e usadas por terceiros como caminhos preferíveis por causa da especificidade dos prefixos?

Essa distinção muda o centro do artigo. Se a análise remover BGP, relações entre AS, política de exportação, filtros de importação, prefixos mais específicos, coletores de rota e convergência, o caso deixa de explicar tanto o mecanismo quanto o dano. A falha visível no Japão não surgiu apenas porque uma empresa de tecnologia teve um erro interno. Ela passou a importar para a conectividade japonesa porque anúncios de rota circularam em uma malha de interconexão onde cada rede decide, por configuração em roteadores reais, o que aceita, prefere, exporta e retira.

A camada documental ajuda a reconstruir responsabilidade, mas o tráfego seguiu o estado efetivo dos roteadores.

O contorno factual precisa permanecer estreito. Este texto trata do evento de 25 de agosto de 2017 em que o Google anunciou para a Verizon um grande conjunto de rotas que, segundo análises públicas, haviam sido aprendidas de relações de peering. A Verizon aceitou essas rotas e as redistribuiu. Redes e usuários no Japão observaram instabilidade ou perda de alcance para determinados destinos. Outros incidentes envolvendo o Google, outros vazamentos de rota em anos diferentes, quedas de provedores de nuvem e eventos posteriores de BGP em empresas distintas não fazem parte da cadeia analisada aqui.

A cronologia pública começa com um erro de controle de rotas dentro do domínio do Google. O relato da Internet Society descreve o Google vazando prefixos aprendidos de pares, fazendo com que o Google se comportasse, do ponto de vista de anúncios de rota, como se estivesse oferecendo trânsito para destinos que não deveria transportar. A análise de Doug Madory publicada no CircleID descreveu a propagação via Verizon e enfatizou que o desvio se tornou relevante porque rotas mais específicas foram vistas globalmente. Veículos japoneses e notas de operadoras registraram o impacto local.

O ponto técnico é que o Google não precisava anunciar uma origem falsa para criar risco: bastava exportar caminhos aprendidos em uma relação para outra fronteira onde eles não deveriam ser oferecidos.

A especificidade de prefixos é indispensável nessa cadeia. Em BGP, a seleção administrativa de rotas ocorre em uma sequência de critérios, mas antes mesmo de muitas preferências internas entrarem no debate existe o efeito fundamental do encaminhamento por maior prefixo correspondente. Se uma tabela de roteamento contém uma rota agregada legítima e também uma rota mais específica para parte do mesmo espaço, o tráfego para endereços dentro da rota mais específica tende a seguir o anúncio mais específico.

Por isso, quando análises públicas apontam deagregação ou anúncios mais específicos no incidente, elas não estão descrevendo um detalhe cosmético. Estão descrevendo por que tráfego que antes seguia caminhos normais pôde ser atraído para o caminho anunciado por Google e propagado por Verizon.

Também por isso as contagens de prefixos não devem ser fundidas em um único número absoluto. O relato da Internet Society falou em aproximadamente 135 mil prefixos, enquanto a análise de Doug Madory publicada no CircleID falou em mais de 160 mil prefixos afetados ou visíveis em sua reconstrução. Essas medições não devem ser tratadas como o mesmo total exato: uma contagem pode se referir a prefixos recebidos por um observador, outra a rotas vazadas, outra a rotas propagadas por uma rede específica, outra a prefixos afetados em determinada janela de visibilidade.

Coletores públicos não têm presença em todas as sessões BGP do mundo, e cada observador vê a Internet a partir de seus próprios pares. A responsabilidade analítica aqui é atribuir cada número à fonte que o publicou e evitar transformar medições distintas em uma verdade única.

O mesmo cuidado vale para o tempo. Reportagens japonesas preservam a declaração atribuída ao Google de que o erro de configuração foi corrigido em cerca de oito minutos. A Internet Society descreveu o vazamento em si como durando menos de dez minutos. Esses marcadores pertencem ao relógio de correção do erro iniciador e ao relógio estreito da propagação observada. Eles não encerram, por si só, o relógio de retirada de todas as rotas, a convergência vista por todos os sistemas autônomos, a estabilização de equipamentos de acesso nem a restauração percebida por clientes finais.

Misturar esses tempos produziria uma narrativa errada: a intervenção inicial pode ser rápida, enquanto a recuperação operacional em redes a jusante continua por mais tempo.

Os avisos japoneses tornam essa separação concreta. A NTT Communications informou instabilidade na conectividade OCN em uma janela de 12:22 a 12:45, horário japonês, associando o problema a grandes mudanças de rotas na Internet e afirmando que não havia anormalidade nos próprios equipamentos OCN. A KDDI publicou aviso de instabilidade para alguns clientes de acesso à Internet e registrou uma janela de recuperação mais longa, encerrada às 16:47 para o conjunto descrito em sua nota. Esses dois avisos não provam impacto universal no Japão. Eles provam que operadores específicos observaram efeitos com janelas próprias.

A diferença entre os tempos é parte da evidência, não um ruído a ser apagado.

A cadeia técnica, portanto, deve ser lida em cinco passos. Primeiro, o Google criou ou exportou anúncios inesperados. Segundo, a Verizon aceitou esses anúncios em uma fronteira onde filtros de relacionamento poderiam ter limitado a aceitação. Terceiro, a Verizon os propagou adiante, ampliando a visibilidade do vazamento. Quarto, rotas mais específicas atraíram tráfego que, em condições normais, seguiria outros caminhos para os detentores dos prefixos.

Quinto, o Google não era a rede de trânsito operacional para esses destinos, de modo que pacotes podiam ser desviados, descartados ou encaminhados de forma incapaz de completar a comunicação esperada. A recuperação, por sua vez, exigiu retirada de anúncios, convergência de rotas e estabilização a jusante.

A atribuição de controles também precisa acompanhar essa cadeia. O Google controlava seus sistemas de geração de anúncios, políticas de exportação por par, validação de mudanças, alarmes de vazamento, autoridade de reversão e comunicação pública. A Verizon controlava sua aceitação de rotas do Google, filtros de importação, regras de exportação para outros vizinhos, limites de prefixos, detecção de anúncios anômalos e escalonamento. Operadoras japonesas controlavam sua própria observabilidade, comunicação com clientes, resposta local a flutuações de rota e estabilização de serviços.

Detentores de recursos de numeração controlavam registros e autorizações de origem dentro dos limites desses registros. Observadores públicos controlavam medições parciais, não a verdade completa da topologia.

Essa é uma análise de responsabilidade prática, não uma alegação de intenção maliciosa. As fontes públicas citadas não dão base para chamar o evento de ataque deliberado, hijack intencional, ilegalidade, quebra contratual ou negligência. Também não dão base para inferir termos privados de peering, comandos específicos digitados em roteadores, preferências locais internas ou a aceitação de todas as rotas por todos os pares da Verizon. A evidência pública permite dizer que houve uma cadeia de anúncios anômalos, aceitação, propagação e efeitos japoneses observáveis.

Ela não permite reconstruir todos os logs privados nem substituir investigação interna por suposição.

A camada de registros de recursos tem papel importante, mas limitado. Registros de ASN, prefixos, contatos e autorizações ajudam a saber quem deveria ser associado a determinados recursos de numeração e a criar trilhas auditáveis. Objetos ROA em RPKI podem indicar quais origens são autorizadas para determinados prefixos e tamanhos máximos. Isso é essencial para auditoria e para automação de filtros. Mas registros corretos não obrigam roteadores a obedecer relações comerciais ou políticas de exportação.

Se uma rota preserva a origem autorizada, mas é transportada por um caminho incompatível com a relação entre redes, a validação de origem pode não rejeitá-la. A política de relacionamento precisa ser codificada e verificada em BGP, não apenas documentada em registros.

Essa limitação é central para o incidente. Um vazamento de rota pode ocorrer sem falsificar a origem do prefixo. O problema pode estar no caminho pelo qual a rota é oferecida e na relação que permite ou proíbe a exportação daquele aprendizado para outro vizinho. ROV, conforme definido para validação de origem, pergunta se o AS de origem anunciado é compatível com a autorização existente. Ela não pergunta, sozinha, se um provedor deveria ter exportado para um par uma rota aprendida de outro par, nem se uma rede de trânsito deveria ter aceitado um conjunto anômalo de mais específicos vindos daquela sessão.

Portanto, dizer que “RPKI resolveria” o evento apagaria o verdadeiro ponto de controle.

As análises posteriores ajudam como comparação, não como dever retroativo. RFC 8212 tornou explícita a ideia de rejeitar por padrão em eBGP quando políticas de importação e exportação não estão configuradas. RFC 9234 descreveu BGP Roles e o atributo Only-to-Customer para sinalizar relações e reduzir vazamentos. RFC 7908 classifica tipos de route leak. RFC 7454 consolida boas práticas operacionais para filtros, limites de prefixos e segurança de sessões. MANRS organiza compromissos de filtragem, coordenação, validação e medição. Peerlock e ASPA aparecem em discussões posteriores como mecanismos para reduzir certos vazamentos de caminho.

Esses controles iluminam o que faltava como engenharia de defesa em profundidade; não provam, por si sós, uma infração em 2017.

A visibilidade pública vem de fontes como RouteViews, BGPStream e análises que usam dados de coletores. Esses sistemas são fundamentais porque preservam anúncios vistos por pares participantes, permitem reconstruir janelas de tempo e mostram caminhos AS em pontos específicos da rede. Mas eles não veem todas as sessões privadas, não revelam rotas rejeitadas por uma rede, não mostram a FIB de cada roteador, não expõem preferências locais e não medem diretamente a experiência de cada aplicação. Um coletor ver uma rota não significa que todos instalaram a rota. Um coletor não ver uma rota não prova que ninguém a recebeu.

A evidência é forte, mas parcial.

A análise do CircleID é relevante porque conecta o evento a trajetos e impactos japoneses, incluindo a presença de caminhos via Verizon e Google em observações públicas. A Internet Society é relevante porque descreve o vazamento como exportação de prefixos aprendidos de pares e destaca o efeito de rotas mais específicas. As notas da NTT Communications e da KDDI são relevantes porque transformam o debate de plano de controle em impacto operacional delimitado. Reportagens japonesas preservam a comunicação pública do Google e a percepção local do evento.

A reconstrução técnica do Geekpage ajuda a tratar mais específicos e propagação sem reduzir a história a uma manchete.

O resultado para usuários japoneses deve ser descrito com precisão. Houve instabilidade e problemas de alcance em redes e serviços observados no Japão, mas as fontes públicas disponíveis não autorizam dizer que toda a Internet japonesa ficou fora do ar, que todos os provedores foram afetados, que todos os clientes da Verizon receberam as rotas ou que todo serviço japonês falhou pelo mesmo caminho. A formulação mais defensável é que anúncios anômalos globais provocaram efeitos materiais em conectividade japonesa, observados por operadoras e reportagens, com intensidade e duração variáveis conforme a rede, o serviço e a etapa de recuperação.

A pergunta de responsabilidade, então, não busca um culpado único. Ela distribui controles conforme fronteiras operacionais. O primeiro controle é impedir exportação indevida: uma rede que aprende rotas de pares ou clientes precisa garantir que essas rotas sejam anunciadas apenas aos vizinhos adequados. O segundo é impedir importação indevida: uma rede grande não pode depender apenas da boa formação do vizinho; precisa limitar o que aceita conforme a relação, o volume, a especificidade e a coerência com registros.

O terceiro é impedir propagação indevida: uma rota aceita não deve automaticamente se tornar uma rota exportada a terceiros sem política explícita. O quarto é detectar e reverter: quando anúncios anômalos escapam, alertas, autoridade de rollback e verificação externa determinam o tempo real de exposição.

A diferença entre correção e recuperação é a lição de continuidade operacional. O Google pode corrigir uma configuração em oito minutos e ainda assim clientes japoneses podem observar instabilidade por uma janela mais longa, porque a Internet não é um banco de dados central que volta ao estado anterior instantaneamente. Atualizações BGP precisam ser retiradas, caminhos concorrentes precisam ser recalculados, sessões podem precisar estabilizar, sistemas a jusante podem ter filas, timeouts e caches, e operadores precisam confirmar que o problema deixou de afetar clientes.

A responsabilidade de continuidade mede tanto a prevenção quanto a capacidade de provar restauração. Sem evidência de retirada, convergência e normalização de serviço, o relógio público fica incompleto.

Essa separação também evita duas leituras simplistas. A primeira diz que, se o erro foi corrigido rapidamente, o impacto restante não importa. Isso é errado porque clientes dependem da continuidade percebida, não apenas da linha do tempo interna do originador. A segunda diz que, se a KDDI registrou recuperação mais tarde, o vazamento BGP durou até esse horário. Isso também é errado porque o aviso de cliente mistura efeitos a jusante, estabilização e comunicação de recuperação; não é necessariamente a duração do anúncio anômalo nos coletores. A análise correta mantém todos os relógios visíveis.

No plano de controles atuais, a lição é que política de roteamento deve ser escrita para a máquina e auditada com dados externos. Uma relação de peering não vira controle apenas por ser descrita em contrato ou diagrama. O roteador precisa ter filtros específicos de importação e exportação, preferencialmente gerados a partir de fontes verificadas e revisados contra exceções conhecidas. O operador precisa aplicar limites de prefixos para impedir que uma sessão aceite, de repente, uma quantidade incompatível com o perfil esperado.

O monitoramento precisa alertar sobre deagregação, picos de prefixos, caminhos AS inesperados e propagação por relações improváveis. A reversão precisa estar ensaiada e autorizada antes do incidente.

O caso de 2017 permanece atual exatamente porque muitas organizações ainda confundem evidência com execução. Registros corretos de recursos de Internet são indispensáveis, mas não substituem filtros. Coletores públicos são indispensáveis, mas não substituem telemetria interna. Declarações públicas são indispensáveis, mas não substituem trilhas verificáveis de retirada e convergência. Uma rede pode cumprir parcialmente uma camada e falhar em outra. A responsabilidade madura não escolhe uma única solução; ela exige camadas que se verifiquem mutuamente.

Quando o tráfego japonês foi atraído por rotas mais específicas, o ponto de falha não estava no usuário final, nem em algum ato voluntário de quem apenas tentou acessar serviços. Usuários e empresas dependiam de uma malha global de roteamento que não controlavam. A obrigação técnica estava nas redes que criaram, aceitaram, redistribuíram e monitoraram o estado interdomínio. Isso não elimina a responsabilidade de operadoras locais por comunicação e estabilização, mas impede deslocar a prevenção para quem não opera BGP.

O evento também ilustra o valor de uma linguagem de incidentes que preserve incerteza. É legítimo dizer que análises públicas apontaram Google, Verizon e efeitos japoneses. É legítimo discutir filtros de exportação, filtros de importação, max-prefix, monitoramento, rollback e validação como controles de responsabilidade. Não é legítimo preencher lacunas com afirmações sobre intenção, comando interno, contrato privado ou aceitação universal. Em infraestrutura de rede, precisão não é cautela excessiva; é parte da segurança. Diagnósticos imprecisos criam controles errados.

Por fim, a conclusão técnica não é que BGP seja intratável. O protocolo opera em uma Internet descentralizada, com confiança distribuída e políticas locais. Isso cria fragilidade, mas também pontos claros de melhoria. Route leaks podem ser reduzidos quando operadores codificam relações, rejeitam por padrão, limitam volumes, validam origens, filtram por registros, monitoram propagação externa, coordenam resposta e publicam evidência de restauração. O incidente de 2017 mostrou que a continuidade japonesa podia ser afetada por uma cadeia curta de decisões de roteamento fora do controle dos usuários afetados.

Essa é exatamente a razão para tratar filtragem de trânsito como responsabilidade verificável, não como detalhe interno de engenharia.