Resumo

  • Quando todas as associações de segurança RSVP aplicáveis expiram, o rascunho recomenda avisar a gestão e tratar a última como infinita até que seja prorrogada, removida ou substituída.
  • A exceção não transforma criptografia vencida em criptografia segura; ela evita voltar a mensagens sem autenticação e impede que uma data interrompa reservas e amplifique uma falha.
  • A rotação só termina de fato com uma sucessora ativa no mesmo escopo, sobreposição suficiente, relógios confiáveis e handshake concluído por cada receptor.

Uma chave vence à meia-noite. À meia-noite e um segundo, o roteador ainda precisa decidir se aceita o próximo pacote. É nesse intervalo entre a política escrita e o estado em execução que o novo texto do RSVP revela sua principal escolha operacional.

A revisão 02 do RSVP Cryptographic Authentication Version 2 foi publicada em 27 de setembro de 2026 e está em Working Group Last Call no TEAS. Continua sendo um Internet-Draft, candidato a Proposed Standard, não uma RFC nem prova de implantação. Se avançar, substituirá RFC 2747 e RFC 3097.

O próprio documento chama a falha de “Pathological Case”. Todas as associações capazes de proteger a troca expiraram. Retornar a RSVP sem autenticação é inaceitável; derrubar reservas correntes pode causar uma falha maior. A resposta recomendada é emitir a notificação de expiração da última associação e continuar tratando-a como de vida infinita, até que a gestão estenda sua duração, a apague ou configure outra.

Essa regra já aparecia na revisão 01. Não é uma novidade inserida na -02. O fato atual é que o compromisso continua no texto que chegou à etapa presente de revisão: a expiração passa a indicar uma transição incompleta, não uma ordem automática de desligamento.

O RSVP de RFC 2205, estendido para engenharia de tráfego em RFC 3209, sinaliza reservas de recursos. O rascunho protege as mensagens salto a salto com um objeto INTEGRITY. Emissor e receptor são os sistemas RSVP vizinhos naquele salto, e não necessariamente os pontos finais da aplicação.

O objeto carrega um Key Identifier de 48 bits, um número de sequência de 64 bits e dados de autenticação. O receptor combina o identificador com o endereço do emissor para selecionar a associação. Ela também especifica transformação criptográfica, chave, interfaces ou pares e datas de início e fim. Cada associação vale em uma direção.

O resultado prova um fato limitado: o vizinho que possui a chave produziu uma mensagem em uma posição de sequência aceita como nova. Não há confidencialidade. Também não há prova de que o solicitante tinha autoridade, de que a política admitiu a reserva ou de que o plano de dados entregou serviço. Autenticidade de mensagem não é sinônimo de resultado de rede.

O número de sequência torna reinicializações perigosas. Ele deve crescer sem repetição durante a vida da chave. Um receptor que perde a referência pode considerar nova uma mensagem antiga. Por isso, o rascunho exige suporte ao Integrity Handshake e recomenda ativá-lo por padrão. O receptor envia um cookie imprevisível; o emissor devolve o cookie e sua sequência atual em resposta autenticada.

Cada sessão precisa desse handshake ou de armazenamento estável da sequência. RFC 4086 e RFC 8937 sustentam a qualidade do desafio aleatório, mas não registram quais receptores completaram a troca.

A rotação acontece em uma janela. A implementação deve aceitar pelo menos duas associações simultâneas. A nova começa antes do fim da anterior; a sobreposição deve ser ao menos duas vezes maior que a incerteza entre relógios, e o texto observa que cinco minutos costumam bastar. Cada receptor precisa fazer handshake na sucessora.

Logo, “chave nova configurada” não encerra o trabalho. A associação deve cobrir o mesmo escopo, estar ativa segundo um relógio confiável, ser usada pelo emissor, reconhecida pelo receptor e partir de uma sequência segura. Sem um desses recibos, o inventário parece completo, mas a transição ainda não existe.

O tempo entra na superfície de segurança. O rascunho pede sincronização suficiente e recomenda autenticar a distribuição horária. RFC 5905 define NTPv4, porém uma linha de configuração não comprova a diferença real nem a saúde da fonte de tempo.

Se houver uma substituta válida, a regra é dura: o pacote que indicar a associação expirada deve ser descartado antes do cálculo criptográfico, com erro de segurança registrado sob limitação de frequência. Assim, o par não pode escolher a chave antiga quando a transição está de fato disponível.

Sem substituta, o efeito se inverte. A associação expirada valida o pacote como se ainda estivesse vigente. É uma escolha fail-operational: conservar a última relação autenticada conhecida, sem aceitar tráfego nu nem desmontar reservas pela simples passagem do tempo.

O problema é que a continuidade parece sucesso. Como a rede funciona, o reparo perde urgência. O alerta pode não ter dono. E “vida infinita” significa que não haverá uma segunda expiração automática: só uma ação de gestão encerra a exceção.

O gerenciamento de chaves está fora do escopo. A distribuição manual precisa ser suportada; uma chave manual pode durar para sempre, embora isso não seja recomendado. A agilidade de algoritmos vem de um registro de transformações da IANA. A compatibilidade com HMAC-MD5 permanece no formato, enquanto RFC 6151 explica seus limites. Nenhuma dessas escolhas entrega a chave nova ao vizinho correto.

O registro mínimo deve acompanhar a mudança de estado: Key Identifier e endereço emissor, escopo, transformação, início e fim, sucessora, janela de sobreposição, incerteza do relógio, receptores esperados, handshake individual, primeiro pacote aceito após a expiração, entrega e confirmação do alerta e ação que encerrou a exceção. A chave secreta não pertence ao registro; a procedência do estado, sim.

Essa trilha distingue criar uma chave, ativar uma associação, inicializar cada receptor e retirar da antiga o papel de única opção utilizável. Apenas o último evento demonstra que a rotação terminou.

A primazia do código em execução de Heng Lu oferece a leitura correta: a data é símbolo; o processamento real é estado. A especificação inicial mínima deixa o protocolo comum revelar o ponto de decisão sem dominar a política local. As camadas de realidade impedem que “expirada” seja confundida com evidência de que a confiança terminou.

Quando a última chave vence, o RSVP mantém o caminho autenticado, acende o alarme e espera que alguém conclua a transição.

Fontes