Vazamento de rota do Google em 2018 revela descompasso entre contratos e controle de roteamento

Resumo

• Em 12 de novembro de 2018, rotas associadas aos serviços do Google foram vazadas pelo provedor nigeriano MainOne para a China Telecom e depois propagadas por outros provedores, fazendo com que parte do tráfego destinado ao Google seguisse caminhos inesperados e deixasse serviços inacessíveis para alguns usuários.
• O incidente é diferente do sequestro do YouTube pela Pakistan Telecom em 2008. Aqui, o problema crítico de responsabilidade não foi um bloqueio nacional exportado como rota mais específica de origem errada; foi uma incompatibilidade entre contrato e controle na qual rotas aprendidas por meio de um relacionamento vazaram para outros.
• O registro público sustenta configuração incorreta acidental, e não prova de comprometimento bem-sucedido do conteúdo. O Google teria dito que o tráfego afetado era criptografado e que não havia razão para acreditar que os serviços foram comprometidos, enquanto observadores independentes consideraram o caminho de roteamento como um sério risco de disponibilidade e vigilância.
• A validação de origem RPKI não é uma resposta completa para essa classe de falha porque as rotas afetadas ainda poderiam parecer originadas do AS legítimo do Google. Vazamentos de rota exigem filtragem de cliente e peer, controles com reconhecimento de relacionamento, limites de prefixo, monitoramento, coordenação e mecanismos posteriores, como Funções BGP.
• A lição de responsabilidade é que contratos comerciais de peering e trânsito não se aplicam sozinhos. Os operadores devem converter relacionamentos comerciais em políticas de roteador e controles externamente verificáveis antes que uma rota vazada se torne uma interrupção global.

Registro de evidências e como é usado

Este artigo trata o registro público como evidência em camadas. Relatórios de incidentes, padrões, medições de navegador ou roteamento, materiais regulatórios ou políticos e orientações atuais para operadores são usados para diferentes alegações. Fontes de autoria corporativa são atribuídas como posições da empresa. Padrões e orientações posteriores são usados para explicar controles e apresentar expectativas de responsabilidade, não para inventar fatos privados ou impor retroativamente obrigações posteriores quando o registro público não sustenta essa alegação.

O incidente foi sobre limites que os roteadores não podiam inferir

O vazamento de rota do Google em 2018 é fácil de achatar em uma frase familiar: o BGP é frágil. Essa frase é verdadeira, mas não é precisa o suficiente. A lição mais cortante é que a internet contém muitos relacionamentos comerciais que o software de roteamento não pode inferir a menos que os operadores os codifiquem. Um peer pode enviar rotas que deveriam permanecer locais. Um provedor de trânsito pode receber rotas que nunca deveriam ser aceitas daquele vizinho. Uma rota pode reter o AS de origem correto enquanto ainda viaja por um caminho que viola expectativas comerciais e operacionais.

Os relatos da Cloudflare, ThousandEyes e Internet Society convergem para a forma central. A MainOne tinha conectividade com o Google por meio de um relacionamento de peering em Lagos. Rotas associadas ao Google escaparam desse relacionamento em direção à China Telecom. A China Telecom as propagou adiante, e caminhos envolvendo TransTelecom, NTT e outras redes apareceram. Usuários tentando alcançar os serviços do Google então seguiram caminhos que não tinham a capacidade, política ou filtragem esperada para transportar esse tráfego. Parte do tráfego foi descartada e os serviços se tornaram inacessíveis para alguns usuários.

Isso não é o mesmo mecanismo do sequestro do YouTube pela Pakistan Telecom. Em 2008, a Pakistan Telecom originou uma rota mais específica para o espaço de endereço do YouTube a partir do AS de origem errado, e a PCCW a propagou. Em 2018, as importantes análises públicas descrevem um vazamento de rota onde rotas originadas pelo Google foram propagadas além do relacionamento pretendido. A origem podia parecer legítima enquanto o caminho ainda estava errado. Essa distinção importa porque muda os controles que teriam ajudado. A validação de origem pode rejeitar uma origem falsa.

Não pode, por si só, provar que uma rota de origem correta cruzou apenas relacionamentos comerciais válidos.

A incompatibilidade contrato-controle é o centro do problema de governança. Um contrato de peering pode dizer que uma parte deve trocar apenas certas rotas ou não deve fornecer trânsito. Um acordo de trânsito pode definir cones de cliente e regras de exportação. Mas um roteador remoto encaminhará com base nas rotas que recebe e na política que está configurado para aplicar. Se a política estiver ausente, desatualizada ou muito permissiva, o limite legal ou comercial se torna decorativo. O pacote segue o plano de controle, não o PDF do contrato.

É por isso que o evento pertence à governança. A falha não foi um desastre natural misterioso. Foi uma incompatibilidade entre configuração técnica, relacionamento comercial, autoridade de rota, monitoramento e escalação. Cada organização no caminho tinha uma visão operacional mais estreita do que o efeito global. A MainOne podia configurar incorretamente a exportação. A China Telecom podia aceitar e propagar. Outros provedores podiam preferir ou repassar os caminhos. O Google podia detectar, comunicar e proteger a confidencialidade da camada de serviço, mas não podia reescrever diretamente toda política de importação externa.

Origem correta não significava rota correta

Muitas discussões sobre segurança de roteamento começam com sequestros porque anúncios de origem errada são mais fáceis de explicar. Alguém que não possui um prefixo diz, em efeito, envie esse tráfego para mim. A Validação de Origem de Rota RPKI é construída para lidar com essa classe: o titular do recurso publica uma Autorização de Origem de Rota, e redes validadoras podem rejeitar rotas cujo AS de origem ou comprimento de prefixo não correspondem. Esse controle é importante. O evento do Google em 2018 mostra seu limite.

A Internet Society deixou o ponto claro em sua análise pública: neste cenário, os prefixos ainda estavam se originando legitimamente do AS correto, então é difícil para redes intermediárias bloquear o vazamento usando apenas a validação de origem. A rota poderia ter uma origem válida e ainda representar uma relação de exportação inválida. É por isso que um vazamento de rota não é simplesmente um sequestro com linguagem mais suave. É uma falha de relacionamento: as rotas se propagam além de seu escopo pretendido.

O efeito prático pode ser igualmente severo para os usuários. Uma rota de origem correta que viaja pelo provedor errado pode levar o tráfego para uma rede com capacidade insuficiente, filtragem restritiva, preocupações de vigilância ou baixa acessibilidade. Os usuários veem timeouts. Os clientes veem serviços em nuvem quebrados. As equipes de incidente veem traceroutes estranhos através de países e provedores que não esperavam. A origem correta não os tranquiliza se o caminho descarta pacotes ou viola suas suposições de risco.

Essa distinção deve mudar a aquisição e a supervisão do conselho. Perguntar se um provedor tem RPKI é útil, mas incompleto. Os compradores também devem perguntar se o provedor filtra rotas de clientes, rejeita rotas inconsistentes com relacionamentos comerciais, mantém limites de prefixo, monitora vazamentos, participa de canais de coordenação e pode explicar como as rotas de peering são mantidas longe de se tornarem rotas de trânsito. Uma resposta sim/não sobre a cobertura RPKI não pode substituir o controle de rota com reconhecimento de relacionamento.

Trabalhos técnicos posteriores, como Funções BGP e o atributo Only-to-Customer, tentam tornar os relacionamentos comerciais visíveis para o protocolo de roteamento. Esses mecanismos não eram um controle universal concluído em 2018, e o artigo não os aplica retroativamente como um padrão obrigatório. Sua relevância é explicativa: eles existem porque os operadores reconheceram que muitos vazamentos prejudiciais são falhas de política de caminho, e não falhas de autorização de origem. A indústria precisava de maneiras de tornar "esta rota não deveria ir por aqui" verificável por máquina.

A China Telecom foi o amplificador de propagação

A MainOne aparece no registro público como a fonte do vazamento, mas o evento se tornou globalmente significativo porque outros provedores aceitaram e propagaram as rotas. A China Telecom é central nos relatos públicos porque recebeu as rotas vazadas do Google e as passou adiante. Esse papel deve ser descrito com cuidado. Fontes públicas sustentam manuseio acidental ou incorreto de rotas; elas não provam uma operação bem-sucedida de interceptação de tráfego. Mas a intenção não é necessária para a responsabilidade. Um provedor de trânsito pode causar grandes danos ao acreditar em uma rota de cliente ou peer que deveria ter filtrado.

Um provedor com alcance global tem uma obrigação de alta alavancagem de saber quais rotas um vizinho está autorizado a anunciar e quais rotas devem ser exportadas. Isso não significa que toda decisão de rota é simples. Os cones de cliente mudam, os peers têm arranjos complexos, as trocas de internet carregam rotas diversas e os dados de registro podem ser confusos. No entanto, o dever básico permanece: um grande provedor não deve tratar toda rota inesperada como globalmente exportável meramente porque a sintaxe BGP é válida.

A filtragem também deve corresponder ao relacionamento. Uma rota de peer não deve se tornar uma rota de trânsito a menos que o relacionamento permita explicitamente. Um cliente não deve poder anunciar as rotas de uma grande plataforma de nuvem a menos que esse cliente esteja legitimamente fornecendo trânsito para essa plataforma. Um provedor deve aplicar filtros de prefixo e caminho AS, limites de prefixo máximo, geração de política de rota a partir de dados confiáveis, monitoramento de mudanças repentinas em conjuntos de rotas e escalação fora de banda para anúncios anômalos de prefixos famosos.

A visibilidade pública do caminho da rota tornou difícil ignorar o papel da propagação. A ThousandEyes descreveu caminhos através da China Telecom e TransTelecom. A Cloudflare registrou roteamento incomum e impacto no serviço. Reportagens da imprensa focaram no tráfego passando pela China e Rússia porque esse caminho carregava preocupações óbvias de vigilância e soberania. Mesmo que o tráfego estivesse criptografado e não tivesse sido mostrado como comprometido, a própria rota minou as expectativas dos clientes sobre onde o tráfego viajaria e se permaneceria acessível.

Este é o ponto político: um provedor que exporta uma rota vazada converte o erro de outra rede em um evento global. A configuração incorreta original importa, mas a propagação determina o raio da explosão. A responsabilidade de roteamento deve, portanto, medir a primeira exportação ruim e todos os principais pontos de amplificação.

O Google tinha deveres de resiliência, mas não controle unilateral

O Google era o operador do serviço afetado e uma das partes com maior capacidade de detectar que algo estranho estava acontecendo com o tráfego destinado ao Google. Também controlava as proteções da camada de aplicação que importavam. Relatos públicos afirmaram que o Google disse que o tráfego afetado era criptografado e não havia razão para acreditar que os serviços foram comprometidos. Essa distinção importa. A criptografia pode reduzir o risco de confidencialidade mesmo quando o roteamento segue um caminho ruim.

Ela não resolve o risco de disponibilidade, mas impede que o vazamento de rota se torne automaticamente um evento comprovado de exposição de dados.

Os deveres do Google em tal evento incluem monitoramento de rota, publicação de ROA, objetos IRR precisos, escalação a provedores, comunicação com clientes, engenharia de tráfego de emergência e evidência pós-evento. Uma plataforma do tamanho do Google não pode parar todo vazamento externo, mas pode reduzir o tempo de detecção e reparo. Também pode projetar serviços para que um desvio de caminho não exponha silenciosamente o conteúdo do usuário. Criptografia, higiene de certificados, redundância de serviço e telemetria de rede fazem parte desse pacote de resiliência.

Ao mesmo tempo, o Google não podia forçar unilateralmente a MainOne ou a China Telecom a aplicar a política correta de importação e exportação. É por isso que a responsabilidade de segurança de rota deve seguir a capacidade de controle, e não a visibilidade da marca. Os usuários experimentaram sintomas de interrupção do Google, e a marca do Google sofreu o impacto público de confiança. Mas a política do roteador que aceitou e exportou as rotas vazadas estava fora da rede do Google. A questão de governança é como os contratos do Google, arranjos de peering e playbooks de escalação abordaram essa dependência externa antes do evento.

Um registro público mais forte das plataformas afetadas incluiria o tempo de detecção, número de prefixos afetados, impacto no cliente, mudanças de caminho observadas, avaliação de criptografia e confidencialidade, provedores contatados, timestamp de reparo e quaisquer mudanças no monitoramento de rota ou requisitos de parceiros após o incidente. Parte dessa evidência pode ser sensível durante um evento ao vivo, mas resumos pós-evento podem compartilhar categorias sem expor segredos defensivos.

Para os clientes, a lição não é culpar o Google por toda rota externa. É perguntar aos grandes provedores de nuvem e plataforma como eles monitoram a acessibilidade global, quais rotas são autorizadas, com que rapidez detectam caminhos suspeitos e quais compromissos assumem quando uma falha de roteamento de terceiros torna os serviços inacessíveis. A disponibilidade não termina na borda do provedor.

Contratos precisam de controles executáveis

A frase incompatibilidade contrato-controle captura um padrão de falha que aparece em toda a infraestrutura da internet. As partes podem ter contratos que definem quem é peer, cliente ou provedor. Mas os roteadores aplicam política de rota, não intenção legal. Se a política de rota não incorpora o relacionamento, o contrato se torna um argumento a posteriori, em vez de um controle preventivo. O vazamento do Google em 2018 tornou essa lacuna visível para usuários comuns porque a mudança de caminho quebrou serviços altamente visíveis.

Controles executáveis incluem filtros de prefixo construídos a partir de conjuntos de rotas autorizados pelo cliente, filtros de caminho AS, limites de rota, políticas de sessão peer, validação de origem RPKI, detecção de vazamento de rota, alertas para exportações repentinas de prefixos famosos e contatos de emergência testados. Eles também incluem controles de governança: revisão de mudanças na política de exportação, reconciliação periódica de conjuntos de rotas, revisão de cone de cliente, simulações de incidentes e autoridade documentada para desligar rapidamente uma sessão com vazamento.

As orientações do MANRS, NIST e IETF tornam esses controles menos exóticos do que eram em eras anteriores. A questão não é que todo operador pode eliminar todo vazamento amanhã. A questão é que o vocabulário de controle existe. Um provedor que vende alcance global deve ser capaz de explicar como impede que uma rota de peering local se torne trânsito global e como detecta a falha se a prevenção falhar.

Conselhos devem pedir evidências, não slogans. "Seguimos as melhores práticas" não é suficiente. Um painel útil mostraria política de validação RPKI, cobertura de filtro de cliente, cobertura explícita de política de importação e exportação EBGP, eventos de prefixo máximo, exceções de objeto de rota desatualizadas, alertas de vazamento, tempos de resposta e anomalias não resolvidas. Distinguiria a rejeição de origem inválida dos controles de vazamento de caminho, porque são classes de risco diferentes.

O resultado final é que o vazamento de rota do Google em 2018 foi um evento de responsabilidade sobre a governabilidade dos relacionamentos. O erro da MainOne importou. A propagação da China Telecom importou. A aceitação de outras redes importou. A resiliência e comunicação do Google importaram. O público teve que experimentar uma falha de política de rota como uma interrupção de serviço. A lição de reparo não é apenas melhor higiene BGP no abstrato; é a conversão de contratos e expectativas em controles de rota que falham visivelmente e se recuperam rapidamente.

O caminho parecia político porque o caminho estava operacionalmente errado

O vazamento de rota do Google em 2018 atraiu atenção pública em parte porque o tráfego parecia passar pela China e Rússia. Essa geografia importou para usuários e jornalistas porque levantou preocupações de vigilância e soberania. Também ilustra uma regra mais geral: quando os caminhos de roteamento violam as expectativas, o espaço de explicação se expande rapidamente. Os usuários não sabem se estão vendo congestionamento, censura, sequestro, vazamento acidental, vigilância, ataque ou um otimizador de roteamento que deu errado.

O registro do operador deve, portanto, ser preciso o suficiente para separar o impacto na disponibilidade do comprometimento da confidencialidade e o acidente da intenção.

Relatos públicos preservaram a posição do Google de que o tráfego afetado era criptografado e que não havia razão para acreditar que seus serviços foram comprometidos. Essa declaração foi importante. Reduziu o risco de que um desvio de caminho fosse automaticamente tratado como uma violação de conteúdo. Mas a criptografia não eliminou o problema de disponibilidade. Um usuário cujo tráfego é criptografado, mas descartado, ainda não consegue alcançar o serviço. Uma empresa cujo serviço do Google está inacessível ainda enfrenta interrupção operacional.

Uma agência pública cujo caminho agora atravessa uma jurisdição inesperada ainda pode ter preocupações políticas, mesmo que a confidencialidade da carga útil seja preservada.

O caminho também expôs por que os controles com reconhecimento de relacionamento importam mais do que rótulos nacionais. O papel da China Telecom não foi problemático meramente porque a rede é chinesa. Foi problemático porque a rota aparentemente não deveria ter sido aceita e propagada nessa forma. Um provedor diferente em um país diferente poderia ter criado uma interrupção semelhante se aceitasse uma rota aprendida de peer ou vazada por cliente que violasse a política de rota.

O padrão de responsabilidade deve, portanto, focar em filtros, autoridade de rota, relacionamento, monitoramento e evidência de reparo, ao mesmo tempo em que reconhece que a geografia pode amplificar a preocupação do usuário.

Essa distinção ajuda a evitar duas leituras ruins. Uma leitura ruim trata o evento como prova de interceptação maliciosa sem evidências. A outra o trata como um acidente inofensivo porque nenhum comprometimento de conteúdo foi comprovado. A leitura correta está no meio: um vazamento de rota pode ser acidental e ainda assim grave; o tráfego criptografado pode permanecer confidencial e ainda assim indisponível; um provedor pode não ter intenção maliciosa e ainda assim falhar em um importante dever de filtragem. A governança precisa desse vocabulário intermediário.

A ótica política também mostra por que a comunicação pública oportuna importa. Na ausência de explicação do operador, traceroutes e caminhos BGP se tornam matéria-prima para especulação. As plataformas afetadas devem comunicar o que se sabe sobre o caminho, o que se sabe sobre a criptografia, o que permanece desconhecido, o que foi corrigido e quais partes controlavam as políticas de rota com falha. Isso não é apenas gestão de reputação. É uma maneira de evitar que os usuários confundam toda rota estranha com uma violação confirmada, enquanto ainda tratam a disponibilidade e a integridade do roteamento como riscos reais.

Peering e trânsito são relacionamentos comerciais com dentes técnicos

Peering e trânsito são frequentemente resumidos como arranjos comerciais: peers trocam tráfego para benefício mútuo, enquanto provedores de trânsito vendem acessibilidade para a internet mais ampla. O vazamento do Google mostra por que esses termos precisam de dentes técnicos. Uma rota aprendida de peer não deve ser automaticamente exportada como se fosse uma rota de cliente. Uma rota de cliente não deve ser automaticamente acreditada como se o cliente estivesse autorizado a transitar uma plataforma global. Uma rota aceita sob um relacionamento deve carregar restrições de política ao cruzar outro limite.

Esse mapeamento deve ser implementado na configuração do roteador e nos sistemas de validação. Inclui política explícita de importação para o que um vizinho pode enviar, política explícita de exportação para onde essas rotas podem ir, filtros de prefixo e caminho AS, limites de rota, validação de origem RPKI quando aplicável, tags de relacionamento, monitoramento para expansão repentina do conjunto de rotas e autoridade de desligamento de emergência. A palavra importante é explícito. Padrões, suposições e conhecimento tribal não são suficientes quando um erro de configuração pode tornar o Google inacessível.

O princípio de rejeição padrão da RFC 8212 reflete a mesma filosofia: sessões BGP externas não devem importar ou exportar rotas sem política explícita. Isso não impede todo erro. Uma política explícita errada ainda pode vazar rotas. Mas remove a suposição mais perigosa de que uma sessão não configurada ou subconfigurada deve propagar por padrão. Na linguagem de governança, a rejeição padrão força os operadores a declarar sua intenção de roteamento antes que o plano de controle atue.

Os contratos devem seguir a mesma lógica. Um acordo de peering ou contrato de trânsito não deve apenas dizer o que as partes pretendem; deve exigir evidências de que a intenção é aplicada. Cada parte mantém filtros de rota? Como os conjuntos de prefixos de cliente são gerados? Com que frequência são revisados? O que acontece quando um vizinho vaza prefixos famosos? Quem tem autoridade para desligar uma sessão? Que aviso público ou ao cliente se segue? Essas cláusulas não são extrapolações legais exóticas. São a tradução do dano de roteamento em obrigações operacionais.

Os clientes devem se importar mesmo quando não são operadores de rede. Um comprador de SaaS, banco, editora ou agência governamental pode depender de um provedor cuja acessibilidade depende de relacionamentos de trânsito. O comprador não pode auditar toda rota global, mas pode perguntar a seus provedores críticos como monitoram a acessibilidade, como usam RPKI, como se protegem contra vazamentos de rota e como notificam os clientes quando uma falha de rota externa afeta o serviço. Um acordo de nível de serviço que exclui "problemas de roteamento da internet" pode descrever a alocação legal, mas não faz a dependência operacional desaparecer.

Por que a validação de origem ainda pertencia à discussão

Porque o evento do Google em 2018 foi um vazamento de rota, e não um simples sequestro de origem errada, alguns leitores podem concluir que o RPKI é irrelevante. Essa seria a lição errada. A validação de origem RPKI não foi um controle completo para o vazamento, mas ainda pertence à pilha de responsabilidade. Ajuda a distinguir uma classe de falsa autoridade de outra, reduz o nível de fundo de rotas ruins e dá aos operadores evidências legíveis por máquina para muitos incidentes que de outra forma dependeriam de confiança manual.

A limitação é precisa. Se a rota ainda se origina do AS autorizado do Google, o componente de origem pode validar enquanto o caminho permanece inaceitável. Nesse caso, o RPKI diz que a origem é permitida, não que MainOne, China Telecom, TransTelecom, NTT ou qualquer outro segmento de caminho deva estar carregando a rota nesse relacionamento. A validação de caminho e a prevenção de vazamento de rota exigem controles adicionais. É por isso que a RFC 9234 e os mecanismos com reconhecimento de relacionamento importam. Eles abordam uma parte diferente do problema de confiança.

A validação de origem ainda pode ajudar durante a resposta a incidentes. Se uma rota suspeita é inválida na origem, os operadores podem rejeitá-la ou escalá-la como provavelmente não autorizada. Se é válida na origem, mas suspeita no caminho, podem classificar o incidente como um vazamento ou falha de política de caminho. Essa classificação afeta quem chamar e quais evidências inspecionar. Uma operação madura de segurança de roteamento não pede ao RPKI para responder a todas as perguntas; usa o RPKI para remover ambiguidade onde pode e, em seguida, aplica verificações adicionais de política de rota.

O RPKI também muda os incentivos em torno da documentação. Uma plataforma como o Google deve manter ROAs precisas, mas também deve manter objetos de rota, políticas de peer, contatos de provedor e monitoramento externo. Um provedor como a China Telecom deve validar origens, mas também filtrar de acordo com o relacionamento. Um peer como a MainOne deve evitar que rotas aprendidas de peer vazem para o trânsito. Os controles se complementam em vez de se substituir.

O leitor deve, portanto, levar um modelo em camadas. O RPKI lida com a autoridade de origem. Filtros de prefixo e caminho AS lidam com a autoridade esperada de cliente e peer. Funções BGP e OTC podem codificar a direção do relacionamento. O monitoramento detecta desvios. A coordenação humana repara o que a automação não pode decidir com segurança. A linguagem contratual e as métricas de governança mantêm as camadas mantidas. O evento do Google expôs uma lacuna nesse modelo em camadas, não a futilidade de construí-lo.

Um melhor registro público de reparo teria separado cada ponto de controle

Um registro pós-incidente útil para o vazamento de 2018 identificaria cada ponto de controle no caminho. Na MainOne, o registro explicaria qual conjunto de rotas foi aprendido do Google, qual política deveria ter impedido a exportação, o que mudou, quando o vazamento começou, quando foi detectado e como foi corrigido. Na China Telecom, explicaria por que a rota vazada foi aceita, se existiam filtros de cliente ou peer, se os limites de rota foram acionados e quando a exportação parou. Nos provedores downstream, explicaria quais caminhos foram selecionados e por quê.

Para o Google, o registro cobriria o impacto no cliente, serviços afetados, avaliação de criptografia e comprometimento, linha do tempo de detecção, escalação a provedores, monitoramento de rota, qualquer engenharia de tráfego de emergência e mudanças pós-evento nos requisitos de peering. Para observadores independentes, evidências de coletores de rota poderiam mostrar propagação e retirada. Para clientes, um resumo conciso poderia distinguir perda de disponibilidade de evidência de exposição de dados.

Esses registros separados permitiriam que cada parte possuísse sua superfície de controle sem forçar a declaração de um ator a explicar toda a internet.

O registro público está parcialmente disponível por meio de análises independentes, mas o registro interno de reparo permanece fino. Isso é comum em incidentes de roteamento. Os operadores frequentemente corrigem a rota e seguem em frente. O problema é que incidentes de roteamento são oportunidades de aprendizado apenas se a falha de controle for descrita no nível em que pode ser reparada. "Configuração incorreta" não é suficiente. Qual política? Qual sessão? Qual conjunto de rotas? Qual relacionamento com vizinho? Qual alerta? Qual autoridade para retirar?

Sem essas respostas, a mesma falha pode se repetir com um prefixo diferente e uma plataforma diferente.

Reguladores e grandes compradores não devem exigir que todo operador publique configuração sensível de roteador. Podem exigir planos de segurança de rota e categorias de evidência. Por exemplo: cobertura de filtro de prefixo de cliente, política de validação RPKI, alerta de vazamento de rota, cobertura explícita de política EBGP, exceções de prefixo máximo, taxas de sucesso de contato de emergência e resumos pós-ação de incidentes. Essas métricas são práticas o suficiente para auditar sem expor cada linha de roteador.

O vazamento do Google em 2018 continua útil porque torna visível a incompatibilidade contrato-controle. Não foi suficiente que os relacionamentos comerciais implicassem que a rota não deveria viajar por ali. Os roteadores precisavam de política aplicável. O monitoramento precisava ver o desvio. Os humanos precisavam de contatos alcançáveis. O público precisava de evidências de que o vazamento foi contido e que a criptografia limitou o risco de confidencialidade. Essa é a pilha de governança que o incidente expôs.

A decisão do leitor para contratos de roteamento

Um leitor deve sair do vazamento de rota do Google em 2018 com uma pergunta de aquisição e governança: nossos provedores críticos traduzem relacionamentos de roteamento em controles que podemos medir? Um vazamento de rota não se importa que um contrato rotule um vizinho como peer ou cliente. Ele se importa se a política do roteador impede a exportação errada e se o monitoramento detecta o vazamento quando a política falha.

Os clientes devem, portanto, pedir aos provedores evidências de filtragem de prefixo de cliente, políticas explícitas de importação e exportação EBGP, validação RPKI, alerta de vazamento de rota e contatos de escalação 24 horas.

Para plataformas, a decisão é tratar o roteamento externo como parte da resiliência do serviço. Um provedor pode possuir excelentes datacenters, TLS forte e aplicações endurecidas, mas ainda se tornar inacessível se redes remotas preferirem um caminho vazado. Isso significa que monitoramento global de rota, simulações de escalação a provedores, higiene de ROA, higiene de objeto de rota e comunicação com o cliente precisam estar perto da engenharia de disponibilidade comum. "A internet quebrou fora de nossa borda" pode ser descritivamente verdadeiro, mas os clientes ainda precisam de evidências de detecção, diagnóstico e reparo.

Para provedores de trânsito, a decisão é provar a filtragem antes que um vazamento de rota famoso torne o problema público. Uma sessão de cliente ou peer não deve ser autorizada a se tornar um caminho de trânsito surpresa para o Google, um banco, um serviço governamental ou uma CDN. O provedor deve conhecer os conjuntos de rotas esperados, rejeitar anúncios implausíveis, alertar sobre expansão repentina e manter logs suficientes para explicar o reparo. O valor do alcance global vem com o dever de não globalizar o erro de outra parte.

Para conselhos e reguladores, a lição é exigir métricas de segurança de rota da mesma forma que exigem métricas cibernéticas. Taxa de rejeição inválida RPKI, cobertura de filtro de cliente, cobertura de política explícita, alertas de vazamento, objetos de rota desatualizados, incidentes de prefixo máximo e tempo de resposta de contato são sinais de governança. Não são segredos de pacotes profundos. São evidências de que os limites de relacionamento têm aplicação técnica.

O evento de 2018 ainda é útil porque se recusa a se encaixar em um único controle. O RPKI importa, mas a validação de origem sozinha não foi suficiente. Os contratos importam, mas não se aplicaram sozinhos. A criptografia importou, mas não restaurou a acessibilidade. O reparo exigiu a pilha inteira: política de rota, monitoramento, coordenação, comunicação com o cliente e evidência pública.

Um teste operacional final é perguntar se o próximo vazamento de rota seria notado primeiro por clientes, pesquisadores externos ou as redes que o transportam. Se usuários externos são o principal detector, o sistema contrato-controle é muito fraco. Os provedores devem ser capazes de ver quando um peer de repente parece transitar uma rede hiperscala, quando um cliente exporta um conjunto de rotas fora de sua autoridade e quando os caminhos de tráfego contradizem os relacionamentos comerciais. Essa visibilidade transforma contratos de roteamento de papelada em infraestrutura aplicável.

O mesmo teste pertence à aquisição de nuvem e provedor de conteúdo. Um comprador pode não executar BGP em escala global, mas pode perguntar se seu provedor monitora vazamentos de rota, valida origens, publica contatos de segurança de rota, ensaia escalação a provedores e pode explicar se o tráfego estava meramente indisponível ou também exposto a risco de caminho. Essas respostas não são curiosidades abstratas de rede. Elas moldam a continuidade da receita, o suporte ao cliente, a garantia de privacidade e o acesso do setor público.

O incidente Google/MainOne é, portanto, um lembrete de que os proprietários de aplicações herdam alguma dependência de roteamento, quer suas equipes toquem na política do roteador ou não. A responsabilidade começa quando essa dependência herdada é nomeada, medida e atribuída a um proprietário de controle, em vez de ser tratada como o clima incognoscível da internet.

Esse proprietário também deve controlar a linguagem usada durante uma interrupção. Vazamentos de rota podem soar como curiosidades remotas de operadora, mas a pergunta do cliente é imediata: os usuários podem alcançar o serviço, o caminho é confiável, o que mudou e quando voltará ao normal? Uma nota de incidente forte distingue perda de acessibilidade, caminho de trânsito inesperado, status de criptografia, comprometimento suspeito e remediação. O registro do Google mostra por que essas distinções importam. A garantia de que o tráfego estava criptografado é importante, mas não responde à pergunta de disponibilidade.

Uma retirada de rota pode restaurar o serviço, mas não explica qual relacionamento falhou. Uma boa comunicação mantém essas superfícies de controle separadas o suficiente para que compradores, usuários e operadores aprendam com o evento.

A conclusão

O padrão de responsabilidade é o controle prático unido à evidência pública. O registro mais forte não finge que todo ator controlou todo resultado. Ele identifica quem poderia prevenir a falha, quem poderia detectá-la, quem poderia limitar o raio de explosão, quem poderia notificar as partes afetadas, quem poderia reparar o relacionamento de confiança e que evidência prova que o reparo alcançou os sistemas e pessoas que dele dependiam.