Resumo

  • Na RFC 9986, o ISAAC entrega valores de autenticação em páginas de 256. Criar a próxima página é irreversível e destrói a atual.
  • Antes de cruzar esse limite para verificar um pacote, o receptor deve salvar o estado ISAAC completo. Se houver correspondência, adota o novo estado; se não houver, restaura o anterior.
  • O modo confirma a continuidade de um emissor autêntico numa sessão já Up, não a integridade de todo o pacote nem a saúde do serviço. A operação precisa comprovar tanto o commit quanto a restauração sem expor segredos.

Uma validação capaz de alterar aquilo que ainda julgava

BFD troca pacotes de controle em alta frequência para perceber rapidamente a falha de uma adjacência. Em equipamentos com poucos recursos criptográficos, aplicar o cálculo mais caro a cada mensagem pode comprometer justamente essa rapidez. A RFC 9985 separa, então, a autenticação forte das mudanças relevantes e um modo mais leve para manter uma sessão que já está Up.

A RFC 9986 define o Meticulous Keyed ISAAC para essa segunda tarefa. Um segredo compartilhado, uma Seed por sessão e material dos discriminadores BFD inicializam um fluxo pseudoaleatório. O ISAAC produz saídas de 32 bits em páginas de 256. Dentro da página, o receptor chega quase sem custo ao valor indicado pelo número de sequência. Depois do limite, a função de mistura cria a página seguinte.

O detalhe decisivo é que a criação não preserva a página antiga. Ela é irreversível. O pacote que aponta para a posição futura ainda não provou ser legítimo. Se o receptor avançar seu único estado apenas para fazer a comparação e a Auth Key estiver errada, rejeitar a mensagem não recupera o ponto de partida. A própria verificação consumiu o passado que deveria proteger.

Por isso a RFC 9986 exige a ordem inversa: se o cálculo puder gerar uma nova página, o receptor deve copiar todo o estado ISAAC antes de começar. Uma saída correspondente permite descartar a cópia e tornar a página nova oficial. Uma saída diferente exige restaurar o estado salvo; o candidato modificado é eliminado ou mantido separadamente para eventual uso posterior.

A decisão só se torna definitiva depois que o pacote ganha confiança.

A tolerância à perda tem uma cerca

Olhar adiante não significa necessariamente aceitar um ataque. Pacotes intermediários podem se perder. Como o número de sequência cresce a cada envio, a diferença observada indica quantas posições o receptor precisa avançar para testar a Auth Key correta. Uma correspondência permite resincronizar as pontas.

Essa busca, porém, não é ilimitada. Conhecido o último número, a RFC aceita do valor seguinte até três vezes Detect Mult à frente, tratando o campo de 32 bits como circular. Fora dessa janela, o pacote é descartado. Dentro dela, o receptor pode procurar a posição indicada — e essa posição pode cair na página seguinte.

Um registro que guarde somente “autenticou” ou “falhou” perde a estrutura do incidente. Deve registrar a sequência anterior e a recebida, Detect Mult, a janela derivada, base e índice da página e a necessidade de mistura. No sucesso, mostra checkpoint concluído antes da mistura, correspondência e adoção da nova base. Na falha, mostra checkpoint, divergência e retorno à mesma impressão digital opaca do estado anterior.

O estado bruto e a chave secreta ficam fora do registro público. Uma identificação não reconstruível, horários e resultados bastam. Evidência operacional não pode entregar a terceiros a capacidade de prever o próximo autenticador.

Emissor autêntico não significa conteúdo integralmente autenticado

O formato ISAAC transporta ID de chave, sequência, Seed e uma saída de 32 bits. Tipo, modo, comprimento, ID, faixa, Seed ou Auth Key incorretos provocam descarte.

Mas a saída não contém resumo nem hash do BFD Control Packet. A RFC 9986 afirma que o pacote, como um todo, permanece sem autenticação. A correspondência prova que somente a parte autêntica poderia produzir aquele sinal de continuidade; não garante a integridade de todos os campos.

Consequentemente, o modo barato só funciona numa sessão já Up e não pode anunciar mudança de estado. Transições e confirmações fortes periódicas usam o modo mais caro, com integridade completa. A divisão de autoridade da RFC 9985 já é tema de outro Artigo. Aqui, a questão exclusiva está dentro do verificador da RFC 9986: até uma checagem de continuidade permitida deve preservar o retorno antes de atravessar um estado de mão única.

O alcance do BFD também não deve crescer por conveniência. Up não demonstra que a aplicação responde, que a rota está correta, que o cliente alcança o serviço ou que uma carga percorreu o caminho fim a fim. É uma resposta sobre a sessão observada.

Um experimento que não esconde o compromisso

Ashesh Mishra assina a RFC 9986 com Alan DeKok, Mahesh Jethanandani, Sonal Agarwal e Jeffrey Haas. Ele também aparece no rascunho precursor de 2017, na RFC 9985 e numa patente anterior sobre otimização de verificações de integridade em BFD. O conjunto demonstra vínculo continuado com o problema, não autoria individual.

A RFC 9986 é Experimental, não um Internet Standard. O texto reconhece que o ISAAC teve análise criptográfica limitada. Ele foi escolhido para sistemas sem aceleração adequada; onde há suporte de hardware, não oferece vantagem, e a própria RFC o considera impróprio para outros protocolos IETF.

A distribuição das chaves fica fora do escopo. Não há procedimento para mudar o Auth Key ID no meio da sessão e sincronizar novamente; a rotação exige desativar e semear a sessão de novo. Chaves separadas para modos forte e leve limitam parte do risco de comprometimento, mas aumentam a chance de as duas pontas divergirem e a sessão cair na troca de modo.

Esses são controles locais, com responsáveis locais. A publicação de uma especificação comum não transfere para seus autores as decisões que continuam nas mãos do implementador e do operador.

Testar o depois da rejeição

O teste revelador injeta um pacote inválido logo além da fronteira da página, mas ainda dentro da janela de perda. O laboratório toma uma impressão privada do estado, envia uma Auth Key errada e observa a sequência: checkpoint completo, mistura, comparação negativa e restauração exata. Em seguida, envia o pacote legítimo esperado e comprova que ele continua aceitável.

O ensaio deve variar Seed, ID, modo e comprimento; saltos dentro e fora da janela; e a volta do contador de 32 bits. Também mede memória e latência do checkpoint, mistura, restauração e busca comum. Uma rajada de futuros inválidos não pode criar crescimento sem limite de CPU, memória ou estados candidatos.

O recibo público guarda build, sessão, ticket, ID não secreto, janela, base, índice, impressão opaca, tempos e destino de commit ou rollback. Acrescenta o último controle forte e a simulação de rotação com reinício. Demonstra a execução sem publicar o material que a autentica.

Poder restrito à superfície controlada

Pelo teste de agência de Lu Heng, os autores definem o invariante interoperável; o fabricante escolhe como representar e proteger a cópia; o operador escolhe chaves, frequência forte e reinício; o código do par decide cada correspondência. Nenhuma parte promete pelo controle da outra.

A especificação mínima fixa “salvar antes de destruir” e “restaurar depois de falhar”, sem impor o mesmo layout de memória a todos. Ela mantém a decisão futura localizada, mas cria uma condição que outro sistema pode testar.

O fechamento vem do running code. Um MUST descreve a ramificação correta; não prova que o caminho raro de um produto realmente volta. Injeção de falhas, impressões antes/depois e aceitação do próximo pacote legítimo produzem o recibo.

Uma entrada ainda não confiável não deveria receber poder irreversível sobre o estado legítimo apenas porque pediu ao verificador que olhasse para a frente. Salvar, testar e só então avançar é a disciplina que sustenta a via rápida.

Fontes