Experimento BGP RIPE-Duke de 2010: Responsabilidade de Roteamento

Resumo

Um atributo BGP transitivo opcional válido foi corrompido quando sistemas IOS XR afetados o propagaram, causando reinicializações de sessão downstream e instabilidade de roteamento mais ampla.
A responsabilidade segue pontos de controle distintos: escopo e monitoramento do experimento, comportamento e reparo do produto, controles de continuidade do operador e tratamento de erros do protocolo.

Em 27 de agosto de 2010, a equipe do RIPE NCC que opera o Routing Information Service, ou RIS, trabalhou com um grupo de pesquisa da Duke University em um experimento ao vivo do Border Gateway Protocol. Os pesquisadores estudavam um projeto de roteamento seguro que transportava informações de certificação em um atributo de caminho transitivo opcional. Às 08:41 UTC, o RIPE NCC originou o prefixo 93.175.144.0/24 a partir do RIS AS12654 por meio de conexões na AMS-IX e na GN-IX. A rota foi retirada conforme planejado às 09:08 UTC.[1]

O anúncio foi incomum porque o atributo era novo na internet pública. Incomum, porém, não significava malformado. O RIPE NCC e a Cisco descreveram o atributo iniciador como válido ou compatível com os padrões.[1][2] Essa distinção determina como o evento deve ser analisado. O experimento não demonstrou simplesmente que roteadores rejeitam entradas inválidas. Ele mostrou que uma entrada compatível com os padrões podia passar por verificações formais, encontrar um defeito no software implantado, ser corrompida durante a propagação e, em seguida, ativar um tratamento de erro severo em outros lugares.

A Cisco relatou que os sistemas IOS XR afetados manipularam incorretamente o atributo transitivo válido, porém não reconhecido, ao encaminhá-lo adiante. Um roteador vizinho podia receber o UPDATE corrompido resultante e reinicializar a sessão de peering BGP. Como uma sessão BGP carrega muitas rotas, uma resposta a um único UPDATE defeituoso podia remover temporariamente informações de alcançabilidade válidas não relacionadas. Se o roteador responsável pela corrupção de saída não detectasse o próprio erro, ele podia anunciar novamente as informações problemáticas depois que a sessão retornasse, renovando a instabilidade.[2][3]

As medições do RIPE NCC sustentam uma conclusão de impacto limitado, porém material. O evento produziu taxas de atualização até vinte vezes maiores que a linha de base ao redor. O RIPE estimou que 0,5% adicionais dos prefixos ficaram completamente inalcançáveis por mais tempo que o normal. A proporção de prefixos instáveis atingiu o pico de 1,4%, representando quase 4.500 prefixos e aproximadamente nove vezes o nível comum observado em torno do evento. Os resultados variaram por coletor e localização, com atividade de atualização especialmente intensa visível no coletor de Viena.[1]

Esses números são significativos, mas não autorizam afirmar que uma porcentagem conhecida de usuários, roteadores, redes ou tráfego desapareceu. Observações do plano de controle contam comportamento de roteamento, não pessoas. A análise DNSMON do RIPE não encontrou falha nos servidores raiz.

Ela encontrou perda limitada de consultas para alguns domínios monitorados e problemas mais visíveis em partes da infraestrutura autoritativa.si e.fr, enquanto servidores redundantes continuaram respondendo.[1] Comentários contemporâneos de operadores mencionaram problemas de acesso e mudanças no tráfego de troca, mas esses relatos não formam uma contabilidade quantitativa completa.[4][6]

A lição de responsabilidade é, portanto, mais estreita e mais útil do que uma história de um único ator “quebrando a internet”. O RIPE NCC controlava se sua infraestrutura de medição originava uma rota experimental visível na internet, além do momento, do aviso, do monitoramento e da retirada. Os pesquisadores da Duke controlavam o desenho da pesquisa e a implementação do lado da pesquisa. A Cisco controlava o tratamento de um atributo válido não reconhecido no IOS XR, seus testes de produto, a divulgação e as correções de manutenção.

Os operadores de rede controlavam o software instalado, as políticas de roteamento, as proteções de peer, o monitoramento e a restauração em suas próprias redes. As regras de protocolo da época forneceram um mecanismo de amplificação ao permitir que um único UPDATE malformado causasse falha no nível da sessão.

Os reparos também pertenciam a camadas separadas. A Cisco emitiu um aviso no dia do evento e preparou atualizações de manutenção.[2] O RIPE NCC preservou evidências, forneceu informações ao fornecedor, publicou uma análise e se comprometeu com controles mais rígidos para experimentos cooperativos futuros.[1] Seu Conselho Executivo apoiou posteriormente a continuidade da pesquisa, enfatizando a comunicação apropriada.[5] A correção do produto reduziu o risco de implementação; uma governança de experimento mais forte reduziu o risco de descobrir uma interação desconhecida por meio de um domínio de falha público desnecessariamente amplo.

Padrões posteriores ajudam a explicar como o setor aprendeu com essa classe de falha, mas não podem ser usados como prova do que estava implantado ou era exigido em agosto de 2010.

A RFC 7606 promoveu mais tarde um tratamento mais restrito de UPDATEs BGP malformados, porque reinicializar uma sessão inteira pode descartar muitas rotas válidas.[13] Recomendações operacionais sobre política externa explícita, prevenção de vazamento de rota, validação de origem, RPKI e BGPsec iluminam controles adjacentes, mas nenhuma estabelece retroativamente negligência, e nenhuma sozinha corrige o defeito preciso de corrupção de saída exposto por este evento.[14][15][16][17][18][19][20]

A conclusão central é contida: um anúncio experimental válido desencadeou uma cadeia em que um defeito de implementação corrompeu informações, o tratamento de erros no nível da sessão amplificou essa corrupção e controles insuficientemente limitados de experimentos ao vivo expuseram a interação na internet pública. A responsabilidade segue a alocação de controle, não a simplicidade do primeiro gatilho visível.

1. Por que este evento merece uma análise restrita

Incidentes de BGP costumam ser comprimidos em rótulos como vazamento, sequestro, interrupção ou configuração incorreta. Esses rótulos podem ser úteis quando as evidências se encaixam neles, mas também podem apagar o mecanismo que realmente importa. Este evento exige uma fronteira mais precisa.

O objeto é apenas o experimento RIPE NCC–Duke University de 27 de agosto de 2010. Não se trata de um relato de vazamentos de rota posteriores, sequestros posteriores ou de todas as falhas de BGP subsequentes. A taxonomia de vazamento de rota posterior da RFC 7908 é útil para distinguir categorias, mas não justifica rotular este experimento como um vazamento de rota convencional sem evidências de que as condições especificadas de vazamento ocorreram.[16]

O experimento originou uma rota deliberadamente construída carregando um novo atributo transitivo opcional. Sua visibilidade pública foi intencional. A instabilidade resultante não foi. Essa combinação cria três perguntas que não devem ser colapsadas em uma:

O UPDATE BGP inicial era válido?
Qual componente transformou informações válidas em informações corrompidas?
Quais controles permitiram que a falha resultante se espalhasse além de um teste estritamente limitado?

O registro disponível responde às duas primeiras perguntas com confiança relativamente alta. O RIPE NCC e a Cisco caracterizaram o atributo original como válido ou compatível com os padrões, enquanto a Cisco identificou uma vulnerabilidade no IOS XR envolvendo corrupção durante a propagação.[1][2] O NVD registra o problema do produto como CVE-2010-3035.[3]

A terceira pergunta é distribuída. Os pesquisadores não controlavam cada roteador implantado. A Cisco não decidiu que o RIS originaria a rota experimental. Operadores individuais não projetaram o experimento nem a implementação afetada. As conexões de troca de internet não provaram, por sua mera presença, aprovação de cada atributo transportado por elas. A atribuição, portanto, deve seguir os pontos de controle reais.

Este evento importa porque quebra uma suposição fácil, porém insegura: a de que a conformidade com padrões na origem é suficiente para estabelecer segurança operacional em um sistema de roteamento heterogêneo. A conformidade é necessária, mas o comportamento implantado decide se um pacote ou UPDATE sobrevive ao contato com o código em execução. O experimento passou por um tipo de fronteira de validade e falhou em outro.

O próprio RIS existe para coletar e expor informações de roteamento de múltiplos pontos de observação.[7][8] Registros do RIPEstat e do RIPE Database fornecem contexto de identificação para o AS12654, mas um registro de sistema autônomo não pode revelar todos os comportamentos de software encontrados ao longo de um caminho propagado.[9][10] Sistemas coletores de rota como RIS e Route Views são valiosos exatamente porque nenhum registro único de registro, declaração de peer ou log local pode descrever todo o sistema de roteamento interdomínio.[11]

A lição não é que os padrões sejam irrelevantes. É que um padrão descreve o comportamento exigido, enquanto a responsabilidade exige evidências de que implementações, implantações e controles operacionais produzem esse comportamento em condições reais.

2. Cronologia: de um anúncio programado a uma perturbação não intencional

Antes das 08:41 UTC: desenho e verificação pré-anúncio

O grupo de pesquisa da Duke estudava um projeto de roteamento seguro no qual informações de certificação viajariam em um atributo de caminho BGP transitivo opcional. A Duke forneceu uma implementação Quagga modificada dentro do esforço de pesquisa. As verificações pré-anúncio estabeleceram que o atributo tinha uma forma de protocolo aceitável, e uma segunda instância Quagga não reproduziu o comportamento visto depois em equipamentos implantados afetados.[1]

Esse resultado foi informativo, mas incompleto. Ele mostrou que a implementação iniciadora e um ambiente receptor semelhante podiam processar o atributo. Não mostrou que cada família de roteadores, versão de software ou caminho de encaminhamento na internet pública preservaria o atributo corretamente.

Essa foi a lacuna crítica de detecção. O caminho de teste avaliou a estrutura formal e um comportamento de implementação limitado. Ele não reproduziu a base instalada heterogênea pela qual um atributo transitivo poderia viajar. Mais importante, não expôs um defeito em que um roteador aceitava um atributo desconhecido válido, mas o corrompia ao enviá-lo adiante.

O registro público não estabelece o registro completo de aprovação, todos os riscos considerados ou todos os controles discutidos antes do evento. Seria, portanto, inadequado inventar um processo de decisão não documentado. O que se pode dizer é que os controles usados antes do anúncio não detectaram a interação que produziu a perturbação pública.

08:41 UTC: a rota se torna visível

Às 08:41 UTC de 27 de agosto de 2010, o RIS AS12654 começou a anunciar o prefixo 93.175.144.0/24 com o atributo transitivo opcional experimental. O anúncio percorreu as conexões do RIPE NCC na AMS-IX e na GN-IX.[1]

Esse momento foi o evento desencadeador. “Desencadeador”, porém, não é sinônimo de “causa raiz”. Um gatilho é o evento que ativa uma condição latente. Se uma entrada válida encontra uma implementação defeituosa, a entrada válida inicia a sequência observada, mas o defeito explica por que a sequência se afasta do comportamento especificado.

A visibilidade pública da rota também criou a exposição de governança do experimento. Um teste em um sistema fechado ou estritamente limitado pode revelar um defeito sem permitir que ele atravesse um conjunto amplo de redes autônomas. Uma vez que a rota entrou na propagação interdomínio comum, o resultado passou a depender de software e políticas fora do controle direto das partes iniciadoras.

Durante a propagação: informações válidas são corrompidas

Os sistemas IOS XR afetados receberam um atributo que não reconheciam. No desenho transitivo opcional do BGP, a falta de reconhecimento não era, por si só, motivo para rejeitar o atributo. O comportamento relevante era preservá-lo e propagá-lo.

O relato da Cisco identificou uma falha nesse caminho de propagação: os sistemas afetados corromperam o atributo transitivo válido não reconhecido ao enviá-lo a um vizinho.[2] As evidências disponíveis não justificam inventar a mutação precisa em nível de byte para cada caminho afetado. A constatação confiável é funcional: informações válidas não familiares entraram em uma implementação afetada, e informações corrompidas emergiram na propagação.

Essa distinção localiza o defeito do produto com mais precisão do que dizer que o roteador meramente “não suportava” o recurso experimental. A transitividade opcional existe para que um roteador possa transportar um atributo sem entender sua semântica completa. Uma implementação conforme não precisa agir sobre as informações de certificação. Ela precisa preservar o atributo corretamente se o propagar.

A corrupção então cruzou uma fronteira de implementação. Um vizinho downstream recebeu um UPDATE que não era mais equivalente ao válido originado pelo experimento.

Recepção downstream: um UPDATE ameaça uma sessão inteira

Segundo as regras de tratamento de erros associadas à linha de base dos padrões da época, um atributo de caminho malformado podia produzir um UPDATE Message Error e o fechamento da sessão BGP.[12] Essa resposta era severa por desenho: um roteador que não conseguisse interpretar com segurança as informações de roteamento se protegia encerrando a sessão.

O efeito colateral operacional era amplo. Uma sessão BGP normalmente carrega muitas rotas, não apenas o prefixo experimental. Fechar a sessão podia, portanto, retirar rotas válidas não relacionadas aprendidas daquele peer. As redes então procuravam alternativas, trocavam novos UPDATEs e reconvergiam.

Um mecanismo adicional de repetição era possível. O roteador que corrompeu o atributo de saída não necessariamente se identificava como a fonte da corrupção. Depois que uma sessão vizinha se recuperava, a mesma rota podia ser anunciada novamente. A mesma corrupção podia se repetir, o sistema downstream podia reinicializar de novo e a instabilidade de roteamento podia se renovar.[2]

A cadeia de falha era, consequentemente, maior que o prefixo experimental:

Um atributo válido, porém não familiar, entrou em um roteador afetado.
O roteador o corrompeu durante a propagação adiante.
Um vizinho recebeu um UPDATE malformado.
O vizinho podia encerrar a sessão BGP.
Rotas não relacionadas ao experimento podiam desaparecer daquela adjacência.
A reconvergência produziu um volume maior de atualizações.
O reanúncio podia repetir a sequência.

É por isso que o evento se tornou um teste de responsabilidade, e não apenas uma curiosidade de interoperabilidade. Cada etapa era controlada por um componente ou organização diferente.

09:08 UTC: retirada programada

O RIPE NCC retirou o anúncio experimental às 09:08 UTC, conforme planejado.[1] A rota, portanto, havia sido originada por aproximadamente vinte e sete minutos.

A retirada era necessária, mas não é uma borracha instantânea. O BGP é distribuído. Atualizações já aceitas ou propagadas precisam viajar por outras sessões, enquanto os roteadores recalculam caminhos e restauram adjacências. Uma retirada planejada pode interromper a origem contínua no ponto iniciador sem cancelar imediatamente cada cópia, atualização enfileirada, reinicialização ou processo de reconvergência já em andamento.

O RIPE descreveu o impacto operacional não intencional como durando cerca de trinta minutos. A maior parte da instabilidade voltou ao normal aproximadamente vinte minutos após o experimento, em vez de terminar no segundo exato da retirada.[1] Essas descrições devem ser tratadas como intervalos operacionais medidos, não convertidas em uma afirmação de que todos os caminhos afetados se recuperaram simultaneamente.

Após a retirada: resposta do operador e coleta de evidências

Os operadores observaram e responderam a partir de suas próprias redes. Discussões contemporâneas em listas de e-mail incluíram relatos de problemas de acesso, mudanças de roteamento e efeitos no tráfego de troca.[4][6] Esses comentários são evidências úteis de que a perturbação era operacionalmente visível, mas têm limites estritos. Eles não enumeram todos os sistemas autônomos afetados, não normalizam observações entre locais nem fornecem uma contagem completa do tráfego perdido.

O RIPE NCC reteve os dados do experimento e forneceu as evidências coletadas à Cisco. Essa preservação importou porque o evento cruzou fronteiras organizacionais. Um log do lado da origem sozinho poderia mostrar o que o RIS enviou, mas não necessariamente o que uma implementação intermediária emitiu. Um relatório do fornecedor sozinho poderia explicar um defeito, mas não quantificar observações em toda a internet. Uma reconstrução confiável exigia evidências de mais de um domínio de controle.

22:00 UTC: o aviso da Cisco

A Cisco publicou seu aviso sobre o IOS XR às 22:00 UTC de 27 de agosto de 2010.[2] O problema foi registrado como CVE-2010-3035, e a Cisco preparou atualizações de manutenção de software.[3]

O aviso no mesmo dia estabeleceu uma resposta pública no nível do produto. Ele não provou, por si só, qual versão estava instalada em cada operador afetado, quantos dispositivos encontraram a rota ou se todos os operadores tinham uma mitigação imediatamente utilizável. Essas questões permanecem desconhecidas no registro limitado.

31 de agosto e depois: análise pública e resposta de governança

O RIPE NCC publicou sua análise de incidente e medição em 31 de agosto de 2010.[1] O relato descreveu o experimento, a interação de implementação, os efeitos de roteamento observados, as conclusões do DNSMON e mudanças prospectivas em futuros experimentos cooperativos.

O RIPE NCC disse que os experimentos futuros receberiam tratamento mais rígido, incluindo avaliação de impacto abrangente, aviso prévio suficiente aos operadores e tratamento responsável de vulnerabilidades.[1] Seu Conselho Executivo apoiou posteriormente a continuidade da experimentação, enfatizando a comunicação adequada.[5]

Essa resposta não negou o valor da pesquisa. Ela reconheceu que um objetivo de pesquisa útil não elimina a necessidade de limitar a exposição operacional. O reparo de governança, portanto, não foi “parar de experimentar”. Foi tornar a autoridade para iniciar um experimento público condicionada a controles mais claros de risco, aviso, contenção e resposta.

3. O que é um atributo transitivo opcional — e por que “desconhecido” não significava “inválido”

Atributos de caminho BGP carregam informações associadas a uma rota. Alguns são bem conhecidos e espera-se que sejam compreendidos pelas implementações de BGP. Outros são opcionais. Uma distinção separada diz respeito à transitividade: se um atributo deve continuar entre falantes BGP mesmo quando uma implementação intermediária não reconhece seu significado.

A RFC 4271 define o comportamento relevante. Um atributo opcional não transitivo não reconhecido não precisa ser encaminhado. Um atributo transitivo opcional não reconhecido é diferente. Ele é aceito e passado a outros peers BGP, com o bit Partial usado para indicar que um sistema intermediário não reconheceu totalmente o atributo.[12]

Esse mecanismo apoia a extensão. Sem ele, cada sistema autônomo ao longo de um caminho precisaria de suporte de software simultâneo antes que um novo recurso transitivo pudesse cruzar a internet. A transitividade opcional permite implantação incremental: um roteador pode transportar informações sem interpretá-las.

O desenho cria uma responsabilidade de implementação estrita. Um roteador que não entende um atributo transitivo opcional ainda deve manipular sua representação com segurança. Em termos práticos, ele não deve transformar informações opacas válidas em informações malformadas.

Quatro conceitos devem permanecer separados:

Reconhecimento.O roteador entende a semântica do atributo?

Aceitação.O atributo tem uma forma que o roteador pode receber com segurança segundo as regras do protocolo?

Propagação.O roteador deve ou pode passar o atributo adiante?

Mutação.O roteador altera o atributo e, se sim, essa alteração é permitida e codificada corretamente?

O evento de 2010 não exigiu que os sistemas IOS XR afetados entendessem o esquema de certificação da pesquisa. O defeito dizia respeito à propagação. O relato da Cisco foi que os sistemas afetados corromperam o atributo transitivo válido não reconhecido ao enviá-lo adiante.[2]

Isso explica por que uma segunda instância Quagga não foi suficiente para prever o incidente. Duas implementações podem concordar sobre a forma de um atributo enquanto uma terceira contém um defeito em um caminho de código diferente. Receber, armazenar e serializar um atributo desconhecido podem envolver operações separadas. Passar por uma verificação de conformidade na entrada não prova comportamento correto na saída.

O evento também demonstra a diferença entre validade sintática e segurança operacional de ponta a ponta. O UPDATE inicial podia ser válido na origem. Um sistema intermediário podia então produzir uma representação inválida. Um sistema downstream podia responder corretamente segundo as regras disponíveis para ele e ainda criar uma consequência operacional danosa ao fechar uma sessão inteira.

Nenhuma camada isolada explica o impacto:

O experimento forneceu a entrada não familiar.
O produto afetado forneceu a corrupção.
A resposta de erro downstream forneceu a perda de sessão.
A reconvergência do BGP forneceu a amplificação de atualizações.
A propagação pública forneceu o domínio de falha.

Chamar o atributo original de malformado apagaria o defeito do produto, a menos que evidências de pacote provem o contrário. Chamar o evento inteiro de apenas um bug de produto apagaria a decisão de expor uma interação incerta na internet ao vivo. Chamá-lo apenas de uma resposta severa do protocolo apagaria a implementação que gerou o UPDATE downstream malformado.

A descrição precisa é uma falha em cadeia com proprietários de controle distintos.

4. De um UPDATE corrompido a uma instabilidade de roteamento mais ampla

O BGP distribui alcançabilidade entre sistemas autônomos. Quando uma sessão de peering fecha, rotas aprendidas exclusivamente ou preferencialmente por meio dessa sessão podem ser retiradas da tabela de roteamento local. O roteador pode selecionar alternativas e anunciar essas mudanças a outros peers. Esses peers então repetem seus próprios processos de seleção.

Isso significa que um erro associado a uma rota pode criar mudanças envolvendo muitas rotas se a resposta remover uma adjacência inteira. O prefixo experimental não precisava ser o destino procurado pelos usuários afetados. Uma reinicialização podia perturbar outra alcançabilidade aprendida na mesma sessão.

O volume de atualizações do evento é consistente com esse mecanismo de amplificação. O RIPE observou taxas de atualização até vinte vezes maiores que a linha de base ao redor.[1] Essa é uma medição do plano de controle: os roteadores estavam trocando substancialmente mais mudanças de roteamento. Ela não declara diretamente quanto tráfego de aplicação foi perdido, mas mostra que a perturbação se estendeu além de uma rejeição silenciosa de um único prefixo.

A restauração da sessão também podia criar recorrência. Se o roteador afetado upstream retivesse a rota e repetisse sua propagação defeituosa quando a sessão retornasse, o vizinho poderia encontrar novamente o UPDATE malformado. O ciclo resultante combinaria:

estabelecimento da sessão;
anúncio da rota;
corrupção durante a propagação;
recepção do UPDATE malformado;
fechamento da sessão;
retirada da rota e reconvergência; e
novo estabelecimento.

Nem todo peer ou caminho experimentou necessariamente cada etapa. As evidências sustentam um mecanismo quepoderiase repetir e observações de instabilidade elevada; elas não fornecem um registro completo pacote por pacote para cada sistema autônomo.

Essa distinção importa ao atribuir impacto. Um coletor de rotas vê anúncios e retiradas em seu ponto de observação. Ele não vê cada decisão de encaminhamento, cada sessão de usuário ou cada pacote descartado. Coletores diferentes veem fatias diferentes do sistema de roteamento. A atividade especialmente intensa no coletor de Viena ilustra que o efeito foi desigual.[1]

A desigualdade não é uma falha na medição. É uma propriedade da topologia e das políticas da internet. Os sistemas autônomos escolhem rotas localmente. Eles têm peers, software, filtros e alternativas diferentes. Um anúncio defeituoso pode passar por um caminho, ser bloqueado em outro e nunca ser selecionado em um terceiro.

O movimento analítico correto, portanto, não é extrapolar o pico de um coletor para toda a internet. É combinar coletores, descrever a distribuição e preservar os limites da inferência.

5. Impacto limitado: o que as evidências sustentam

As medições do RIPE fornecem três indicadores principais.

Primeiro, as taxas de atualização de roteamento alcançaram até vinte vezes a linha de base ao redor.[1] Isso demonstra atividade excepcional do plano de controle durante a janela do evento. A expressão “até” importa: ela descreve um pico, não uma taxa uniforme em todos os coletores ou durante todo o período.

Segundo, o RIPE estimou que 0,5% adicionais dos prefixos ficaram completamente inalcançáveis por mais tempo que o normal.[1] Essa é uma medida de visibilidade no nível do prefixo. Ela não deve ser traduzida em 0,5% dos usuários, do tráfego, dos roteadores ou da atividade econômica. Os prefixos variam muito em tamanho, uso e tráfego, e os coletores de rotas não observam todos os caminhos de encaminhamento.

Terceiro, a parcela de prefixos instáveis atingiu o pico de 1,4%. O RIPE associou esse pico a quase 4.500 prefixos, cerca de nove vezes o nível usual.[1] “Instável” não é idêntico a “universalmente inalcançável”. Um prefixo pode sofrer mudanças repetidas de caminho e permanecer alcançável em alguns lugares.

Essas constatações sustentam a conclusão de que o evento causou instabilidade de roteamento material, mensurável e distribuída. Elas não sustentam uma afirmação de que 1,4% da internet ficou totalmente offline.

Uma abreviação contemporânea de que o evento afetou aproximadamente um por cento da internet pode capturar a ordem de grandeza de algumas medições, mas é menos precisa que os indicadores separados do RIPE. Ela não deve substituí-los. As evidências distinguem inalcançabilidade completa adicional, instabilidade observada e volume de atualizações.

Variação geográfica e entre coletores

Os efeitos variaram por localização e coletor. O coletor de Viena mostrou atividade de atualização especialmente alta.[1] A variação pode refletir topologia, seleção de peers, exposição a implementações afetadas e disponibilidade de caminhos alternativos.

A localização de um coletor não é um mapa direto do impacto do usuário naquela cidade ou país. Os pontos de observação BGP recebem rotas de peers participantes. Sua visão pode incluir caminhos que atendem redes remotas, e usuários locais podem seguir caminhos não visíveis ao coletor. A evidência do coletor é forte para comportamento de roteamento e mais fraca para atribuir uma contagem geográfica de pessoas afetadas.

Observações de DNS

O RIPE usou o DNSMON para examinar se a perturbação de roteamento produziu efeitos visíveis no DNS. Ele não encontrou falha no sistema de servidores raiz.[1] Essa constatação negativa é importante porque instabilidade ampla de roteamento não implica automaticamente falha de todos os serviços críticos.

A análise observou perda limitada de consultas para alguns domínios monitorados e dificuldade mais perceptível em partes da infraestrutura autoritativa.si e.fr. Servidores redundantes continuaram respondendo.[1] As evidências, portanto, sustentam efeitos de DNS parciais e desiguais, não falha universal de DNS.

A disponibilidade contínua de servidores redundantes também lembra que a responsabilidade de roteamento inclui arquitetura de serviço. Uma perturbação de roteamento pode atingir um caminho de servidor autoritativo enquanto outro permanece alcançável. A redundância não elimina o defeito de roteamento, mas pode impedir que uma falha de componente se torne falha completa do serviço.

Relatos de operadores

Fóruns operacionais contemporâneos registraram relatos de interrupção de acesso, reações de roteamento e mudanças de tráfego.[4][6] Esses relatos ajudam a estabelecer que o incidente era visível fora das instituições iniciadoras. Eles também podem identificar questões para investigação adicional.

Eles não substituem a medição normalizada. Uma queda de tráfego em uma troca ou operadora pode refletir redirecionamento, perda, mudanças de política por precaução ou outra resposta local. Sem linhas de base, topologia e registros de tráfego compatíveis, isso não pode ser convertido em um número de impacto total da internet.

Alegações que as evidências não sustentam

O registro limitado não estabelece:

uma lista completa das versões do IOS XR afetadas conforme implantadas na época;
um número exato de roteadores ou dispositivos afetados;
todos os sistemas autônomos que reinicializaram uma sessão;
um número exato de usuários afetados;
o tráfego total de aplicação perdido;
falha universal do prefixo experimental;
falha da raiz do DNS;
intenção maliciosa do RIPE NCC, da Duke, da Cisco ou dos operadores;
um relato completo de todas as aprovações pré-evento;
que todos os operadores tinham uma mitigação disponível antes do evento; ou
responsabilidade legal.

Essas não são isenções menores. Elas definem a diferença entre uma reportagem de infraestrutura baseada em evidências e uma história de interrupção construída a partir de multiplicação não sustentada.

6. Responsabilidade por meio da alocação de controle

A responsabilidade é mais forte quando pergunta quem controlou cada decisão, implementação e ação de recuperação consequente. Ela fica mais fraca quando trata a proximidade do primeiro evento visível como prova de responsabilidade única.

Domínio de controle	O que o participante controlava	O que o participante não controlava	Evidências necessárias para uma avaliação mais forte
RIPE NCC	Uso da infraestrutura do RIS, originação visível na internet, momento, comunicação, monitoramento, retirada, retenção de evidências e política de experimento futuro	Comportamento do software em cada roteador externo e a recuperação de cada operador	Registro de aprovação, avaliação de risco, plano de aviso, limites de monitoramento, critérios de retirada e observações retidas
Pesquisadores da Duke	Desenho da pesquisa, construção do atributo experimental, mudanças no Quagga do lado da pesquisa e testes do lado da pesquisa	Código IOS XR implantado, políticas de sessão downstream e implantação de software do operador	Vetores de teste, bytes de UPDATE gerados, registros de implementação da pesquisa e escopo dos testes de interoperabilidade
Cisco	Comportamento de análise, armazenamento e propagação do IOS XR; cobertura de testes do produto; divulgação; correções de manutenção	A decisão de originar o experimento e os cronogramas de instalação dos operadores	Análise do defeito, matriz de versões afetadas, resultados de regressão, evidências do código corrigido e orientação de implantação
Operadores de rede	Software instalado, manutenção, política de importação e exportação, controles de peer, filtragem, monitoramento e restauração dentro de suas redes	Desenho experimental, código do fornecedor upstream e o caminho completo de propagação global	Logs de dispositivos, capturas de pacotes, configurações, versões de software, histórico de sessões e registros de restauração
Implementações BGP downstream	Tratamento local do UPDATE malformado segundo as regras que implementavam	A criação do atributo válido original ou a corrupção upstream	Logs de erro de UPDATE, notificações de sessão e prova de tratamento mais restrito onde suportado
Trocas de internet	Conectividade por meio da qual as redes participantes trocavam rotas	Por padrão, o conteúdo e a correção do anúncio BGP de cada participante	Evidências de qualquer papel específico de route-server, filtragem ou função operacional antes de atribuir mais controle

O controle do RIPE NCC

O RIPE NCC controlou o ato que introduziu a rota experimental na propagação pública. O RIS AS12654 foi a origem usada para o teste, e o anúncio percorreu as conexões do RIPE NCC na AMS-IX e na GN-IX.[1] O RIPE NCC também controlou a retirada planejada, sua coleta de evidências e suas regras futuras para pesquisas cooperativas semelhantes.

Esse controle estabelece responsabilidade de governança do experimento. Ele não estabelece que o RIPE NCC criou o defeito do produto. O atributo iniciador foi descrito como válido. A pergunta relevante para o RIPE NCC não é se ele deveria ter previsto a falha exata não documentada com certeza. É se a incerteza do experimento foi avaliada, comunicada, monitorada e contida em proporção ao seu possível alcance público.

O compromisso posterior com avaliação de impacto mais abrangente, aviso prévio ao operador e tratamento responsável de vulnerabilidades indica que o próprio RIPE NCC identificou melhorias de governança.[1] O apoio do Conselho Executivo à continuidade da experimentação com comunicação apropriada reforça uma distinção entre a legitimidade da pesquisa e a adequação de seus controles operacionais.[5]

O controle da Duke

Os pesquisadores da Duke controlaram o desenho da pesquisa de roteamento seguro e forneceram a modificação do Quagga usada dentro de seu escopo. Seu trabalho ajudou a criar a entrada experimental válida. O registro disponível não mostra que eles controlaram o tratamento interno do IOS XR ou a resposta de erro dos roteadores downstream.

A responsabilidade do lado da pesquisa diz respeito aos pressupostos de desenho e à amplitude dos testes de interoperabilidade. Uma segunda instância Quagga pôde demonstrar comportamento em um ambiente de software semelhante. Não pôde estabelecer segurança em todas as implementações implantadas relevantes.

As evidências públicas não revelam a divisão completa das decisões pré-evento entre a Duke e o RIPE NCC. Seria impróprio inventar uma. Qualquer atribuição mais granular exigiria planos de experimento, registros de teste e comunicações que identifiquem quem aprovou as condições de propagação pública.

O controle da Cisco

A Cisco controlou a implementação afetada do IOS XR. Seu aviso identificou corrupção de um atributo transitivo válido não reconhecido durante a propagação.[2] Esse comportamento se situa dentro do domínio de controle do produto: análise, retenção, serialização, tratamento de flags de atributos e testes de regressão.

A Cisco também controlou sua divulgação e resposta de manutenção. O aviso apareceu no dia do incidente, e atualizações de manutenção de software foram preparadas.[2] O CVE-2010-3035 fornece o identificador público de vulnerabilidade.[3]

A responsabilidade do produto ainda deve permanecer baseada em evidências. O registro não estabelece todas as versões implantadas, o número de dispositivos afetados ou se o defeito havia sido descoberto antes. Uma avaliação mais forte exigiria testes específicos por versão, histórico do defeito e evidências de instalação.

O controle dos operadores

Cada operador de rede controlava uma porção local do sistema: seleção e instalação de software, momento da manutenção, política de peering, filtros, monitoramento, proteção de sessão e restauração. Esses controles podiam afetar a exposição e a recuperação.

Isso não torna os operadores responsáveis por prever um defeito de corrupção desconhecido do fornecedor. Nem mostra que todos os operadores tinham um patch ou mitigação de configuração disponível antes do experimento. A responsabilidade do operador é condicional ao que era conhecível e controlável no momento relevante.

Após a divulgação, as evidências exigidas para garantia contínua mudam. Pode-se pedir aos operadores que identifiquem versões afetadas, apliquem correções, testem o comportamento e retenham provas. Antes da divulgação, alegações sobre inação irrazoável exigiriam evidências de que um risco e uma mitigação viável já eram conhecidos.

Por que as trocas não devem receber um papel inventado

O experimento usou conexões na AMS-IX e na GN-IX.[1] Esse fato estabelece um caminho de propagação. Ele não estabelece, sem evidências adicionais, que qualquer troca desenhou o experimento, aprovou o atributo, operou um roteador afetado ou controlou as políticas de exportação dos participantes.

A reportagem de infraestrutura frequentemente confunde trânsito físico ou lógico com autoridade de decisão. Uma troca nomeada pode fazer parte do caminho da rota sem ser o ator que originou, corrompeu ou aceitou o UPDATE. A responsabilidade não deve ser inferida apenas da topologia.

7. Reparo do produto e reparo da governança do experimento são diferentes

Uma resposta completa exigiu duas trilhas de reparo.

Reparo do produto

O defeito do produto foi a corrupção de um atributo transitivo válido não reconhecido durante a propagação pelos sistemas IOS XR afetados. O reparo direto pertencia ao software e a seus testes.

Um reparo de produto confiável demonstraria que:

um atributo transitivo opcional desconhecido válido pode ser recebido;
ele é armazenado sem mutação destrutiva;
ele é propagado na forma exigida pelo protocolo;
as flags de atributo e os campos de comprimento relevantes permanecem consistentes;
o estabelecimento repetido da sessão não recria a corrupção;
variantes malformadas são contidas de acordo com o comportamento de tratamento de erros suportado;
os testes de regressão cobrem tanto o reconhecimento quanto os caminhos de propagação opaca; e
a versão corrigida é identificável pelos operadores.

O aviso e as atualizações de manutenção da Cisco foram as ações públicas imediatas que trataram dessa camada.[2] Um aviso comunica o defeito; uma atualização altera a implementação. Os dois estão relacionados, mas não são intercambiáveis.

A verificação também exige evidências de implantação. Um fornecedor pode provar que uma compilação corrigida passa nos testes de regressão, enquanto um operador pode provar qual compilação está em execução em um roteador específico. Nenhum registro isolado estabelece tanto a correção do produto quanto a adoção em campo.

Reparo da governança do experimento

O defeito de governança não foi a ocorrência da pesquisa. Foi o fato de uma interação incerta ter sido testada por meio da infraestrutura pública de roteamento sem controles suficientes para prevenir ou limitar rapidamente o raio de impacto observado.

A resposta do RIPE NCC identificou requisitos futuros mais rígidos: avaliação de impacto abrangente, aviso prévio suficiente para os operadores e tratamento responsável de vulnerabilidades.[1] Eles tratam de decisões tomadas antes e durante um experimento.

Um reparo de governança confiável incluiria:

um objetivo técnico claramente delimitado;
identificação de cada atributo e rota a serem originados;
uma fronteira de propagação documentada ou explicação de por que a propagação mais ampla é necessária;
testes de implementação heterogênea apropriados ao risco;
comunicação prévia aos operadores afetados quando viável;
uma janela de teste definida;
observação em tempo real do coletor de rotas;
sondas de plano de dados ou de serviço quando relevantes;
critérios quantitativos de interrupção;
uma pessoa autorizada capaz de retirar imediatamente;
um procedimento de retirada ensaiado;
critérios para contatar fornecedores;
dados preservados pré-evento e pós-evento; e
um relato público de incidente quando ocorrer impacto externo não intencional.

Controles de governança não podem garantir que um defeito desconhecido nunca aparecerá. Seu propósito é reduzir a probabilidade de que a descoberta produza consequências externas descontroladas e encurtar o tempo entre detecção e contenção.

Por que um reparo não pode substituir o outro

Se a Cisco corrigisse o IOS XR, mas os controles do experimento permanecessem inalterados, um experimento posterior poderia expor um defeito desconhecido diferente em outra implementação. O risco específico do produto diminuiria, enquanto o risco de descoberta permaneceria.

Se o RIPE NCC fortalecesse os controles do experimento, mas o software afetado permanecesse sem correção, o tráfego comum da internet carregando outro atributo transitivo não familiar válido ainda poderia encontrar o defeito latente. O risco de teste público diminuiria, enquanto o risco do produto permaneceria.

O evento, portanto, exige duas perguntas independentes de encerramento:

O defeito de implementação está corrigido e implantado onde relevante?
Os futuros experimentos ao vivo estão limitados, observáveis e governados de uma maneira compatível com sua incerteza?

Um relatório que responde apenas uma delas não demonstrou reparo completo.

8. Padrões posteriores como contexto analítico — não julgamento retroativo

Padrões publicados depois de agosto de 2010 ajudam a descrever melhores práticas de contenção e política. Eles não provam que essas práticas estavam implantadas durante o evento e não podem converter retroativamente recomendações posteriores em uma constatação de negligência.

RFC 4271: a linha de base histórica

A RFC 4271 descreve o BGP-4, incluindo atributos transitivos opcionais e tratamento de erros.[12] Suas regras de propagação explicam por que um atributo transitivo não reconhecido deve ser transportado adiante. Seu tratamento de erros de UPDATE também ajuda a explicar por que um atributo malformado podia levar ao encerramento da sessão.

Essa combinação produziu uma interação perigosa. A extensibilidade dependia de propagação opaca segura, enquanto entradas malformadas podiam ativar uma resposta ampla. Quando uma implementação intermediária corrompeu informações opacas, o sistema downstream enfrentou uma condição de erro com consequências maiores que a de uma única rota.

RFC 7606: estreitando o domínio de falha

A RFC 7606 revisou posteriormente o tratamento de erros de UPDATE do BGP porque a reinicialização da sessão pode descartar grandes números de rotas válidas e causar perturbação substancial de roteamento.[13] Ela promove, em geral, respostas mais estreitas, incluindo tratar as rotas afetadas como retiradas em casos definidos, em vez de destruir automaticamente a sessão inteira.

Aplicada como contexto analítico, isso mostra como o domínio de falha pode ser reduzido. Se um anúncio malformado puder ser contido na rota afetada enquanto a sessão e as rotas não relacionadas permanecem, um atributo corrompido tem menos poder para desestabilizar uma adjacência.

Seria impreciso dizer que a RFC 7606 era a regra que governava o evento de 2010. Ela foi publicada depois. Também seria impreciso supor que toda implementação atual aplica cada recomendação de modo uniforme. A RFC explica uma direção de reparo arquitetural; evidências de implantação ainda são necessárias.

RFC 7454 e RFC 8212: política externa explícita

A RFC 7454 reúne recomendações de segurança operacional para BGP, enquanto a RFC 8212 estabelece uma expectativa de política explícita para anúncios e aceitação de BGP externo.[14][15] Juntas, elas reforçam um princípio básico de controle: rotas externas não devem ser trocadas apenas porque uma sessão existe.

Políticas explícitas de importação e exportação podem reduzir a propagação acidental e tornar as relações pretendidas auditáveis. Em um experimento limitado, uma política cuidadosamente delimitada poderia ajudar a limitar quais peers recebem uma rota de teste.

Essas medidas não corrigem diretamente um roteador que corrompe um atributo que é obrigado a propagar. Elas operam na fronteira da política, não dentro do caminho defeituoso de serialização. Elas podem reduzir a exposição, mas apenas se a rota ou a sessão puder ser distinguida e restringida sem derrotar o objetivo legítimo do experimento.

RFC 7908: taxonomia de vazamento de rota

A RFC 7908 descreve tipos de vazamentos de rota.[16] Ela é útil aqui principalmente como fronteira contra terminologia frouxa. O evento de 2010 envolveu uma rota experimental originada intencionalmente e um defeito de implementação que afetou um atributo transitivo opcional. As evidências disponíveis não devem ser esticadas para colocá-lo em uma categoria de vazamento posterior sem corresponder às condições da categoria.

A taxonomia apoia a responsabilidade quando impede que mecanismos não relacionados sejam fundidos. Ela a enfraquece quando um rótulo familiar substitui a análise causal.

Validação de origem RPKI

A RFC 6480 descreve a arquitetura da Infraestrutura de Chave Pública de Recursos, e a RFC 6811 define a validação de origem de prefixo BGP.[17][18] A validação de origem pergunta se um sistema autônomo de origem é autorizado por uma Route Origin Authorization relevante para um prefixo.

Esse controle trata de uma pergunta diferente da exposta aqui. Uma rota pode ter uma relação de origem aceitável enquanto carrega um atributo que um produto intermediário corrompe mais tarde. A validação de origem não prova que todos os atributos de caminho estão codificados ou preservados corretamente.

Nenhuma conclusão sobre o estado real de RPKI do experimento é necessária. O ponto analítico é limitado: a validação de origem, por si só, não testaria o caminho de manipulação de saída afetado.

BGPsec

A RFC 8205 especifica a validação de caminho BGPsec.[19] O BGPsec trata da proteção criptográfica de informações de caminho em uma arquitetura definida. Ele está relacionado ao objetivo mais amplo de roteamento seguro estudado pelo grupo da Duke, mas não é evidência sobre o que estava implantado durante este experimento de 2010.

Nem deve ser apresentado como correção automática para todo defeito de implementação. Os mecanismos de segurança são eles próprios implementados em software. Análise segura, serialização, contenção de falhas e testes de interoperabilidade continuam necessários.

Orientação de segurança de roteamento do NIST

A NIST SP 800-189 fornece orientação posterior para proteger a troca de tráfego interdomínio, incluindo proteções de roteamento e práticas operacionais.[20] Ela é útil para estruturar expectativas atuais em torno de filtragem, monitoramento, validação e resposta.

Ela não estabelece um dever legal de 2010 nem prova o que qualquer participante sabia na época. Seu uso adequado é prospectivo: perguntar quais evidências uma rede deve agora reter e quais controles podem reduzir cadeias de falha semelhantes.

9. Contrafactuais: qual fato alterado teria reduzido o impacto?

A análise contrafactual é útil apenas quando cada cenário altera uma condição definida e preserva o restante das evidências. Ela não pode provar o que certamente teria acontecido, mas pode identificar controles de alto valor.

Contrafactual 1: o IOS XR preserva o atributo corretamente

Altere um fato: os sistemas IOS XR afetados recebem o atributo transitivo válido não reconhecido e o propagam sem corrupção.

O UPDATE malformado downstream não surge desse caminho de produto. O mecanismo de reinicialização de sessão atribuído ao UPDATE corrompido, portanto, não é ativado por esse defeito. O anúncio permanece incomum e experimental, mas a cadeia de falha documentada é interrompida em seu principal ponto de implementação.

Este é o contrafactual de produto mais forte porque remove o mecanismo de corrupção identificado. Ele não prova que nenhuma outra implementação teria reagido mal.

Contrafactual 2: testes heterogêneos reproduzem o comportamento implantado

Altere um fato: os testes pré-públicos incluem uma implementação afetada suficientemente representativa e acionam a corrupção de saída.

O defeito pode ser investigado antes de a rota entrar na propagação pública ampla. A Cisco pode receber o caso de teste, enquanto o RIPE NCC e a Duke podem decidir adiar, restringir ou redesenhar o experimento.

A limitação é a representatividade. Nenhum laboratório pode reproduzir todos os caminhos da internet. O valor está em expandir além de dois endpoints Quagga semelhantes e testar especificamente o comportamento de recebimento e propagação opaca entre implementações distintas.

Contrafactual 3: o experimento é conduzido em um ambiente de roteamento limitado

Altere um fato: o mesmo atributo e o software afetado interagem em um ambiente de teste fechado ou estritamente controlado, em vez de na propagação pública comum.

O defeito ainda pode reinicializar uma sessão, mas o número de rotas não relacionadas e redes externas expostas pode ser limitado. Evidências podem ser capturadas em cada salto.

A limitação é o realismo. Um ambiente limitado pode não reproduzir topologia, política ou combinações de software encontradas na internet pública. É por isso que a escalada em etapas é preferível: comece com diversidade limitada e amplie apenas quando o risco e as evidências justificarem.

Contrafactual 4: roteadores downstream usam tratamento de erro de UPDATE mais estreito

Altere um fato: um roteador downstream contém o anúncio malformado sem fechar toda a sessão BGP, onde uma resposta estreita de estilo posterior é aplicável.

A rota experimental pode ser descartada, mas rotas válidas não relacionadas aprendidas pela sessão permanecem disponíveis. A amplificação de atualizações e a pressão de reconvergência devem ser materialmente menores.

Este contrafactual reflete a direção formalizada posteriormente na RFC 7606.[13] Ele deve permanecer analítico porque essa RFC é posterior ao evento, e o tratamento exato depende da classe de erro e da implementação.

Contrafactual 5: aviso prévio alcança os operadores afetados

Altere um fato: os operadores recebem aviso técnico suficiente do prefixo, do atributo, da janela, do comportamento esperado e das condições de interrupção.

Alguns operadores podem monitorar sessões relevantes mais de perto, preparar equipes, restringir a exposição ou coordenar rapidamente após o aparecimento de anomalias. O diagnóstico pode acelerar porque a rota é reconhecida como um experimento, e não como um evento inexplicado.

O aviso não repara o IOS XR. Ele também pode exigir tratamento cuidadoso de vulnerabilidades se um teste deverá expor comportamento inseguro. A comunicação é, portanto, uma mitigação e um controle de coordenação, não um mecanismo completo de contenção.

Contrafactual 6: critérios quantitativos de interrupção acionam uma retirada antecipada

Altere um fato: o monitoramento identifica taxas de atualização anormais ou reinicializações de sessão cedo o suficiente para cruzar um limite de parada predefinido antes das 09:08 UTC.

O RIPE NCC retira mais cedo. A originação contínua termina mais cedo, potencialmente reduzindo repetições e tempo de exposição.

A limitação é o estado distribuído do BGP. Atualizações já propagadas ainda exigiriam retirada e reconvergência. A ação antecipada poderia reduzir a duração, mas não restauraria instantaneamente todos os caminhos afetados.

Contrafactual 7: a política limita a propagação a peers selecionados

Altere um fato: políticas de importação e exportação restringem a rota experimental a redes explicitamente participantes.

O domínio de falha diminui, e os operadores participantes podem capturar evidências. Isso se alinha com a ênfase posterior em política externa explícita.[14][15]

A limitação é a pergunta de pesquisa. Se o objetivo exige observar implementações públicas diversas, a contenção estrita muda o que pode ser aprendido. Essa compensação deve ser feita explicitamente, e não assumida como inexistente.

Contrafactual 8: coletores de rota e sondas de serviço fornecem alarmes correlacionados imediatos

Altere um fato: observações do plano de controle, telemetria de sessão e sondas de serviço relevantes são correlacionadas em tempo real.

Os investigadores podem distinguir mais cedo um anúncio novo inofensivo da amplificação de atualizações, da invisibilidade de prefixos e dos efeitos de serviço. A decisão de retirada se torna orientada por evidências.

Isso não impede a primeira corrupção. Melhora a detecção e encurta o intervalo em que a incerteza persiste.

Contrafactual 9: o experimento nunca ocorre

Altere um fato: nenhum anúncio público é feito.

O gatilho de 27 de agosto desaparece, então este evento não expõe o defeito. A falha do produto, no entanto, pode permanecer latente e ser ativada mais tarde por outro atributo válido não familiar.

Este contrafactual esclarece por que “não experimentar” não é uma estratégia de segurança suficiente. Evitar o teste evita este incidente, mas não corrige o software em execução. O objetivo melhor é a descoberta segura: experimentos limitados combinados com reparo do produto.

10. Como seria um reparo verificável

Uma alegação de reparo deve estar ligada a artefatos e observações, não a garantias.

Evidências do produto

Para a implementação afetada, evidências confiáveis incluiriam:

as versões exatas de software corrigidas;
uma descrição do fornecedor sobre o caminho de manipulação defeituoso em um nível apropriado de detalhe;
testes de regressão usando atributos transitivos opcionais desconhecidos válidos;
testes mostrando propagação que preserva bytes ou de outro modo conforme;
testes usando variantes malformadas ou deliberadamente corrompidas;
evidências de que o tratamento de erro estreito suportado preserva rotas não relacionadas onde aplicável;
testes repetidos de ciclos de sessão para detectar recorrência;
registros do operador identificando versões instaladas; e
observações pós-instalação mostrando que o defeito não é mais reproduzido.

O CVE e o aviso públicos identificam o problema e a resposta.[2][3] Eles são o começo da verificabilidade, não a prova completa do encerramento em campo.

Evidências do experimento

Para um futuro experimento de roteamento ao vivo, evidências confiáveis incluiriam:

o prefixo de teste e a origem;
a codificação do atributo proposto;
peers participantes e escopo pretendido de propagação;
resultados de interoperabilidade entre implementações materialmente diferentes;
uma avaliação de impacto cobrindo consequências de plano de controle e de serviço;
um registro de aviso prévio;
limites quantitativos de interrupção;
uma autoridade de retirada imediata;
um ensaio de retirada;
monitoramento ao vivo do coletor;
verificações relevantes de plano de dados ou serviço;
carimbos de data e hora para anomalias e decisões;
dados de UPDATE preservados; e
um relato pós-evento comparando comportamento esperado e observado.

O RIS e o Route Views ilustram o valor de múltiplos pontos de observação de roteamento.[7][11] Eles não substituem logs de dispositivos ou capturas de pacotes, mas podem mostrar de forma independente se um anúncio se propagou, se as retiradas se multiplicaram e se os efeitos diferiram por ponto de observação.

Evidências do operador

Um operador que afirma que sua rede está protegida deve ser capaz de mostrar:

se o software IOS XR afetado está ou esteve presente;
qual versão corretiva está instalada;
como a política de rota externa é definida;
como UPDATEs malformados são tratados pelo software atual;
como reinicializações de sessão são detectadas;
como a perda de rotas não relacionadas é medida;
quais proteções de peer estão ativadas;
como as decisões de restauração são registradas; e
se um teste de regressão controlado foi concluído.

Isso é continuidade operacional em forma concreta. Uma declaração de configuração sem evidência de versão em execução é incompleta. Uma versão de software sem evidência de política e observação também é incompleta.

Critérios de encerramento

O evento pode ser considerado tecnicamente compreendido quando os bytes originais, a mutação intermediária e a resposta downstream estiverem ligados por evidências. A questão do produto pode ser considerada reparada quando o software corrigido passar nos testes de regressão relevantes e a implantação for demonstrada onde exigida. A questão de governança pode ser considerada reparada quando um experimento futuro não puder prosseguir sem escopo, aviso, monitoramento, autoridade de interrupção e retenção documentados.

Esses critérios de encerramento são intencionalmente separados. Um relatório público de incidente deve declarar quais estão satisfeitos e quais permanecem desconhecidos.

11. Evidências que alterariam a conclusão

A conclusão atual depende de evidências. Várias descobertas exigiriam revisão material.

Capturas de pacotes mostrando que o atributo inicial era malformado

Se capturas autoritativas demonstrassem que o RIS AS12654 originou um atributo malformado antes de alcançar um sistema IOS XR afetado, a constatação de que uma entrada válida foi corrompida pela primeira vez durante a propagação teria de mudar.

A responsabilidade se deslocaria para a geração e a validação pré-anúncio, embora qualquer mutação ou amplificação adicional ainda exigisse análise separada. O requisito essencial seria a comparação de bytes de ponta a ponta: o que a origem transmitiu, o que cada sistema intermediário recebeu e o que emitiu.

Logs de dispositivos identificando um ponto de corrupção diferente

Se logs ou capturas mostrassem que outra implementação, route server ou intermediário criou a corrupção, a atribuição do produto precisaria de revisão. Um aviso da Cisco pode identificar um defeito real sem provar que o mesmo defeito explica todos os caminhos observados.

O evento pode ter contido mais de um modo de falha. Somente evidências específicas de caminho podem estabelecer se todas as reinicializações compartilharam um ponto de corrupção.

Dados do coletor revisando materialmente as estimativas de impacto

Se os dados preservados do coletor mostrassem que a linha de base, a contagem de prefixos afetados ou a duração era materialmente diferente, a avaliação de impacto limitado deveria ser atualizada. As correções poderiam aumentar ou diminuir o escopo medido.

Uma revisão não mudaria automaticamente o mecanismo de implementação. Causa e magnitude são perguntas de evidência relacionadas, mas independentes.

Registros de aprovação e risco mostrando controles adicionais

Se registros completos do experimento mostrassem controles substanciais de contenção, notificação ou interrupção não visíveis no relato público, a avaliação de governança deveria reconhecê-los. Ela precisaria então explicar por que esses controles não impediram ou encurtaram a perturbação observada.

Inversamente, registros mostrando que riscos de alto impacto identificados foram aceitos sem mitigação fortaleceriam a crítica de governança. O relato público sozinho não estabelece nenhum dos cenários.

Registros do produto mostrando identificação prévia e controle eficaz

Se registros de teste do produto demonstrassem que o defeito havia sido identificado e controlado de forma eficaz antes do experimento, a linha do tempo e a alocação de responsabilidade mudariam. Os investigadores precisariam perguntar se os sistemas implantados afetados não tinham correção disponível, se os operadores haviam recebido aviso aplicável e se o comportamento observado veio de outro mecanismo.

O registro atual não estabelece tal identificação prévia.

Evidências de impacto de serviço mais amplo ou mais restrito

Medições completas de tráfego, logs de operadores ou telemetria de serviço poderiam melhorar a avaliação das consequências visíveis ao usuário. Elas poderiam mostrar que a instabilidade do plano de controle causou mais interrupção de aplicação do que o atualmente documentado, ou que a redundância manteve a maioria dos serviços disponíveis apesar da agitação de roteamento.

Tais evidências mudariam a seção de impacto, mas não justificariam reescrever a validade do UPDATE original sem prova em nível de pacote.

12. Uma conclusão contida

O experimento RIPE-Duke de 2010 não foi um sequestro de rota malicioso convencional, e as evidências disponíveis não sustentam retratá-lo como tal. Tampouco foi simplesmente um teste de padrões inofensivo que por acaso encontrou roteadores irracionais.

Foi um experimento de roteamento ao vivo em que um atributo transitivo opcional válido e não familiar encontrou uma implementação IOS XR afetada. Essa implementação corrompeu o atributo ao propagá-lo. Um roteador downstream pôde então responder ao UPDATE malformado reinicializando uma sessão BGP, retirando rotas válidas não relacionadas e contribuindo para reconvergências repetidas. As medições do RIPE capturaram uma perturbação limitada, porém material: taxas de atualização excepcionais, invisibilidade adicional de prefixos e um pico de quase 4.500 prefixos instáveis.[1][2]

O evento expôs dois defeitos em domínios de controle diferentes. Um foi um defeito de produto no tratamento de informações de roteamento opacas válidas. O outro foi uma fraqueza de governança do experimento: testes pré-públicos limitados e exposição pública insuficientemente delimitada permitiram que uma interação desconhecida se tornasse um incidente de roteamento da internet.

O aviso e as atualizações de manutenção da Cisco trataram do defeito do produto. A investigação, a preservação de evidências e os compromissos futuros mais rígidos do RIPE NCC trataram do defeito de governança. Padrões posteriores forneceram melhor contenção de erros e orientação de política, mas são contexto, não prova retroativa.

A lição mais durável é sobre controle. Conformidade com padrões na origem não garante comportamento seguro de ponta a ponta. Um registro ou coletor de rotas pode identificar quem anunciou um prefixo e mostrar como a visibilidade mudou, mas não pode forçar cada implementação intermediária a preservar um atributo corretamente. Os fornecedores devem provar código seguro em execução. Os iniciadores de experimentos devem limitar testes públicos incertos. Os operadores devem conhecer seu software, políticas e estado de recuperação.

Os sistemas de observação devem preservar evidências suficientes para distinguir gatilho, corrupção, amplificação e impacto.

A responsabilidade não é alcançada nomeando a primeira organização na cronologia. Ela é alcançada combinando cada controle consequente a um proprietário e exigindo evidências de que o reparo correspondente funciona.