Resumo

  • A versão 02 da minuta RSVP Cryptographic Authentication v2 saiu em 27 de setembro de 2026, durante a última chamada do grupo TEAS, aberta até o dia 30. O texto continua sendo Internet-Draft, sem aprovação final como RFC.
  • Quando há uma associação de segurança válida, a mensagem que usa a associação vencida deve ser descartada. Quando todas as aplicáveis venceram, a minuta prevê validar com a última e manter sua utilização em caráter excepcional.
  • Não se trata de aceitar sinalização sem autenticação. O problema transferido para a operação é identificar o início da exceção, preparar a substituta e demonstrar o encerramento.

Uma rede não espera a troca de chave para parar de sinalizar suas reservas. Se a única associação de segurança RSVP chegar ao fim do prazo antes que uma substituta esteja funcionando, há uma tensão real entre a regra do calendário e a continuidade do plano de controle. A proposta do TEAS enfrenta essa tensão de modo específico; não oferece uma autorização geral para deixar a autenticação desligada.

O procedimento de recepção traça a primeira distinção. Um pacote vinculado a uma associação expirada é rejeitado antes do processamento criptográfico se outra associação válida já estiver disponível. Assim, a chave antiga não tem preferência sobre a substituta. Sem associação válida no instante em que o pacote chega, o texto orienta a verificar a mensagem com a expirada.

A seção 5.4 descreve o caso mais amplo de todas as associações aplicáveis terem vencido: o sistema deveria alertar o gestor da rede e tratar a última associação como de duração indefinida até que seja formalmente prorrogada, removida pela gestão ou substituída por nova configuração.

O que sobrevive é a verificação do valor de autenticação, não a pretensão de que o prazo nunca terminou. O próprio documento chama a situação de fortemente indesejável e recomenda evitá-la. Por isso, «o pacote passou na checagem criptográfica» e «a credencial estava dentro da política temporal» são afirmações distintas. A exceção mantém a primeira possível enquanto exige uma decisão explícita sobre a segunda.

Na operação normal, a minuta exige que as implementações consigam manter pelo menos duas associações ativas por interface ou vizinho protegido. O período de sobreposição acomoda diferenças de relógio durante a troca. O identificador de chave e o endereço de origem direcionam a escolha da associação que verifica o pacote. Nada disso prova que uma rede específica tenha distribuído a segunda chave ou testado sua ativação. Uma capacidade especificada num documento não substitui uma evidência de configuração.

Os sinais do processo de padronização também têm limites. A chamada final do grupo de trabalho começou em 16 de setembro e termina em 30 de setembro. Em 21 de setembro, uma revisão antecipada da área de segurança classificou a versão 01 como Ready, depois de considerar satisfatória a explicação sobre gestão de chaves e o caso extremo. A versão 02 veio no dia 27, com referências, ajustes de redação e uma nota num registro IANA proposto. O caso da última associação vencida já constava da versão anterior. Nem a revisão individual nem a nova versão equivalem a uma aprovação do IESG.

Há ainda uma separação entre mecanismo e algoritmo. O texto principal foi escrito para não impor uma única transformação criptográfica. Seu registro proposto lista HMAC-MD5 inicialmente como SHOULD, com a observação de que é legado e deve ser descontinuado; outra minuta do TEAS trata de HMAC-SHA2. Essas etiquetas não revelam qual algoritmo está em uso em um roteador, nem atestam que suas chaves foram giradas no prazo.

Uma evidência operacional útil reuniria a hora do primeiro alerta, os vizinhos afetados, os pacotes autenticados aceitos sob a exceção, a decisão responsável por manter o serviço e o teste da associação sucessora antes de fechar o episódio. Essa é uma proposta editorial de Daniel Kade, não um requisito já imposto pelo TEAS. Continuidade sem registro pode impedir uma interrupção hoje e ocultar uma credencial envelhecida amanhã.

Fontes