AS7007 1997: teste de responsabilidade no roteamento da internet

Resumo

Limite do incidente congelado:Este artigo examina as rotas originadas pelo AS7007 em 25 de abril de 1997 e a consequente interrupção de alcançabilidade. Ele não combina esse evento com fugas de rotas posteriores, sequestros maliciosos ou falhas não relacionadas em exchanges de nome semelhante. Registros contemporâneos do NANOG mostram operadores observando seu próprio espaço de endereços como rotas mais específicas com o AS7007 na origem. [3][4]
Reconstrução técnica delimitada:Uma conta posterior da APNIC descreve rotas eBGP sem classes entrando em um sistema, sendo redistribuídas para RIPv1, perdendo informação de tamanho de prefixo e retornando ao BGP como rotas deagregadas com informação de origem reescrita. [1] Esse é um modelo explicativo forte, não autorização para inventar uma sequência exata de comandos internos.
Por que as rotas prevaleceram:O encaminhamento de internet usa combinaçăo de prefixo mais específico. Uma rota mais específica atrai tráfego antes da comparação de vários atributos de caminho BGP. As rotas vazadas, portanto, criaram uma realidade operacional que conflitou com propriedade de recurso e informação de origem esperada.
Responsabilidade segue controle:O AS7007 controlou redistribuição, política de exportação, validação de mudanças, monitoramento e retirada. Seus provedores upstream controlaram filtros de cliente, limites de prefixo e propagação. Pares de importação e redes de downstream controlaram sua própria aceitação de políticas e resposta de emergência. Usuários finais poderiam relatar falhas, mas não reparar o estado de rota interdomínio.
Evidência de registro não é fiscalização:ASN, registro de endereços, IRR e registros RPKI posteriores podem preservar evidência sobre titulares esperados e origens autorizadas. Os roteadores ainda agem com base nas rotas e políticas carregadas nos sistemas em execução. O incidente é, assim, um exemplo claro de primazia do código em execução: autoridade escrita importa apenas quando a política operacional a aplica.
Controles modernos são em camadas:Validação de origem de rota, política explícita de importação e exportação, BGP Roles, filtragem de cone de cliente, limites de prefixo, monitoramento independente e rollback testado tratam falhas diferentes. Nenhum mecanismo único deve ser apresentado como cura retrospectiva universal.
Recuperação precisa ser demonstrada:Desconectar ou corrigir o roteador de origem não é o fim da responsabilidade. Operadores precisam de evidência de retiradas, limpeza de rotas antigas, normalização de tabela de rotas, coordenação com peers e restauração de encaminhamento observável em múltiplos pontos.

O limite do evento é 25 de abril de 1997

Uma história técnica responsável começa congelando o evento. Em 25 de abril de 1997, operadores de internet reportaram um conjunto extraordinário de rotas mais específicas associado ao AS7007, operado pela MAI Network Services. Mensagens do NANOG do dia oferecem evidência contemporânea do que os operadores viram: blocos de endereços que esperavam originar-se em outro lugar apareceram em prefixos menores com o AS7007 como origem, e o tráfego seguiu esses anúncios para caminhos que não conseguiam transportá-lo corretamente. [3][4]

O evento é frequentemente descrito em resumos posteriores como o "incidente AS7007" ou um grande vazamento de rota da internet. Esse rótulo é útil apenas se permanecer ligado às evidências. Não deve virar atalho para todo erro de roteamento da época, nem sugerir intenção hostil. O registro público mais forte sustenta uma falha de propagação acidental com efeitos severos. Não sustenta a alegação de que o AS7007 queria interceptar tráfego ou reivindicar conscientemente a propriedade de todos os blocos afetados.

Histórias técnicas posteriores costumam descrever milhares de rotas /24 e uma interrupção aguda de cerca de duas horas. O registro retrospectivo da APNIC fornece uma contagem aproximada de 6.000 anúncios /24 e reconstrói como o comportamento classful de roteamento poderia transformar uma tabela externa ampla em rotas mais específicas. [1] O catálogo de incidentes do Secure Routing também registra o evento como uma falha de roteamento de referência.

[2] Essas fontes tardias ajudam a organizar a história, mas os relatos contemporâneos dos operadores continuam importantes porque mostram o estado de rota visível externamente enquanto o incidente acontecia.

O número exato de anúncios, o horário exato inicial e final visível em todos os pontos e a configuração interna completa não são estabelecidos em um único documento público. As visões de BGP dependem do ponto de observação. Uma rota pode aparecer em um peer antes de outro, permanecer obsoleta em uma tabela após ser retirada em outro local, ou ser suprimida por um filtro que outra rede não possui. Uma narrativa defensável, portanto, atribui estimativas numéricas e evita transformar a visão de um único coletor em um relógio universal.

O papel da Florida Internet Exchange também exige cautela. Narrativas posteriores às vezes conectam o evento à infraestrutura da exchange ou usam o nome da exchange como marcador de local conveniente. A evidência pública revisada aqui não justifica atribuir a falha inteira à exchange em si. A tese de responsabilidade repousa em transformação de rota, exportação, aceitação de peer e recuperação. Ela não exige a alegação não sustentada de propriedade do incidente por uma única instalação.

Esses limites importam porque o diagnóstico orienta a remediação. Se o evento é chamado incorretamente de sequestro deliberado, a resposta pode focar em credenciais e detecção de origem maliciosa. Se for reduzido a uma falha genérica de indisponibilidade, a resposta pode focar apenas em disponibilidade. As evidências apontam, em vez disso, para uma transformação de política de rota que escapou de uma fronteira interna e foi aceita por várias fronteiras externas.

O BGP sem classes encontrou um protocolo interno com classes

O mecanismo técnico é incomum o bastante para exigir explicação cuidadosa. O BGP transporta informações de alcançabilidade entre sistemas autônomos. Rotas modernas de BGP incluem um prefixo e seu tamanho, como /16 ou /24, além de atributos de caminho que os operadores usam em seleção e política de exportação. A RFC 4271 descreve o protocolo base e o processo de decisão. [8]

RIPv1 foi projetado para um modelo classful anterior. Ele não transportava máscaras de sub-rede nos anúncios de rota. Em uma interpretação classful, um endereço podia ser tratado segundo classes históricas de rede amplas, em vez do comprimento de prefixo explícito presente em uma rota classless de BGP. Quando rotas se movem entre protocolos com modelos de informação diferentes, redistribuição não é cópia neutra. É uma transformação.

A reconstrução da APNIC descreve rotas aprendidas por eBGP sem classes sendo redistribuídas para RIPv1. Como o RIPv1 não podia preservar os tamanhos de prefixo classless originais, as rotas foram representadas de forma a levar à deagregação. Quando essas rotas foram redistribuídas de volta ao BGP, os anúncios resultantes apareceram como muitos prefixos mais específicos e a informação externa original de AS-path não foi mais preservada como histórico externo. [1]

Essa reconstrução explica duas observações ao mesmo tempo. Primeiro, explica o volume de anúncios /24. Um número menor de rotas mais amplas pode gerar muitas rotas mais estreitas quando a semântica do prefixo é transformada. Segundo, explica por que o AS7007 apareceu como origem de espaço de endereços que operadores associavam a outras redes. Se a informação externa do caminho é removida durante a redistribuição e a rota é reintroduzida no BGP, o sistema que reintroduz a rota pode tornar-se a origem visível.

O registro público não revela toda versão de software, objeto de roteador, comando de redistribuição, route-map ou ação administrativa. Seria irresponsável transformar a reconstrução em um transcript terminal fabricado. A evidência suporta uma classe de mecanismo: informação foi perdida ou transformada entre uma fronteira de protocolo, e as rotas transformadas foram exportadas para o BGP interdomínio.

Essa distinção é importante para responsabilidade. Uma revisão pós-incidente não deve parar em RIPv1 ser antigo ou redistribuição ser arriscada. Deve perguntar quem autorizou a fronteira de protocolo, quais atributos se esperava que sobrevivessem, qual conjunto de rota gerado foi testado, qual invariante de exportação deveria rejeitar o resultado e qual alarme deveria disparar quando volume de rota e origem mudaram.

A tradução de protocolo é um risco recorrente em infraestrutura. Cada protocolo pode funcionar conforme projetado enquanto a composição viola a intenção do sistema. Uma rota válida em uma representação pode tornar-se materialmente diferente ao ser importada para outra. O responsável pelo controle precisa validar a saída da transformação, não apenas a sintaxe de cada lado.

Rotas mais específicas transformaram informação ruim em realidade de encaminhamento

Na seleção de caminho do BGP, a especificidade de prefixo é relevante. Roteadores encaminham pacotes usando o prefixo com maior correspondência no quadro de encaminhamento. Uma rota /24 corresponde a uma faixa menor de endereços que uma /16 cobrindo. Quando ambas existem, o tráfego para endereços dentro da /24 segue a rota /24 mesmo se a rota abrangente permanecer disponível.

Esse comportamento ajuda redes a implementar engenharia de tráfego e multihoming. Também torna a deagregação acidental muito forte. Se o AS7007 originou milhares de rotas mais específicas, essas rotas poderiam atrair tráfego para longe das rotas de cobertura legítimas. A internet não precisava acreditar que o AS7007 era dono legal do espaço. Bastava que os roteadores aceitassem os anúncios e instalassem os caminhos mais específicos.

A distinção entre propriedade e alcançabilidade é central. Registros de endereço podem registrar qual organização recebeu um bloco. Registros de roteamento podem registrar a política de origem pretendida. Sistemas RPKI posteriores podem permitir que um titular autorize um ASN de origem para um prefixo. Nenhum desses registros altera automaticamente uma tabela de encaminhamento. A rede em operação segue rotas aceitas sob política configurada.

Durante o incidente, operadores relataram caminhos para suas próprias redes mostrando o AS7007 como origem. [3][4] Se o tráfego seguiu essas rotas mais específicas para uma rede sem capacidade de entregá-lo aos destinos pretendidos, o resultado foi um grande buraco negro. Alguns caminhos podem ter se comportado de forma diferente porque as redes aplicaram filtros, preferiram outras rotas ou ainda não tinham recebido os anúncios. Essa variação não enfraquece o mecanismo; mostra que o escopo do incidente foi definido pela política distribuída.

A palavra vazamento é mais precisa do que sequestro aqui. A RFC 7908 publicou depois uma taxonomia para vazamentos de rota como propagação além do escopo pretendido. [9] O evento de 1997 é anterior a esse padrão, e sua deagregação incomum não precisa ser forçada em uma categoria moderna única para que a responsabilidade fique clara. As rotas saíram do limite operacional pretendido, carregaram especificidade e origem enganosas e foram propagadas o bastante para degradar a alcançabilidade.

Discussões de segurança às vezes tratam qualquer rota de origem errada como evidência de atacante. Essa inferência não tem suporte aqui. Controles operacionais devem detectar o estado de rota prejudicial independentemente de intenção. Um alarme de limite de prefixo, uma verificação de origem autorizada ou uma comparação de conjunto exportado não precisa decidir se o operador foi descuidado, comprometido ou malicioso antes de bloquear o anúncio.

Por isso a evidência de rota é valiosa. Ela permite que investigadores descrevam o que a rede afirmou e aceitou sem especular sobre motivação. A responsabilidade então segue os sistemas e organizações que controlaram essas afirmações e decisões de aceitação.

A responsabilidade foi distribuída, mas não ficou sem dono

O roteamento interdomínio é descentralizado. Isso não significa que a responsabilidade desaparece. Significa que responsabilidade deve ser atribuída aos controles que cada organização pode operar.

O AS7007 controlou a fronteira interna de redistribuição. Controlou se rotas externas de BGP entraram em protocolo interno, se atributos e semântica de prefixo foram preservados, se rotas transformadas puderam retornar ao BGP e quais anúncios foram exportados para provedores upstream. Também controlou aprovação de mudança, implantação, monitoramento, rollback e comunicação de incidente.

Os provedores upstream que aceitaram as rotas do AS7007 controlaram uma fronteira diferente. Podiam manter lista de prefixos de cliente esperados, rejeitar origens fora de conjunto autorizado, limitar número de prefixos, limitar especificidade aceita ou exigir exceção para anúncios incomuns. Também controlavam se rotas aceitas eram exportadas adiante para peers e clientes.

Peers de importação e redes downstream controlaram suas próprias políticas. Algumas podem ter tido filtros que continham partes do evento. Outras podem ter confiado amplamente em relacionamento upstream. A responsabilidade delas não é idêntica à do originador, porque não criaram as rotas transformadas. Mas a aceitação de rota ainda é um ato operacional.

Operadores de serviços críticos e redes corporativas controlaram resiliência ao redor do sistema de roteamento. Podiam monitorar estado externo de rota, usar provedores diversos, manter comunicação fora de banda e testar se a suposta diversidade de caminho compartilhava as mesmas dependências upstream. Esses controles podem reduzir impacto ou melhorar detecção, mas não corrigem o conjunto global de rotas na origem.

Usuários finais e clientes comuns tinham quase nenhum controle prático. Podiam tentar novamente, alternar rede de acesso quando havia alternativa ou reportar falhas. Não podiam inspecionar cada caminho BGP, alterar filtros de provedor ou forçar retiradas. Culpabilizar usuários por não contornar o evento confunde exposição com responsabilidade.

A divisão de controle sugere uma conclusão em camadas:

O operador de origem tinha dever principal de impedir que uma transformação interna se tornasse uma alegação externa.
Os upstreams diretos tinham forte dever de contenção porque conheciam o relacionamento de cliente e podiam definir rotas esperadas.
Outras redes tinham dever geral de manter política de importação defensável e monitorar anomalias.
Operadores de serviço tinham dever de continuidade para entender dependências de rota e detectar falhas externas.
Provedores de evidência pública tiveram papel de observação, não de controle de produção.

Esse modelo evita dois erros. Evita colocar todas as consequências em um único engenheiro que pode ter executado uma mudança em sistema fraco. Também evita afirmar que a internet é descentralizada demais para responsabilidade. A pergunta relevante é sempre controle prático: quem podia prevenir, conter, detectar, retirar ou verificar?

A modelagem de exportação deve testar o conjunto de rotas gerado

Uma regra escrita que diz do not announce other networks’ prefixes (não anunciar prefixos de outras redes) não é suficiente. O sistema precisa de uma representação verificável do conjunto esperado de exportação e de uma comparação contra as rotas que a configuração realmente gera.

Para uma rede de cliente ou borda, um modelo de exportação pode definir:

os prefixos que a rede está autorizada e esperada para originar;
o número máximo de rotas em estado normal e em estado de emergência;
comprimentos de prefixo permitidos;
quais rotas podem ser anunciadas para cada relacionamento;
se rotas aprendidas de cliente, peer e provedor podem ser reexportadas;
quais caminhos e comunidades AS são esperados;
quais exceções existem, quem as aprovou e quando expiram.

A configuração gerada deve ser testada antes da implantação. Um teste não deve confirmar apenas que existe um route-map. Deve alimentar rotas representativas pela política e examinar os anúncios resultantes. Se rotas sem classe cruzarem uma representação classful ou com perda, o teste deve comparar contagem de prefixo, tamanho, origem e caminho antes e depois da transformação.

O evento AS7007 ilustra um invariante de alto valor: um processo de roteamento não deve exportar um prefixo mais específico para um prefixo externo a menos que esse prefixo esteja explicitamente autorizado. Outro invariante poderia limitar a diferença entre a contagem de rotas esperada e a gerada. Uma mudança do conjunto de anúncios ordinário de cliente para milhares de /24 deveria parar a implantação mesmo que cada rota individual seja sintaticamente válida.

Limites de prefixo oferecem uma segunda camada. Um upstream pode configurar número máximo de prefixos aceitos de um cliente. Um limiar sensato inclui margem operacional, mas permanece baixo o bastante para detectar um grande vazamento. O limiar deve ser específico por relacionamento. Um provedor de trânsito, uma rede de conteúdo e um cliente de acesso pequeno têm conjuntos normais diferentes.

Limites de prefixo não bastam por si só. Um vazamento pode causar sério dano e permanecer abaixo de um máximo generoso. Um cliente pode anunciar o número esperado de rotas, porém rotas erradas. Limites devem, portanto, ser combinados com autorização de prefixo e origem.

Filtros de cliente podem vir de registro, contrato, IRR e dados RPKI, mas essas fontes têm lacunas. Um sistema defensável registra qual fonte autorizou cada rota, quando foi atualizada e como conflitos são tratados. Exceções de emergência devem ser explícitas e temporárias, não desvios invisíveis.

A RFC 7454 fornece orientação operacional de segurança para BGP, incluindo filtragem e limites de prefixo. [13] A MANRS enquadra práticas relacionadas como ações de operador. [14] BITAG e NIST também descrevem controles de segurança de roteamento e realidades de implantação. [15][16] Esses documentos devem informar um sistema de controle, não substituir evidência de que o controle está ativo na sessão relevante.

A evidência mais forte é um registro de teste: o conjunto esperado de rotas, o conjunto gerado, a decisão de política para cada diferença, a lista aprovada de exceções, o resultado canário e a observação de rota ao vivo após implantação.

A doutrina Heng.lu separa registros de fiscalização

O incidente AS7007 é um caso direto de controle de rede para a doutrina Heng.lu. Número de recursos exigem unicidade, registros precisos, histórico de transferência, metadados de segurança e continuidade operacional. Esses registros são essenciais, mas o registro é um livro-razão e guardião de registros, não um controlador soberano de roteadores em execução.

Um registro ASN pode identificar o AS7007. Dados de registro de endereços podem identificar titulares esperados dos prefixos que apareceram sob AS7007. Um objeto de rota IRR pode descrever política de origem pretendida. Uma ROA pode autorizar um ASN para originar um prefixo. Estas são superfícies de evidência.

O plano da realidade é a rota aceita por um roteador e instalada para encaminhamento. Em 25 de abril de 1997, a verdade operacional não era apenas o que os registros diziam. Era que rotas mais específicas com AS7007 como origem foram aceitas e propagadas, e o tráfego as seguiu.

Isso não torna os registros irrelevantes. Sem registros, um peer tem menos evidência confiável para montar filtros e um investigador tem menos evidência para identificar anomalias. O ponto é que um registro vira proteção operacional apenas quando política o consome, exceções são controladas e implantação é verificada.

A primazia do código em execução também se aplica a procedimentos escritos. Um procedimento pode exigir revisão por pares e filtragem de prefixo. Se uma configuração gerada contorna o filtro, o sistema em funcionamento define o resultado. Uma auditoria que verifica apenas o procedimento relata um controle que não restringiu o incidente.

Assim, a doutrina mapeia três exigências práticas:

Livro-razão preciso:Registros de recurso e política devem identificar prefixos, origens e operadores responsáveis esperados.
Política aplicada:Roteadores e servidores de rota devem transformar essa evidência em decisões de importação e exportação.
Continuidade operacional:Monitoramento e rollback devem mostrar que estado errado pode ser removido e a alcançabilidade correta restaurada.

O artigo não precisa transformar esses princípios em defesa de uma organização de registro ou produto. A evidência é mais estreita. O incidente mostra que registros de unicidade e propriedade não evitam danos quando a política de roteamento aceita estado operacional contraditório.

Remover os fatos de redistribuição BGP, especificidade de prefixo, origem AS, filtros de peer e retiradas destruiria a tese do artigo. Por isso este não é um texto genérico de risco corporativo com terminologia de rede adicionada depois. É uma análise de responsabilidade da própria infraestrutura de rede.

RPKI, RFC 8212 e BGP Roles resolvem problemas diferentes

Discussões modernas de segurança de roteamento costumam perguntar se a RPKI teria evitado um incidente antigo. A resposta responsável é condicional.

A validação de origem de rota compara prefixo e ASN de origem observados com Route Origin Authorizations. A RFC 6811 define os estados de validação usados por roteadores. [12] Se um prefixo possui uma ROA válida autorizando outra origem e o AS7007 anuncia uma rota mais específica com conflito, a rota pode ser classificada como inválida, conforme cobertura de prefixo e comprimento máximo.

Muitas declarações de origem errada do AS7007 seriam, portanto, mais fáceis de identificar e rejeitar em ambiente RPKI completamente coberto e configurado corretamente. Isso é uma melhora real de controle. Não prova que toda rota do incidente de 1997 teria sido rejeitada.

Alcançabilidade depende de cobertura. Uma rota sem ROA de cobertura não é inválida apenas porque um observador a acha suspeita. Configurações de comprimento máximo importam. Uma autorização abrangente pode tornar uma rota mais específica inválida se exceder o comprimento autorizado, mas uma autorização excessivamente ampla pode permitir especificidade nociva. A política de implantação importa porque uma rede pode calcular estado de validação sem rejeitar rotas inválidas.

Validação de origem também não reconstrói a intenção de relacionamento. Uma rota com origem autorizada ainda pode vazar de cliente para provedor ou peer em violação da política de exportação esperada. A RFC 7908 descreve várias formas de vazamento onde a origem pode ser legítima, mas a propagação está errada. [9]

A RFC 8212 muda a postura padrão de eBGP ao exigir política explícita de importação e exportação. [10] Isso reduz a propagação acidental causada por aceitação implícita total. Não garante que uma política explícita esteja correta. Um operador pode escrever uma política permissiva, autorizar uma transformação insegura ou anexar o objeto de política errado.

A RFC 9234 introduz BGP Roles e atributo OTC para ajudar redes a identificar e prevenir alguns vazamentos baseados em relacionamento. [11] Ela trata propagação ciente de relacionamento. Não substitui validação de origem, testes de política gerada, limites de prefixo ou rollback.

Abordagens de customer-cone inferem ou mantêm o conjunto de rotas esperado de um cliente e de seus descendentes. Filtros do tipo peerlock restringem caminhos envolvendo redes maiores. Pesquisas mostram que implantação parcial ainda pode oferecer proteção útil, ao mesmo tempo em que documenta limites e complexidade operacional. [17]

O aprendizado em camadas é:

RPKI e validação de origem de rota tratam origem autorizada.
IRR e dados de registro apoiam registros de prefixo e política esperados.
RFC 8212 exige política explícita.
BGP Roles e OTC tratam prevenção de vazamento ciente do relacionamento.
Filtros de customer-cone e de caminho limitam propagação.
Limites de prefixo limitam volume.
Modelagem de configuração detecta defeitos de política gerada.
Monitoramento independente detecta desvios no estado em execução.
Rollback e coordenação restauram serviço.

Tratar um único controle como resposta completa cria um novo vazio de responsabilidade. Operadores devem declarar quais modos de falha um controle cobre, o que acontece quando faltam dados, como exceções são revisadas e como o controle é testado contra uma falha representativa.

A recuperação não terminou quando o roteador de origem foi desconectado

A evidência contemporânea mais reveladora trata da recuperação. Um pedido de desculpas publicado no NANOG descreveu dificuldade em limpar rotas ruins mesmo após o roteador de origem ter sido desconectado. [4] Essa observação transforma a recuperação de uma narrativa de desligamento simples para um problema de estado distribuído.

Rotas BGP propagam-se por muitos sistemas autônomos. Quando a origem retira uma rota ou uma sessão cai, vizinhos processam a alteração, atualizam seus caminhos selecionados e publicam mudanças resultantes. Temporizadores, amortecimento de flap de rota, estado da sessão, comportamento de implementação e política local podem afetar o quão rápido as tabelas se normalizam.

A fonte original pode parar de emitir rotas ruins enquanto informação antiga permanece em outros locais. Um peer pode reter um caminho temporariamente, um refletor de rota pode processar mudanças em ritmo diferente, ou um operador pode precisar reiniciar uma sessão para limpar estado inesperado. Relatórios de um único ponto de observação não provam convergência em todos os roteadores.

Um registro de recuperação com responsabilidade deve incluir:

quando a origem parou de gerar ou exportar as rotas ruins;
quando cada upstream direto observou as retiradas;
se sessões foram reiniciadas e por quê;
se o amortecimento de flap de rota ou mecanismos de rota obsoleta afetaram a limpeza;
quando coletadores deixaram de ver as origens ruins;
quando origens legítimas e rotas de cobertura voltaram à visibilidade esperada;
quando testes de encaminhamento atingiram os destinos pretendidos;
quando peers principais confirmaram tabelas normalizadas;
quais rotas permaneceram anômalas e por quanto tempo;
quem declarou serviço restaurado e com que evidência.

O incidente também mostra por que planos de rollback precisam de validação do estado de rota. Restaurar uma configuração anterior não basta se rotas ruins permanecerem instaladas além da origem. Uma checklist de rollback deve incluir retiradas esperadas, comparação de tabela e confirmação independente.

CAIDA’s BGPStream torna dados históricos e ao vivo de roteamento acessíveis para análise. [18] Coletadores públicos são valiosos para confirmação independente, mas são amostras. Um processo de recuperação maduro combina dados internos de RIB e FIB, relatos diretos de peers, coletadores públicos e sondas de encaminhamento.

Comunicação de recuperação deve separar contenção da restauração global. "O roteador foi desconectado" é um marco de contenção. "Todas as rotas afetadas foram retiradas dos peers diretos" é um marco de propagação. "Pontos de observação independentes não veem mais as rotas e o encaminhamento está normal" está mais próximo da evidência de restauração.

Essa estrutura evita fechamento prematuro. Também ajuda organizações a medir a parte da recuperação que controlam diretamente e a parte que depende de coordenação.

A evidência pública de rota é forte, mas incompleta

O registro público de um evento de roteamento de 1997 é incomumente útil, mas ainda tem limites. Mensagens do NANOG trazem observações diretas de operadores e um pedido de desculpas. [3][4] Relatos contemporâneos capturam escala e surpresa da indisponibilidade. [5] Contas técnicas posteriores explicam a interação entre protocolos. [1][2][6] Padrões e orientações descrevem os controles que operadores podem aplicar. [8]-[17]

Nenhuma fonte pública revela toda tabela de roteamento privada, diff de configuração, ticket de suporte, contrato de peering ou log de decisão. A evidência não identifica o primeiro dispositivo exato que aceitou cada rota ou o número exato de usuários afetados. Não pode mostrar quais filtros bloquearam silenciosamente e evitaram propagação mais ampla.

A reconstrução histórica também enfrenta deslocamento terminológico. Em 1997, operadores descreveram o incidente com a linguagem e ferramentas disponíveis na época. Contas posteriores usam vazamento de rota, sequestro, deagregação e validação de origem em maneiras moldadas por padrões posteriores. Um artigo cuidadoso não deve fazer com que um operador de 1997 pareça ter seguido ou violado um padrão que ainda não existia.

Padrões modernos são lições de desenho de controle atual, não requisitos retroativos de conformidade. A RFC 4271 foi publicada depois do evento, embora documente o modelo de BGP-4 maduro. A RFC 7908, RFC 8212 e RFC 9234 vieram bem depois. [8]-[11] Elas ajudam a explicar classes de falha e camadas de prevenção, mas não provam o que AS7007 ou seus upstreams eram contratualmente obrigados a implantar em 1997.

As evidências sustentam várias conclusões de alta confiança:

O AS7007 originou grande número de rotas mais específicas para espaço de endereços associado a outras redes.
O estado de rota causou interrupção substancial de alcançabilidade.
O evento foi acidental conforme o registro disponível.
A transformação de interna para externa foi central na reconstrução técnica posterior.
A aceitação e propagação por peers ampliaram o impacto.
Retirada e limpeza não foram instantâneas.

Sustenta também conclusões de confiança moderada:

A redistribuição de classless para classful explica plausivelmente a deagregação e a origem reescrita.
Um filtro upstream direto ou limite de prefixo poderia ter contido grande parte do conjunto de rotas.
Melhor modelagem de exportação teria exposto grande diferença entre anúncios pretendidos e gerados.

Ela deixa desconhecimentos importantes:

a sequência de configuração exata;
a topologia completa de dispositivos e softwares;
o estado de filtro de cada peer direto;
a linha do tempo completa do incidente;
a propriedade e aprovação de decisões;
o efeito total por rede e geografia;
a remediação implementada após o evento.

Responsabilidade fica mais forte quando esses níveis de confiança permanecem visíveis. Exagerar conclusões tornaria o artigo mais fácil de criticar e mais difícil de usar como padrão de auditoria.

Uma agenda de remediação verificável

O registro público não estabelece quais controles MAI Network Services ou cada upstream implantaram depois. A resposta correta é definir evidência que mostraria que o caminho de falha agora está controlado.

1. Congelar o conjunto de exportação esperado

Para cada sessão eBGP, preservar um conjunto de exportação esperado versionado. O conjunto deve incluir prefixo, máxima especificidade, origem, restrições de caminho, relacionamento e exceções aprovadas. Deve ser gerado a partir de registros autorizativos e da intenção operacional explícita.

Evidência: commit de repositório, registro de aprovação, carimbos de tempo de fonte de dados, proprietário da exceção e vencimento.

2. Testar transformações de protocolo

Onde rotas passam entre BGP, um IGP, sistema de rotas estáticas ou outra representação, testar se o tamanho de prefixo, origem, caminho e atributos de política são preservados conforme pretendido. Rejeitar transformações com perda, salvo se o conjunto de rotas resultante for explicitamente limitado.

Evidência: rotas de entrada representativas, rotas de saída geradas, resultados de invariantes e testes negativos.

3. Comparar anúncios gerados e esperados

Antes da implantação, calcular o delta de rotas. Interromper se o conjunto gerado introduzir prefixos não autorizados, mais específicos inesperados, mudanças de origem ou aumento de contagem além do limite aprovado.

Evidência: diff pré-implantação e resultado da condição de parada.

4. Aplicar filtros de cliente direto

Upstreams devem filtrar rotas de cliente contra um conjunto esperado, aplicar limites de prefixo por relacionamento e registrar toda exceção. Dados de registro e RPKI podem informar o conjunto, mas conflitos não resolvidos devem falhar em segurança ou exigir revisão explícita.

Evidência: anexo de política ativa, testes de anúncios aceitos e rejeitados, histórico de atualização e lista de exceções.

5. Implantar política de relacionamento explícita

Toda sessão eBGP deve ter política explícita de importação e exportação. Onde suportado, BGP Roles e controles cientes de relacionamento devem alinhar a política operacional com o relacionamento real. A configuração deve rejeitar relação ausente ou inconsistente em vez de aceitar silenciosamente um padrão amplo.

Evidência: inventário de sessão, mapeamento de função, anexo de política e teste de conformidade.

6. Monitorar fora da rede

Monitorar origem, especificidade, caminho, volume de rota e alcançabilidade de pontos de vista independentes. Os alertas devem conectar anomalias de rota com testes de encaminhamento para que as equipes diferenciem atualização visível de evento com impacto de usuário.

Evidência: consultas de coletor, cronologia de alertas, resultados de sondas e ligação com incidente.

7. Definir paradas automáticas de rollout

Uma implantação deve parar quando rota, origem inesperada, volume de mais específicas, visibilidade de peer ou prejuízo de encaminhamento ultrapassar limiar definido. A parada não deve depender apenas da percepção humana de reclamações públicas.

Evidência: política de canário, limiar, gatilho e parada executada.

8. Testar retirada e limpeza

Executar testes em laboratório ou isolamento mostrando que uma rota defeituosa é retirada, as sessões convergem, estado antigo é detectado e sondas independentes retornam ao normal. O exercício deve incluir comunicação com peers e acesso fora de banda.

Evidência: carimbos de tempo de retirada de origem, recebimento por peer, normalização de tabela e recuperação de encaminhamento.

9. Preservar evidência do incidente

Preservar atualizações de rota, diffs de configuração, entradas de geração de política, registros de aprovação, alertas, comandos, mensagens de peer e checagens de recuperação. A sincronização temporal deve tornar a sequência auditável.

Evidência: pacote de incidente imutável com hashes e controles de acesso.

10. Verificar remediação contra a classe de falha original

Não encerrar a remediação com declaração genérica de melhoria de monitoramento. Recriar representação segura da transformação classless para classful ou uma deagregação não autorizada equivalente e mostrar onde a cadeia de controle atual a interrompe.

Evidência: desenho de teste, ponto de falha esperado, resultado observado e revisão independente.

Essa agenda é deliberadamente neutra em relação a produtos. Não exige um provedor, registro ou serviço de segurança específico. Exige que o operador mostre que a política esperada é precisa, que a política em execução a imponha, que anomalias bloqueiem implantação e que a recuperação seja visível de forma independente.

As perguntas de governança devem seguir a rota

Conselhos, reguladores, compradores de serviço e auditores não precisam operar BGP para fazer perguntas úteis. Eles precisam seguir a rota pela cadeia de controle.

Conselhos devem perguntar quais mudanças podem alterar anúncios públicos, como exports gerados são testados, quem pode aprovar exceções e quão rápida é a execução de rollback. Devem receber resultados de exercícios, não apenas documentos de política.

Provedores de trânsito devem perguntar se filtros de cliente derivam de evidência atual, quantas sessões têm limite de prefixo, quais sessões aceitam exceções amplas e se essas exceções expiram. Um controle aplicado à maioria dos clientes ainda pode deixar exposta a sessão de maior risco.

Compradores corporativos devem perguntar se há provedores duais operacionalmente independentes, se o monitoramento de rota externo cobre prefixes críticos e se as comunicações de incidente distinguem falha de roteamento de falha de aplicação. Diversidade contratual não é o mesmo que diversidade de caminho.

Auditores devem amostrar políticas de sessão reais, conjuntos de rotas geradas e observações de rota. Devem rastrear um registro ou ROA até uma decisão de roteador e testar o que acontece quando falta dado ou há conflito.

Reguladores devem evitar definir responsabilidade de roteamento como implantação de uma única tecnologia. Exigir criação de ROAs pode melhorar segurança de origem, mas não prova filtragem ciente de relacionamento, validação de mudança ou recuperação. Obrigações baseadas em evidência podem pedir que operadores documentem controles adequados ao seu papel e os testem.

Revisores de incidente devem separar causa raiz, condições contribuintes, gatilho, detecção, resposta e recuperação. "Erro humano" não é causa raiz suficiente. Não explica por que o sistema gerou milhares de rotas inesperadas, por que upstreams as aceitaram, por que monitoramento não interrompeu a propagação ou por que a limpeza permaneceu difícil.

O objetivo de governança não é tornar cada mudança de rota isenta de risco. É assegurar que organizações com controle prático possam mostrar como reduzem, contêm e reparam o risco criado por sua posição na rede.

O teste de responsabilidade é fiscalização observável

O incidente AS7007 de 1997 permanece importante porque concentra em um só evento vários deveres de infraestrutura de rede. Uma fronteira interna de protocolo transformou informação de rota. A saída transformada cruzou uma fronteira de política externa. Rotas mais específicas alteraram a realidade de encaminhamento. Múltiplas redes aceitaram e propagaram as alegações. A recuperação exigiu retirada e coordenação distribuídas.

O registro público não justifica uma alegação de intenção maliciosa ou uma sequência exata de comando não documentada. Ele justifica uma conclusão operacional forte: a propriedade esperada dos recursos e a intenção escrita de roteamento não restringiram o estado de rota em execução.

Responsabilidade era em camadas. O AS7007 controlou a transformação e a exportação. Upstreams diretos controlaram aceitação e contenção de cliente. Outras redes controlaram política de importação. Operadores de serviço controlaram monitoramento externo e resiliência. Usuários finais sofreram consequências sem controle rotineiro de roteamento.

Mecanismos modernos melhoram o ambiente de controle, mas apenas quando seus limites são explícitos. RPKI pode ajudar a rejeitar origens não autorizadas. RFC 8212 pode eliminar comportamento padrão implícito de eBGP. BGP Roles e OTC podem ajudar a conter vazamentos de relacionamento. Limites de prefixo podem capturar volume anormal. Filtros de cliente podem conter rotas esperadas. Modelagem pode comparar exportações geradas com intenção. Monitoramento e rollback podem conter e reparar falhas.

A doutrina Heng.lu oferece um padrão final conciso. Registros e evidências de política de roteamento preservam prova de responsabilidade, mas não determinam o plano de encaminhamento. O código em execução, a política configurada e as rotas aceitas determinam o que a internet faz. A continuidade operacional exige que estado ruim possa ser detectado, removido e verificado de forma independente.

Um registro de remediação credível mostraria, portanto, o conjunto de exportação esperado, testes de política gerada, filtros de cliente direto, limites de prefixo, detecção de anomalia ao vivo, confirmação de peers e recuperação de encaminhamento. Reconstraria a classe de falha original de forma segura e mostraria qual controle agora a bloqueia.

A pergunta duradoura de 25 de abril de 1997 não é se os operadores atuais sabem que vazamentos de rota são perigosos. É se conseguem provar que um conjunto de rotas transformado, não autorizado e altamente específico não atravessa suas fronteiras sem detecção, e se conseguem provar recuperação quando isso acontece. Essa é a prova de responsabilidade da internet que o AS7007 tornou visível.

AS7007 1997: por que o vazamento transformou o filtro de rotas em teste de responsabilidade da internet

Por que isso importa