Resumo

  • Por volta de 02:24 UTC em 6 de novembro de 2012, a Cloudflare observou serviços do Google inacessíveis em partes da Internet. Um caminho publicado por sua equipe passava por AS4436, PCCW/AS3491, Moratel/AS23947 e, ao final, pela origem legítima Google/AS15169 [1].
  • A Cloudflare descreveu uma interrupção limitada de aproximadamente 27 minutos e estimou impacto potencial sobre 3-5% da população da Internet, mais intenso perto de Hong Kong. O número é uma estimativa da Cloudflare, não um censo independente [1].
  • A RFC 7908 cita o incidente Moratel-PCCW como exemplo de vazamento do tipo 4: prefixos aprendidos de um par foram exportados para um provedor de trânsito além do escopo pretendido [2].
  • A avaliação inicial da Cloudflare considerou provável um anúncio equivocado. Uma atualização registrou a explicação de Moratel de que uma falha inesperada de hardware causou a condição anormal e não houve intenção maliciosa [1]. A evidência pública não resolve a sequência interna exata.
  • A responsabilidade cobre exportação e aceitação. Moratel precisava impedir que rotas não autorizadas saíssem; PCCW precisava distinguir rotas válidas de cliente daquelas aprendidas em outra relação.

O que a observação estabelece

A Cloudflare informou que sua equipe percebeu a indisponibilidade por volta de 02:24 UTC. O sintoma inicial parecia ser DNS, porque nem o endereço 8.8.8.8 estava acessível de sua rede. A investigação mudou para o roteamento quando um traceroute mostrou um endereço Moratel na Indonésia, um desvio inesperado para tráfego saindo da Califórnia em direção ao Google [1].

O caminho registrado para um prefixo do Google continha AS4436, AS3491, AS23947 e AS15169. O último ASN continuava sendo a origem Google. Não era, portanto, uma simples troca da origem por um invasor. A falha estava no meio: uma rota plausível atravessou uma fronteira operacional e comercial que não deveria transportá-la.

A Cloudflare afirmou ter contatado um engenheiro de Moratel. O anúncio foi corrigido perto de 02:50 UTC e o roteamento voltou ao normal cerca de três minutos depois [1]. A interrupção foi curta e limitada, mas real para os usuários afetados. Aplicações e servidores de destino podiam continuar saudáveis enquanto o caminho entre redes tornava o serviço inalcançável.

Os limites precisam permanecer explícitos. A Cloudflare tinha um ponto de observação operacional relevante, mas não via todos os usuários, redes ou produtos do Google. Sua estimativa de 3-5% não deve virar uma medida universal. Da mesma forma, a hipótese inicial de erro humano foi posteriormente acompanhada da declaração de Moratel sobre falha de hardware. Sem logs do roteador, alarmes, histórico de configuração e cronologia interna, o público não consegue decidir entre hardware, software, configuração, failover ou uma interação desses elementos.

Por que a classificação é tipo 4

BGP permite que sistemas autônomos troquem informações de alcance. Cada sistema tem um ASN e aplica sua própria política. Um anúncio leva prefixo, AS_PATH e outros atributos. O roteador decide o que aceitar, preferir e anunciar novamente.

Essas decisões representam relações. Um cliente compra trânsito de um provedor. Dois pares normalmente trocam suas rotas e as de seus clientes, sem dar trânsito completo um ao outro. Assim, uma rota pode ser válida na sessão em que foi recebida e proibida quando exportada para outro vizinho.

A RFC 7908 define vazamento como propagação além do escopo pretendido. O tipo 4 descreve um AS que anuncia ao seu provedor de trânsito rotas aprendidas de um par lateral. O documento lista especificamente o vazamento Moratel-PCCW de prefixos do Google [2].

Isso explica por que validar apenas a origem não basta. AS15169 permanecia no final do caminho. O controle necessário era relacional: AS23947 podia exportar essa rota para AS3491? AS3491 deveria aceitá-la como rota de cliente? Uma origem autorizada não torna automaticamente legítimo o caminho intermediário.

Dever de evidência na exportação

O operador exportador deve conseguir reconstruir a sessão, seu papel, as rotas recebidas, as selecionadas e as efetivamente anunciadas ao vizinho. O registro deve separar prefixos próprios, rotas autorizadas de clientes, rotas aprendidas de pares e rotas recebidas de provedores.

Se uma falha de hardware iniciou o incidente, o fechamento útil precisa mostrar o efeito sobre a política. Um reinício carregou configuração incompleta? Um caminho de contingência ativou uma regra mais ampla? Uma tabela temporária saiu durante a convergência? Um filtro deixou de ser aplicado? “Falha de hardware” descreve uma categoria de gatilho, mas não explica por que a exportação pôde falhar de forma aberta.

A prova deve ligar intenção e execução. Um diff de configuração ajuda, porém não basta. São necessários o conjunto anunciado, atributos e comunidades relevantes, eventos do equipamento, marcas de tempo, responsáveis e a sequência de retirada. Só assim é possível saber se a correção fechou a falha ou apenas removeu o sintoma visível.

Dever de evidência na aceitação

A Cloudflare descreveu PCCW como o provedor upstream que confiou nas rotas de Moratel e as propagou [1]. O RDAP atual identifica AS3491 como PCCWG-APAC-HK e o associa à PCCW Global (HK) Limited [6]. Isso dá continuidade de identidade atual; não reconstrói todos os termos da relação de 2012.

Um provedor de trânsito escolhe quais anúncios de cliente aceita e para onde os distribui. Ele precisa manter prefixos e origens autorizados, cone esperado de cliente, padrões de caminho, limites de quantidade, alertas e exceções. Se um cliente carrega legitimamente rotas de terceiros, o filtro fica mais complexo. A complexidade exige uma base de autorização melhor, não ausência de controle.

Uma grande rede upstream amplia o impacto. A frase “o cliente anunciou” não encerra a responsabilidade. O produto do provedor é propagação controlada. Seus registros devem mostrar quando a rota foi recebida, por que passou pelo filtro, como foi classificada e para quais vizinhos foi anunciada.

Registro e camada de realidade

O RDAP atual da APNIC identifica AS23947 como MORATELINDONAP-AS-ID e o associa à PT. Mora Telematika Indonesia [5]. O registro de AS3491 identifica PCCWG-APAC-HK e PCCW Global (HK) Limited [6]. Esses registros preservam identidade e contatos de recursos numéricos.

Eles não mostram o estado em execução às 02:24 UTC. Um registro diz quem opera um ASN, não qual política estava carregada ou quais rotas saíam por uma sessão. Essa é a superfície Heng.lu: o registro é livro de controle e continuidade, não substituto da rede em operação. A evidência nasce da conciliação entre identidade, relação pretendida e estado realmente executado.

A resposta histórica do RIPEstat para 8.8.8.0/24 mostra visibilidade de AS15169 como origem durante o dia consultado [4]. A granularidade de oito horas não prova uma fuga que durou minutos. O caminho anormal vem da observação contemporânea da Cloudflare; a classificação vem da RFC 7908.

Controles que devem fechar com segurança

Cada sessão externa precisa de políticas explícitas de importação e exportação. A ausência de política não pode significar tabela aberta. Uma rota aprendida de um par não deve se tornar exportável a um provedor por padrão.

O sistema de provisionamento deve registrar ASN vizinho, papel, prefixos ou origens autorizados, limites, dono da mudança e expiração de exceções. A automação deve gerar a política e depois reconciliar a configuração implantada com essa intenção.

O conjunto efetivamente anunciado precisa ser monitorado. Aumento repentino de rotas, origem externa inesperada ou sequência de AS incompatível com o papel da sessão deve acionar contenção.

A RFC 9234, publicada anos depois, define BGP Roles e o atributo Only-to-Customer. Esses mecanismos tornam algumas relações legíveis por máquinas e ajudam a identificar propagação incompatível [3]. São contexto de controle atual, não evidência de implantação em 2012.

Observação externa também é necessária. Coletores e redes remotas podem ver uma rota fora da fronteira quando os dois operadores acreditam que seu estado local está correto. Essa observação deve ser correlacionada com Adj-RIB-In, decisão local e Adj-RIB-Out.

Um fechamento público verificável

O fechamento deve começar com uma linha do tempo UTC: primeiro sintoma, alerta interno, identificação da rota, contato, interrupção do anúncio, retirada observada e estabilidade. Deve diferenciar hora de observação e hora de diagnóstico.

Também deve definir a classe de falha sem publicar segredos: rota aprendida de par exportada para trânsito, política ausente, obsoleta ou contornada e filtro de cliente amplo demais. A incerteza sobre o gatilho precisa permanecer visível.

Por fim, a mudança durável deve ser testada. Intenção aprovada, política gerada, hash da implantação, teste negativo com rota equivalente, limite de alerta, responsável por rollback e observação externa formam uma prova muito mais forte do que “filtros atualizados”. Restaurar o serviço fecha a urgência; provar a rejeição futura fecha o risco.

Fontes

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491