Resumo

  • A RFC 3169 trata as informações enviadas por um Network Access Server (NAS) como evidências ou “indícios”, não como ordens; a decisão final de autorização cabe ao servidor AAA.
  • Essa decisão ainda precisa ser aplicada no NAS. O estado dos recursos, a contabilidade e o serviço efetivamente recebido exigem verificações independentes.

A divisão de funções está registrada em um documento que pode ser confundido com uma norma. Publicada em setembro de 2001, a RFC 3169 é Informational e declara que não especifica nenhum padrão da Internet. O título — “Criteria for Evaluating Network Access Server Protocols” — anuncia critérios de avaliação, não um novo formato de pacote. O texto separa os espaços de protocolo do NAS em acesso, rede, AAA e gerenciamento de dispositivos, com foco principal em AAA. O modelo inclui equipamentos que concentram sessões telefônicas, de banda larga e de túneis, podendo atender milhares de conexões simultâneas.

O ponto mais relevante não é a extensão da lista, mas a atribuição de autoridade. A seção de autorização determina que os dados enviados pelo NAS ao servidor AAA sejam tratados como “informações ou indícios”, não como diretivas. O servidor toma a decisão final e não deve depender de um estado que o NAS apenas espera que exista. Assim, o equipamento de borda pode descrever uma sessão, mas não autoriza o acesso só por descrevê-la.

Uma decisão no servidor, porém, não significa que a política já foi aplicada. A RFC 3169 prevê perfis de acesso transmitidos para execução pelo NAS. O servidor AAA determina o que a política permite; o equipamento ainda precisa instalar ou aplicar esse perfil em seu próprio ambiente operacional. Portanto, um Access-Accept válido, uma resposta de política ou uma mensagem de autorização dinâmica comprova uma decisão ou solicitação — não prova que a interface mudou de estado, que o filtro entrou em vigor ou que o usuário recebeu um serviço funcional.

Os requisitos de gerenciamento de recursos tornam essa diferença concreta. A RFC 3169 prevê alocar e liberar recursos compartilhados durante uma sessão, como endereços, limites de uso simultâneo, portas e túneis. O documento diz que a função se destina principalmente aos recursos locais do NAS. Em uma configuração com proxy ou vários domínios administrativos, o servidor que alocou um recurso remoto — e talvez seus servidores de reserva — deve guardar as informações dessa alocação. Alterações de autorização em outro domínio devem usar funções de autorização dinâmica.

Decidir o acesso e manter o registro atual necessário para recuperar ou restaurar um recurso são responsabilidades diferentes.

Essa separação aparece durante uma falha. A transferência para um servidor secundário pode preservar a política, mas não reconstruir o limite de túneis ou o conjunto de endereços mantido pelo alocador. Após reiniciar, o estado local do NAS pode divergir do registro do alocador. Uma ordem de desconexão pode chegar sem ser executada. Por isso, a RFC 3169 pede recursos de sincronização e recuperação e alerta contra depender da sequência de mensagens de contabilidade para administrar recursos. A contabilidade pode registrar o uso; isso não a torna automaticamente o livro de controle autoritativo das alocações ativas.

A contabilidade é outra trilha de evidência, não um substituto para as três anteriores. A RFC 3169 pede entrega confiável, define como tempo real o início da entrega dentro de um segundo após o evento que a disparou e exige marcas de tempo sem ambiguidade. São requisitos para avaliar protocolos, não resultados observados em uma rede. Receber um registro a tempo não prova que um pacote chegou, que todos os eventos foram capturados ou que outro sistema reconstituiu corretamente a sessão. Recebimento em tempo real não equivale a verdade de campo em tempo real.

A história dos protocolos relacionados contextualiza a lista sem provar que algum sucessor cumpriu todos os seus itens. O RADIUS já tinha especificações separadas para autenticação/autorização e contabilidade. A RFC 3169 pede que protocolos AAA candidatos lidem com esses conjuntos de atributos, interoperabilidade, extensibilidade, vários servidores e relações entre domínios. Publicada depois, a RFC 6733 descreve Diameter como protocolo-base para aplicações AAA; autorização dinâmica, transporte de EAP e proteção de transporte também evoluíram em documentos distintos.

A existência desses documentos não é uma auditoria de conformidade com todos os requisitos da RFC 3169. As diretrizes posteriores de projeto do RADIUS reconhecem limites de tamanho e do modelo de dados, em vez de tratarem um grande espaço de atributos como promessa de capacidade de implementação ilimitada.

Como história da Internet, a RFC 3169 mapeia limites de controle. O NAS fornece evidências sobre a sessão; o servidor AAA tem o papel de autorização final; o NAS executa a política; o alocador conserva o estado atual dos recursos; e a contabilidade gera outro registro. Eles podem se comunicar na mesma família de protocolos, mas nenhuma mensagem isolada comprova toda a cadeia. Este artigo não afirma taxas de adoção, produtos nem implantação atual. Mantém a lição mais restrita do documento: em uma operação distribuída, uma decisão central é apenas um comprovante entre vários.

Fontes: RFC 3169; registro atual da RFC 3169; registro Datatracker da RFC 3169; modelo NAS da RFC 2881; RADIUS, RFC 2865; contabilidade RADIUS, RFC 2866; extensões RADIUS, RFC 2869; avaliação de protocolos AAA, RFC 2989; EAP no RADIUS, RFC 3579; autorização dinâmica, RFC 5176; diretrizes de projeto do RADIUS, RFC 6158; RADIUS sobre TLS, RFC 6614; protocolo-base Diameter, RFC 6733; RADIUS/1.1, RFC 9765; Lu Heng, “Quando o Contador Aspira ao Olimpo”.