Resumo

  • Na versão 18 do Internet-Draft do RadSec, uma resposta com falha de Response Authenticator deve ser descartada pelo cliente, enquanto a conexão (D)TLS continua aberta. A mesma obrigação de manter a conexão vale para resposta sem solicitação pendente correspondente. O documento ainda está sob avaliação do IESG e não é um RFC aprovado.
  • Um Identifier de um octeto pode ser reutilizado após o prazo de uma solicitação. A resposta antiga, recebida quando uma nova solicitação ocupa aquele número, falha na verificação feita com o contexto novo. A regra preserva a conexão, não a resposta, e não afasta o fechamento exigido por uma falha aplicável de Message-Authenticator.

O operador pode enxergar uma desconexão, mas a origem do problema ser apenas uma resposta atrasada. Imagine que o cliente tenha desistido da solicitação A e atribuído seu Identifier à solicitação B. O servidor devolve então o resultado de A. Quando o cliente tenta relacionar esse pacote a B, a verificação do Response Authenticator falha. Há motivo suficiente para eliminar o pacote. Falta demonstrar que a identidade da conexão inteira também fracassou.

A proposta do grupo RADEXT, datada de 30 de setembro, muda justamente essa segunda inferência. A seção 3.12 da revisão 18 diz que o cliente RadSec deve descartar a resposta inválida e manter aberta a conexão. Uma resposta sem pedido em andamento recebe o mesmo tratamento. Na versão 17, a falha do Response Authenticator integrava a lista de motivos para fechar; no caso da resposta sem pedido correspondente, a implementação podia decidir. O novo apêndice A.1 expõe a corrida entre expiração, reutilização do número e retorno da resposta anterior. O transporte seguro não passou a aceitar dados não autenticados; o destino de um pacote foi separado do destino do canal.

O RFC 6613 é importante para medir a mudança, não para atribuir uma falha a uma rede real. Para RADIUS/TCP, ele exigia fechar TCP quando o Response Authenticator não validava e permitia escolher a reação a uma resposta órfã. Como o Identifier tem um octeto, há apenas 256 valores para distinguir solicitações em voo em uma conexão. Sob carga, a reutilização logo após um timeout cria uma janela em que o servidor ainda responde ao pedido anterior. Diferentes temporizadores nos proxies também podem fazer a resposta aparecer depois de o cliente deixar de aguardá-la. Nenhuma fonte consultada mede quantas redes enfrentam esse cenário.

Há uma linha de segurança que a revisão não move. A resposta com autenticação falha não pode ser entregue como sucesso. Depois da falha do Response Authenticator, verificar o Message-Authenticator daquele pacote já descartado não acrescenta uma decisão; isso não significa que falhas de Message-Authenticator sejam toleradas em outros casos. Quando a resposta está corretamente associada ao pedido, mas esse último controle falha, o fechamento permanece exigido. Um servidor que considere o cliente inadmissível também deve encerrar imediatamente (D)TLS e, no caso de RADIUS/TLS, TCP.

A distinção evita tanto um desligamento excessivo quanto uma exceção ampla demais.

Um ensaio operacional honesto precisa mostrar mais que a permanência do socket. É necessário comprovar que a resposta tardia foi descartada, que nenhum resultado foi associado à solicitação nova, que transações válidas posteriores ainda funcionaram e que uma falha real de integridade levou ao fechamento. Logs devem dizer qual regra foi violada e qual Identifier estava envolvido, com limitação de taxa para pacotes ignorados enquanto a conexão continua aberta — cuidado previsto pelo rascunho. Esse roteiro de aceite é análise editorial; não constitui uma nova exigência de telemetria do IETF.

O Datatracker registra a versão 18 como Internet-Draft ativo do RADEXT, submetido ao IESG e no estado IESG Evaluation::AD Followup, com intenção de Proposed Standard. A substituição dos RFCs 6614 e 7360 só ocorreria se aprovada. A notícia não é a promessa de uma cura implantada, e sim uma mudança delimitada de autoridade: um pacote pode ser rejeitado sem que um erro temporal retire a credencial da conexão que o transportou.

Fontes