Cloudflare, o vazamento de rota de junho de 2019 e a responsabilidade além da borda da rede

Sumário

• Em 24 de junho de 2019, rotas otimizadas e mais específicas geradas dentro da rede da DQE Communications foram passadas pelo cliente AS396531 e aceitas pela AS701 da Verizon. A Verizon então propagou caminhos que cobriam milhares de redes. Como os roteadores preferem prefixos de destino mais específicos, uma parte substancial do tráfego seguiu os caminhos vazados para links que não estavam dimensionados para suportá-lo; a Cloudflare relatou perder cerca de 15% do seu tráfego global no pior momento do incidente.
• O registro público de rotas suporta uma cadeia de falhas de controle, não um slogan de causa única. O gerador de rotas não manteve suas rotas de otimização locais, um cliente multi-homed exportou rotas aprendidas de um provedor para outro, e uma grande rede de trânsito aceitou e espalhou rotas que não se encaixavam na autoridade de roteamento esperada do cliente. A Cloudflare pôde detectar, comunicar e ajudar a retirar as rotas, mas não pôde unilateralmente alterar a política de importação de outra rede.
• O RPKI (Resource Public Key Infrastructure) para validação de origem de rota foi excepcionalmente adequado para a parte da Cloudflare neste evento porque as Autorizações de Origem de Rota (ROA) da Cloudflare permitiam apenas seus prefixos agregados até um comprimento máximo declarado. As rotas mais específicas vazadas excederam esse comprimento e, portanto, eram inválidas. Isso não faz do RPKI uma solução completa para vazamentos de rota: caminhos com origem válida ainda podem violar relações comerciais, e é por isso que filtragem de cliente, limites de prefixo, Funções BGP, controles de caminho, monitoramento e contatos operacionais acessíveis continuam necessários.
• A responsabilidade acompanha a capacidade de controle. Operadores que geram ou exportam rotas excepcionais devem contê-las e testá-las; provedores devem verificar o que os clientes podem anunciar; plataformas de nuvem devem publicar autoridade de rota, observar caminhos externos, coordenar rapidamente e divulgar o impacto ao cliente; clientes devem planejar a falha de dependências; e conselhos e reguladores devem exigir garantias mensuráveis de segurança de roteamento, não uma declaração genérica de que as melhores práticas do setor estão sendo seguidas.

Uma interrupção de roteamento, não uma falha dos servidores da Cloudflare

Às 10:34:25 UTC de 24 de junho de 2019, coletores públicos de BGP começaram a registrar rotas anormais e mais específicas para o espaço de endereços da Cloudflare. A última das rotas estudadas da Cloudflare desapareceu às 12:38:54 UTC. A análise aprofundada da Cloudflare (em inglês) reconstroi o intervalo a partir de dados do RIPE NCC e mostra um caminho notavelmente consistente: AS13335 da Cloudflare, um de seus provedores de trânsito, AS33154 da DQE Communications, AS396531 da Allegheny Technologies e AS701 da Verizon. Outras redes então aprenderam a rota através da Verizon.

O caminho é importante porque a interrupção não começou com uma falha de data center da Cloudflare ou uma implantação de aplicativo. As máquinas da Cloudflare continuaram a anunciar suas rotas agregadas comuns. O sistema de roteamento global simplesmente aprendeu rotas concorrentes para pedaços menores do mesmo espaço de endereço. Esses pedaços menores venceram a decisão de encaminhamento em muitas redes e direcionaram pacotes por um caminho não intencional. Congestionamento e perda de pacotes ocorreram antes que as solicitações pudessem chegar à borda da Cloudflare.

O relato contemporâneo do incidente (em inglês) da Cloudflare reportou que aproximadamente 15% do seu tráfego global foi perdido no pior momento. Essa é uma medição da empresa, não uma porcentagem de interrupção universal auditada de forma independente. Ela descreve o tráfego da Cloudflare, não 15% de toda a Internet. A observação independente, no entanto, suporta o mecanismo amplo e o impacto entre serviços.

A ThousandEyes relatou em sua análise de caminho de rede que os usuários tiveram dificuldade em acessar serviços protegidos pela Cloudflare e alguns serviços da AWS por aproximadamente duas horas, enquanto a revisão da Catchpoint registrou problemas de desempenho em serviços online nomeados por volta das 10:30 UTC.

A distinção entre disponibilidade de rota e disponibilidade de servidor é importante para a responsabilidade. Uma plataforma pode operar servidores saudáveis em muitos países e ainda ser inacessível se o plano de controle de roteamento direcionar o tráfego para outro lugar. Os clientes experimentam um resultado: timeouts, erros e aplicativos indisponíveis. A causa de engenharia, no entanto, determina quais controles poderiam ter evitado a perda e qual parte poderia operá-los.

O registro de status da Cloudflare para o evento (em inglês) primeiro descreveu problemas de desempenho de rede, depois identificou um possível vazamento de rota e, posteriormente, disse que a rede responsável havia corrigido. Cópias públicas das atualizações de status colocam o aviso de investigação às 11:02 UTC, a identificação às 11:36 UTC e o monitoramento após a correção às 12:42 UTC. O arquivo BGP mostra rotas anormais antes do primeiro aviso de status. Essa diferença não é prova de que a Cloudflare ignorou um evento conhecido por 28 minutos.

É uma questão útil de responsabilidade: quando os sistemas automatizados detectaram tráfego anormal, quando os engenheiros identificaram o roteamento externo como a causa e quando a empresa teve confiança suficiente para notificar os clientes.

Nenhuma evidência pública mostra intenção maliciosa, inspeção de tráfego ou comprometimento dos sistemas da Cloudflare neste evento. Um vazamento de rota pode criar uma oportunidade de interceptação, mas o dano observado ao serviço foi congestionamento e perda ao longo de um caminho não intencional. O artigo, portanto, trata o incidente como uma falha de disponibilidade e integridade de roteamento. Não converte uma possível propriedade de segurança de vazamentos de rota em uma alegação de que o tráfego foi lido.

Como uma otimização local se tornou uma rota global

A Internet é um acordo entre sistemas autônomos, não uma rede centralizada. Cada sistema autônomo usa o Border Gateway Protocol, ou BGP, para informar aos sistemas vizinhos quais prefixos IP pode alcançar e por qual caminho AS. O protocolo central na RFC 4271 dá aos operadores considerável liberdade de política. Essa flexibilidade suporta peering comercial, trânsito pago, multi-homing, engenharia de tráfego e preferências locais. Também significa que uma rota recebida de um vizinho não é acompanhada por uma prova universal de que cada AS no caminho pretendia que o anúncio viajasse tão longe.

Antes do incidente, a DQE usava um produto de otimização BGP da Noction. Esse produto pode medir o desempenho do caminho e injetar rotas mais específicas para influenciar qual link carrega o tráfego selecionado. No exemplo que a Cloudflare publicou, o anúncio normal104.20.0.0/20foi dividido em104.20.0.0/21e104.20.8.0/21. Os dois /21s cobrem a mesma faixa de endereços que o /20, mas cada um nomeia um bloco de destino menor.

Dentro de uma rede controlada, mais específicos podem ser um instrumento legítimo de engenharia de tráfego. O perigo é o escopo. As rotas deveriam influenciar as decisões internas da DQE. A DQE as anunciou para a AS396531. A AS396531 estava conectada tanto à DQE quanto à Verizon e exportou as rotas aprendidas em direção à Verizon. A Verizon as aceitou de seu cliente e as propagou adiante. Uma instrução local havia se tornado uma reivindicação global.

A própria resposta ao incidente da Noction em 26 de junho reconheceu que sua plataforma gerou as mais específicas e descreveu três condições agravantes: geração dentro da rede de seu cliente, vazamento através de um ASN downstream para um grande provedor e filtragem inadequada em todos os três sistemas autônomos. A Noction argumentou que criar mais específicos é uma prática comum, não um defeito inerente, e enfatizou a filtragem do provedor. Essa resposta é relevante porque confirma o papel do otimizador, mas contesta o relato de uma parte única.

Não é uma autópsia independente e não publica a configuração precisa, o registro de alterações ou as evidências de teste para a implantação da DQE.

A análise de roteamento separada da Qrator Labs (em inglês) associou o início ao restabelecimento da sessão BGP entre AS396531 e Verizon pouco depois das 10:35 UTC. Seu relato diz que a AS396531 perdeu filtros e exportou rotas aprendidas da DQE. Isso fornece um gatilho plausível para por que a condição começou quando começou, mas o registro público disponível não inclui configurações de roteador ou logs da AS396531, DQE ou Verizon. A conclusão segura é mais restrita: o caminho observável prova que as rotas cruzaram esses limites de AS; os relatos dos operadores identificam filtros ausentes ou inadequados;

a sequência exata de mudanças internas permanece não pública.

Essa distinção evita três erros comuns. Primeiro, a DQE não deve ser descrita como a origem do espaço de endereços da Cloudflare no sentido BGP. O caminho AS observado ainda terminava no AS13335 da Cloudflare. O otimizador da DQE criou e propagou um caminho mais específico com a origem legítima mantida. Segundo, a Verizon não inventou as rotas, mas sua aceitação e propagação global ampliaram muito seu alcance. Terceiro, a rede da Cloudflare não escolheu AS396531 como caminho preferido. Redes remotas tomaram decisões de encaminhamento com base nos anúncios que receberam.

Por que rotas mais específicas derrotaram distância e anycast

Para um não especialista, o evento pode soar como se os roteadores tivessem selecionado um caminho AS mais curto. A preferência decisiva ocorreu antes. O encaminhamento da Internet usa correspondência de prefixo mais longo: uma rota que cobre o bloco de destino mais específico é selecionada em detrimento de uma rota que cobre um bloco mais amplo. A RFC 4632, a especificação de roteamento interdomínio sem classe, descreve esse comportamento de correspondência mais longa e sua relação com rotas agregadas e mais específicas.

Suponha que um roteador saiba que104.20.0.0/20da Cloudflare é acessível através de um provedor normal e também aprenda104.20.0.0/21através da Verizon, AS396531 e DQE. Um destino dentro do primeiro /21 corresponde a ambos os anúncios. O /21 é mais específico, então ele vence mesmo que seu caminho AS seja mais longo ou operacionalmente absurdo. Atributos de caminho normais decidem entre rotas para o mesmo prefixo; eles não fazem um /20 saudável derrotar um /21 aceito.

É por isso que a pegada anycast da Cloudflare não contornou automaticamente o problema. Anycast permite que muitos locais da Cloudflare anunciem os mesmos prefixos, deixando o BGP selecionar uma instância adequada. Ele fornece distribuição geográfica e pode absorver a falha de sites ou links individuais. Mas os /21s vazados eram mais específicos do que os anúncios /20 comuns da Cloudflare. O sistema de roteamento global poderia preferir o /21 antes de comparar qual local anycast da Cloudflare estava mais próximo. A redundância por trás da rota perdedora não restaurou o tráfego.

O caminho indesejado também concentrou a carga. A AS396531 e suas conexões não foram provisionadas como trânsito global para Cloudflare, Amazon, Linode e muitas outras redes afetadas. O tráfego atraído pelos anúncios mais específicos entrou em um corredor sem capacidade ou política para transportá-lo. Pacotes foram atrasados ou descartados. Um vazamento de rota pode às vezes entregar tráfego por um caminho ineficiente; aqui, a escala transformou o caminho em um gargalo.

A taxonomia de vazamentos de rota da Força-Tarefa de Engenharia da Internet RFC 7908 define um vazamento de rota como a propagação além do escopo pretendido de um anúncio. O evento de junho de 2019 combina características que a taxonomia separa para fins analíticos. Envolveu rotas aprendidas de provedor exportadas por uma rede multi-homed em direção a outro provedor, o que se assemelha ao padrão clássico de hairpin-turn, e rotas mais específicas internamente úteis que nunca foram destinadas à propagação global.

O rótulo importa menos do que o invariante violado: um cliente da Verizon parecia oferecer trânsito para prefixos fora de seu cone legítimo de cliente, e a Verizon aceitou essa aparência.

A cronologia e a janela de responsabilidade em expansão

A responsabilidade muda à medida que um incidente passa da prevenção para a detecção e recuperação. A seguinte linha do tempo usa dados públicos de rota e declarações atribuídas de operadores; não preenche lacunas com ações internas presumidas.

O período mais consequente começou antes do primeiro timestamp. Se um conselho inicia sua revisão às 10:34, ele se concentrará em alertas e chamadas. Se começa quando as rotas do otimizador foram autorizadas para produção, pode examinar segurança de projeto, escopo de rota, padrões de falha fechada, políticas de peer, revisão de mudanças e testes de propagação independentes. A resposta ao incidente reduziu a duração. Os controles preventivos determinaram se havia um incidente para responder.

Quatro oportunidades de filtragem falharam na mesma direção

A rota cruzou várias fronteiras, cada uma com uma oportunidade diferente de pará-la. Tratar essas oportunidades como camadas esclarece a responsabilidade sem fingir que todas as partes tinham controle igual.

Contenção da rede de origem e do otimizador.A DQE controlava o ambiente no qual o produto da Noction gerava mais específicos. Rotas destinadas apenas a decisões locais precisavam de uma barreira de exportação que não dependesse de todos os downstreams se comportarem corretamente. As opções incluíam política de exportação estritamente delimitada, um contexto de roteamento dedicado, comunidades explícitas interpretadas por cada saída, verificações automatizadas de coletores externos e um interruptor de segurança vinculado a propagação inesperada.

A Noction diz que realizou testes de implantação e discute o uso deNO_EXPORT, mas também argumenta queNO_EXPORTnão é apropriado em todo projeto multi-AS. A comunidade bem conhecida é definida na RFC 1997: uma rota que a carrega não deve ser anunciada fora de um limite de confederação. Se foi usada, preservada, removida ou nunca anexada neste evento não está estabelecido publicamente.

Controle de exportação do cliente multi-homed.A AS396531 não deveria ter oferecido as rotas completas ou otimizadas de um provedor a outro provedor, a menos que operasse intencionalmente como trânsito. Uma rede folha ou empresarial pode aplicar uma regra simples de saída: anunciar apenas seus próprios prefixos autorizados e prefixos de cliente explicitamente aprovados. Uma negação padrão é mais confiável do que tentar identificar cada rota que não deve sair. A RFC 8212, publicada em 2017, codificou a rejeição padrão de eBGP quando nenhuma política explícita de importação ou exportação está configurada.

Ela não pode impedir um operador de anexar uma política permissiva errada, mas remove uma classe de propagação acidental causada por uma política ausente.

Controle de ingresso do cliente do provedor.A Verizon tinha o ponto de parada de maior alavancagem. Um provedor de trânsito sabe qual sessão é uma sessão de cliente e deve saber o que esse cliente está autorizado a originar ou transitar. A análise aprofundada da Cloudflare descobriu que as informações do registro de rota associadas ao cliente não incluíam o ASN da Cloudflare ou as outras redes vazadas. Um filtro de prefixo e caminho AS específico do cliente poderia, portanto, ter rejeitado os anúncios.

O guia de operações e segurança BGP na RFC 7454, publicado em 2015, recomenda políticas para rotas recebidas e anunciadas em cada fronteira, controles de prefixo de cliente, filtragem de caminho AS e limites máximos de prefixo.

Rejeição por downstreams e pares.As redes que receberam as rotas da Verizon também tiveram uma chance de rejeitá-las. Como a Verizon é uma grande rede de trânsito, muitos destinatários deram a seus anúncios uma confiança substancial. Algumas redes usando Validação de Origem de Rota teriam rejeitado as mais específicas afetadas da Cloudflare como inválidas pelo RPKI. Outras poderiam usar heurísticas de vazamento de rota ou políticas de peer. No entanto, pedir a toda rede remota que detecte um erro depois que um grande provedor o distribui é menos eficiente do que rejeitá-lo na sessão original do cliente.

A prevenção mais próxima da violação da política limita a propagação antes que a convergência global transforme um erro de configuração em uma interrupção distribuída.

Essas camadas não eram independentes o suficiente. A otimização da DQE, a exportação da AS396531 e a importação da Verizon dependiam todas de uma configuração correta de política de rota. Se cada camada é manualmente permissiva ou construída a partir de registros de cliente incompletos, três controles podem falhar juntos. Um programa de garantia maduro, portanto, testa o resultado de fora do domínio administrativo. Ele não aceita apenas a revisão de configuração como prova de que uma rota permaneceu local.

O RPKI poderia ter bloqueado essas rotas, mas não é a resposta completa

A Cloudflare começou a assinar rotas e implantar validação em 2018, conforme descrito em seu relato de implantação do RPKI. Uma Autorização de Origem de Rota, ou ROA, declara qual sistema autônomo pode originar um prefixo e, opcionalmente, o comprimento de prefixo mais específico que pode anunciar. A Cloudflare diz que suas rotas relevantes autorizaram AS13335 com um comprimento máximo de /20. Os /21s vazados mantiveram AS13335 como sua origem, mas excederam o comprimento máximo autorizado. Eles eram, portanto, inválidos sob a Validação de Origem de Rota.

A lógica é formalizada na RFC 6811. Uma rota recebida é válida se uma carga útil ROA validada cobre o prefixo, o ASN de origem corresponde e o comprimento do prefixo da rota não excede o máximo da ROA. É inválida quando existe uma autorização de cobertura, mas nenhuma corresponde a todas as propriedades necessárias. A explicação de validação de origem do RIPE NCC (em inglês) separa utilmente os estados válido, inválido e desconhecido e enfatiza que os operadores de rede ainda decidem qual política aplicar a esses estados.

O ato da Cloudflare de criar ROAs foi necessário, mas não suficiente. Uma ROA é uma evidência publicada, não um comando de execução remota. A Verizon ou outra rede receptora teve que recuperar dados RPKI validados, aplicar validação à rota do cliente e rejeitar inválidos. A Cloudflare poderia rejeitar rotas inválidas entrando em sua própria rede, mas isso não impediu que redes terceirizadas enviassem tráfego destinado à Cloudflare ao longo de uma rota selecionada em outro lugar. A segurança de roteamento tem uma estrutura recíproca: um titular de endereço publica autorização, enquanto outros operadores a tornam eficaz.

Para este incidente, o RPKI foi um controle preventivo particularmente forte porque o otimizador mudou o comprimento do prefixo. Seria errado generalizar essa condição de sucesso para todo vazamento de rota. Se a AS396531 tivesse vazado o /20 comum da Cloudflare enquanto preservava AS13335 no final do caminho, a validação de origem poderia considerar a rota como válida. A rota ainda violaria a topologia esperada de provedor-cliente. A validação de origem RPKI responde quem pode originar um prefixo e em que comprimento. Ela não prova que toda relação de trânsito no caminho AS é autorizada.

Esse limite não é uma crítica ao RPKI. É a razão para implantá-lo com outros controles. O guia SP 800-189 do NIST combina RPKI e validação de origem BGP com filtragem de prefixo e práticas mais amplas de resiliência interdomínio. Ele trata vazamentos de rota, sequestros, desvios de tráfego, negação de serviço e degradação de desempenho como riscos operacionais relacionados que exigem camadas. O evento de junho de 2019 é uma demonstração excepcionalmente concreta: uma camada poderia ter rejeitado os prefixos ruins exatos, enquanto a filtragem básica de cliente poderia ter rejeitado o caminho de autoridade implausível mesmo sem criptografia.

Há também uma lição de governança nomaxLength. Uma ROA excessivamente permissiva pode fazer com que mais específicos não autorizados pareçam válidos; uma ROA excessivamente restritiva ou desatualizada pode fazer com que rotas legítimas sejam rejeitadas. A cobertura da ROA, comprimento máximo, expiração, saúde da chave e do repositório e mudanças planejadas de roteamento precisam de controle de mudanças. Um painel mostrando que ROAs existem não é evidência de que elas descrevem precisamente a intenção de produção.

Controles de política de caminho após 2019

O cenário de padrões e políticas continuou a se desenvolver após a interrupção. Controles posteriores não devem ser descritos como se os operadores pudessem ter implantado uma versão finalizada em junho de 2019, mas mostram como a indústria tentou codificar suposições que antes eram implícitas.

A RFC 9234, publicada em 2022, introduziu Funções BGP e o atributo Only-to-Customer, ou OTC. Redes vizinhas podem declarar se um relacionamento é de provedor, cliente, peer, servidor de rota ou cliente de servidor de rota. O acordo de função e o manuseio do OTC permitem que os roteadores detectem alguns anúncios que cruzam um limite de relacionamento em uma direção impermissível. Em uma versão simplificada do caminho de 2019, uma rota aprendida de um provedor e depois enviada a outro provedor deve carregar evidências inconsistentes com uma exportação apenas para cliente.

As Funções BGP convertem algum conhecimento de topologia comercial de uma convenção de operador para um estado visível pelo protocolo.

Peerlock oferece outra abordagem focada no caminho. O artigo de 2020 "Flexsealing BGP Against Route Leaks" estudou o mecanismo implantado por operadores, incluindo sua capacidade de parar caminhos nos quais uma grande rede protegida aparece onde não deveria. Peerlock existia antes do artigo e antes do evento de junho de 2019, mas a implantação dependia de conhecimento bilateral e configuração. É evidência de que filtros de caminho práticos eram possíveis, não prova de que um controle universal pronto para uso estava disponível.

A Autorização de Provedor de Sistema Autônomo, ou ASPA, visa permitir que um AS publique relacionamentos de provedor verificáveis através do sistema RPKI. É promissor porque muitos vazamentos de rota são falhas de plausibilidade de caminho, não falhas de origem. Também exige linguagem cuidadosa: os padrões e o estado de implantação do ASPA evoluíram, e a cobertura parcial produz caminhos desconhecidos. Deve ser tratado como um sinal de validação adicional, não como evidência retrospectiva de que os participantes de 2019 violaram um padrão de caminho criptográfico então obrigatório.

A detecção também amadureceu. A Cloudflare descreveu posteriormente seu serviço de detecção de vazamento de rota Radar, que usa relações de roteamento e caminhos observados para sinalizar possíveis vazamentos. O monitoramento reduz o tempo para saber e o tempo para coordenar, mas não impede que um roteador aceite a rota. Um incidente de duas horas ainda pode impor danos globais se o caminho de remediação for uma cadeia telefônica humana.

A detecção tem que se conectar a uma ação ensaiada: identificar prefixos afetados, aplicar política defensiva onde seguro, contatar operadores autorizados, publicar status do cliente, verificar retiradas em coletores independentes e observar a recuperação do tráfego.

O modelo de controle útil é, portanto, cumulativo:

1. Publicar autoridade de rota precisa através de objetos IRR e ROAs.
2. Gerar filtros de importação de cliente a partir de dados confiáveis e atualizá-los com segurança.
3. Por padrão, rejeitar rotas que não tenham uma política explícita.
4. Impor expectativas de cone de cliente, caminho AS, comprimento de prefixo e máximo de prefixo.
5. Rejeitar anúncios RPKI-inválidos em todo ingresso externo relevante.
6. Adicionar controles conscientes de relacionamento, como Funções BGP, OTC, Peerlock e, à medida que amadurece, validação ASPA.
7. Observar a propagação de pontos de observação externos independentes.
8. Manter contatos operacionais continuamente testados e autoridade de retirada de rota.

Nenhum item substitui os demais. Seu valor vem de diferentes modos de falha.

Alocando responsabilidade sem inventar um veredito de responsabilidade legal

O registro técnico público suporta a análise de responsabilidade, mas não contém uma sentença judicial, ordem regulatória ou conjunto completo de contratos alocando responsabilidade legal entre DQE, AS396531, Verizon, Noction, Cloudflare e clientes afetados. Nenhum relatório público de causa raiz da Verizon foi localizado no registro usado para este artigo. A alocação a seguir é, portanto, operacional: quem controlava qual salvaguarda e quem poderia reduzir qual risco. Não é uma atribuição percentual de danos.

DQE Communications.A DQE controlava a rede onde as rotas de otimização foram geradas e o relacionamento através do qual elas alcançaram a AS396531. Seus deveres de maior valor eram restringir o escopo da rota, testar a visibilidade externa, manter a política de exportação correta e parar os anúncios uma vez contactada. A Cloudflare creditou o pessoal da DQE por ajudar a retirar as rotas. A cooperação rápida reduziu a duração; não apaga a falha do controle preventivo.

AS396531.A rede multi-homed era a ponte entre provedores. Seu anúncio observável em direção à Verizon a fez parecer oferecer alcance para rotas aprendidas através da DQE. Uma empresa não-trânsito deve exportar uma lista de permissões estreita, não uma tabela completa aprendida. O registro público não identifica o engenheiro, fornecedor ou mudança que removeu ou contornou a filtragem, então a culpa individual seria especulação. A responsabilidade organizacional está ligada ao projeto que permitiu que uma restauração de sessão expusesse rotas fora da autoridade da empresa.

Verizon.A política de importação voltada para o cliente da Verizon era o controle não exercido mais consequente. Uma grande rede de trânsito aceitando milhares de rotas de um cliente deve verificar prefixos autorizados, origens e caminhos esperados e volume de prefixo. O arquivo de rotas mostra que a Verizon propagou o caminho. A Cloudflare diz que dados IRR relevantes e validação RPKI poderiam ter rejeitado e relata dificuldade em alcançar a Verizon durante o evento. Sem os registros internos da Verizon, não se pode dizer se um filtro estava ausente, desatualizado, mal aplicado, contornado ou falhou de outra forma.

Qualquer uma dessas possibilidades aponta para deveres de garantia e coordenação de incidentes proporcionais à escala do provedor.

Noction.Um otimizador de roteamento que pode criar mais específicos globalmente preferidos tem um modo de falha previsível de alta consequência se a contenção falhar. A responsabilidade do produto inclui padrões seguros, avisos de risco conspícuos, validação de implantação, marcação de rota, testes de vazamento externo, reversão e controles que tornam o modo intrusivo difícil de ativar sem limites verificados. A resposta da Noction diz que testou a propagação durante a implantação e que os filtros permaneceram obrigatórios.

Essa afirmação levanta a próxima questão de auditoria: o produto verificou continuamente a contenção após mudanças de peering ou sessão, ou apenas na comissionamento? Um teste único não pode provar a segurança de um ambiente de roteamento dinâmico indefinidamente.

Cloudflare.A Cloudflare não gerou nem propagou os caminhos indesejados, e ela não podia configurar a sessão de cliente da Verizon. Ela havia, no entanto, vendido aos clientes um serviço de disponibilidade e segurança construído sobre roteamento global. Sua responsabilidade reside, portanto, nos controles residuais: ROAs precisas, interconexão diversificada, monitoramento externo de rota, diagnóstico rápido, contatos de peer acessíveis, comunicação com o cliente, opções de mitigação e divulgação transparente. Ela também tinha o dever de não reivindicar além do que sua arquitetura podia suportar.

Anycast e uma grande rede global reduzem muitas falhas, mas não podem derrotar um mais específico globalmente aceito sem ajuda de redes validadoras.

Outras redes.Pares e downstreams que aceitaram as rotas da Verizon não estavam igualmente posicionados para conhecer a autorização de cliente da AS396531, mas podiam implantar validação RPKI e controles de caminho. Suas decisões afetaram seus próprios usuários e, em alguns casos, a propagação adicional. O sistema é mais seguro quando grandes redes de trânsito agem corretamente, mas uma rede receptora continua responsável pelas rotas que instala.

Esta alocação evita a declaração conveniente, mas inútil, de que o BGP é baseado em confiança e, portanto, ninguém é responsável. A confiança é implementada através de configurações, registros, contratos e práticas operacionais. Isso é controlável. A abertura do protocolo explica por que uma falha pode se espalhar; não desculpa um provedor de filtrar rotas de cliente.

A responsabilidade empresarial da Cloudflare sobreviveu à causa externa

Um gatilho externo não remove as obrigações de um provedor de nuvem para com os clientes. A declaração de registro alterada do Formulário S-1 da Cloudflare em 2019 (em inglês) disse que o vazamento de rota de junho causou interrupção significativa ao seu tráfego e ao de outros provedores. Ela alertou que vazamentos de rota poderiam prejudicar a reputação e a confiança, descreveu compromissos de nível de serviço que poderiam levar a créditos ou reembolsos e afirmou que o vazamento de rota de junho e uma interrupção separada em julho acionaram algumas dessas obrigações.

Na época, a Cloudflare não esperava que os incidentes tivessem um efeito material nos resultados das operações ou na condição financeira.

Essa divulgação seguiu um comentário da equipe da SEC pedindo que a empresa abordasse o impacto financeiro razoavelmente esperado do vazamento de rota de junho à luz dos compromissos de nível de serviço. A troca é um exemplo compacto de responsabilidade movendo-se do centro de operações de rede para o relatório corporativo. Um incidente pode ser causado externamente, operacionalmente significativo, contratualmente compensável e financeiramente imaterial para o provedor ao mesmo tempo.

O arquivamento não divulga o número de clientes afetados, créditos totais, reembolsos, transações perdidas ou tempo de inatividade no nível do cliente. Ele também discute o vazamento de rota de junho juntamente com a interrupção do firewall de aplicativo web causada internamente pela Cloudflare em 2 de julho. Esses eventos não devem ser mesclados. O incidente de junho testa a dependência de roteamento externo. O incidente de julho testa os controles internos de mudança de software. Ambos afetaram a disponibilidade, mas os proprietários preventivos e as evidências são diferentes.

Para os clientes, um crédito de serviço não equivale a negócios restaurados. Um pequeno comerciante online pode perder pedidos, um serviço de comunicações pode perder sessões e uma empresa pode consumir horas de pessoal antes que um crédito de assinatura mensal seja calculado. Os remédios contratuais alocam uma fração das taxas diretas do provedor, não o custo social total ou do cliente da inatividade. Os provedores de nuvem devem, portanto, relatar mais do que tempo de atividade contratual: acessibilidade por região e rede, perda de tráfego, tempo para detectar, tempo para identificar, tempo para comunicar e tempo para recuperação estável.

O que os conselhos devem perguntar sobre risco de peering e trânsito

O roteamento é frequentemente tratado como uma preocupação especializada abaixo do nível de supervisão do conselho. O evento de junho de 2019 mostra por que essa divisão é muito simplista. Uma política de importação BGP em um grande provedor alterou o acesso a muitos serviços de nuvem, acionou obrigações com o cliente, criou divulgação ao investidor e expôs concentração fora dos contratos formais de provedor de nuvem. O conselho não precisa escolher sintaxe de roteador. Ele precisa de evidências de que a gerência sabe onde a disponibilidade depende do comportamento de outro sistema autônomo.

Um pacote útil para o conselho começa com exposição, não com alegações de conformidade:

O denominador importa em cada métrica. Dizer que o RPKI está implantado em roteadores principais não revela se uma sessão de borda não validada pode injetar uma rota na mesma rede. Dizer que os filtros de cliente são automatizados não mostra se o registro de origem está completo, se exceções de emergência persistem ou se uma nova sessão BGP herdou a política. Dizer que os contatos estão em um banco de dados não prova que alguém atende com autoridade às 06:30, horário local.

O teste deve incluir casos negativos controlados. Um provedor pode tentar anunciar um prefixo de laboratório não autorizado, um prefixo mais longo do que sua ROA permite, uma contagem excessiva de rotas e um caminho que viole o relacionamento declarado com o cliente. O resultado esperado deve ser observado na política receptora e em coletores independentes. Os testes precisam de salvaguardas para que eles mesmos não se tornem vazamentos, mas evitar todos os testes realistas deixa o comportamento de maior risco não comprovado.

Resiliência do cliente sem conselhos simplistas de múltiplos provedores

Os clientes frequentemente ouvem que devem evitar dependência comprando uma segunda CDN, um segundo provedor de DNS ou uma segunda nuvem. A diversidade pode ajudar, mas as falhas de roteamento não respeitam rótulos de produtos. Dois provedores podem compartilhar trânsito, pontos de troca, fibra, coletores de rota ou as mesmas redes de acesso não validadoras. Um mais específico vazado também pode atrair tráfego antes que a lógica de failover de DNS ou aplicativo do cliente tenha chance de ajudar.

O projeto correto começa com o caminho do serviço. Qual provedor é autoritativo para DNS? Onde estão as chaves TLS e as políticas de segurança? Uma origem pode aceitar com segurança tráfego direto? O tráfego pode ser desviado sem criar uma brecha de segurança? Com que rapidez os caches de DNS mudam? Os clientes retêm conexões? Um provedor secundário tem configuração e capacidade atuais? A organização pode distinguir uma falha de roteamento upstream de uma falha de origem antes de mover o tráfego?

Para alguns serviços, a entrega ativo-ativo em provedores com roteamento independente é justificada. Para outros, a complexidade, a política de segurança inconsistente, o comportamento do cache e a superfície de ataque adicional superam um ganho de disponibilidade de duas horas. Uma decisão defensável registra a criticidade, o tempo de recuperação testado, as dependências compartilhadas, o custo e o risco residual. Ela não conta nomes de fornecedores e chama o resultado de resiliente.

Os clientes também podem usar alavancagem de compras. Eles podem perguntar a um provedor de nuvem ou rede sobre cobertura de ROA, política de ROV, controles de filtro de cliente, participação no MANRS, práticas de contato de incidente, monitoramento externo e resultados de testes anonimizados. As ações de operador de rede do MANRS fornecem um quadro prático: filtragem, anti-spoofing, coordenação e publicação de informações que outros podem validar. A adesão ou conformidade é um sinal, não prova de operação impecável, mas as ações traduzem segurança de roteamento em perguntas que um comprador pode entender.

A pergunta contratual mais importante muitas vezes não é a porcentagem de tempo de atividade. É qual evidência e assistência o provedor fornece quando o tráfego não pode alcançar um serviço saudável devido a roteamento externo. A comunicação de status rápida e específica ajuda os clientes a evitar mudanças destrutivas em origens saudáveis. Dados de rota pós-incidente os ajudam a reconciliar suas próprias observações. Uma cláusula de força maior ou terceiros redigida restritivamente pode limitar a compensação, mas não deve encerrar o dever operacional do provedor de diagnosticar e comunicar.

De normas voluntárias a evidências de gestão de risco

O evento de junho de 2019 ocorreu em um ambiente de segurança de roteamento em grande parte voluntário. As melhores práticas não eram desconhecidas. Filtragem de prefixo e caminho AS, dados IRR, controles de máximo de prefixo, RPKI e registros de contato de operador existiam. A adoção e a garantia eram desiguais, particularmente onde uma rede tinha que arcar com o custo de implantação enquanto os benefícios se espalhavam pela Internet.

Esse problema de ação coletiva posteriormente atraiu atenção governamental mais explícita. O Roteiro para Melhorar a Segurança de Roteamento da Internet de 2024 do Escritório do Diretor Nacional de Cibersegurança dos EUA descreve a incapacidade do BGP, na operação comum, de validar autoridade de origem, integridade de mensagem, informações de caminho remoto ou anúncios que violam políticas comerciais vizinhas. Ele pede uma adoção mais forte da segurança de origem de rota, especialmente entre grandes provedores e serviços contratados pelo governo. O roteiro é uma orientação política, não uma conclusão sobre os participantes de 2019.

O aviso de Roteamento Seguro da Internet de 2024 da Comissão Federal de Comunicações propôs planos de gestão de risco BGP e relatórios para provedores de banda larga e solicitou comentários sobre medidas além da validação de origem RPKI. Ele reconheceu explicitamente que a segurança do caminho requer mais trabalho. Novamente, isso não cria responsabilidade retroativa para junho de 2019. Ilustra uma mudança de governança de perguntar se um provedor suporta RPKI em princípio para exigir um plano mantido, dados de cobertura, atestado e progresso.

A regulação tem seus próprios riscos. Uma meta percentual para registro de ROA pode recompensar autorizações amplas e permissivas. Um requisito de arquivamento pode se tornar papelada desconectada da política do roteador. A divulgação pública de configurações defensivas detalhadas pode criar preocupações de segurança. A supervisão eficaz deve, portanto, focar em resultados e evidências controladas: autorização precisa, cobertura de rejeição, política de cliente testada, governança de exceção, velocidade de detecção, prontidão de contato e aprendizado com incidentes.

O acesso supervisório confidencial pode ser apropriado para detalhes sensíveis, enquanto métricas agregadas de adoção e incidentes permanecem públicas.

Os comuns de segurança de rota também cruzam fronteiras nacionais. A propagação da Verizon afetou usuários e serviços globalmente; engenheiros da Cloudflare em várias regiões participaram da resposta; a autoridade de rota é distribuída através de registros regionais; e os destinatários aplicam sua própria política. Uma regra nacional pode melhorar a conduta dos provedores sob sua jurisdição, mas padrões interoperáveis e normas de operador são o que fazem essa melhoria viajar.

A evidência ainda ausente do registro público

A análise aprofundada da Cloudflare é excepcionalmente reproduzível: identifica dados do RIPE NCC, fornece comandos e mostra caminhos e timestamps observados. Essa transparência suporta alta confiança na cronologia da rota. Ela não responde a toda pergunta de responsabilidade.

Os seguintes registros melhorariam materialmente a análise se os operadores envolvidos os liberassem:

• Configuração do otimizador da DQE, política de prefixo gerado, mapas de exportação, manipulação de comunidade e testes de propagação externa antes e depois da implantação.
• Política BGP da AS396531 anexada às sessões da DQE e Verizon, linha do tempo de sessão inativa e ativa, mudanças de configuração, contagens de rota e a razão pela qual as rotas aprendidas do provedor eram elegíveis para exportação.
• Registro de integração de cliente da Verizon, fonte de IRR ou lista de prefixos, política de caminho AS, configuração de máximo de prefixo, estado de validação RPKI, alertas, linha do tempo de resposta do operador e explicação para a propagação global.
• Lista de verificação de implantação da Noction, salvaguardas de contenção contínua, comportamento de alerta e mudanças de produto feitas após o incidente.
• Primeiro timestamp de detecção interna da Cloudflare, fonte de alerta, decisões de mitigação consideradas, linha do tempo de escalação de contato de peer, impacto ao cliente por rede e região e verificação de ação corretiva.
• Créditos de serviço quantificados, reembolsos, carga de suporte e rotatividade de clientes atribuíveis especificamente ao vazamento de rota de junho, em vez da interrupção separada de julho.

Sua ausência não torna o evento incognoscível. Anúncios BGP públicos são evidência do que as redes disseram umas às outras. Medições de tráfego são evidência de impacto no serviço. Arquivamentos na SEC são evidência de divulgação corporativa e materialidade esperada. Blogs de operadores são evidência de explicações atribuídas. A disciplina é manter essas classes de evidência separadas.

Também é importante não confundir um registro público ausente com um registro interno ausente. Verizon, DQE, AS396531 e Noction podem ter realizado revisões extensivas que nunca foram publicadas. A Cloudflare pode deter telemetria detalhada não incluída em seus posts. A responsabilidade pública é mais fraca quando a evidência permanece privada, mas o artigo não pode inferir que nenhum aprendizado ocorreu.

Um padrão durável de responsabilidade para resiliência de rota

A interrupção de junho de 2019 é lembrada porque uma pequena rede se tornou a rota aparente para grandes partes da Internet. Sua lição mais profunda é que a escala não criou ceticismo correspondente. Um grande provedor de trânsito recebeu alegações extraordinárias de um cliente e as distribuiu; muitas redes aceitaram o resultado; o tráfego seguiu regras de protocolo para um caminho implausível; e a recuperação dependeu de encontrar pessoas que pudessem retirar os anúncios.

O evento era evitável com controles disponíveis na época. A DQE poderia ter confinado as rotas de otimização. A AS396531 poderia ter exportado apenas prefixos autorizados. A Verizon poderia ter filtrado anúncios de cliente com evidência de registro, caminho, contagem de prefixos e RPKI. As redes receptoras poderiam ter rejeitado os mais específicos da Cloudflare inválidos pelo RPKI. Melhor monitoramento e prontidão de contato poderiam ter encurtado o evento. Padrões posteriores tornam algumas suposições de relacionamento mais fáceis de sinalizar, mas não transformam a disciplina operacional em uma preocupação legada opcional.

O papel da Cloudflare é mais complicado do que vítima ou proprietário. Ela era o destino cuja acessibilidade foi prejudicada por decisões externas. Ela já havia publicado ROAs adequadas para rejeitar os mais específicos vazados, operava uma rede distribuída, detectou o evento, coordenou a retirada, explicou o registro de rota e divulgou consequências contratuais. Ela ainda devia aos clientes status claro, esforço de recuperação, remédios financeiros onde contratados e um relato verdadeiro do risco residual de roteamento. Um provedor não pode prometer que o resto da Internet validará suas rotas;

ele pode prometer tornar a validação possível, monitorar o que acontece e responder com evidência.

O padrão final de responsabilidade não é, portanto, zero vazamentos de rota. Nenhuma rede global pode garantir que todo sistema autônomo configurará cada sessão corretamente. O padrão é se cada parte reduziu o risco dentro de seu controle, testou essa redução de fora, conteve o raio de explosão de erros inevitáveis, respondeu através de um caminho de coordenação praticado e produziu evidência suficiente para clientes e supervisores verificarem a melhoria.

É assim que a resiliência de rede se parece além da borda: não independência de outras redes, o que a Internet torna impossível, mas limites disciplinados sobre quanta confiança não verificada uma única rota pode consumir.