Resumo

  • A RFC 7474 combina 32 bits de boot count e 32 bits de contador de pacotes. A época fica em armazenamento não volátil; o contador inferior sobe a cada envio, e o receptor descarta qualquer valor que não supere o último aceito daquele tipo de pacote.
  • Acee Lindem editou o padrão coletivo com Manav Bhatia, Sam Hartman e Dacheng Zhang. O limite operacional é decisivo: perder a história persistente em reparo, upgrade ou troca de hardware exige novas chaves, e o rollover normal só é seguro quando os períodos de envio e aceitação realmente se sobrepõem.

O pacote autêntico que esperou o esquecimento

Imagine a captura de um OSPF Database Description protegido pela chave correta. O atacante não consegue alterar o conteúdo nem produzir um digest novo. Enquanto o receptor guarda uma sequência posterior, a gravação não vale nada. A adjacency cai, o processo reinicia e o estado ligado ao vizinho volta ao início. O pacote não ganhou legitimidade; o verificador perdeu a prova de que ele era antigo.

Esse é o corte tratado pela RFC 7474, publicada no Standards Track em abril de 2015. No mecanismo anterior, a sequência criptográfica fazia parte do estado da adjacency. Ao derrubá-la, também se podia reinicializar o contador, abrindo espaço para replay entre sessões apesar de o digest continuar correto.

O grupo completo de autores é Manav Bhatia, Sam Hartman, Dacheng Zhang e Acee Lindem, editor do texto. O perfil público da IETF confirma a participação de Lindem e um histórico amplo em routing. Não comprova invenção individual, domínio sobre OSPF ou conformidade de produto. O vínculo útil é específico: participação num padrão coletivo que fez a cronologia de segurança atravessar a falha que antes a apagava.

Um hash forte não responde se o pacote é atual

A RFC 5709 já havia acrescentado HMAC-SHA à autenticação do OSPFv2. Seus autores são Manav Bhatia, Vishwas Manral, Michael Fanto, Russ White, Michael Barnes, Tony Li e Randall Atkinson; Lindem não pertence a essa autoria. Um algoritmo melhor dificulta falsificação. Não faz um pacote produzido corretamente no passado envelhecer por conta própria.

A RFC 6039, de Vishwas Manral, Manav Bhatia, Joel Jaeggli e Russ White, descreve o problema maior de chaves manuais em protocolos de roteamento: segredos duradouros, rollover difícil, replay e contexto incompleto. Ela fornece o histórico da ameaça, sem atribuí-lo a Lindem.

“Authentication succeeded” prova a relação entre bytes e chave. Não prova que o pacote pertence a este boot, que veio do endereço usado para identificar o neighbor ou que a chave foi empregada no domínio OSPFv2. Integridade, freshness e contexto precisam aparecer como evidências separadas.

Um contador para a vida, outro para o instante

A RFC 7474 amplia a sequência para 64 bits. Os 32 bits superiores guardam o boot count; os inferiores, um contador estritamente crescente. A primeira metade identifica a época; a segunda localiza o pacote dentro dela.

O boot count deve permanecer em armazenamento não volátil durante toda a vida implantada do roteador OSPFv2. Sempre que o equipamento perde o estado anterior, inclusive num cold restart, incrementa esse valor. É permitido usar snmpEngineBoots, mas a RFC recomenda um contador próprio de OSPF para não acoplar reinicializações diferentes dos dois subsistemas.

O contador baixo aumenta a cada pacote enviado. O receptor exige um valor maior que o último aceito, daquele mesmo tipo de pacote, vindo do neighbor. Caso contrário, descarta por replay. A comparação por tipo preserva tráfego legítimo quando prioridade e fila mudam a ordem relativa entre Hello, Database Description e Link State Update.

Se a parte inferior der a volta, o boot count pode avançar para manter a sequência total monotônica. O reboot não é escondido; vira mudança autenticada de época que uma captura antiga não consegue ultrapassar.

Os oito octetos ficam depois do pacote OSPF e entram no digest. O Authentication type 3 identifica o formato, e o Key ID cresce para 32 bits. A época precisa estar autenticada; do contrário, justamente o dado que prova a idade poderia ser alterado.

O endereço de origem entra no cálculo

O cálculo anterior não cobria o header IPv4. Em redes broadcast e NBMA, porém, OSPF usa o endereço de origem para determinar o neighbor remetente. Uma captura com source trocado podia afetar o estado de sequência de outro neighbor sem romper o digest.

A RFC 7474 coloca o IPv4 source nos quatro primeiros octetos do padding usado pela RFC 5709. O transmissor usa o endereço que enviará; o receptor usa o recebido. A mudança passa a causar authentication failure, bloqueando reflexões capazes de simular comunicação one-way ou perturbar Database Description.

Não se trata de congelar todo o header. O padrão protege o campo que OSPF usa para atribuir identidade ao neighbor. É uma especificação mínima com motivo operacional explícito.

A chave ganha um domínio de protocolo

Bancos de chaves long-lived podem reutilizar o mesmo segredo em mais de um protocolo. Para reduzir replay cruzado, a RFC 7474 acrescenta um OSPFv2 Cryptographic Protocol ID de dois octetos à chave antes do hash. O material armazenado pode ser igual por decisão local, mas a chave efetiva agora declara o domínio OSPFv2.

Isso não torna bom o compartilhamento. Um segredo comprometido continua comprometido, e chaves independentes reduzem o blast radius. O identificador cria uma fronteira defensiva onde a infraestrutura compartilhada já existe.

Rollover é sobreposição, não um clique

Uma chave de transmissão só vale na SendLifetime; uma chave de recepção, na AcceptLifetime. A nova pode ser aceita antes de virar a escolhida para envio, e a antiga pode permanecer aceitável por um período curto após a mudança. A sobreposição oferece continuidade sem manter autorização antiga indefinidamente.

A seleção também combina algoritmo, peer ou area, interface e direction. Correspondência explícita supera all. Se várias chaves de envio continuarem válidas, vence aquela com início de envio mais recente. O Key ID do pacote leva o receptor ao segredo simétrico, mas ele ainda verifica escopo e período de aceitação.

O processo correto é distribuir a nova chave, abrir aceitação, mover envio, observar as duas pontas e só então fechar a antiga. “Duas chaves instaladas” não demonstra sobreposição, relógios coerentes ou qual delas foi realmente usada.

Incompatibilidade deve aparecer

O novo tipo não faz downgrade silencioso. Se o AuType recebido não coincide com o configurado na interface, o pacote é descartado. Uma implantação parcial pode impedir adjacency; ainda assim, é melhor que formar uma relação em que cada ponta atribui um significado diferente à freshness.

A unidade de migração inclui os dois lados: código, tipo, algoritmo, Key ID, segredo, lifetime e época. Sucesso é aceitação simétrica dos pacotes novos, rejeição da captura antiga, adjacency estável e forwarding observado—not apenas uma configuração salva.

Se a memória morreu, a chave também envelheceu

A regra mais dura aparece na manutenção. Se repair, upgrade ou replacement apaga o boot count não volátil, as chaves devem mudar. Restaurar Router ID, áreas, interfaces e o mesmo arquivo de segredos devolve a aparência administrativa, mas não o fato que separava os pacotes de hoje dos de ontem.

Uma chave velha ao lado de uma época reiniciada permite que capturas anteriores disputem o novo espaço baixo. Trocar equipamento é, portanto, evento de ciclo de vida criptográfico.

A RFC ainda registra limites. O replay de todo um estabelecimento idêntico de sessão para um router totalmente retirado permanece um cenário muito improvável; rekey também o bloqueia. Dois links ponto a ponto unnumbered com o mesmo source e uma sequência comum devem usar chaves diferentes sob ameaça de tap ativo. Automatic key management fica fora do escopo.

Regra comum pequena, custódia local grande

O texto posterior de Lu Heng Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption oferece a Sofia Ren uma lente: sequência, source autenticado, protocol ID, Key ID e rejeição podem ser comuns; geração, armazenamento, escopo, calendário, implantação e recuperação permanecem locais.

Running-Code Primacy eleva a prova. É preciso ligar boot count persistente, sequência emitida, chave escolhida, digest preso ao source, decisão do receptor, contadores de replay, adjacency e forwarding. Essa comparação é análise posterior de Sofia Ren, não intenção privada de Lindem nem intenção IETF fora das RFCs.

O invasor consegue guardar o passado por mais tempo que o roteador. A RFC 7474 exige que a rede reverta essa vantagem. Se o roteador não consegue provar a própria história, a chave antiga não pode autenticar a vida nova.

Fontes