Resumo

  • Em 27 de outubro de 1980, os IMPs da ARPANET aceitaram e retransmitiram repetidamente atualizações de rota com os números 8, 40 e 44: a comparação de seis bits fazia cada valor parecer mais novo que outro.
  • A reconstrução provável de Eric Rosen no RFC 789 aponta para uma retransmissão alterada por falha de hardware; o ciclo consumiu buffers, interrompeu as verificações dos enlaces e tornou a própria rede um canal lento para o patch de recuperação.

Acesso ativo, comunicação entre IMPs indisponível

Os primeiros sintomas não pareciam um simples cálculo incorreto de rotas. Algumas pessoas ainda conseguiam discar para um Terminal Interface Processor, ou TIP, mas recebiam “net trouble” ao tentar chegar a um computador ligado a outro Interface Message Processor (IMP). Conexões existentes eram interrompidas. O TIP podia responder à pessoa na linha telefônica enquanto o caminho entre IMPs não funcionava. Essa diferença ajudou a investigação a separar o acesso local da rede que conectava seus nós.

Eric C. Rosen reconstruiu o incidente no RFC 789, com base, entre outros elementos, em despejos de memória de vários IMPs. Os buffers estavam cheios de atualizações de roteamento à espera de processamento. Elas pareciam vir do IMP 50, que havia falhado pouco antes e já estava fora da rede durante a pane. O vizinho imediato, IMP 29, também apresentava defeitos de hardware e perdia bits. Reiniciar IMPs próximos não resolvia: quando voltavam à rede, recebiam novamente as mesmas atualizações de seus vizinhos.

Uma comparação que voltava ao início

Cada IMP enviava periodicamente informações de atraso e estado dos enlaces. As atualizações eram propagadas para que os nós mantivessem uma visão comum da rede. Cada uma carregava um número de sequência de seis bits, incrementado módulo 64. O receptor precisava decidir se a atualização recebida era posterior à última que havia aceitado daquele emissor.

A regra usava metade do espaço de valores para lidar com o retorno a zero: um número podia ser considerado posterior se avançasse até 32 posições ou se tivesse dado a volta e estivesse mais de 32 posições adiante no ciclo. Isso não é uma data nem um relógio. Para os valores observados, porém, produzia uma volta completa: 44 era posterior a 40, 40 era posterior a 8 e 8 era posterior a 44.

Os despejos mostravam filas com a sequência 8, 40, 44, seguida da mesma sequência outra vez. As atualizações eram iguais, exceto pelo número. Cada uma podia substituir outra como a informação “mais recente” e voltar a ser propagada pelos IMPs. A decisão de cada nó seguia a regra local. O ciclo só se tornou possível porque três valores que o processo normal de geração deveria manter separados passaram a coexistir.

Rosen não tratou a origem desses três números como comprovada. Sua hipótese mais provável era que uma atualização 44 havia sido recriada de dados armazenados para retransmissão, e que bits perdidos mudaram o campo primeiro para 40 e depois para 8. Os pacotes transmitidos tinham checksum; as tabelas internas usadas para reconstruir uma retransmissão não eram verificadas continuamente. Fazer isso gastaria CPU ou memória, recursos escassos na época. Rosen também considerou a hipótese inversa: 8 poderia ser o valor original e bits teriam sido acrescentados. O ciclo está nos despejos; o caminho exato da falha física continua sendo uma inferência.

O ciclo de rota virou escassez de recursos

O processamento das atualizações tinha prioridade alta. À medida que elas circulavam, consumiam processador e buffers. Os IMPs não conseguiam reservar buffers para as mensagens HELLO e I-HEARD-YOU, usadas pelos nós vizinhos para verificar se cada enlace estava funcionando. Sem essas trocas, o protocolo de estado de linha deixava de operar e o software declarava os enlaces indisponíveis. O tráfego de controle passou, assim, a alterar a topologia que os demais IMPs tentavam medir.

Por isso, “o roteamento escolheu uma rota errada” não corresponde ao diagnóstico de Rosen. Rotas e código continuavam consistentes com as regras definidas. A falha de hardware criou um estado inesperado; o processamento válido desse estado consumiu recursos demais sem contenção suficiente. O caso não prova um ataque nem descreve diretamente o roteamento da Internet atual. Ele mostra como dados corrompidos podem ser amplificados por retransmissões e transformar uma falha localizada em uma interrupção ampla.

A recuperação precisava atravessar a rede que falhava

Os operadores instalaram um patch nos IMPs para ignorar atualizações do IMP 50, embora ele já estivesse fora de serviço. Em condições normais, o Centro de Controle da Rede conseguia distribuir o patch em minutos. Durante a pane, o comando remoto a IMPs geralmente sem operadores no local podia levar três ou quatro horas, pois dependia da própria rede. O caminho de recuperação dependia da infraestrutura que precisava ser recuperada. O patch funcionou; Rosen não relatou dano duradouro além da interrupção.

Ele propôs mudar um limite da comparação LATER, reforçar a detecção e a correção de erros na próxima geração de hardware C30 e detectar quando um processo prioritário estivesse consumindo recursos demais, colocando o IMP em um estado ainda controlável à distância. Eram respostas em camadas: impedir o ciclo observado, perceber o erro físico e permitir a recuperação do nó. Nenhuma delas garantia que toda falha rara desapareceria.

Evidências e limites

Rosen publicou o relato na edição de janeiro de 1981 de SIGSOFT Software Engineering Notes e o distribuiu como RFC 789. É a fonte principal e separa observação de hipótese. O trabalho de McQuillan, Richer e Rosen, publicado em maio de 1980, documenta testes anteriores do novo algoritmo em operação. Não demonstra que a combinação excepcional de corrupção de tabela armazenada e ciclo de sequência tivesse sido testada. Uma nota comemorativa do Computer History Museum chama os valores de “marcas de tempo”; o RFC identifica números de sequência de seis bits.

Fontes: RFC 789; McQuillan, Richer e Rosen, “The New Routing Algorithm for the ARPANET”; registro de 27 de outubro do Computer History Museum; cópia digitalizada do artigo de 1980 hospedada na IPCOMPRO; a primazia do código em execução, de Heng Lu, citada apenas como lente editorial.