Safe Host 2019: vazamento de rotas e teste de responsabilização

Resumo

Limite de evento congelado:Este artigo cobre o vazamento de rotas do Safe Host AS21217 para a China Telecom AS4134 observado em 6 de junho de 2019 e as evidências imediatas de propagação e recuperação. Ele não mescla o evento com o vazamento separado de 24 de junho de 2019 da Verizon, DQE e Cloudflare, nem com outras controvérsias de roteamento da China Telecom.
Contagens exigem atribuição:Relatos públicos descrevem mais de 70.000 rotas em algumas medições e mais de 40.000 rotas IPv4 em outra reconstrução. Os números dependem do coletor, intervalo, família de rotas, tratamento de duplicatas e do que um analista considera parte do evento. Nenhuma contagem pública deve ser apresentada como uma tabela global universal.
Caminho de plano de controle não é constatação de vigilância:Coletores de rotas e medições de caminho podem mostrar que o AS4134 entrou nos caminhos observados e que algum tráfego seguiu rotas inesperadas a partir de pontos de observação específicos. Eles não provam por si sós a localização física de cada pacote, inspeção de pacotes, acesso a dados ou intenção maliciosa.
Responsabilidade segue o controle operacional:O Safe Host controlava o que o AS21217 exportava. A China Telecom controlava o que o AS4134 aceitava e propagava. Outras redes de trânsito e acesso controlavam suas próprias decisões de importação, preferência, exportação subsequente, monitoramento e escalonamento. Os usuários finais não tinham meios práticos para corrigir o estado das rotas.
A incerteza de relacionamento deve permanecer visível:A discussão pública entre operadores não estabeleceu um rótulo comercial incontestável para a conexão Safe Host-China Telecom. A falha de responsabilização observável é a propagação além do escopo pretendido, não uma alegação retrospectiva de que todos os termos contratuais privados são conhecidos.
Evidência de registro é necessária, mas não autoaplicável:Registros de ASN, endereço, IRR e RPKI podem identificar recursos e origens esperadas. Eles não podem codificar todos os relacionamentos ou forçar um roteador a rejeitar um caminho não pretendido. A política em execução determinava quais anúncios se tornavam caminhos alcançáveis.
RPKI aborda apenas parte do problema:A validação de origem de rota pode rejeitar uma origem conflitante quando existe uma ROA válida. Um vazamento de rota pode manter uma origem autorizada enquanto atravessa um relacionamento não pretendido de provedor, par ou cliente. Filtros cientes de relacionamento, validação de cone de cliente, controles de máximo de prefixos, padrões explícitos, monitoramento e coordenação continuam necessários.
Recuperação exige prova independente:Uma correção de configuração local não é um registro de recuperação completo. A remediação responsável mostra retiradas, caminhos de substituição, convergência a partir de múltiplos pontos de observação, exceções residuais, filtros atualizados, alarmes testados e uma repetição demonstrando que a mesma classe de anúncio agora é rejeitada ou contida.

Congele o evento antes de atribuir responsabilidade

A responsabilização de infraestrutura começa fixando o limite do evento. Em 6 de junho de 2019, observadores públicos de roteamento relataram que o Safe Host, sistema autônomo 21217, anunciou um conjunto muito grande de rotas para a China Telecom, sistema autônomo 4134, por meio de uma interconexão em Frankfurt. A China Telecom aceitou os anúncios e os propagou. Para alguns destinos e pontos de observação observados, o AS4134 apareceu consequentemente em caminhos que normalmente não o incluiriam.

Relatos contemporâneos e posteriores associaram o evento a interrupções ou degradação de alcançabilidade afetando partes da infraestrutura móvel e de serviços europeia. [1][2][3][4][5][6][7]

Essas proposições são fortes o suficiente para apoiar uma análise de responsabilização de roteamento. Elas não apoiam todas as alegações que circularam em torno do incidente.

O registro público não divulga a configuração completa de exportação do Safe Host, a configuração completa de importação da China Telecom, todos os objetos de política de rota, todos os termos bilaterais, todas as decisões de preferência local, todos os históricos de alerta ou a identidade de cada pessoa que aprovou ou alterou a política. Ele não estabelece intenção maliciosa. Ele não mostra que todo o tráfego europeu foi afetado. Ele não prova que cada pacote cujo caminho de plano de controle incluiu o AS4134 foi fisicamente encaminhado pela mesma geografia, inspecionado, retido ou alterado.

A data é importante porque junho de 2019 continha outros incidentes de roteamento. O vazamento posterior da Verizon, DQE e Cloudflare envolveu redes, mecanismos e efeitos de serviço diferentes. Combinar esses eventos criaria uma história dramática, mas um registro de responsabilização fraco. Um responsável pela remediação não pode corrigir um incidente cujo conjunto de rotas, intervalo de tempo, limite de relacionamento e controles responsáveis foram confundidos com outro evento.

A questão delimitada é, portanto, precisa: como um conjunto extraordinário de rotas saiu do AS21217, por que o AS4134 aceitou e propagou essas rotas, como outras redes responderam, quais evidências mostram as mudanças de caminho resultantes e quais evidências provariam que o estado das rotas foi retirado e restringido contra recorrência?

Esse enquadramento também impede que a inferência geopolítica substitua as evidências de engenharia. O roteamento transfronteiriço pode ter implicações de segurança, e os operadores devem tratar caminhos internacionais inesperados com seriedade. Mas um caminho inesperado é primeiro um evento de roteamento observável. Intenção, acesso e consequência legal exigem evidências adicionais. A análise de responsabilização deve se tornar mais cuidadosa, não menos, quando a rota cruza uma fronteira politicamente sensível.

A divergência na contagem de rotas é um problema de evidência, não um motivo para descartar o evento

As descrições públicas comumente dizem que o AS21217 vazou mais de 70.000 rotas e que o evento durou mais de duas horas. Outra reconstrução do incidente descreve mais de 40.000 rotas IPv4. [1][2][4][5] Esses números não são necessariamente mutuamente exclusivos. Eles podem refletir coletores, famílias de endereços, janelas de tempo, contagem de atualizações versus prefixos, deduplicação de caminhos e definições diferentes de quais anúncios pertencem ao evento.

Um coletor BGP registra o que seus pares participantes exportam para ele. Um coletor pode receber um caminho anormal que outro nunca vê. Um par pode exportar apenas seu melhor caminho selecionado. Um analista pode contar prefixos únicos, atualizações de rota, variantes de caminho ou combinações de origem. A primeira atualização observada em um coletor não é necessariamente o primeiro anúncio ruim em qualquer lugar, e a última retirada em um coletor não é necessariamente o fim do estado obsoleto em todas as redes.

Relatórios responsáveis, portanto, precisam de um protocolo de contagem. Um relatório de incidente defensável declararia:

quais pontos de observação do RouteViews, RIPE RIS, operadores ou medições foram usados;
os carimbos de data e hora exatos de início e término e o padrão de tempo;
se IPv4 e IPv6 foram ambos incluídos;
se a métrica conta prefixos únicos, atualizações, variantes de caminho ou origens;
como anúncios duplicados e substituições de rota foram tratados;
qual padrão de caminho AS definiu uma rota afetada;
como retiradas e caminhos normais posteriores foram correspondidos ao conjunto anormal; e
quais partes da rede permaneceram fora da observação.

Sem esse protocolo, uma contagem de rotas pode se tornar um sinal de autoridade em vez de evidência. Um número maior pode atrair atenção, enquanto um número menor pode parecer mais conservador. Nenhum é confiável a menos que outro analista possa reproduzir o método.

A incerteza não torna o evento pequeno. Dezenas de milhares de rotas eram extraordinárias em relação a qualquer conjunto plausível de anúncios limitados para uma interconexão. Um controle de máximo de prefixos ou volume de rotas não deveria precisar de uma contagem final perfeitamente acordada do incidente antes de detectar que o conjunto recebido está radicalmente fora da expectativa.

Essa distinção importa operacionalmente. Os limites devem ser baseados no conjunto de rotas autorizado e esperado para um relacionamento, com margens de crescimento documentadas e exceções explícitas. Eles não devem se basear na suposição de que a próxima falha se parecerá com o número final de um relatório histórico. O controle deve reagir quando a realidade se afastar do contrato de relacionamento, não apenas quando uma contagem famosa de incidente for excedida.

Um vazamento de rotas é uma falha executável de política de relacionamento

O BGP distribui alcançabilidade entre sistemas autônomos operados de forma independente. O protocolo base carrega prefixos, caminhos, atributos e retiradas. Ele não contém uma verdade comercial universal para cada sessão. Os operadores expressam relacionamentos de cliente, provedor, par, servidor de rotas, backup e propósitos especiais por meio de configuração, geração de política, comunidades, filtros e processo operacional.

Uma rota aprendida em um relacionamento não é automaticamente elegível para exportação em todos os outros relacionamentos. Um cliente geralmente anuncia seus próprios prefixos e rotas para as quais está autorizado a fornecer serviço. Um provedor pode anunciar ampla alcançabilidade para um cliente. Pares geralmente trocam sua própria alcançabilidade e a de seus clientes, em vez de fornecer trânsito gratuito entre provedores não relacionados. Acordos reais podem ser mais complicados, mas a existência de exceções torna a política explícita mais importante, não menos.

A RFC 7908 posteriormente forneceu uma taxonomia para rotas propagadas além do escopo pretendido. [14] O valor dessa taxonomia é que ela se concentra na propagação observável e na política de relacionamento, em vez de assumir intenção maliciosa. A discussão dos operadores em torno do evento de 2019 não definiu todos os rótulos de relacionamento ou um tipo de vazamento incontestável. [8][9] Essa incerteza deve permanecer no registro.

O comportamento externo central ainda é visível. O AS21217 anunciou um conjunto de rotas cuja escala e escopo eram inconsistentes com uma expectativa de interconexão estreita. O AS4134 aceitou e exportou o suficiente desse conjunto para que os caminhos se espalhassem. Outras redes então aplicaram suas próprias políticas: algumas aceitaram o caminho, algumas podem tê-lo preferido, algumas o propagaram, algumas o filtraram e algumas mantiveram alternativas não afetadas.

Chamar isso de falha distribuída não deve torná-la sem dono. O Safe Host controlava o limite de exportação no AS21217. A China Telecom controlava a primeira fronteira visível de importação e reexportação no AS4134. Cada sistema autônomo subsequente controlava se o caminho entrava em sua base de informações de roteamento, tornava-se um caminho selecionado, entrava na tabela de encaminhamento ou era anunciado para outro vizinho. Os coletores de rotas controlavam a qualidade e a retenção de evidências independentes. Operadores de serviço e acesso controlavam a resiliência e a comunicação com o usuário.

As obrigações não são idênticas. O exportador tem a obrigação mais direta de restringir o que sai de sua rede. Um importador direto tem uma poderosa oportunidade de contenção porque conhece o relacionamento bilateral e pode rejeitar anúncios que não se encaixam nele. Redes posteriores podem ter menos conhecimento específico, mas ainda controlam limites de máximo de prefixos, validação de origem, política ciente de relacionamento, monitoramento de anomalias e escalonamento.

A frase "BGP aceitou as rotas" é, portanto, incompleta. O software executando uma política configurada aceitou as rotas. O protocolo transportou o anúncio; os operadores determinaram as restrições.

A responsabilização da exportação começa com um contrato de rotas autorizado

Um exportador deve ser capaz de definir o conjunto de rotas que uma sessão tem permissão para anunciar. Esse contrato pode ser construído a partir de inventário de clientes, objetos de registro de roteamento, dados RPKI, registros de serviço internos, autoridade delegada e exceções explícitas. Quaisquer que sejam as fontes, a política resultante precisa de um proprietário, um tempo de geração, uma versão, um caminho de revisão e um método para provar o que chegou ao roteador.

Para o AS21217, um registro de responsabilização pós-evento distinguiria pelo menos quatro conjuntos:

rotas que o Safe Host estava autorizado a originar;
rotas de clientes que o Safe Host estava autorizado a transportar;
rotas amplas aprendidas de outro provedor ou par;
rotas que a política AS21217-para-AS4134 realmente exportou durante o evento.

A diferença entre os conjuntos pretendidos e reais é a constatação técnica central. É mais útil do que uma declaração genérica de que ocorreu um erro de configuração.

A política de exportação deve ter como padrão nenhum anúncio até que uma política pretendida seja anexada. A RFC 8212 formaliza o valor operacional da política explícita de importação e exportação eBGP. [15] Uma postura de rejeição por padrão não resolve todos os erros de geração ou anexação, mas elimina a suposição perigosa de que uma sessão nova ou mal classificada deve trocar tudo até que alguém adicione filtros.

O contrato de rotas também precisa de testes negativos. Um pipeline de política deve provar que rejeita:

uma tabela de roteamento completa recebida de uma fonte que se espera anunciar um conjunto limitado;
um prefixo não presente no inventário de clientes autorizado;
um caminho contendo uma sequência de relacionamento impossível ou não autorizada;
uma rota padrão inesperada;
um aumento súbito na contagem de rotas fora de uma janela de crescimento documentada;
rotas obsoletas que permanecem após a autoridade ser removida; e
uma exceção cuja aprovação expirou.

A revisão de configuração sozinha é uma evidência fraca porque a fonte revisada pode diferir da configuração gerada, do candidato implantado ou do estado em execução. Um processo confiável registra os dados de origem, o filtro gerado, o diff do dispositivo, o resultado do commit, o conjunto de rotas anunciadas observado e o resultado independente do coletor.

O controle de mudanças deve ser encenado. Uma atualização de política pode ser testada contra dados BGP gravados, aplicada a uma sessão canário, monitorada para delta de rota inesperado e revertida sem ampla propagação. Uma repetição de vazamento de rota deve fazer parte do teste de resiliência, não ser reservada para um incidente.

A responsabilização da exportação também inclui prontidão para retirada. Um operador deve saber como interromper rapidamente um anúncio anormal sem substituir um evento de roteamento por uma interrupção mais ampla. Isso exige autoridade nomeada, comandos ou automação testados, contatos de pares, critérios de atualização de rota e reinicialização de sessão, e monitores externos que mostrem se a mudança se propagou.

A responsabilização da importação é a primeira oportunidade de contenção externa

A responsabilidade de um importador às vezes é descrita como secundária porque ele não criou o anúncio ruim. Isso é fraco demais para a infraestrutura interdomínio. Um vizinho direto controla a primeira fronteira externa e frequentemente possui informações que redes distantes não têm: o relacionamento bilateral, o volume de rotas esperado, prefixos autorizados, caminhos AS conhecidos, histórico de exceções e canal de contato.

O AS4134, portanto, importa independentemente do AS21217. As evidências públicas sustentam que a China Telecom aceitou e propagou o conjunto extraordinário de rotas. O registro não divulga todos os filtros ou decisões internas, mas o resultado observado mostra que os controles de importação e reexportação não contiveram o evento naquela fronteira.

Um importador ciente de relacionamento pode combinar vários controles.

Primeiro, filtros de prefixo podem ser gerados a partir de registros autorizados de clientes e recursos. Os dados devem ser atuais, versionados e reconciliados com o contrato de serviço real. Uma lista de permissões obsoleta pode rejeitar crescimento legítimo; uma lista de permissões excessivamente ampla pode transformar o filtro em teatro.

Segundo, restrições de caminho AS podem testar se um anúncio é plausível para o relacionamento. Um cliente geralmente não deve anunciar um caminho que implique trânsito entre provedores não relacionados. Dados de cone de cliente são imperfeitos, então exceções e incertezas precisam de tratamento operacional, mas evidências imperfeitas de relacionamento ainda podem apoiar detecção e revisão.

Terceiro, controles de máximo de prefixos e volume de rotas podem detectar um afastamento radical da expectativa. O limite de aviso deve alertar um canal de propriedade antes do limite rígido. A resposta rígida deve ser documentada: rejeitar novas rotas, encerrar a sessão, colocar o conjunto em quarentena ou invocar outra ação limitada. O comportamento de falha aberta deve ser explícito, não acidental.

Quarto, a política explícita de importação impede que uma sessão se torne permissiva porque um mapa de rotas está ausente, mal nomeado ou anexado na direção errada.

Quinto, a validação de origem pode rejeitar uma origem inválida quando uma ROA válida cobre o prefixo. Ela adiciona evidências fortes, mas não prova que o caminho é apropriado.

Sexto, o monitoramento de anomalias pode comparar rotas recebidas e aceitas com a linha de base do relacionamento, coletores globais e mudanças conhecidas. Um alerta deve incluir o caminho ofensor, contagem de rotas, conjunto esperado, versão da política, pares afetados e uma ação segura de contenção.

O importador também controla a reexportação. Mesmo que uma rota seja retida para diagnóstico, ela não precisa ser propagada para clientes, pares e provedores. Separar os controles de aceitação, seleção, encaminhamento e anúncio pode impedir que uma falha se torne um evento distribuído.

Esses controles impõem custos operacionais. Os filtros precisam de manutenção. Limites de máximo de prefixos podem criar interrupções se definidos descuidadamente. Dados de relacionamento podem estar incompletos. Exceções de emergência podem ser necessárias. A responsabilização não nega essas compensações. Ela exige que os operadores as documentem, as testem e mostrem por que a exposição resultante é aceitável.

Evidências de caminho AS não devem ser confundidas com prova sobre cada pacote

A natureza transfronteiriça do evento atraiu preocupação compreensível. Análises públicas mostraram o AS4134 aparecendo em caminhos para destinos associados a operadoras e serviços móveis europeus. Relatórios de medição também descreveram tráfego seguindo caminhos inesperados a partir de pontos de observação específicos. [1][2][3][4][5][7]

Quatro camadas de evidência devem permanecer distintas.

A primeira é apropagação no plano de controle. Uma atualização BGP observada pelo RouteViews, RIPE RIS ou outro coletor mostra que um caminho foi anunciado para o par desse coletor. Ela sustenta declarações sobre visibilidade de rota em um momento e ponto de observação.

A segunda é aseleção de rota. Uma rede pode receber vários caminhos e selecionar um sob preferência local, comprimento de caminho, comunidades, validação de origem e outras políticas. Um coletor frequentemente vê apenas o caminho que seu par exporta, não todos os caminhos considerados.

A terceira é ocomportamento de encaminhamento. Uma rota selecionada pode entrar na tabela de encaminhamento e transportar tráfego, mas traceroute ou medição ativa é necessária para testar o caminho de uma fonte específica. Mesmo assim, o mapeamento IP-para-localização, saltos ocultos, MPLS, roteamento assimétrico, balanceamento de carga e diferenças de caminho de resposta limitam a inferência.

A quarta é omanuseio de pacotes e consequência de segurança. Um caminho de encaminhamento através de um sistema autônomo não prova por si só inspeção de pacotes, acesso a conteúdo, retenção, alteração ou intenção. Criptografia, protocolos de aplicação, comportamento do endpoint e operações internas da rede importam.

Um relato forte de incidente alinha essas camadas por carimbo de data/hora. Ele pode dizer que uma rota com um caminho AS particular tornou-se visível, que medições ativas de locais especificados observaram então um caminho de encaminhamento alterado ou serviço degradado, e que o comportamento normalizou após as retiradas. Ele não deve colapsar essas observações em uma declaração universal sobre todo o tráfego.

Essa disciplina é especialmente importante quando o caminho é politicamente sensível. As evidências podem justificar uma investigação de segurança e controles mais rigorosos. Elas não justificam substituir a suspeita geopolítica pela prova em nível de pacote.

Os operadores devem preservar os dados necessários para essa distinção: atualizações brutas, bases de informações de roteamento, resultados de looking-glass, traceroutes, resumos de fluxo, medições de perda de pacotes, saúde de aplicações, registros de sincronização de tempo e o método usado para mapear saltos de rede. A retenção deve ser suficiente para reconstruir o período antes, durante e depois do evento.

Coletores de rotas são infraestrutura de responsabilização com pontos cegos conhecidos

RouteViews e RIPE RIS fornecem evidências independentes indispensáveis para incidentes interdomínio. Seus arquivos de junho de 2019 e documentação de medição possibilitam reconstrução posterior. [12][13] O RIPEstat também fornece uma superfície de evidência para AS21217 e AS4134, embora os registros atuais não devam ser projetados para trás sem qualificação. [10][11]

Os coletores não são oniscientes. Eles recebem rotas de pares selecionados sob as políticas de exportação desses pares. Eles podem não ver um caminho confinado a outra parte da topologia. Eles podem ver um melhor caminho, mas não alternativas. Seus carimbos de data/hora registram a chegada ao coletor, não a primeira causa global. Reinicializações de sessão, atualizações duplicadas, amortecimento de flapping de rota e disponibilidade do coletor podem afetar o registro.

Uma reconstrução responsável deve usar mais de um coletor e documentar suas diferenças. Deve preservar arquivos brutos ou referências precisas de arquivo, código de análise ou comandos, regras de normalização e conjuntos de dados derivados. Deve registrar o par do coletor usado para fazer cada alegação.

A telemetria do operador pode fechar algumas lacunas. Instantâneos de rotas recebidas e anunciadas na sessão direta mostram o que cruzou a fronteira do relacionamento. Bases locais de informações de roteamento mostram a seleção. Tabelas de encaminhamento e fluxos amostrados mostram o uso. Registros de mudanças e repositórios de política conectam o estado observado à configuração implantada. Relatórios de pares adicionam confirmação independente.

As evidências também devem preservar resultados negativos. Se um coletor não viu o caminho, isso não prova que o caminho estava ausente globalmente, mas pode restringir a propagação. Se um serviço permaneceu alcançável de um local, isso não refuta o impacto em outros lugares, mas pode revelar diversidade de caminho.

Relatórios públicos de incidentes frequentemente citam um gráfico de coletor sem explicar esses limites. Isso cria precisão falsa e faz disputas sobre números parecerem disputas sobre se o evento ocorreu. Um relatório melhor trata o coletor como uma testemunha limitada: valiosa, reproduzível e incompleta.

Registros de registry são livros-razão, não imposição de roteadores

O evento do Safe Host está diretamente sobre a superfície de controle do roteamento BGP, evidências de registro de ASN e IP e relacionamentos de peering ou trânsito.

Um registro de ASN pode identificar AS21217 e AS4134. Registros de endereço podem identificar alocações e atribuições. Objetos do Internet Routing Registry podem publicar origens e políticas pretendidas. O RPKI pode fornecer autorização de origem assinada. Esses registros melhoram unicidade, precisão, histórico de transferência, metadados de segurança e coordenação operacional.

Eles não determinam o caminho em execução.

Uma entrada de registro não conhece todos os relacionamentos comerciais privados. Um objeto IRR não força um roteador a carregar um filtro gerado. Uma ROA diz qual origem é autorizada para um prefixo e comprimento máximo; ela não diz quais provedores ou pares podem transportar essa rota. Um contato de abuse ou NOC não garante que um alerta chegue a uma pessoa com autoridade para retirar rotas.

É por isso que a legitimidade do registro deve ser entendida pela qualidade do livro-razão, não por soberania imaginada sobre o roteamento. O mantenedor de registros fornece evidências que os operadores podem usar. Os sistemas em execução, políticas e interconexões determinam a alcançabilidade.

A primazia do código em execução torna a governança testável. Um conselho pode exigir registros de autorização de rota, mas também deve exigir evidências de que esses registros são buscados, validados, transformados em política, implantados e monitorados. Um auditor pode inspecionar um objeto de rota IRR, mas deve rastrear o objeto através do gerador de política até um dispositivo e injetar um anúncio de teste conflitante.

O livro-razão em si precisa de controles. Registros de recursos devem ser únicos, atuais, autenticados, transferíveis por processo documentado e recuperáveis durante interrupções organizacionais ou de infraestrutura. Registros obsoletos ou ambíguos podem tornar a filtragem estrita operacionalmente arriscada. Os operadores podem então criar exceções amplas, que devem ter proprietários, datas de expiração e monitoramento.

A camada de realidade rejeita duas histórias fáceis. Uma diz que roteamento descentralizado significa que ninguém é responsável. A outra diz que um registro central pode comandar rotas para a correção. O sistema real é uma rede de operadores autônomos usando evidências compartilhadas, política bilateral, código em execução e coordenação. A responsabilização segue os pontos onde esses elementos podem ser alterados e verificados.

Remover AS21217, AS4134, anúncios BGP, política de relacionamento, coletores de rotas e evidências de retirada deste artigo destrói a tese. A superfície de controle da rede não é uma metáfora adicionada a um incidente corporativo genérico. Ela é o incidente.

RPKI é valioso, mas validade de origem não é autorização de caminho

RPKI e validação de origem de rota são frequentemente propostos após incidentes de roteamento. Eles merecem tratamento preciso.

A RFC 6811 descreve como um roteador pode classificar uma rota contra dados ROA validados. [16] Uma rota pode ser válida, inválida ou não encontrada dependendo da origem anunciada, prefixo, comprimento máximo e registros validados disponíveis. Rejeitar ou de-preferir rotas inválidas pode prevenir algumas origens incorretas e sequestros.

Um vazamento de rota pode preservar a origem legítima. O problema pode ser que uma rota autorizada foi exportada através de um relacionamento não pretendido e depois propagada ainda mais. A origem permanece válida enquanto a política de caminho está errada. A validação de origem sozinha não codifica quem é cliente, provedor ou par, ou se uma rota aprendida em um relacionamento pode ser exportada para outro.

Essa limitação não é um argumento contra o RPKI. É um argumento a favor de controles em camadas.

Um operador deve implantar validação de origem com política documentada, monitorar rotas inválidas e não encontradas, manter suas próprias ROAs e coordenar exceções. Também deve manter filtros de prefixo e caminho, política explícita de importação e exportação, evidências de cone de cliente, controles de máximo de prefixos, detecção de vazamento de rota, coordenação de pares e monitoramento independente.

O RPKI também pode fortalecer a responsabilização após um incidente. Ele ajuda a distinguir um conflito de origem de um vazamento de relacionamento e fornece evidências assinadas sobre autorização em um ponto no tempo. A validação histórica requer estado validado arquivado; usar as ROAs de hoje para julgar uma rota de 2019 sem qualificação pode ser enganoso.

A mesma cautela se aplica a padrões e práticas posteriores. RFC 8212, ações MANRS e orientação NIST fornecem estruturas de controle úteis. [15][17][18] Eles devem ser usados para projetar a remediação presente, não para inventar prova sobre o que cada operador tinha implantado ou devia contratualmente durante o evento.

Limites de máximo de prefixos são necessários e fáceis de usar incorretamente

O volume extraordinário de rotas torna o controle de máximo de prefixos uma questão óbvia. Um vizinho direto que normalmente anuncia um conjunto limitado não deveria poder enviar dezenas de milhares de rotas inesperadas sem aviso ou contenção.

No entanto, um limite de máximo de prefixos não é um número único copiado de uma lista de verificação da indústria. Ele deve ser derivado do conjunto de rotas esperado do relacionamento, crescimento legítimo, padrões de manutenção, famílias de endereços e impacto de falha. Um limite definido alto demais não contém o evento. Um limite definido baixo demais pode encerrar uma sessão saudável e causar uma interrupção.

Um design maduro separa limites de aviso e de ação. O aviso deve chegar a um canal operacional de propriedade com contexto antes da resposta rígida. A resposta rígida pode rejeitar rotas excessivas, preservar o último conjunto autorizado conhecido, colocar a sessão em quarentena ou encerrá-la. O comportamento escolhido deve ser testado.

Alterações de limite precisam de governança. Um aumento de emergência deve identificar o solicitante, evidência, aprovador, expiração e monitoramento. Caso contrário, uma exceção temporária pode se tornar exposição permanente.

O volume também é apenas uma dimensão. Um pequeno número de prefixos estrategicamente importantes pode causar impacto severo. Os controles devem combinar volume com autorização, validade de origem, plausibilidade de caminho, escopo de relacionamento, criticidade do destino e taxa de mudança.

O evento do Safe Host ilustra por que os importadores devem conhecer a contagem de rotas esperada antes de um incidente. Se a linha de base for montada somente após o início de um vazamento, a contenção se torna uma negociação sob pressão. Um conjunto autorizado congelado e um limite testado transformam o volume anormal em um sinal imediato e acionável.

Outras redes ainda controlam sua própria aceitação e propagação

O exportador e importador diretos são centrais, mas a rota viajou por um ecossistema mais amplo. Cogent e outras redes apareceram em discussões e relatos contemporâneos, às vezes de maneiras posteriormente corrigidas ou esclarecidas. [3][5][6] A lição não é atribuir uma pontuação indiferenciada de culpa. É mapear cada segmento de caminho observado ao controle disponível naquela rede.

Uma rede de trânsito adicional pode não conhecer os detalhes privados do relacionamento original Safe Host-China Telecom. Ela ainda pode perguntar se o caminho é plausível, se a origem da rota é autorizada, se o volume é anômalo, se o caminho conflita com dados de cone de cliente e se feeds independentes relatam um vazamento.

Operadoras de acesso e móveis controlam a diversidade de rotas e a resiliência do serviço. Se serviços críticos dependem de caminhos que compartilham dependências upstream, um vazamento pode afetar várias marcas ou regiões apesar da aparente diversidade contratual. Evidências de topologia devem, portanto, complementar contagens de provedores.

Operadores de conteúdo e nuvem podem monitorar seus prefixos de pontos de observação externos, manter contatos de alerta de rota e coordenar com upstreams. Eles não podem configurar diretamente todas as redes de trânsito, mas podem detectar caminhos inesperados e fornecer evidências que aceleram a contenção.

Operadores de pontos de troca de internet e servidores de rota têm papéis diferentes dependendo da topologia. Seus controles podem incluir política de participantes, filtragem de servidor de rota, configurações de máximo de prefixos e coordenação de incidentes. As evidências devem estabelecer que eles estavam realmente no caminho relevante antes de atribuir deveres.

Reguladores e clientes devem evitar tratar todas essas partes como intercambiáveis. As perguntas mais eficazes seguem a rota:

O que esta rede recebeu?
O que ela aceitou?
O que ela selecionou?
O que ela encaminhou?
O que ela anunciou adiante?
Qual política e evidência regeram cada decisão?
Qual alerta disparou, quem era o dono e qual ação se seguiu?
Como a rede provou que o estado anormal foi retirado?

Esse método rota por rota torna a responsabilidade distribuída concreta sem fingir que todos os operadores tinham visibilidade ou autoridade idênticas.

Resiliência transfronteiriça deve ser projetada, não inferida de nomes de provedores

O evento também expôs uma fraqueza de planejamento. Organizações frequentemente contam provedores, data centers ou contratos e assumem que cada nome representa um caminho de rede independente. A política BGP pode fazer serviços nominalmente separados convergirem para um trânsito, troca, cabo ou sistema autônomo compartilhado.

A avaliação de resiliência deve inspecionar caminhos reais de regiões de usuários relevantes até prefixos críticos. Deve testar condições normais e de falha, incluir IPv4 e IPv6, e identificar sistemas autônomos e instalações comuns. Um vazamento de rota pode alterar esses caminhos dinamicamente, então monitoramento externo contínuo ou amostrado é mais útil do que um diagrama único.

Restrições transfronteiriças precisam de tratamento explícito. Um serviço pode ter requisitos sobre latência, jurisdição, acesso operacional ou exposição. Esses requisitos não podem ser aplicados apenas por uma cláusula contratual se as mudanças de roteamento forem invisíveis. O monitoramento deve alertar quando um caminho entra em um AS ou geografia inesperados, mas o alerta deve preservar a incerteza na geolocalização e distinguir evidências de plano de controle do encaminhamento de pacotes.

A criptografia permanece essencial porque o controle de caminho é imperfeito. Ela reduz a consequência de trânsito inesperado, mas não elimina riscos de disponibilidade, metadados, análise de tráfego ou endpoint. Controles de roteamento e controles criptográficos resolvem problemas diferentes.

Exercícios de incidente devem incluir um vazamento de caminho que envie rotas através de uma rede internacional inesperada. O exercício deve testar detecção técnica, escalonamento de NOC, contatos de provedor, comunicação com clientes, avaliação legal e preservação de evidências. O objetivo não é dramatizar risco geopolítico. É tornar as responsabilidades de resposta executáveis antes que ocorra um evento ambíguo.

Um registro de recuperação confiável prova retirada e normalização

Relatos públicos indicam que o roteamento anormal persistiu por mais de duas horas em algumas observações antes que os caminhos normalizassem. [1][2][4][5][7] Assim como nas contagens de rotas, a duração exata depende do ponto de observação e da definição. A última rota anormal de um observador pode não representar convergência global.

Um registro de recuperação responsável deve distinguir:

quando a exportação desencadeadora começou;
quando o primeiro observador externo a detectou;
quando um alerta chegou a uma equipe de propriedade;
quando o Safe Host alterou ou desativou a exportação;
quando o AS4134 parou de aceitar ou propagar as rotas;
quando vizinhos diretos observaram retiradas;
quando coletores principais retornaram aos caminhos esperados;
quando o encaminhamento e a saúde do serviço normalizaram; e
quando rotas obsoletas ou excepcionais residuais foram limpas.

O registro deve identificar a fonte de cada carimbo de data/hora. Logs de roteadores, atualizações de coletores, sistemas de tickets, registros de chat, medições ativas e saúde de aplicações podem usar relógios diferentes. Sincronização de tempo e normalização fazem parte da evidência.

A prova de retirada deve operar em múltiplas camadas. Um roteador local pode mostrar que não anuncia mais a rota. Um vizinho direto pode mostrar o recebimento de uma retirada ou substituição. Coletores de rotas podem mostrar o desaparecimento do caminho AS anormal de seus pares. Medições ativas podem mostrar normalização do encaminhamento. Telemetria de serviço pode mostrar recuperação.

Nenhuma dessas observações sozinha prova convergência universal. Juntas, elas formam um registro limitado e auditável.

O relatório também deve identificar o que mudou permanentemente. Exemplos incluem:

uma função de sessão ou anexação de mapa de rota corrigida;
um filtro gerado de prefixos autorizados;
uma restrição de cone de cliente ou caminho;
limiares mais baixos de aviso e rígidos de máximo de prefixos;
uma política explícita de rejeição por padrão;
validação RPKI e manutenção de ROA;
um alerta de anomalia de propriedade;
dados de contato e escalonamento aprimorados;
um processo de implantação canário ou encenado; e
um teste de repetição usando o padrão de rota histórico.

Dizer "filtros foram adicionados" não é suficiente. A evidência deve mostrar a entrada do filtro, saída gerada, resultado da implantação, estado em execução, teste negativo e resultado do monitoramento.

O risco residual deve permanecer visível. Dados de relacionamento podem estar incompletos. Um vazamento de origem válida pode escapar da validação de origem. Exceções podem ampliar o escopo. Coletores têm pontos cegos. Um encerramento rígido de sessão pode afetar a disponibilidade. O registro de remediação deve explicar como essas compensações são gerenciadas.

O teste de recorrência é mais importante que uma declaração de política

A evidência mais forte de que a remediação funciona é uma repetição controlada da classe de falha.

O ambiente de teste deve reproduzir uma sessão com a função de relacionamento relevante e um conjunto de rotas esperado congelado. Ele deve então introduzir:

uma rota fora do conjunto de prefixos autorizado;
um anúncio de tabela completa ou de alto volume;
um caminho AS inesperado;
uma rota de origem válida propagada através de um relacionamento não pretendido;
uma exceção expirada;
uma rota obsoleta após remoção de autoridade; e
uma falha de uma fonte de dados de política.

O operador deve mostrar o que cada camada faz. O exportador deve rejeitar ou suprimir o conjunto inválido. O importador deve conter o que escapar. Controles de máximo de prefixos e anomalias devem alertar. A reexportação deve permanecer limitada. O responsável pela resposta deve receber contexto suficiente para agir. A reversão deve restaurar o último estado autorizado conhecido.

Os testes devem usar o caminho real de geração e implantação de política. Um filtro de laboratório que difere da produção prova pouco. Os resultados devem incluir versões de software e política, hashes de configuração, rotas esperadas e reais, tempo, entrega de alerta, decisões humanas e observação independente.

O teste também deve incluir falha do próprio controle. O que acontece se o feed IRR estiver obsoleto, o validador RPKI estiver indisponível, o compilador de política apresentar erro ou o coletor de monitoramento perder uma sessão? Escolhas de falha aberta e falha fechada devem ser deliberadas e vinculadas à criticidade do serviço.

Executivos não precisam inspecionar cada rota. Eles devem exigir evidências de que o teste ocorreu, as exceções foram explicadas, as falhas têm proprietários e o próximo teste está agendado. Auditores podem amostrar os artefatos subjacentes.

Essa abordagem transforma a segurança de roteamento de uma aspiração em uma alegação operacional que pode ser falseada.

Perguntas de governança devem seguir o controle, não as manchetes

Conselhos, reguladores, clientes e auditores podem fazer perguntas eficazes sem fingir operar sessões BGP.

Os conselhos devem perguntar:

Quais pessoas e sistemas podem alterar anúncios públicos de rota?
Quantas sessões externas não têm uma função de relacionamento explícita?
Qual proporção de sessões de clientes usa filtros atuais de prefixos autorizados?
Quais sessões têm limites de aviso e rígidos de máximo de prefixos?
Quantas exceções estão abertas, quem é o dono e quando expiram?
Quando foi a última repetição de vazamento de rota e o que falhou?
Com que rapidez a organização pode provar a retirada de pontos de observação independentes?

Provedores de trânsito devem perguntar se os registros de clientes e pares correspondem à configuração ao vivo, se os filtros são gerados e testados, se a validação de origem é aplicada de forma consistente e se a reexportação é restringida separadamente.

Operadores de data center e hospedagem devem perguntar se as responsabilidades de roteamento são claras entre instalação, rede, locatário, revendedor e provedor de trânsito. Um contrato físico de hospedagem não define automaticamente quem é o dono da política de exportação do AS21217.

Clientes empresariais e móveis devem pedir evidências de topologia, monitoramento externo de rotas, contatos de incidente e prova de estado de rota em relatórios pós-incidente. Eles devem evitar equiparar diversidade de marca de provedor com diversidade de caminho.

Auditores devem rastrear um recurso de amostra desde a evidência de registro, passando pela geração de política, até a configuração em execução e um teste de rota negativo. Capturas de tela de um portal ou uma política escrita não são evidência de aplicação.

Reguladores devem evitar impor um controle como cura universal. ROAs melhoram a evidência de origem. Elas não codificam todos os relacionamentos. Limites de máximo de prefixos contêm volume, mas podem causar interrupções se não gerenciados. Requisitos eficazes devem se concentrar em resultados: escopo autorizado, contenção em camadas, evidência retida, coordenação e recuperação testada.

Revisores de incidentes devem rejeitar "erro humano" como causa raiz. A frase não explica por que uma ação pôde exportar um conjunto enorme de rotas, por que um vizinho direto o aceitou, por que salvaguardas subsequentes não o contiveram, por que alertas dispararam ou não, ou por que a recuperação levou o tempo observado.

Relatórios públicos devem distinguir fato, inferência e desconhecido. Devem atribuir contagens de rotas, duração, descrições de relacionamento, serviços afetados, observações de encaminhamento e tempo de recuperação. Devem corrigir erros sem apagar o rastro de evidências.

O teste de responsabilização é propagação limitada e recuperação verificável

O evento do Safe Host de 6 de junho de 2019 permanece instrutivo porque une política técnica de roteamento com consequência transfronteiriça.

O AS21217 exportou um conjunto extraordinário de rotas. O AS4134 aceitou e propagou o suficiente para alterar caminhos observados e afetar a alcançabilidade de partes da infraestrutura de rede europeia. Outras redes tomaram suas próprias decisões de aceitação e propagação. Coletores públicos e sistemas de medição preservaram parte do registro.

As evidências não justificam uma constatação de intenção maliciosa, uma contagem universal de rotas, um rótulo comercial de relacionamento incontestável ou uma alegação de que cada pacote foi inspecionado ou seguiu fisicamente a mesma rota. Esses limites fazem parte do registro de responsabilização.

A responsabilidade permanece concreta. O exportador controlava o conjunto de rotas. O importador direto controlava a primeira fronteira de contenção. Outras redes controlavam a propagação subsequente e a resiliência. Operadores de monitoramento controlavam as evidências. Operadores de serviço controlavam a resposta ao impacto no usuário. Usuários finais suportaram as consequências sem autoridade sobre o estado BGP.

O conjunto de controle duradouro é em camadas: política explícita de importação e exportação, filtros de prefixos e caminhos autorizados, evidências de relacionamento, controles de máximo de prefixos, validação de origem, monitoramento de anomalias, mudanças encenadas, contatos de coordenação nomeados, observação independente de rotas e retirada verificada.

Registros de registry e política de roteamento são livros-razão indispensáveis. Eles identificam recursos, origens e contatos. Eles não impõem um caminho. O código em execução determina a alcançabilidade.

Um operador confiável deve, portanto, ser capaz de provar quatro coisas:

sabe quais rotas um vizinho está autorizado e se espera que anuncie;
sua política em execução rejeita ou contém anúncios além desse escopo;
seu monitoramento detecta mudanças anormais de caminho e volume com rapidez suficiente para um proprietário agir; e
após a contenção, evidências independentes mostram que as retiradas se propagaram e o encaminhamento esperado retornou.

Esse é o teste de filtragem de pares e responsabilização transfronteiriça exposto pelo vazamento do Safe Host. O padrão não é prevenção perfeita. É propagação limitada, controle atribuído, evidência reproduzível e recuperação que pode ser verificada fora da rede que faz a alegação.

Vazamento de rotas de 2019 da Safe Host tornou a filtragem de pares um teste de responsabilização transfronteiriça

Por que isso importa