Resumo

  • RFC 8559 acrescentou uma trilha de retorno para que um proxy encaminhe CoA e Disconnect ao NAS de origem. O Operator-NAS-Identifier é um identificador opaco de roteamento, não a identidade única de uma sessão de assinante.
  • Depois de encontrar o NAS, RFC 5176 ainda exige autorização do solicitante, correspondência de sessões, execução atômica e resposta precisa. A confirmação operacional exige também estado de sessão, contabilidade e tráfego.

“Entregue ao destino correto” parece uma frase conclusiva. Em autorização dinâmica RADIUS, ela só encerra a etapa do caminho. Dentro do Network Access Server ainda existe um conjunto de sessões, e os atributos do pedido precisam selecionar o estado que será alterado ou removido.

Essa separação explica por que o RFC 5176 original tinha dificuldade com proxies. O documento definia CoA-Request e Disconnect-Request, mas não fornecia informação padronizada suficiente para o proxy reencontrar o NAS que originara a sessão. RFC 8559 introduziu Operator-Name e um Operator-NAS-Identifier opaco, permitindo construir o retorno.

Um endereço de retorno não é uma chave de assinante

O identificador do NAS pertence ao domínio operacional que o criou. Serve para o proxy localizar o equipamento e devolver a resposta pelo caminho apropriado. Não deve ser reinterpretado como nome do usuário, Acct-Session-Id ou prova de que existe uma única sessão naquele dispositivo.

Quando o pedido chega, o NAS consulta atributos como User-Name, NAS-Port, Framed-IP-Address, Calling-Station-Id, Acct-Session-Id e Chargeable-User-Identity. A busca pode produzir zero, uma ou várias correspondências. Sem correspondência, há NAK. Com várias, a operação se aplica a todas. Se o equipamento não consegue lidar com seleção múltipla, devolve Error-Cause 508.

Logo, o proxy pode funcionar perfeitamente enquanto a seleção final continua ampla demais. Um painel que registra apenas “proxy encaminhou ao NAS X” prova topologia, não precisão sobre o assinante.

O conjunto inteiro muda ou permanece

RFC 5176 trata todos os atributos da solicitação como obrigatórios e exige atomicidade. Em um CoA, todas as mudanças precisam ter sucesso em todas as sessões correspondentes; então o NAS devolve CoA-ACK. Se uma única mudança falhar, devolve CoA-NAK e não aplica nenhuma. Em Disconnect, todas as sessões selecionadas precisam terminar ou todas permanecem.

A atomicidade evita uma implantação fragmentada. Não corrige o conjunto escolhido. Um seletor excessivamente amplo pode desconectar três sessões de forma coerente e receber um ACK totalmente correto. Por isso, o número e a identidade das correspondências são parte do controle anterior à execução, não detalhes opcionais do log posterior.

A resposta do NAS tem conteúdo real

Disconnect-ACK declara que o contexto das sessões selecionadas foi descartado e elas já não estão conectadas. CoA-ACK declara que a alteração de autorização teve sucesso. Não é correto reduzir esses pacotes a recibos de transporte.

Também não é correto fazê-los falar por sistemas que não observaram. O registro de Accounting-Stop pode atrasar. Um gateway posterior pode manter estado. Uma cópia de política pode divergir. O tráfego do usuário pode continuar por um mecanismo fora do NAS. A verificação independente amplia o quadro sem negar o significado do ACK.

NAK também exige leitura completa. No caso Authorize Only, a aceitação do pedido produz CoA-NAK com Error-Cause 507, Request Initiated. O NAS então origina Access-Request, e Access-Accept ou Access-Reject define o resultado. O NAK registra o começo correto de outro fluxo, não uma falha simples.

Canal protegido e poder autorizado

No RADIUS/UDP histórico, o endereço de origem seleciona um segredo compartilhado e a construção baseada em MD5 autentica o pedido. Event-Timestamp e regras de retransmissão/duplicidade tratam de replay. Mesmo assim, um cliente autenticado de um provedor não ganha direito sobre usuários de outro provedor no mesmo NAS.

RFC 9765 atualiza o transporte com RADIUS/1.1 sobre TLS ou DTLS negociado. Nesse modo, o canal seguro substitui a autenticação legada do pacote e Message-Authenticator não é enviado. A melhoria criptográfica não responde quem pode alterar qual realm nem quantas sessões o seletor alcançou.

O RFC 5176 foi publicado como Informational justamente porque vulnerabilidades e ambiguidades presentes em implementações não poderiam ser removidas sem incompatibilidade. A resposta prudente não é fingir que todo controle é incerto. É preservar uma cadeia em que cada camada prova sua parte: o cliente assina a intenção; o proxy registra o caminho; o NAS registra a seleção e a transição; contabilidade e tráfego registram o efeito.

Isso mantém o protocolo mínimo e a responsabilidade máxima. Nenhum ator precisa se tornar uma autoridade universal para que o resultado seja auditável.

Fontes