Vazamento da TTNet em 2004 e a responsabilização da filtragem de

Resumo

Limite do incidente congelado:Este artigo cobre o vazamento da tabela de rotas AS9121/TTNet observado em 24 de dezembro de 2004. Ele não combina esse evento com incidentes de conectividade turcos posteriores, sequestros de rota não relacionados ou outros vazamentos envolvendo sistemas autônomos diferentes.
A escala precisa ser atribuída:A reconstrução da NANOG e pesquisas posteriores descrevem um vazamento envolvendo mais de 100.000 prefixos, representando grande parte da tabela de roteamento global visível, a partir de alguns pontos de medição, na época. A contagem exata depende do coletor, do intervalo, do tratamento de duplicatas e da definição do evento. Trata-se de evidência, não de um log operacional universal.
A falha atravessou limites de relacionamento:Rotas aprendidas em um contexto foram anunciadas onde não era previsto que fossem para elas. Outras redes as aceitaram e propagaram sob sua própria política local. O resultado não foi apenas uma interrupção de serviço da TTNet; foi uma mudança distribuída no estado global de rota.
A responsabilidade segue o controle:AS9121 controlou sua importação, exportação, geração de rotas, implantação, monitoramento e retirada. Provedores e peers diretos controlaram filtros de prefixo de cliente, restrições de caminho AS, limites de prefixo máximo, alertas e exportação subsequente. Importadores adicionais controlaram sua própria aceitação e contenção.
Um registro é evidência, não enforcement:ASN, endereçamento, IRR e registros RPKI posteriores podem descrever origens esperadas e titulares de recursos. Eles não configuram política de roteador por si sós. O código em execução e a política carregada determinam quais rotas são aceitas e propagadas.
Controles modernos são complementares:Política explícita de eBGP, filtros de prefixo autorizados, limites de máximo de prefixo, validação de origem de rota, BGP Roles e OTC, validação de customer-cone, detecção de anomalias e rollback testado abordam falhas diferentes. Nenhum é cura retroativa completa.
A recuperação exige prova externa:Um ajuste de roteador ou reinicialização de sessão não é evidência suficiente. Um registro de recuperação responsável mostra retiradas, caminhos de substituição, rotas residuais desatualizadas, coordenação com peers, convergência e restabelecimento comprovado de alcançabilidade por pontos de observação independentes.

O limite do evento é 24 de dezembro de 2004

A primeira disciplina em uma revisão de incidente de infraestrutura é congelar o evento. Em 24 de dezembro de 2004, operadores observaram um conjunto anômalo de rotas associado à TTNet, sistema autônomo 9121. O evento foi discutido na NANOG e depois reconstruído em uma apresentação da NANOG com base em dados BGP públicos do RouteViews e de coletores RIPE. [1][2] Estudos acadêmicos posteriores usaram o incidente como exemplo relevante ou como caso de referência para análise de vazamento de rota e anomalia de roteamento. [3][4][5]

O registro público apoia consistentemente a proposição central: AS9121 propagou uma parcela muito grande da tabela de rotas além do escopo pretendido e outras redes aceitaram ou redistribuíram parte suficiente desses anúncios para causar problemas de alcançabilidade generalizados. Esse é o padrão de fatos que este artigo analisa.

É importante não inflar essa proposição. Fontes públicas não oferecem uma configuração completa de roteadores da TTNet, todas as route-maps, todos os acordos bilaterais, todas as mensagens de operador ou uma linha do tempo universalmente autoritativa. Elas não estabelecem intenção maliciosa. Também não mostram que toda a internet aceitou todos os caminhos vazados nem que todos os usuários tiveram o mesmo efeito.

Os números exigem cuidado particular. A reconstrução da NANOG e literatura posterior descrevem com frequência mais de 100.000 prefixos afetados e caracterizam esse conjunto como maioria da tabela global visível no período. [1][3][4] Essas afirmações são significativas, mas são afirmações de medição. Um coletor vê as rotas exportadas pelas sessões que o alimentam. Coletores diferentes podem receber caminhos diferentes, registrar atualizações em momentos diferentes, suprimir duplicatas de forma distinta e permanecer cegos a rotas filtradas antes de alcançá-los.

A prática editorial correta, portanto, é atribuição em vez de precisão falsa. O evento foi enorme pelos padrões da tabela de roteamento de 2004. Seu número exato de prefixos e duração variam conforme o ponto de observação e o método analítico. Essa variabilidade não é desculpa para minimizar o incidente. É uma razão para preservar a evidência BGP subjacente e explicar como uma estimativa foi produzida.

A data também importa. Controles padronizados anos depois devem ser usados como comparação, não como testes retroativos de conformidade. A taxonomia de vazamento de rota da RFC 7908 foi publicada em 2016. [12] O comportamento padrão explícito da RFC 8212 foi publicado em 2017. [13] BGP Roles e o mecanismo OTC (Only-to-Customer) da RFC 9234 foram publicados em 2022. [14] Esses documentos ajudam a identificar o problema de controle, mas não provam o que AS9121 ou seus vizinhos tinham implantado em 2004.

A pergunta defensável não é: "Por que uma rede de 2004 não atendeu a uma norma de 2022?" Ela é: "Quais invariantes operacionais deveriam restringir o que um cliente ou peer pode anunciar, quais organizações controlavam essas invariantes e quais evidências mostrariam que o estado de rota retornou ao normal?"

Um vazamento de rota é uma falha da política de relacionamento

O BGP distribui informações de alcançabilidade entre sistemas autônomos. Cada rede seleciona rotas sob política local e decide quais rotas selecionadas anunciar a cada vizinho. A RFC 4271 define o protocolo base, tipos de mensagem, atributos de rota, processo de seleção e comportamento de retirada. [11] Ela não codifica um relacionamento comercial ou operacional universal para cada sessão.

Essa informação de relacionamento importa porque uma rota da internet não é automaticamente elegível para todo vizinho. Um cliente normalmente anuncia suas próprias rotas e rotas para as quais está autorizado a prover trânsito. Um provedor normalmente pode enviar ampla alcançabilidade a um cliente porque o cliente o remunera por trânsito. Um peer settlement-free normalmente troca suas próprias rotas e rotas de clientes, não trânsito livre entre provedores não relacionados.

Os termos "cliente", "provedor" e "peer" simplificam arranjos reais, mas expõem o limite de política. Uma rota aprendida de um provedor não deveria, ordinariamente, ser anunciada a outro provedor como se a rede anunciante oferecesse trânsito entre ambos. Uma rota aprendida de um peer não deveria, ordinariamente, ser exportada para outro peer ou provedor. O conjunto completo de tabela de um cliente não deveria ser tratado como conjunto de origem autorizado do cliente.

A RFC 7908 posteriormente definiu vazamento de rota como propagação além do escopo pretendido, geralmente em violação de políticas associadas a relacionamentos par a par. [12] A definição é útil aqui porque foca na propagação observável de rotas em vez de em motivo presumido. A rota errada atravessou o limite errado.

O evento da TTNet é frequentemente descrito como vazamento de tabela de roteamento porque os anúncios anômalos representaram um vasto conjunto de rotas que AS9121 não deveria ter exportado naquele contexto. A evidência disponível não exige um único modelo interno exato de topologia para tornar claro o problema de responsabilização. Seja o erro disparador uma route-map, redistribuição, geração de política, classificação de sessão ou outro mecanismo, a falha observável externamente era um conjunto de exportação radicalmente inconsistente com um papel de cliente ou peer limitado.

Os destinatários então tomaram decisões locais. Um vizinho direto aceitou as rotas. Alguns destinatários podem tê-las preferido por atributos de caminho, preferência comercial ou comprimento do caminho. Alguns as exportaram mais adiante. Outros podem tê-las filtrado, rejeitado sob limite de máximo de prefixos ou selecionado alternativas não afetadas. O alcance do evento foi, portanto, uma propriedade emergente de múltiplas políticas.

A causalidade distribuída não deve virar causalidade sem dono. O vazador controlou o que anunciou. Seus vizinhos diretos controlaram o que aceitaram naquela relação. Cada propagador posterior controlou o que retransmitiu. As obrigações relevantes diferem, mas cada obrigação é concreta.

Atualizações BGP não são um log de encaminhamento universal

Coletores públicos de rota tornam possível uma prestação de contas histórica. O RouteViews arquiva atualizações BGP e bases de informação de rotas de peers participantes. Seu arquivo de atualizações de dezembro de 2004 preserva dados que pesquisadores podem usar para reconstruir mudanças ao redor do evento TTNet. [9] O Routing Information Service da RIPE oferece outra superfície de medição distribuída e documentação sobre o que coletores podem e não podem observar. [10]

Um registro de atualização mostra que um anúncio ou retirada de rota alcançou um coletor em uma sessão específica. O registro pode preservar prefixo, caminho AS, origem, atributos e horário. Ao comparar observações, pesquisadores podem estimar quando um caminho anômalo apareceu, quão amplamente ele propagou e quando vieram retiradas ou substituições.

Isso é evidência poderosa, mas tem limites.

Primeiro, a visibilidade do coletor é parcial. Uma rota pode alcançar redes que não alimentam um coletor. Outra rota pode ser filtrada antes de chegar a qualquer ponto de vista público. Um peer de coletor pode exportar apenas seu melhor caminho, e não todos os caminhos que aprendeu. A política pode, portanto, tornar o registro público incompleto.

Segundo, a visibilidade de plano de controle não é idêntica ao encaminhamento de plano de dados. Um roteador pode receber uma atualização e optar por não instalá-la. Uma rota pode entrar na tabela de roteamento e não entrar na tabela de encaminhamento. O tráfego pode seguir a rota, mas encontrar congestionamento ou black hole mais adiante no caminho. Inversamente, sessões em cache e diversidade de caminhos podem manter alguns serviços alcançáveis enquanto o plano de controle está instável.

Terceiro, timestamps refletem observação. A primeira atualização em um arquivo não é necessariamente o primeiro anúncio ruim globalmente. A última retirada em um coletor não é necessariamente o fim do estado obsoleto em todo o mundo. A convergência é distribuída.

Quarto, uma contagem de prefixos depende de definições. Analistas precisam decidir se contam prefixos únicos, mensagens de atualização, caminhos, origens ou mudanças de rota. Devem definir o intervalo do incidente e tratar anúncios duplicados. Diferentes métodos válidos podem gerar números diferentes.

Um artigo responsável evita afirmações como "toda a internet ficou fora do ar por exatamente X minutos" a menos que uma fonte estabeleça esse escopo. A alegação mais forte também é a mais precisa: AS9121 gerou uma anomalia de roteamento extraordinária; a anomalia propagou-se amplamente; medições públicas mostram mudança do plano de controle global e a alcançabilidade foi materialmente prejudicada.

A lacuna de evidência identifica o que um pacote completo de incidente deveria conter. Dados públicos de BGP devem ser pareados com diff de configuração da rede de origem, logs de geração de política, registros de implantação, linha do tempo de alarmes, estados de sessão, comandos de retirada, tickets de NOC e comunicações com peers. Os vizinhos diretos devem preservar as rotas que aceitaram, os filtros aplicados, eventos de máximo de prefixo e o motivo do encerramento ou manutenção da sessão.

Sem esses registros privados, pesquisadores externos podem reconstruir efeitos, mas não atribuir toda ação interna. Isso deve ser reportado como uma fronteira de evidência, não preenchido por especulação.

Vazamento é mais preciso que hijack

Incidentes de roteamento frequentemente são chamados de "hijacks" em discussão pública porque o tráfego passa por um caminho associado à rede errada. O termo pode ser útil para eventos deliberados ou de origem falsa, mas também pode sugerir intenção que a evidência não estabelece.

O registro TTNet apoia "vazamento de rota" como termo principal. As rotas saíram do escopo relacional pretendido. O evento é consistente com falha séria de política ou configuração. Não há necessidade de alegar que a TTNet quis se passar por todas as origens afetadas ou interceptar tráfego deliberadamente.

Essa distinção importa tecnicamente. O hijack de origem de rota frequentemente envolve um sistema autônomo originando prefixo que não está autorizado a originar. Um vazamento por política de caminho pode manter a origem legítima, mas expõe uma rota por relacionamento que não deveria carregá-la. Alguns incidentes combinam elementos, e registros públicos podem ser ambíguos.

A validação de origem de rota com RPKI endereça a primeira pergunta: a origem ASN é autorizada para esse prefixo sob uma ROA (Route Origin Authorization). A RFC 6811 define como um roteador pode classificar rotas usando dados RPKI. [15] Ela não codifica cada relacionamento cliente-provedor nem determina se uma rota com origem válida atravessou um vale proibido.

Mecanismos conscientes de relacionamento tratam de outra pergunta: dado onde essa rota foi aprendida, deveria ela ser exportada ou aceita nessa sessão? A RFC 9234 formaliza BGP Roles e o atributo OTC para uma classe de prevenção e detecção de vazamentos de rota. [14] Validação de customer-cone ou abordagens do tipo ASPA tratam autorização de caminho por outro ângulo.

Chamar todo evento de hijack pode levar a remediação incompleta. Um operador pode criar ROAs, observar que rotas vazadas permanecem com origem válida e concluir que o problema está resolvido. Não está. Autorização de origem, autorização de relacionamento, contenção por volume e segurança de mudança são controles separados.

A intenção ainda importa para achados legais e disciplinares, mas não é necessária para contenção operacional. Filtros devem rejeitar um conjunto de rotas não autorizado, quer foi produzido por erro, automação comprometida, ação maliciosa ou contrato mal compreendido. O monitoramento deve alertar sobre um cliente exportando a maior parte da tabela global sem perguntar primeiro o motivo.

Essa terminologia de evidência é parte da camada de realidade. Ela descreve o que a rede afirmou, aceitou e propagou. Não converte inferência sobre motivo em fato.

A autorização de prefixo de cliente deve ser executável

As lições de controle mais diretas mostram que o conjunto esperado de anúncios de um cliente deve ser representado como política executável.

Se um cliente está autorizado a anunciar um grupo definido de prefixos, o provedor pode criar um filtro de entrada que permita esses prefixos e rejeite o restante. A fonte da verdade pode incluir registros contratuais, registro de roteamento, autorizações de origem RPKI, atestado direto de cliente, histórico de rota observado e exceções manuais. Cada fonte tem limitações, mas o resultado final precisa ser uma decisão explícita de roteador.

Uma allowlist é mais forte que uma denylist ampla. Uma denylist tenta enumerar rotas obviamente impossíveis, como default ou espaço reservado, enquanto deixa aceitável um conjunto não listado imenso. Uma allowlist parte das rotas que o cliente pode originar ou transitar e trata expansão como mudança controlada.

O filtro gerado precisa ser testado. Um objeto de registro aparentemente correto ainda pode produzir configuração incorreta. Uma cadeia de automação pode mesclar cliente errado, omitir prefixo, aceitar um agregado excessivamente amplo ou falhar em modo aberto quando dados não estão disponíveis. O teste deve comparar recursos pretendidos, política gerada e um conjunto representativo de anúncios aceitos e rejeitados.

Exceções precisam de dono e vencimento. Um cliente pode precisar anunciar novo prefixo durante migração, prover trânsito para afiliada ou usar um agregado durante incidente. Uma exceção deve identificar dono aprovador, evidência, sessão afetada, escopo de prefixo e caminho, horário de início, horário de revisão e condição de rollback. Uma exceção temporária permanente é transferência oculta de risco.

O incidente da TTNet mostra por que a escala por si só já é um sinal de autorização. Uma rede esperada para anunciar um conjunto delimitado não deve, de repente, exportar a maioria da tabela global sem acionar múltiplos controles. Mesmo que a lista de prefixos esteja desatualizada ou incompleta, a mudança de volume de rota deveria ser extraordinária.

A autorização de prefixo de cliente também tem dimensão recíproca. O cliente deve validar o que exporta. Deve congelar o conjunto pretendido antes de uma mudança, inspecionar a saída gerada e comparar anúncios outbound reais contra esse conjunto. O provedor deve validar independentemente o que recebe. Esses controles não são redundantes; reduzem falha de modo comum.

Expectativas escritas não se autoexecutam. Objetos do Internet Routing Registry, contratos, planilhas e tickets são registros de responsabilização. O roteador implementa o limite. O teste prático é se uma rota não autorizada é rejeitada em exercício seguro de validação e se a rejeição é visível para ambos os operadores.

Verificações de caminho AS e política de relacionamento cobrem evidências diferentes

Autorização de prefixo pergunta se uma rota cobre um destino esperado. Verificações de caminho AS perguntam se o caminho é plausível para o relacionamento.

Um cliente pode prover trânsito para redes downstream de forma legítima. Nesse caso, um filtro ligado apenas ao ASN de origem do próprio cliente poderia rejeitar serviço válido. O provedor precisa de um customer-cone autorizado ou outra representação de quais origens e caminhos o cliente pode carregar.

Representar caminhos é difícil. Relações AS mudam. Fusões, resellers, arranjos regionais, route servers, confederações e sessões complexas resistem à classificação simples. Inferência de relacionamento pública é útil, mas imperfeita. Registros comerciais privados podem ser precisos, mas podem não chegar a tempo às operações de roteamento.

Essa dificuldade não é razão para aceitar qualquer caminho. É razão para classificar confiança, restringir incerteza e monitorar desvios. Um provedor pode combinar declarações explícitas de cliente, evidência de registro, caminhos estáveis observados, dados RPKI de origem e revisão manual. Pode rejeitar caminhos contendo seu próprio ASN em posição inesperada, ASNs reservados, comprimento implausível ou origens claramente não autorizadas.

O mecanismo OTC do BGP Roles da RFC 9234 torna explícito o relacionamento da sessão entre dois falantes BGP e define regras de propagação para funções de provedor, cliente, peer, route server e cliente de route server. [14] O atributo OTC pode marcar rotas que deveriam seguir somente para clientes depois. O mecanismo ajuda a prevenir e detectar vazamentos que violam essas regras relacionais.

Mas BGP Roles não é modelo completo de cada arranjo comercial. A RFC reconhece relações complexas e alerta que configuração incorreta de função pode afetar a propagação. A lição não é "ativar uma função". É "transformar a relação em máquina legível, confirmar com o vizinho onde possível, testar o resultado e monitorar o estado de rota em execução."

Para um incidente de 2004, esses mecanismos são comparações retrospectivas. A conclusão de responsabilização é mais antiga e mais geral: política de relacionamento foi consequente, mas parte de sua aplicação dependia de configuração que não impediu a cadeia extraordinária de exportação e aceitação anômala.

Limites de máximo de prefixos oferecem um disjuntor de volume

Um limite de máximo de prefixos define um teto para quantas rotas uma sessão BGP pode contribuir. Quando a contagem ultrapassa o limiar configurado, o roteador pode avisar, rejeitar rotas adicionais ou encerrar a sessão conforme implementação e política.

Para um evento envolvendo mais de 100.000 prefixos inesperados, um limite bem escolhido é uma camada de contenção óbvia. Um cliente que normalmente anuncia um conjunto muito menor não deveria expandir para escala quase global sem ultrapassar o limiar.

O controle é simples em conceito e delicado em operação.

Definir limite baixo demais e crescimento legítimo ou evento de deagregação podem derrubar a sessão, causando indisponibilidade. Definir limiar alto demais o torna decorativo. Reiniciar sessão automaticamente sem corrigir a fonte da rota pode criar oscilação. Avisar sem um proprietário responsável e sem resposta vira ruído.

O limiar deve considerar volume esperado, crescimento, variação operacional e custo de falha. Deve ter níveis de aviso e de ação dura. Uma exceção deve ser documentada e com prazo. A resposta deve indicar se mantém sessão inativa, aceita apenas subconjunto autorizado ou coordena correção com o cliente.

O máximo de prefixos também não prova autorização. Um cliente pode vazar um conjunto pequeno mas danoso abaixo do limiar. Pode anunciar uma rota mais específica crítica, um default ou grupo de tamanho plausível pertencente a outra organização. O limite é um disjuntor, não substituto de validação de prefixo e de caminho.

O incidente demonstra valor de controles independentes. Se a allowlist falhar, o limite de volume ainda pode conter vazamento massivo. Se ambos falharem, a detecção de anomalias pode comparar rotas atuais com a linha de base do cliente. Se o monitoramento falhar, alertas externos de rota e relatórios de peers ainda podem disparar resposta.

Um operador responsável deve ser capaz de relatar quantas sessões externas têm limites de aviso e de ação dura configurados, como os limiares são revisados, quais sessões têm exceções, com que frequência acionam e se exercícios provam que a resposta protege tanto segurança de roteamento quanto continuidade.

Política explícita de entrada e saída reduz defaults ambíguos

A RFC 8212 alterou o comportamento padrão esperado para falantes eBGP: rotas não devem ser importadas nem exportadas quando não há política explícita configurada. [13] A norma tratou uma classe recorrente de falhas em que falta de política permitia propagação ampla.

O princípio vai além de um default de fabricante. Cada sessão externa deve ter comportamento pretendido explícito de importação e exportação. O operador deve saber o que acontece se uma route-map está ausente, falha ao gerar, referencia objeto vazio ou se desanexa durante manutenção.

Comportamento fail-open é atraente sob pressão de disponibilidade. Se um feed de registro está indisponível, aceitar tudo pode manter sessão ativa. Se um gerador de política falha, preservar configuração anterior pode parecer obsoleta. Rejeitar todas as rotas também pode quebrar o serviço. Não há resposta universal.

O requisito de responsabilização é escolher deliberadamente e testar modos de falha. Um operador pode manter a última política conhecida válida, bloquear apenas expansões novas, exigir aprovação manual ou migrar tráfego para outro caminho. O que não deve ocorrer é descobrir em incidente que um objeto ausente mudou silenciosamente de "permitir essas rotas" para "permitir tudo".

Política de exportação merece atenção igual. Uma rede pode validar importações de clientes e, por engano, anunciar rotas de provedor ou peer em outro relacionamento. Pode anexar comunidade errada, omitir controle no-export ou aplicar route-map na direção errada. Conjuntos de rotas de saída gerados devem ser comparados com a intenção relacional antes da implantação.

O caso TTNet é um teste útil para sistemas de política. Aplique um conjunto representativo de tabela completa ou de rota anômala de cliente em sessão de laboratório. Verifique se os controles de importação do próprio cliente rejeitam esse conjunto, se os controles de importação do provedor rejeitam, se o máximo de prefixos o contém e se o monitoramento identifica qualquer rota residual.

Esse teste foca comportamento. Um documento de política dizendo que "rotas de clientes são filtradas" não é evidência de que a configuração gerada atual rejeita a classe de incidente.

RPKI melhora a evidência de origem, mas não codifica todo vazamento

RPKI permite que titulares de recursos de endereço criem Route Origin Authorizations verificáveis criptograficamente. Um roteador que confia nesses dados pode comparar prefixo e ASN de origem de uma rota BGP com ROAs validados e classificar a rota como Válida, Inválida ou Não Encontrada conforme semântica relevante. A RFC 6811 define validação de origem de prefixo. [15]

Esta é uma melhora importante sobre declarações de origem não autenticadas. Se um anúncio vazado apresenta ASN de origem que o titular do recurso não autorizou, a validação de origem da rota pode identificá-lo e rejeitá-lo sob política local.

Mas um vazamento por política de caminho pode preservar uma origem legítima. Suponha que um cliente aprenda uma rota válida de um provedor e a vaze para outro provedor mantendo ASN de origem original. A rota pode permanecer validada por origem mesmo que a propagação viole o relacionamento pretendido. A validação RPKI de origem não codifica, por si só, esse vale.

Essa distinção importa para TTNet. Resumos públicos diferem em como descrevem origem e estrutura de caminho de todas as rotas afetadas. Um artigo não deve afirmar que RPKI bloquearia todos os anúncios sem testar o conjunto real de rotas contra autorizações contemporâneas, que também não existiam na forma atual.

O NIST SP 800-189 recomenda proteções interdomínio em camadas, incluindo validação de origem baseada em RPKI e filtro de prefixo. [18] Seu enquadramento mais amplo é útil: roteamento resiliente exige múltiplos mecanismos porque segurança de origem, política de caminho, spoofing, resposta a negação de serviço e monitoramento operacional são problemas distintos.

RPKI também cria responsabilidades operacionais. Operadores precisam de diversidade de cache validado, monitoramento de atualização, comportamento seguro durante falha de repositório, política para rotas Inválidas e Não Encontradas, governança de exceções e métricas que mostram enforcement real. Criar ROAs sem implantar validação de origem da rota mantém a evidência fora da decisão de encaminhamento.

O princípio Heng.lu está visível aqui. Registros de recurso são livros-caixa. Podem estabelecer evidência de autorização e apoiar responsabilização. Não são comandos soberanos de roteadores. Política em execução determina se a evidência afeta alcançabilidade.

Monitoramento deve comparar rotas em execução com rotas pretendidas

O vazamento TTNet foi visível porque o estado de rota mudou dramaticamente. Um sistema maduro de monitoramento deve detectar várias dimensões dessa mudança.

Monitoramento de volume verifica quantos prefixos uma sessão anuncia, retira e mantém. Uma mudança de uma linha de base delimitada para fração grande da tabela global deve ser um evento crítico.

Monitoramento de origem verifica se prefixos esperados mudaram ASN de origem ou se um cliente passou a originar espaço fora de sua autoridade. RPKI e dados de registro podem suportar essa comparação.

Monitoramento de caminho verifica se relações cliente, provedor e peer aparecem em sequências inesperadas. Pode identificar propagação em formato de vale, loops, redução súbita de caminho ou o ASN da própria rede em posição anormal.

Monitoramento de especificidade verifica se rotas mais específicas inesperadas apareceram. Um número pequeno de prefixos mais específicos pode atrair tráfego substancial mesmo quando a contagem total permanece abaixo do limite.

Monitoramento geográfico e topológico compara observações de múltiplos coletores. Uma rota visível apenas numa região pode ser questão de política local; uma rota se espalhando por upstreams independentes indica propagação mais ampla.

Correlação de mudanças conecta anomalias de rota a implantações, janelas de manutenção, commits de configuração e jobs de automação. Um pico global de rota segundos após uma alteração de política deve identificar imediatamente a mudança candidata sem forçar operadores a buscar manualmente sistemas não relacionados.

Monitoramento deve produzir evidência acionável. Um alerta precisa de dono, severidade, sessão afetada, delta de rota observado, linha de base esperada, contenção recomendada e caminho de escalação. Deve preservar as amostras de rota que o dispararam.

Alerta sozinho não é contenção. Uma rede pode detectar vazamento e ainda gastar minutos críticos decidindo quem pode reiniciar sessão, qual route-map restaurar, como contatar peers ou se rollback piora a indisponibilidade. Exercícios devem testar a cadeia operacional.

Monitoramento público fornece camada independente. Clientes e operadores de serviços críticos podem observar seus próprios prefixos e origens em pontos de vista externos. Provedores podem comparar sua visão com RouteViews, RIPE RIS ou feeds comerciais. Evidência independente ajuda a detectar falhas em telemetria interna e confirma se uma retirada se propagou.

Responsabilidade entre AS9121, provedores, peers e importadores

A responsabilização deve ser atribuída conforme controle, evidência e dever.

AS9121 teve controle primário sobre o conjunto de rotas que exportou. A revisão operacional deveria identificar o gatilho, a política pretendida, a configuração gerada, a aprovação, o caminho de implantação, o tempo de detecção, a ação de contenção, a retirada e testes de remediação. Se um cliente ou fonte de rota downstream iniciou a tabela, a revisão deveria distinguir esse gatilho da responsabilidade de AS9121 por aceitar e exportar.

Provedores e peers upstream diretos controlaram a primeira fronteira externa de contenção. Eles deveriam demonstrar a relação atribuída à sessão AS9121, o conjunto de prefixo e caminho esperado, política de máximo de prefixo, exceções, alertas e política de exportação subsequente. Se aceitaram volume extraordinário, a revisão deve explicar qual controle falhou, estava ausente ou foi sobrescrito.

Redes de trânsito posteriores e peers controlaram fronteiras posteriores. A responsabilidade deles depende do que aprenderam, de quem aprenderam e de qual política era razoável para aquele relacionamento. Um cliente downstream recebendo tabela completa de seu provedor está em posição distinta de um provedor aceitando tabela completa de um cliente pequeno.

Operadores de coletores controlaram medição, não propagação de rota. Seu dever é documentar pontos de observação, timestamps, retenção e limites metodológicos. Pesquisadores devem tornar transformações reprodutíveis onde licenciamento e privacidade permitirem.

Operadores de serviços críticos controlaram resiliência ao redor do evento. Multihoming, diversidade de provedor, monitoramento externo de rota, comunicação fora da banda e failover podem reduzir impacto. Mas esses operadores não controlam a origem da rota vazada e não devem absorver culpa que pertence às fronteiras de política interdomínio.

Usuários finais controlaram quase nada relevante para BGP. Eles experimentaram conexões lentas, black holes ou falha de serviço. Seus relatos ajudam a detectar impacto, mas não validam caminhos AS nem emitem retiradas.

Esse modelo em camadas evita dois erros. O primeiro é atribuir toda responsabilidade ao operador de origem tratando provedores como tubulações passivas. O segundo é dispersar responsabilidade tanto que nenhum dono de controle permanece. Cada rede deve responder pela fronteira que operou.

Recuperação é transição de estado de rota, não declaração

Parar o gatilho é necessário, mas não suficiente. O BGP é distribuído, e o estado de rota converge com o tempo.

A rede de origem pode corrigir política, retirar rotas, reiniciar sessões ou desconectar uma fonte. Vizinhos diretos devem processar retirada ou perda de sessão, selecionar alternativas e exportar mudanças. Seus vizinhos repetem o processo. Route flap damping, mecanismos de rotas obsoletas, estado de sessão e comportamento de timers locais e política podem afetar a linha do tempo.

Uma declaração do operador como "a configuração foi corrigida" marca uma ação interna. Não prova que o estado global de rota esteja limpo.

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

Quando AS9121 parou de exportar o conjunto anômalo de rotas?
Quais sessões foram reiniciadas, filtradas ou mantidas inativas?
Quando vizinhos diretos observaram retiradas ou substituições?
Quantos prefixos anômalos permaneceram em cada coletor independente ao longo do tempo?
Os caminhos legítimos retornaram e eram utilizáveis no plano de dados?
Rotas obsoletas ou vazamentos secundários ainda estavam visíveis após a correção primária?
Quando serviços críticos se recuperaram em múltiplas regiões e redes de acesso?
Quais peers exigiram coordenação direta em vez de convergência automática?

O arquivo de rotas pode ajudar a responder algumas dessas perguntas. Logs de sessão privados e snapshots de rota podem responder mais. Sondagens de plano de dados distinguem normalização de tabela de rota de alcançabilidade real.

A evidência de recuperação também deve preservar incerteza. Se um coletor normalizou às 10:00 e outro às 10:07, o relatório não deve inventar um único segundo de recuperação global. Pode reportar um intervalo de convergência e descrever os pontos de observação.

O passo final é um replay seguro. Operadores devem reproduzir a classe de falha em laboratório ou ambiente de validação controlado. Um cliente representativo deve tentar anunciar um conjunto oversized e não autorizado. O teste deve mostrar qual camada rejeita, quais alertas disparam, quem responde e como a evidência fica retida.

Sem esse teste, uma mudança de política permanece uma promessa.

Uma pilha moderna de controle é em camadas

Nenhum controle único resolve todo vazamento de rota, e as camadas devem ser projetadas para falhar de forma independente.

Política explícita de sessão:Comportamento de importação e exportação deve ser explícito, com tratamento seguro para objetos de política ausentes ou com falha. A RFC 8212 fornece uma direção útil de padrão. [13]

Filtros de prefixo autorizados:Clientes diretos devem ficar limitados a prefixos que estão autorizados a originar ou transitar, com base em evidência mantida e exceções controladas.

Verificações de caminho AS e constraints de customer-cone:Provedores devem avaliar se o caminho é plausível para o relacionamento, não apenas se a origem é válida.

Limites de máximo de prefixos:Limiares por sessão devem avisar e conter volume anômalo antes que um vazamento em escala de tabela seja propagado.

Validação de origem por RPKI:Roteadores devem usar evidência de origem validada sob política operacional que trate rotas Inválidas, Não Encontradas, falha de cache e exceções. [15]

BGP Roles e OTC:Onde suportado e apropriado, funções mutuamente confirmadas e tratamento Only-to-Customer podem codificar e impor expectativas de relacionamento. [14]

Teste de política gerada:A automação deve comparar recursos pretendidos, política gerada e anúncios simulados antes da implantação.

Segurança de mudança:Mudanças de roteamento de alto risco devem usar rollout em estágios, revisão por pares, canários quando possível, condições automáticas de parada e rollback testado.

Monitoramento independente:Visão interna e externa de rotas deve detectar anomalias de volume, origem, caminho e especificidade e conectá-las a mudanças recentes.

Coordenação de incidente:Operadores precisam de contatos atualizados, canais fora da banda, ações de contenção pré-autorizadas e templates para compartilhamento de prefixos afetados e evidência de retirada.

Verificação de recuperação:Múltiplos pontos de vista de plano de controle e plano de dados devem confirmar normalização.

Esses controles devem ser medidos. Métricas úteis incluem percentual de sessões de cliente com allowlists geradas, limites de prefixo rígidos, política de origem validada, monitoramento externo, classificação atual de relacionamento e testes recentes de replay de vazamento. Idade de exceções e evidência obsoleta também importam.

MANRS enquadra filtragem, coordenação, anti-spoofing e validação global como ações de operador. [17] O NIST SP 800-189 também trata segurança de roteamento como conjunto de medidas complementares, não como um único appliance. [18] O valor desses frameworks está na adoção operacional e na verificação.

Evidência de registro e primazia de código em execução

O evento TTNet se apoia diretamente na superfície de responsabilização Heng.lu: roteamento BGP, evidência de ASN e IP e relacionamentos de peering/transit.

Um registro ASN pode identificar AS9121. Registros de endereço podem identificar alocações e detentores. Registros de roteamento podem publicar objetos de rota e política. RPKI pode fornecer autorização de origem assinada. Esses registros reduzem ambiguidade e criam trilha de evidência.

Eles não encaminham pacotes.

Os roteadores em execução aceitaram e propagaram um conjunto de rotas conforme configuração carregada e estado de sessão vivo. Se a governança operacional ignorou, interpretou mal ou falhou em recuperar a evidência de registro, o registro escrito não restringiu a rede.

Por isso, um registro deve ser entendido como livro-razão ou guardião de registros, não como soberano. Sua legitimidade vem de registros precisos, únicos, seguros, transferíveis e operacionalmente utilizáveis. A aplicação continua uma responsabilidade de operador.

Primazia do código em execução não descarta governança. Ela torna a governança testável. Um conselho pode exigir registros de recurso autorizados, mas também exigir evidência de que esses registros produzem filtros e decisões de validação de rota. Um auditor pode inspecionar um objeto IRR, mas deve rastrear esse objeto pelo gerador de política até o roteador e testar um anúncio conflitante.

A camada de realidade rejeita duas formas de discurso de advocacy. Uma diz que descentralização significa que ninguém pode ser responsabilizado. A outra diz que um registro central pode mandar a internet para correção. Nenhuma descreve o sistema.

A internet é uma rede de sistemas operados de forma independente conectados por acordos e sessões de protocolo. Responsabilização vem de evidência precisa, limites explícitos, política executável, verificações independentes e recuperação auditável.

Remover de dentro deste artigo a exportação BGP, AS9121, autorização de prefixo, política de relacionamento, coletores e retiradas destrói a tese. A superfície de controle da rede não é decoração. É o tema.

O que um pacote de remediação credível deveria conter

Um pacote credível no padrão TTNet seria suficientemente concreto para que outro operador ou auditor reproduzisse a reivindicação de controle.

Começaria com uma linha do tempo do incidente que distingue primeiro gatilho interno, primeira rota ruim externa, primeiro alerta, diagnóstico, contenção, retirada, convergência parcial e recuperação verificada. Cada carimbo de tempo identificaria fonte e padrão de horário.

Incluiria a política de importação e exportação pretendida para as sessões relevantes, a configuração pré-incidente real, a mudança ou falha que produziu o vazamento e a configuração corrigida. Valores sensíveis podem ser ocultos preservando a lógica.

Congelaria o conjunto esperado de prefixo e caminho do cliente, explicaria os registros de origem, listaria exceções e mostraria o filtro gerado. Registraria limiares de aviso e limiar de ação dura para máximo de prefixos.

Incluiria atualizações BGP representativas de monitores internos, peers diretos, RouteViews e RIPE RIS. Explicaria limitações de coletor e metodologia de contagem.

Mostraria por que os controles originais falharam: filtro ausente, dados desatualizados, sessão com papel errado, geração com falha, ordem de política equivocada, comportamento fail-open, alerta sem dono ou outra causa com prova de evidência.

Documentaria decisões de contenção e coordenação entre peers. Se uma sessão foi reiniciada, o relatório mostraria o motivo. Se rotas foram rejeitadas seletivamente, mostraria os critérios de correspondência.

Forneceria gráfico de retirada e convergência por ponto de observação, além de checks de plano de dados para destinos críticos.

Relataria propriedade de remediação, prazos, evidência de conclusão e risco residual. Uma frase como "os procedimentos foram atualizados" não seria suficiente.

Por fim, incluiria replay controlado mostrando que uma exportação de tabela completa ou anômala de cliente é rejeitada em múltiplas camadas independentes e que o evento chega a um alerta de proprietário sem escapar para peers de produção.

Esse pacote não tornaria a internet isenta de risco. Tornaria a reivindicação de controle do operador falsificável.

As perguntas de governança devem seguir a rota

Executivos, reguladores, auditores e compradores de serviço podem fazer perguntas eficazes sem fingir que configuram roteadores.

Conselhos devem perguntar quais mudanças podem alterar anúncios públicos BGP, quantas sessões de clientes não têm allowlists atuais ou limites de máximo de prefixo rígidos, como as exceções são aprovadas e quando foi o último exercício de replay de vazamento.

Provedores de trânsito devem perguntar se os registros de relacionamento estão atualizados, se política de entrada e saída é explícita, se filtros gerados falham de forma segura e se rotas anômalas são contidas antes de nova propagação.

Compradores corporativos devem perguntar se a diversidade de provedor é topologicamente independente, se seus prefixos críticos são monitorados externamente e se relatórios de incidente do provedor incluem evidência de estado de rota.

Auditores devem amostrar configurações ativas e políticas geradas. Devem rastrear evidência de recurso até decisões de rota e testar casos negativos. Uma captura de tela de portal de política não é prova de enforcement.

Reguladores devem evitar mandates de um único controle que confundem implantação com resultado. Exigir ROAs pode melhorar evidência de origem, mas um programa de responsabilização para vazamento de rota também precisa de política de relacionamento, filtragem, monitoramento, coordenação e testes de recuperação.

Revisores de incidente não devem parar em "erro humano". Essa frase não explica por que um único erro pôde exportar um conjunto extraordinário, por que vizinhos diretos o aceitaram, por que safeguards não o contiveram e por que a recuperação levou o tempo observado.

Métricas devem mostrar cobertura e exceções, não vaidade. Uma rede pode reportar 99% de cobertura de filtro deixando um cliente de alto volume sem restrição. O risco segue a fronteira exposta, não a média.

Governança também deve proteger incerteza honesta. Operadores devem ser cobrados a declarar quais partes do estado de rota não puderam reconstruir, quais dados não foram retidos e quais controles contrafactuais não foram testados.

O teste de responsabilização é propagação limitada e retirada verificada

O evento TTNet de 24 de dezembro de 2004 permanece relevante porque expôs um problema de controle que ainda existe onde políticas de BGP são implícitas, filtros são amplos e evidência de rota fica desconectada da política em execução.

AS9121 propagou um conjunto extraordinário de rotas. Outros sistemas autônomos aceitaram e redistribuíram parte suficiente para transformar uma falha de política local em um evento distribuído de alcançabilidade. Coletores públicos de rota preservaram parte do registro de plano de controle. Análises posteriores tornaram o evento útil como referência para detecção de vazamento.

A evidência pública não justifica alegações de intenção maliciosa, de uma contagem universal única de prefixos ou de reconstrução completa de todas as decisões de operador. Essas limitações devem permanecer visíveis.

A responsabilidade foi em camadas. A rede exportadora controlou geração e anúncios de rota. Provedores e peers diretos controlaram a primeira fronteira de aceitação do cliente. Redes posteriores controlaram a propagação adiante. Operadores de monitoramento controlaram qualidade da evidência. Operadores de serviço controlaram resiliência. Usuários finais sofreram impacto sem controle sobre estado de rota.

A remediação moderna também é em camadas. Filtros de prefixo autorizados, verificações de caminho AS, limites de máximo prefixo, política explícita, validação de origem por RPKI, BGP Roles, testes de política, monitoramento independente, resposta coordenada e verificação de recuperação abordam partes distintas da cadeia de falha.

O princípio Heng.lu fornece a distinção final. Registros de roteamento e de políticas de registro podem estabelecer quem deve originar recursos e quais relacionamentos se pretendem. Eles são livros de responsabilização indispensáveis. Os roteadores em execução ainda determinam alcançabilidade.

Um operador credível, portanto, deve provar três coisas.

Primeiro, ele sabe o que um cliente ou peer está autorizado a anunciar.

Segundo, seus sistemas em execução rejeitam ou contêm anúncios que excedam esse escopo, mesmo quando uma fonte de política ou componente de automação falha.

Terceiro, quando o estado ruim escapa, ele o retira rapidamente e mostra, a partir de pontos de observação independentes, que a internet retornou a estado de rota autorizado.

Esse é o teste de responsabilização da filtragem de prefixo de cliente tornado visível pelo vazamento TTNet de 2004. O padrão não é prevenção perfeita. É propagação limitada, controle atribuído, evidência retida e recuperação verificada.

O vazamento de rota da TTNet em 2004 tornou a filtragem de prefixo de clientes um teste de responsabilização

Por que isso importa