Resumo

  • A revisão 18 do RadSec define a vida por conexão e por próximo salto. O proxy pode responder normalmente enquanto um único realm, home server ou repositório de credenciais atrás dele falha.
  • A troca entre transportes confiáveis e não confiáveis desloca a responsabilidade pela retransmissão; sem registrar esse deslocamento, um timeout ou pacote duplicado não identifica a causa nem o responsável.

Considere o caminho de um Accounting-Request. O cliente envia o pacote por RADIUS/TLS a um proxy. O proxy precisa encaminhá-lo por RADIUS/UDP ao servidor de origem. O trecho TLS é confiável e não retransmite o pacote RADIUS na mesma conexão. O trecho UDP pode perder datagramas, portanto o proxy passa a controlar o temporizador e as cópias.

Se o servidor estiver apenas lento, o cliente poderá acreditar que o evento se perdeu. Ao atualizar Acct-Delay-Time, ele produz um novo pacote com a mesma informação essencial e, possivelmente, outro Identifier. O proxy também continua retransmitindo as versões anteriores no trecho UDP. O apêndice A.2 de draft-ietf-radext-radiusdtls-bis-18 mostra o resultado: um evento vira os IDs 101, 102 e 103 no servidor, cada um com sua própria fila de tentativas.

Esse exemplo revela a arquitetura inteira. “A conexão está viva” não responde “qual ator ainda possui o trabalho?”. O cliente pode ter desistido, o proxy pode continuar retransmitindo e o servidor pode já ter processado a primeira cópia. Cada frase é verdadeira em um domínio diferente.

Por isso o projeto recomenda manter Event-Timestamp fixo. Ele registra quando o evento ocorreu e não deve mudar numa retransmissão. Atualizar repetidamente Acct-Delay-Time transforma o mesmo fato em vários pacotes diferentes e amplia congestionamento. A hora estável ajuda na detecção de duplicatas, mas não é um identificador global nem uma garantia de execução exatamente uma vez. O recibo ainda precisa unir evento, pacote, salto, dono do temporizador e decisão do servidor.

A mesma disciplina governa autenticação e disponibilidade. RADIUS é hop-by-hop. Para o NAS, o proxy parece servidor; para o home server, o proxy parece cliente. Ele lê o realm, escolhe uma rota e pode acessar backends distintos para organizações distintas. O NAS observa a saúde do vizinho, não a topologia que o vizinho esconde.

A seção 3.8 da revisão 18 manda combinar o estado TCP, TLS ou DTLS com o watchdog de aplicação de RFC 3539. Uma conexão só deve ser marcada como down quando a pilha de rede indica que deixou de ser viável, quando D(TLS) não oferece conexão utilizável ou quando o watchdog a classifica como down. O teste é por conexão. Uma associação sem resposta não derruba todas as outras conexões ao mesmo servidor.

Esse detalhe evita que um backend de balanceamento ou uma sessão DTLS perdida retire um pool inteiro. Também impede uma conclusão cômoda no sentido oposto: uma conexão que responde não prova todos os caminhos acessíveis por aquele proxy.

RFC 5997 dá ao Status-Server um limite operacional nítido. Proxy e servidor não podem encaminhá-lo. A resposta fala somente do destino na combinação de endereço e porta testada. Como o servidor não encaminha a consulta conforme o realm do User-Name, ela não informa se um realm específico está alcançável.

O caráter não encaminhável melhora o diagnóstico. Quando um Access-Request fica sem resposta e o watchdog responde, o operador sabe que não deve declarar o primeiro proxy morto apenas por causa do silêncio. Falta, porém, localizar a falha: regra de realm, próximo link, home server, serviço de credenciais ou aplicação da política.

A revisão exige Status-Server no cliente RadSec e resposta no servidor. Como há só 256 valores de Identifier simultâneos, recomenda reservar o zero em cada conexão para o watchdog. Keepalives TCP e heartbeats DTLS podem avisar mais cedo sobre perda de transporte. Eles continuam medindo canal e par adjacente, não a autenticação de um usuário.

Uma automação mal delimitada pode errar para os dois lados. Pode interpretar o timeout de um realm como queda do proxy e deslocar tráfego saudável para a contingência. Reconexões e filas novas sobrecarregam o secundário, e uma dependência local passa a afetar toda a federação. RFC 3539 explica que um cliente separado do home server por um agente não observa os parâmetros fim a fim necessários para escolher sozinho o momento correto de failover.

Ou a automação pode manter a rota defeituosa porque o proxy segue respondendo ao watchdog. O verde continua factual; a decisão é que excede a evidência. Uma ação por realm exige saber qual regra escolheu a rota, se o proxy entregou o pedido, qual resposta veio do servidor ou backend, qual autorização foi formada e qual ação o NAS executou.

Protocol-Error pertence ao mesmo escopo. Ele sinaliza, no salto atual, que um tipo de pacote não é suportado ou não pode ser roteado. O cliente interrompe a retransmissão naquela conexão e pode escolher outro servidor. A resposta não é encaminhada e não representa uma decisão do destino oculto.

Nem a criptografia resolve a visibilidade. TLS/DTLS autentica o par RadSec adjacente e protege esse segmento. O projeto avisa que um proxy intermediário pode encaminhar o pacote por RADIUS/UDP em seguida. O cliente inicial não tem mecanismo que obrigue todos os saltos a permanecerem protegidos. Uma exigência de segurança integral precisa de controle organizacional sobre cada intermediário.

No cruzamento de transportes, a regra sobre retransmissão é explícita. Do lado não confiável para o confiável, o proxy não repassa cada cópia que recebe. Do confiável para o não confiável, ele assume as novas tentativas. Se a conexão confiável de entrada fechar, não haverá onde entregar uma eventual resposta; o proxy deve parar. Se o cliente reutilizar o Identifier e abandonar o pedido antigo, as tentativas antigas também devem cessar.

Essa cadeia explica por que um alarme de timeout precisa nomear a jurisdição. Sem o ID da conexão, o realm, o Identifier e Authenticator, a transição de transporte e o responsável pela tentativa, o alarme não distingue perda, processamento lento, desistência, duplicação ou rota inválida.

Até uma falha no Response Authenticator tem alternativa legítima. O apêndice A.1 descreve uma resposta tardia ao pedido antigo depois de o Identifier ser reutilizado. O cliente a compara com o pedido novo e a validação falha. Deve descartar a resposta, mas manter a conexão. Erro de pacote, falha de canal e par malicioso são conclusões separadas.

O documento analisado ainda é um Internet-Draft do grupo RADEXT. A revisão 18 foi registrada em 30 de setembro de 2026, pretende alcançar Proposed Standard e expira em 3 de abril de 2027. Não tem número RFC. A proposta de substituir os RFC experimentais 6614 e 7360 depende de aprovação e publicação. Ela não prova adoção, interoperabilidade ou comportamento de qualquer organização nomeada.

O registro seguro começa por uma afirmação pequena: este par RadSec respondeu nesta conexão, neste momento. Depois entram realm, rota, servidor de origem, backend, decisão, execução e resultado do usuário. A especificação comum é valiosa justamente porque coordena o primeiro salto sem reivindicar os fatos que só o código em operação nos saltos seguintes pode produzir.

Fontes