Vazamento de rota da Indosat em 2014: controles de exportação

Resumo

O limite do evento é estreito:Este artigo cobre a origem em massa indevida do AS4761 observada em 2 de abril de 2014, aproximadamente das 18h26 às 21h15 UTC. Ele exclui um evento separado da Indosat em 2011, anomalias posteriores do AS4761 e incidentes de roteamento indonésios não relacionados.
O número principal precisa de um observador:O BGPMon relatou 417.038 novas origens, enquanto o RIPE NCC descreveu mais de 400.000 prefixos afetados. Essas medições estabelecem escala extraordinária em pontos de observação específicos. Elas não provam que todas as redes instalaram todos os caminhos ou encaminharam tráfego pela Indosat.
A causa raiz continua atribuída:Relatos contemporâneos descreveram um problema operacional e repetidos relatos de uma janela de manutenção malsucedida ou de um upstream sem filtros. A configuração completa da Indosat, o registro de mudanças, o estado de geração de políticas e o relatório interno do incidente não são públicos.
A responsabilidade acompanha o controle do roteamento:A Indosat controlava o que o AS4761 originava e exportava. Os vizinhos diretos controlavam filtros de prefixo, origem, relacionamento e máximo de prefixos. Outros sistemas autônomos controlavam aceitação, preferência, reexportação, monitoramento e escalonamento.
Registros registram autoridade; roteadores impõem alcançabilidade:Os registros de ASN e de recursos numéricos identificam titulares e origens esperadas. RIS, RouteViews e outros coletores preservam o estado de execução selecionado. Nem um registro nem um coletor bloqueiam automaticamente um anúncio.
Autorização de origem e política de caminho são coisas diferentes:A Validação de Origem de Rota pode rejeitar uma origem que conflite com uma ROA válida, quando existam registros e validação pertinentes. Isso não prova, por si só, que uma relação de caminho ou o volume de rotas seja apropriado.
Recuperação não é uma declaração de configuração local:Um encerramento confiável mostra retiradas, origens substitutas, convergência em múltiplos pontos de observação independentes, exceções residuais, política alterada, comportamento testado de máximo de prefixos e evidência de replay de que a mesma classe de falha agora está contida.
O padrão de responsabilização é contenção reproduzível:Os operadores devem poder mostrar o conjunto de rotas autorizado, a política gerada e em execução, o desvio anormal, a primeira oportunidade de contenção, o cronograma de ações e um teste independente de recorrência.

Congele o incidente antes de interpretá-lo

A primeira disciplina na responsabilização de roteamento é definir exatamente qual evento está sendo examinado. Em 2 de abril de 2014, observadores públicos de BGP relataram que o AS4761, associado à Indosat, começou a originar um número extraordinário de prefixos que normalmente eram originados por outros sistemas autônomos. O BGPMon contou 417.038 novos prefixos e situou o intervalo visível em aproximadamente 18h26 às 21h15 UTC. A análise do RIPE NCC descreveu mais de 400.000 prefixos afetados e usou dados do RIPE Routing Information Service e visualizações do RIPEstat para reconstruir exemplos de propagação e alcançabilidade. [1][2]

Essas observações são suficientes para estabelecer um grande evento de roteamento entre domínios. Elas não são suficientes para estabelecer toda afirmação que possa ser atribuída a ele.

Este artigo não combina o evento de abril de 2014 com um evento de roteamento anterior da Indosat em 2011. Não incorpora anomalias posteriores do AS4761 nem outros incidentes envolvendo redes indonésias. Não infere um defeito operacional contínuo de eventos separados por anos. Tal agregação poderia criar uma narrativa maior, mas enfraqueceria as evidências necessárias para atribuir controle, medir correção e testar recorrência.

O evento delimitado começa com as primeiras origens anormais do AS4761 observadas pelos monitores citados por volta das 18h26 UTC. Inclui sua propagação por redes selecionadas, as mudanças de alcançabilidade visíveis de determinados pontos de observação, detecção e comunicação entre operadores, a retirada das origens anormais e o retorno ao estado de caminho esperado. Termina com as últimas observações relevantes por volta das 21h15 UTC, reconhecendo que diferentes coletores podem ver horários de início e fim diferentes.

Esse limite também restringe a alegação de causa raiz. O BGPMon caracterizou a escala como consistente com um problema operacional e se referiu a relatos de uma janela de manutenção malsucedida. A discussão entre operadores referiu-se a um upstream sem filtros. [2][3] Essas são descrições contemporâneas, não um registro forense publicado do comando exato, mecanismo de redistribuição de rotas, estado do compilador de políticas, decisão de aprovação ou comportamento do dispositivo que criou os anúncios.

Uma análise responsável, portanto, começa com o que a rede em execução expôs: o AS4761 apareceu como origem de centenas de milhares de prefixos; as origens anormais ficaram visíveis além da rede de origem; alguns caminhos e alcançabilidade mudaram; e as origens foram posteriormente retiradas. Ela trata intenção, causa interna e remediação completa como desconhecidas, salvo se apoiadas por evidências adicionais.

Essa distinção não é cautela por si mesma. Ela cria um problema reparável. Uma afirmação como "um erro de manutenção causou um sequestro global" é ampla demais para ser testada. Uma afirmação como "o AS4761 exportou um conjunto de rotas radicalmente além de suas origens autorizadas esperadas, os vizinhos diretos aceitaram o suficiente desse conjunto para propagá-lo, e as evidências públicas não mostram o conjunto completo de controles que posteriormente impediu a recorrência" identifica limites observáveis e registros faltantes.

A contagem de rotas é uma medição, não um mapa de cada decisão de encaminhamento

O número 417.038 é central no registro público porque transmite a escala extraordinária do evento. Ele também deve permanecer vinculado à sua fonte e ao seu método. O BGPMon relatou essa contagem como novas origens associadas ao AS4761. O RIPE NCC usou a formulação mais ampla de mais de 400.000 prefixos afetados. [1][2] Os números são próximos o suficiente para corroborar uma anomalia em escala de tabela completa, mas nenhum deles deve ser apresentado como uma contagem universal instalada por todos os sistemas autônomos.

O BGP é um protocolo de controle distribuído. Um coletor de rotas recebe atualizações selecionadas de pares participantes. Seu registro reflete quais caminhos esses pares escolheram exportar para o coletor, em que momento e sob suas próprias políticas. Outro coletor com pares diferentes pode ver um subconjunto diferente, um primeiro carimbo de tempo diferente e uma sequência de retiradas diferente.

Várias grandezas costumam ser colapsadas no relato de incidentes:

o número de prefixos únicos para os quais uma origem anormal foi observada;
o número de mensagens de atualização BGP;
o número de variantes de caminho;
o número de coletores ou pares que viram uma atualização;
o número de redes que selecionaram o caminho anormal como melhor;
o número de tabelas de encaminhamento que o instalaram;
o volume de tráfego transportado por esses caminhos; e
o número de usuários que sofreram perda, atraso, desvio ou nenhum efeito visível.

Essas grandezas não são intercambiáveis. Um prefixo pode gerar muitas atualizações. Um coletor pode ver um caminho que seu par não usou para todo o tráfego. Uma rede pode aceitar uma rota em uma base de informações de roteamento sem selecioná-la. Um caminho selecionado pode afetar apenas o tráfego de determinadas origens porque os caminhos da internet são assimétricos e específicos por política. Um serviço pode permanecer alcançável por um caminho alternativo enquanto outra rede perde acesso.

A contagem ainda sustenta uma constatação forte de controle. O AS4761 normalmente estava associado a um conjunto pequeno de rotas em relação à tabela global. Um aumento observado para mais de 400.000 origens estava muito além de qualquer margem comum de crescimento. Um vizinho direto não precisava de uma contagem global perfeita para reconhecer que o conjunto recebido havia se afastado de um contrato esperado de cliente, par ou provedor.

É por isso que a responsabilização deve se concentrar no conjunto de rotas esperado e no desvio observado. O responsável por uma sessão deve poder dizer quantos prefixos e origens estavam autorizados imediatamente antes de uma mudança, qual aumento era esperado, quais limites de aviso e rígidos se aplicavam e o que aconteceu quando o conjunto recebido ou anunciado os excedeu.

Uma medição reproduzível de incidente documentaria nomes de coletores, pares de coletores, famílias de endereços, intervalos UTC exatos, regras de desduplicação, contagem de prefixo versus atualização e o predicado de caminho AS usado para identificar rotas afetadas. Preservaria as referências brutas de atualização ou os comandos de extração. O objetivo não é produzir um número perfeito. É permitir que outro operador reproduza escala, cronograma e limites de propagação sem confiar em um título não examinado.

A origem indevida é visível; a intenção não é

Na operação normal, um sistema autônomo de origem sinaliza que pode entregar tráfego para um prefixo anunciado. Durante o evento de abril de 2014, o AS4761 apareceu como a origem de prefixos normalmente associados a muitas outras redes. Esse comportamento é frequentemente descrito como um sequestro porque a origem mudou para um sistema autônomo que não se esperava que originasse o espaço de endereços. O BGPMon usou linguagem de sequestro em seu relato contemporâneo. [2]

O estado de origem observável não estabelece intenção maliciosa. Um sequestro de rota malicioso, uma redistribuição acidental, uma vinculação incorreta de política, um erro de servidor de rotas, um vazamento de teste e um procedimento de manutenção malsucedido podem produzir sintomas sobrepostos no plano de controle. Distingui-los exige configuração interna, logs, registros de autorização, depoimentos de operadores e, frequentemente, evidências de tráfego ou segurança que os coletores públicos não possuem.

A escala deste evento é consistente com uma falha operacional ampla. Isso é uma inferência, não um relatório completo de causa raiz. O artigo, portanto, atribui explicações de manutenção e filtragem a observadores contemporâneos e não afirma que um comando ou ação exata do operador tenha sido comprovado.

Esse limite importa tanto para a imparcialidade quanto para a qualidade técnica. Se um evento acidental for descrito como interceptação intencional sem evidência, o relato se torna legalmente e tecnicamente frágil. Se o mesmo evento for descartado como "apenas um erro", a falha de controles em múltiplas fronteiras de roteamento desaparece. A responsabilização exige nem acusação nem desculpa. Exige um registro do que foi permitido executar.

As perguntas de evidência são concretas:

Qual processo forneceu os prefixos que o AS4761 originou?
Qual política permitiu que essas origens entrassem em um anúncio externo?
O conjunto de rotas foi gerado a partir de um inventário autorizado ou herdado de outra sessão?
A mudança passou por revisão, simulação ou implantação canário?
Que instantâneo de rotas anunciadas existia antes e depois da mudança?
Qual vizinho direto aceitou primeiro o conjunto anormal?
Quais alertas dispararam, quem era responsável por eles e que ação se seguiu?
Quais dados mostraram que a retirada e a normalização estavam completas?

O registro público responde apenas a partes dessa lista. Essa incompletude deve ser registrada como uma lacuna de responsabilização, não preenchida com especulação.

A rede de origem é dona da primeira fronteira de exportação

O AS4761 controlava a fronteira do lado da origem. Independentemente do gatilho interno, o sistema de roteamento em execução da Indosat originou e exportou um conjunto de rotas que excedeu radicalmente o escopo esperado associado ao sistema autônomo. A primeira obrigação, portanto, é definir e impor o que o AS4761 estava autorizado a originar e anunciar.

Um inventário autorizado de origens deve conectar registros de recursos numéricos, delegações de clientes, registros internos de serviço, dados de registro de roteamento e exceções explícitas. Ele deve ter versão, proprietário, histórico de aprovação e data de vigência. A política gerada do roteador deve ser vinculada por soma de verificação a esse inventário, para que um auditor possa distinguir a entrada pretendida da configuração efetivamente implantada.

O contrato de exportação deve responder a quatro perguntas diferentes:

Quais prefixos o AS4761 pode originar por conta própria?
Quais prefixos de clientes o AS4761 pode transportar como trânsito?
Quais rotas aprendidas de provedores ou pares podem ser reanunciadas, e para quem?
Quais exceções temporárias existem, por que existem e quando expiram?

Combinar esses conjuntos em um único filtro permissivo cria as condições para uma exportação de tabela completa. Uma rota aprendida de provedor, uma tabela de roteamento completa usada internamente ou um feed amplo de servidor de rotas pode cruzar uma sessão externa se a política de exportação estiver ausente, anexada na direção errada, gerada a partir de dados errados ou contornada por uma exceção.

Padrões de política explícitos reduzem esse risco. A RFC 8212, publicada anos após o incidente, especifica que rotas eBGP não devem ser importadas ou exportadas sem uma política explícita. [8] Ela não deve ser projetada retroativamente como prova da implementação de 2014 da Indosat. É útil como comparação durável: uma sessão deve falhar fechada quando a política pretendida está ausente, em vez de trocar tudo até que um filtro seja adicionado.

O exportador também precisa de um controle de volume de rotas em seu próprio conjunto anunciado. O máximo de prefixos costuma ser discutido como um recurso de entrada, mas os operadores podem monitorar a contagem de rotas de saída e o desvio antes que as atualizações deixem uma rede. Uma verificação de pré-implantação pode comparar anúncios candidatos com o conjunto autorizado. Uma proteção ao vivo pode alarmar ou bloquear um aumento sem registro de mudança aprovado.

A evidência mais valiosa é a diferença entre o estado esperado e o estado em execução. Uma declaração pós-incidente de que "filtros foram adicionados" não é suficiente. Um registro responsável preservaria:

o conjunto de prefixos e origens autorizado antes do evento;
a fonte de configuração e a política gerada;
os hashes da configuração candidata e confirmada do dispositivo;
instantâneos de rotas anunciadas para a sessão afetada;
o conjunto anormal e como ele entrou no processamento de exportação;
os comandos de retirada ou a mudança de política;
o conjunto autorizado após a recuperação; e
um replay mostrando que o conjunto anormal é rejeitado.

Essa evidência transforma uma narrativa de configuração em um teste de controle. Também impede que uma limpeza posterior de política obscureça o que estava de fato em execução durante o evento.

Os vizinhos diretos são donos da primeira oportunidade externa de contenção

A rede de origem não é a única operadora com controle. Um vizinho direto que recebe um conjunto de rotas do AS4761 tinha a primeira oportunidade externa de contê-lo. Esse vizinho conhecia, ou deveria ter documentado, o tipo de relacionamento, o conjunto esperado de prefixos, o volume comum de rotas e o contato de escalonamento da sessão.

O registro público indica que grande parte da visibilidade anormal das rotas veio por provedores na Tailândia, com algumas rotas se propagando para mais longe. [1][2] As relações comerciais e técnicas completas não são públicas, portanto cada rótulo específico de cliente, par ou provedor deve ser usado apenas onde houver suporte. O princípio de controle não depende de um rótulo contestado. Qualquer vizinho que aceite um conjunto de rotas radicalmente fora de um escopo bilateral esperado controla uma fronteira de importação.

Várias salvaguardas podem operar ali.

Filtragem de prefixocompara rotas recebidas com um inventário autorizado de clientes ou vizinhos. É mais eficaz quando o conjunto bilateral de rotas é delimitado e quando as atualizações do inventário têm dono e são oportunas.

Filtragem ou validação de origemverifica se a origem está autorizada para um prefixo. A Validação de Origem de Rota baseada em RPKI pode fornecer autorização criptográfica quando existir uma ROA de cobertura e houver validadores implantados. Não é a única fonte de evidência de origem e estava muito menos amplamente implantada em 2014.

Política de caminho AS e de relacionamentotesta se o caminho é plausível para a sessão. Um cliente normalmente não deveria fornecer trânsito entre upstreams não relacionados. Relações reais podem ser complexas, então a política precisa de exceções explícitas em vez de supor que qualquer caminho seja aceitável.

Controles de máximo de prefixoscomparam o volume de rotas recebido com uma faixa documentada. Uma sessão normalmente associada a centenas ou milhares de rotas não deveria silenciosamente entregar centenas de milhares. Limites de aviso e rígidos exigem respostas operacionais diferentes, e ambos exigem dono.

Padrões explícitos de importaçãoimpedem que uma sessão nova ou mal classificada aceite tudo porque um mapa de rotas está ausente.

Controles de exportação para a frenteseparam o que uma rede recebe do que ela anuncia para clientes, pares e provedores. Uma rota mantida para diagnóstico não precisa ser propagada.

A RFC 7454 descreve filtragem operacional, limites de máximo de prefixos, controles de bogon e outras práticas de segurança de BGP. [9] O NIST SP 800-189 organizou posteriormente práticas resilientes de troca entre domínios, incluindo filtragem, validação de origem de rota, monitoramento e coordenação. [13] A MANRS igualmente enquadra filtragem, antisspoofing, coordenação e informações de roteamento como ações de operadores. [14] Esses são pontos de comparação modernos, não evidência de que todas as salvaguardas estavam disponíveis ou implantadas nas sessões relevantes de 2014.

A pergunta do vizinho direto não é "por que a internet confiou no BGP?", mas "por que uma política bilateral em execução aceitou esse conjunto e quais evidências mostram agora que o mesmo conjunto seria rejeitado ou colocado em quarentena?"

O controle de máximo de prefixos é necessário, mas um número sozinho não é uma política

O volume extraordinário de rotas torna a proteção por máximo de prefixos um controle óbvio. Também é fácil descrevê-la de forma simples demais. Um limite rígido pode conter um vazamento em massa, mas um limite mal escolhido pode desconectar clientes legítimos, disparar durante o crescimento normal ou incentivar operadores a definir limites tão altos que nunca atuam.

Um projeto responsável de máximo de prefixos começa pelo conjunto autorizado. O limite deve refletir rotas atuais, crescimento documentado, comportamento de agregação, anúncios de backup e exceções aprovadas. Não deve ser uma fração genérica da tabela global nem um valor copiado de outro relacionamento.

Um projeto maduro tem pelo menos três estados:

uma faixa normal de operação;
uma faixa de aviso que alerta um canal de resposta com dono e congela mudanças arriscadas; e
um limite rígido de contenção com ação documentada.

A ação rígida pode variar. Um roteador pode rejeitar prefixos adicionais, derrubar a sessão, colocar o conjunto recebido em quarentena, reduzir a preferência ou invocar automação. Cada escolha tem consequências. Rejeitar novas rotas pode preservar a alcançabilidade estabelecida enquanto bloqueia o crescimento. Reiniciar uma sessão pode criar uma interrupção mais ampla. Continuar aceitando rotas enquanto apenas envia um alerta pode falhar aberto durante o período em que a propagação mais importa.

A resposta, portanto, deve ser testada. Os operadores devem reproduzir um conjunto de rotas semelhante à falha de abril de 2014 e registrar se o dispositivo avisa, rejeita, reinicia ou continua. Devem testar tanto um aumento súbito de tabela completa quanto um vazamento mais lento projetado para permanecer abaixo de um alerta baseado em taxa. Devem verificar se o escalonamento chega a um responsável com equipe e se esse responsável tem autoridade para conter a sessão.

O máximo de prefixos também precisa de proteção contra o desvio de exceções. Aumentos de emergência e migrações únicas podem se tornar permanentes. Toda exceção deve ter um motivo, um aprovador, um intervalo de vigência e expiração automática ou revisão. O limite em execução deve ficar visível nas evidências do incidente junto com a contagem autorizada de rotas.

A pergunta de responsabilização não é se uma configuração contém uma instruçãomaximum-prefix. É se o limite corresponde ao contrato de relacionamento, se a resposta é segura, se os alarmes têm dono e se um replay comprova a contenção.

Autorização de origem e autorização de caminho resolvem problemas diferentes

O evento da Indosat é um forte argumento para a validação de origem porque o AS4761 apareceu como a origem de prefixos associados a muitas outras redes. Onde uma ROA válida autoriza uma origem diferente e uma rede receptora realiza a Validação de Origem de Rota, a rota inesperada pode ser classificada como inválida e rejeitada ou rebaixada sob política.

A RFC 6811 especifica a Validação de Origem de Prefixo BGP usando RPKI. A RFC 6483 fornece orientações para operações de validação de origem. [10][11] Esses documentos explicam o mecanismo, mas não provam a cobertura relevante de 2014, o estado de ROA, a disponibilidade de validadores ou a política de roteamento dos vizinhos da Indosat.

Três limitações precisam permanecer explícitas.

Primeiro, a cobertura de RPKI em 2014 era limitada. Uma rota sem ROA de cobertura não é automaticamente inválida; geralmente é "não encontrada". O estado atual das ROAs não deve ser projetado retroativamente sobre o evento.

Segundo, a validação de origem verifica a relação entre um prefixo e seu ASN de origem. Ela não valida todas as relações de caminho AS. Uma rota pode ter origem autorizada e ainda vazar por um caminho não intencional de provedor, par ou cliente.

Terceiro, a validação só altera o roteamento quando os operadores implantam validadores, mantêm a disponibilidade do cache, anexam política e decidem como tratar cada estado. Um registro de registro público não se impõe sozinho.

A RFC 9234 introduziu posteriormente os Papéis BGP e o atributo Only-to-Customer para melhorar a prevenção de vazamentos de rota por meio de sinalização explícita de relacionamento. [12] Novamente, é uma comparação de controle moderno, não uma descrição da rede de 2014. Papéis e OTC podem ajudar roteadores a detectar anúncios que violam expectativas de relacionamento livre de vale, mas dependem de implantação e configuração correta de papéis.

A arquitetura defensável organiza controles em camadas:

registros de recursos e origens para autoridade esperada;
filtros de prefixo e origem nas fronteiras de clientes;
validação de origem de rota quando houver dados;
políticas de importação e exportação sensíveis a relacionamento;
Papéis BGP e OTC onde houver suporte;
contenção por máximo de prefixos e desvio de rota;
política padrão explícita;
monitoramento independente de anomalias; e
coordenação e retirada testadas.

Nenhum controle isolado deve ser apresentado como solução completa. O objetivo de responsabilização é defesa em profundidade com evidência de que cada camada aborda um modo de falha definido.

Registros são livros-razão de responsabilização, não soberanos da alcançabilidade

Registros de números da internet, registros de roteamento, ROAs e bancos de dados de operadores são superfícies essenciais de evidência. Eles ajudam a identificar titulares de recursos, autoridade de origem, contatos e política esperada. A visão AS4761 do RIPEstat fornece uma interface atual para observações de registro e roteamento, enquanto a análise histórica deve vincular afirmações ao período relevante. [4]

Esses registros não determinam a alcançabilidade em execução por declaração. Um roteador aceita, rejeita, seleciona e exporta rotas de acordo com software e configuração implantados. Um registro preciso pode coexistir com um filtro permissivo. Um registro impreciso ou desatualizado pode fazer um filtro gerado rejeitar rotas legítimas. Uma ROA assinada pode classificar uma origem, mas somente a política de uma rede que valida determina o resultado operacional.

Essa distinção sustenta um modelo de responsabilização baseado na realidade. Os registros devem ser avaliados como livros-razão:

Os registros de recursos e contatos são precisos?
As mudanças são registradas e atribuíveis?
Os operadores conseguem derivar filtros de forma reproduzível?
As exceções são visíveis?
Os metadados de segurança estão atuais?
Outra rede pode verificar a origem esperada?

Roteadores e sistemas de políticas devem ser avaliados como imposição em execução:

A política derivada foi de fato implantada?
Qual versão rodou na sessão afetada?
Ela tinha rejeição como padrão?
O dispositivo aceitou o conjunto anormal?
A exportação para a frente preservou ou amplificou o erro?
O estado em execução correspondeu à intenção derivada do registro?

O evento de abril de 2014 não pode ser explicado apenas como um problema de registro nem apenas como um problema de roteador. Ele expôs a emenda entre a autoridade registrada e a política executável. Se os registros eram precisos, mas os filtros estavam ausentes, a imposição falhou. Se a geração de política dependia de registros imprecisos, tanto o livro-razão quanto seu uso operacional precisam de correção. Se uma redistribuição ampla contornou o caminho de dados pretendido, os controles de implantação falharam.

A evidência necessária para distinguir esses casos não é exótica. Inclui registros datados de recursos, dados-fonte de política, filtros gerados, hashes de configuração, rotas recebidas e anunciadas e observações independentes de coletores. A ausência de um registro conjunto assim já é, por si, uma constatação de responsabilização.

A evidência de coletores comprova observações selecionadas, não convergência universal

O RIPE RIS e o RouteViews preservam dados históricos de BGP que possibilitam reconstrução independente. O RIPE descreve o RIS como um sistema de medição que coleta e armazena dados de roteamento da internet. O RouteViews arquiva atualizações de abril de 2014. [5][6] O BGPStream da CAIDA fornece uma estrutura para processar dados BGP de grandes projetos de coleta. [18]

Esses sistemas são infraestrutura de responsabilização porque preservam evidências fora da rede que causou ou propagou um incidente. Eles permitem que analistas testem se uma origem anormal apareceu, quais caminhos AS a levaram a pares específicos, quando as retiradas se tornaram visíveis e se as origens esperadas retornaram.

Seus limites devem fazer parte de toda afirmação.

Um coletor vê rotas exportadas por seus pares. Ele não vê todas as rotas que esses pares receberam nem todas as alternativas que consideraram. Um carimbo de primeira observação é a primeira observação naquele coletor, não necessariamente o primeiro anúncio na origem. Uma retirada observada em um par não prova convergência global. Um melhor caminho visível em um coletor não prova o caminho de encaminhamento de todos os usuários.

A diversidade de coletores melhora a confiança. Uma reconstrução de incidente deve comparar pares do RIS e do RouteViews em redes e regiões diferentes. Deve identificar se a origem anormal era visível de cada ponto de observação, por quanto tempo permaneceu visível, quais caminhos a transportaram e quando a origem esperada retornou. As diferenças devem ser preservadas, não diluídas em médias.

A análise também precisa de um predicado reproduzível. Para este evento, um analista pode identificar atualizações em que o AS4761 é a origem de prefixos fora do seu conjunto esperado. A fonte exata do conjunto esperado, o horário, a família de endereços, o tratamento de duplicatas e a normalização de caminho devem ser documentados. Contagens derivadas de rotas devem vincular-se a intervalos brutos de arquivo ou comandos.

Sistemas de pesquisa como o BGPInspector mostram como eventos históricos podem ser examinados por múltiplas dimensões e visões de evidência. [15] Trabalhos acadêmicos posteriores sobre vazamentos e detecção de rotas demonstram ainda que a classificação depende de topologia, relacionamentos e observação. [16] Essas ferramentas não substituem a telemetria do operador, mas possibilitam contestação independente.

Um encerramento de operador deve, portanto, parear evidências internas e externas. Rotas internas recebidas e anunciadas explicam o que cruzou uma sessão. Coletores externos mostram o que escapou para o sistema de roteamento mais amplo. Os dois registros devem convergir em um cronograma delimitado, mantendo a incerteza dos pontos de observação.

O impacto deve ser medido como alcançabilidade, não inferido do volume de rotas

A reconstrução do RIPE NCC mostrou que os efeitos variaram por ponto de observação e por rota. O BGPMon relatou que muitas rotas anormais eram visíveis por provedores na Tailândia e que algumas se propagaram mais amplamente. [1][2] Isso sustenta uma constatação de propagação desigual e impacto desigual na alcançabilidade.

Não sustenta a alegação de que o evento redirecionou a maior parte do tráfego global da internet pela Indonésia. Uma contagem próxima do tamanho da tabela global pode soar equivalente ao controle da internet, mas as decisões de roteamento são distribuídas. As redes aplicam preferência local, política de caminho AS, especificidade de prefixo, validação de origem e relações comerciais. Algumas mantêm uma rota não afetada; algumas preferem a origem anormal; algumas nunca a recebem.

O impacto deve ser medido em camadas:

Visibilidade no plano de controle:quais coletores e pares viram o AS4761 como uma origem inesperada?

Seleção de rota:quais redes selecionaram o caminho, quando essa informação for observável?

Evidência de encaminhamento:de quais locais de origem dados de traceroute, looking glass ou fluxo mostraram tráfego seguindo um caminho alterado?

Desempenho do serviço:quais destinos sofreram perda, latência, instabilidade ou nenhuma degradação observável?

Abrangência de usuários:quais clientes, regiões ou serviços foram afetados, com base na telemetria do provedor e não apenas na contagem de rotas?

Consequência de segurança:houve evidência de acesso, inspeção ou alteração de pacotes? O registro público de rotas, sozinho, não estabelece isso.

Essa disposição em camadas impede tanto o exagero quanto a minimização. Evita tratar cada prefixo visível como um caminho de encaminhamento instalado globalmente. Também evita descartar o incidente porque algumas redes mantiveram alcançabilidade.

Para eventos futuros, os operadores devem preservar medições ativas, tabelas de roteamento, resumos de fluxo, saúde de aplicações e dados de impacto no cliente com carimbos de tempo sincronizados. A metodologia deve considerar caminhos assimétricos, saltos ocultos, anycast, balanceamento de carga e geolocalização incompleta.

A medida-chave de responsabilização não é a maior população plausível afetada. É se cada operador consegue conectar um estado anormal de rota a efeitos concretos de alcançabilidade, explicar a incerteza e mostrar como seus controles limitaram ou falharam em limitar a propagação.

O monitoramento só tem valor quando está ligado à ação

O evento era visível para monitores externos porque a mudança de origem e o volume de rotas eram extraordinários. Sistemas públicos e comunidades de operadores ajudaram a trazer a anomalia à tona. Essa visibilidade, por si só, não contém um vazamento de rota.

O monitoramento deve conectar quatro elementos:

uma linha de base que defina origens, prefixos, caminhos e volume de rotas esperados;
uma regra de detecção que explique por que o estado observado é anormal;
um responsável com autoridade e caminhos de contato; e
uma ação segura que possa conter ou retirar a rota.

Um alerta dizendo "AS4761 originou 417.038 novos prefixos" é útil para triagem. Um alerta operacional deve acrescentar as sessões afetadas, contagens recebidas e aceitas, inventário esperado, upstreams observados, versão atual da política, mudanças recentes e uma ação de contenção recomendada.

O horário dos alertas deve ser preservado. Um cronograma completo distingue primeira atualização anormal, primeira observação do coletor, primeiro alerta automatizado, primeiro reconhecimento humano, primeiro contato com a origem ou upstream, primeira ação de contenção, primeira retirada e normalização posterior. Esses carimbos revelam se o atraso foi de detecção, escalonamento, autoridade, diagnóstico ou convergência.

Dados de coordenação também importam. Incidentes de roteamento cruzam fronteiras organizacionais. Contatos devem estar atuais, acessíveis e com poder de decisão. A MANRS trata validação global e coordenação como responsabilidade central do operador. [14] Um registro de contato que existe, mas não alcança um responsável operacional, não é um controle funcional.

A automação pode acelerar a contenção, mas precisa de proteções. Um desligamento automático de sessão baseado em falso positivo pode criar uma interrupção. Um alerta que falha aberto pode permitir que um vazamento de tabela completa se propague enquanto humanos investigam. Um projeto delimitado pode colocar novas rotas em quarentena, congelar mudanças, reduzir preferência ou exigir confirmação sob limites definidos.

O evento, portanto, testa mais do que a detecção de anomalias. Ele testa se a observação se torna ação responsável com rapidez suficiente para importar.

A retirada inicia a recuperação; ela não prova o encerramento

Relatos públicos indicam que as origens anormais foram retiradas após várias horas e que o estado das rotas voltou a se aproximar das origens esperadas. [1][2] A retirada é essencial, mas é apenas o começo de um registro de recuperação.

A convergência do BGP é específica do observador. Redes recebem e processam retiradas em horários diferentes. Algumas podem reter rotas obsoletas, caminhos anormais alternativos ou estado de sessão por mais tempo que outras. O amortecimento de oscilação de rota, reinicializações de sessão, política local e visibilidade do coletor podem alterar o horário aparente de término.

Um registro confiável de recuperação deve mostrar:

o conjunto exato de rotas alvo da retirada;
o comando, a mudança de política ou a ação de sessão usada;
quem a autorizou;
quando os vizinhos afetados a receberam;
quando as contagens internas de rotas recebidas, selecionadas e anunciadas se normalizaram;
quando múltiplos coletores independentes deixaram de ver o AS4761 como a origem inesperada;
quando as origens esperadas reapareceram;
quais exceções residuais permaneceram; e
se a alcançabilidade voltada ao usuário se recuperou no mesmo cronograma.

O registro deve separar a retirada de rotas da correção de configuração. Um operador pode retirar rotas ruins manualmente enquanto deixa o mecanismo de falha intacto. Por outro lado, uma mudança de configuração pode estar correta localmente enquanto rotas obsoletas ou alternativas permanecem visíveis em outros lugares.

A recuperação também precisa de uma linha de base sabidamente boa. "Normal" deve significar um estado de origem e caminho autorizado vinculado por soma de verificação, não apenas a ausência de um alarme atual. Se o conjunto autorizado mudou durante o incidente, a mudança deve ser documentada em vez de escondida no encerramento.

Evidências independentes são particularmente valiosas porque verificam afirmações fora da rede de origem. RIS, RouteViews, looking glasses e operadores afetados podem mostrar se as origens anormais desapareceram de diferentes pontos de observação. Suas observações não serão perfeitamente simultâneas, e essa variação deve fazer parte do registro.

O registro público não fornece um relatório de remediação assinado completo, replay de rotas ou inventário de exceções para o evento de 2014. A ausência não prova que nenhuma remediação ocorreu. Significa que pessoas de fora não podem verificar a durabilidade da remediação a partir das evidências disponíveis.

Um teste de recorrência deve reproduzir a classe de falha sem exportá-la

O encerramento mais forte é um teste controlado de recorrência. Ele não envia centenas de milhares de rotas não autorizadas à internet pública. Ele recria a classe de falha em laboratório, simulador de políticas, sistema de replay de rotas ou sessão isolada e prova que cada fronteira pretendida responde corretamente.

O teste deve começar com um conjunto esperado congelado para o relacionamento AS4761. Em seguida, deve introduzir:

uma origem não autorizada;
um pequeno lote de prefixos não autorizados;
um conjunto em escala de tabela completa;
um aumento gradual projetado para escapar de um detector de pico súbito;
um caminho que viole o relacionamento documentado;
uma exceção expirada;
uma política explícita ausente;
um registro de cliente ou de registro público desatualizado; e
uma retirada seguida de tentativa de reanúncio.

Para cada caso, o registro deve mostrar o filtro gerado, a configuração candidata, o resultado do dispositivo ou simulador, o alerta, o reconhecimento do responsável, o comportamento de contenção e a evidência exportada para monitoramento independente.

O teste deve rodar tanto na fronteira de origem quanto na de vizinho. O exportador deve rejeitar ou impedir anúncio não autorizado. O vizinho direto deve rejeitar ou colocar em quarentena um conjunto que ultrapasse o escopo bilateral. A política de exportação para a frente deve impedir que rotas de diagnóstico aceitas se espalhem.

Controles negativos são importantes. O sistema deve continuar aceitando crescimento legítimo de clientes, caminhos de backup autorizados e mudanças de manutenção documentadas. Caso contrário, um filtro estrito pode se tornar um risco de disponibilidade, e os operadores o contornarão.

O teste de recorrência deve ser reexecutado quando inventário de roteamento, geradores de política, software de roteador, topologia ou relacionamentos mudarem. Um teste aprovado em um ambiente não prova que todas as sessões de produção permanecem protegidas.

Essa abordagem muda a pergunta de responsabilização de "o operador prometeu ter cuidado?" para "o operador consegue reproduzir a falha e mostrar que seus controles atuais em execução a contêm?"

Controles modernos devem ser usados como comparações, não como alegações retroativas

Vários padrões e estruturas operacionais publicados antes ou depois de 2014 fornecem um mapa útil de controles.

A RFC 7908 define categorias e terminologia de vazamento de rota. [7] Sua taxonomia ajuda a separar propagação não intencional de sequestro de origem, mas aplicar um tipo específico de vazamento exige conhecimento de relacionamentos que podem não ser públicos.

A RFC 8212 promove política explícita de importação e exportação de eBGP. [8] Ela aborda o padrão perigoso no qual rotas fluem quando a política pretendida está ausente.

A RFC 7454 descreve práticas de segurança de BGP, incluindo filtros, máximo de prefixos, tratamento de bogon e proteções operacionais. [9]

A RFC 6811 e a RFC 6483 tratam da validação de origem de rota por meio de RPKI. [10][11] Elas ajudam a testar se uma origem está autorizada, mas não estabelecem a adequação completa do caminho.

A RFC 9234 acrescenta Papéis BGP e OTC para apoiar a prevenção de vazamentos de rota por sinalização de relacionamento. [12]

O NIST SP 800-189 enquadra a troca resiliente de tráfego entre domínios em torno de filtragem, RPKI, monitoramento, segurança e coordenação. [13]

A MANRS identifica ações de operadores para filtragem, antisspoofing, coordenação e validação global. [14]

Ferramentas de pesquisa e medição acrescentam análise independente. O BGPInspector ilustra a inspeção multidimensional de incidentes, pesquisas posteriores sobre vazamento de rota examinam detecção e classificação, o RIPEstat conecta visões de registro e roteamento, e o BGPStream apoia o processamento reproduzível. [15][16][17][18]

A disciplina histórica é essencial: esses documentos não provam o que a Indosat ou seus vizinhos tinham implantado em 2 de abril de 2014. Alguns controles eram imaturos, incomuns ou ainda não padronizados. Uma comparação moderna pode identificar o que reduziria a recorrência agora sem reescrever a história.

O objetivo de controle em camadas é estável ao longo do tempo: definir autoridade, restringir exportação, validar importação, limitar o escopo de relacionamento, detectar volume anormal, preservar evidência independente, coordenar resposta, retirar com segurança e testar recorrência.

A responsabilização deve ser alocada por fronteira, não diluída pela internet

Incidentes entre domínios envolvem muitas redes, o que pode fazer a responsabilidade parecer coletiva e, portanto, vaga. Um modelo melhor atribui deveres conforme o controle.

Indosat / AS4761controlava o estado de origem e exportação. Sua carga de evidência inclui o conjunto autorizado de origens, a fonte de política, a configuração gerada e em execução, o registro de mudanças, rotas anunciadas, ação de retirada e teste de recorrência.

Vizinhos diretoscontrolavam a primeira aceitação externa. Sua carga inclui documentação de relacionamento, filtros de prefixo e origem, limites de máximo de prefixos, política de importação, política de exportação para a frente, tratamento de alertas e evidência de contenção.

Outros sistemas autônomoscontrolavam sua própria aceitação, preferência, propagação, monitoramento e comunicação com clientes. Podem ter tido menos informações específicas de relacionamento, mas ainda eram donos de sua política em execução.

Registros de números e roteamentocontrolavam a precisão, disponibilidade e auditabilidade de registros de recursos e políticas dentro de seu escopo. Não controlavam a imposição nos roteadores.

Operadores de monitoramento e pesquisadorescontrolavam qualidade de medição, carimbo de tempo, retenção, metodologia e os limites das afirmações públicas. Podiam expor o evento, mas não retirar rotas.

Provedores de serviço e acessocontrolavam resiliência, diversidade de caminhos, medição de impacto e comunicação com clientes afetados por meio de suas redes.

Clientes e usuários finaisgeralmente não tinham controle prático sobre a aceitação de rotas entre domínios. Eles não deveriam arcar com o ônus de descobrir ou reparar a falha de política de um provedor.

Essa alocação evita dois erros. Impede que o operador de origem trate a propagação a jusante como problema de terceiros. Também impede que outras redes aleguem que qualquer rota recebida de um vizinho é responsabilidade exclusiva do originador.

A primeira fronteira evitável merece atenção especial. Se o exportador podia ter interrompido a rota, sua falha é primária. Se um vizinho direto tinha um contrato de rotas esperado e mesmo assim aceitou uma tabela completa, isso foi uma falha de contenção separada. Se as redes adiante podiam detectar um caminho ou volume implausível e não o fizeram, seus controles também exigem exame.

O controle distribuído cria múltiplos deveres, não dever nenhum.

A governança deve exigir evidências sem fingir que a topologia privada é pública

Algumas evidências de roteamento são necessariamente privadas: contratos, configurações completas, topologia, controles de segurança e detalhes de clientes. A responsabilização não exige divulgação indiscriminada. Exige evidência independentemente verificável suficiente para sustentar afirmações sobre controle e recuperação.

Os operadores podem publicar ou compartilhar atestações delimitadas:

a faixa esperada de contagem de rotas sem revelar todos os clientes;
hashes de inventários autorizados e filtros gerados;
confirmação de que política explícita de importação e exportação está anexada;
comportamento de aviso e limite rígido de máximo de prefixos;
carimbos de tempo de alertas, contenção e retirada;
referências de coletores independentes;
resultados de testes de replay de tabela completa e violação de relacionamento;
o número e o tipo de exceções;
o proprietário e o processo de expiração dessas exceções; e
uma declaração de lacunas de evidência não resolvidas.

Reguladores, clientes, pares e seguradoras devem pedir esses artefatos em vez de garantias amplas. A linguagem contratual pode exigir notificação, retenção de evidências, testes de política de rota, contatos atuais e contenção coordenada.

A divulgação deve distinguir fatos, inferências e desconhecidos. Para o evento da Indosat, o estado de origem em massa e o amplo intervalo de tempo são fatos fortes. Uma explicação de manutenção ou filtragem é um relato atribuído. O mecanismo interno exato e a remediação completa permanecem desconhecidos no registro público.

Esse formato protege a confidencialidade legítima e, ao mesmo tempo, torna as afirmações operacionais contestáveis. Também possibilita comparação entre incidentes. Um operador que consegue fornecer um diff reproduzível de conjunto de rotas e resultado de replay tem evidência mais forte do que aquele que oferece apenas um rótulo de causa raiz.

A governança não deve transformar registros em autoridades centrais imaginárias sobre o roteamento. Registros numéricos, ROAs, objetos de IRR e contatos são insumos críticos. A alcançabilidade continua sendo o resultado da política distribuída em execução. A supervisão eficaz, portanto, testa a conexão entre a autoridade registrada e o comportamento implantado.

O evento de abril de 2014 foi um teste de controle de tabela completa

A lição mais duradoura do evento AS4761 não é que o BGP se baseia em confiança ou que um operador cometeu um grande erro. Essas afirmações são generalistas demais para atribuir um reparo.

O evento testou se uma rede podia impedir que um conjunto de origens em escala de tabela completa não autorizado saísse de sua fronteira. Testou se vizinhos diretos podiam comparar rotas recebidas com uma expectativa bilateral e conter um afastamento radical. Testou se as redes adiante podiam evitar amplificar o estado. Testou se monitores podiam fornecer evidência precisa e limitada ao observador. Testou se retirada e normalização podiam ser provadas em vez de apenas afirmadas.

A evidência pública estabelece que mais de 400.000 origens inesperadas associadas ao AS4761 se tornaram visíveis em 2 de abril de 2014 e foram retiradas após várias horas. Ela sustenta propagação desigual e efeitos na alcançabilidade. Não estabelece intenção maliciosa, encaminhamento universal, uma causa interna completa ou um programa de remediação publicamente verificável.

Uma resposta responsável do operador fecharia essas lacunas com:

um inventário congelado de prefixos e origens autorizados;
política explícita de importação e exportação com rejeição padrão;
filtros gerados de prefixo e origem;
controles de caminho sensíveis a relacionamento;
aviso de máximo de prefixos e contenção rígida;
validação de origem de rota onde houver dados relevantes;
exceções controladas com donos e expiração;
monitoramento independente com múltiplos pontos de observação;
um registro de contenção e retirada com carimbos de tempo; e
um replay provando que a mesma classe de falha é rejeitada na fronteira de origem e na de vizinho.

O padrão não é a perfeição. O roteamento entre domínios é distribuído, relacionamentos mudam, registros podem ficar defasados e a visibilidade é incompleta. O padrão é se cada operador consegue identificar a fronteira que controla, mostrar qual política rodou ali, explicar o que se afastou da expectativa, agir dentro de um processo testado e fornecer evidência de que o estado autorizado das rotas retornou.

Essa é a diferença entre um incidente que apenas termina e um incidente que produz responsabilização.