Resumen

  • La RFC 3169 trata la información que envía un Network Access Server (NAS) como evidencia o una “pista”, no como una orden; el servidor AAA toma la decisión final de autorización.
  • Esa decisión aún debe aplicarse en el NAS. El estado de los recursos, la contabilidad y el servicio que recibe el usuario requieren comprobaciones separadas.

La separación aparece en un documento que fácilmente se confunde con una norma. Publicada en septiembre de 2001, la RFC 3169 es Informational y declara que no especifica ningún estándar de Internet. Su título, “Criteria for Evaluating Network Access Server Protocols”, anuncia una lista para evaluar protocolos, no un nuevo formato de paquetes. Divide los espacios de protocolo del NAS en acceso, red, AAA y gestión de dispositivos, con el foco principal en AAA. El modelo abarca equipos que reúnen sesiones telefónicas, de banda ancha y de túnel, incluso miles de conexiones simultáneas.

Lo más interesante no es la longitud de la lista, sino dónde coloca la autoridad para decidir. La sección de autorización dice que los datos que el NAS envía al servidor AAA deben tratarse como “información o pistas”, no como directivas. La decisión final corresponde al servidor, que no debe depender de un estado que el NAS simplemente espera que exista. Así evita confundir dos cosas: el equipo de borde informa sobre una sesión, pero ese informe no la autoriza.

Sin embargo, una decisión del servidor no equivale a una política aplicada. La RFC 3169 prevé perfiles de acceso que se transmiten para que el NAS los ejecute. El servidor AAA puede decidir lo que permite la política; el equipo debe instalar o aplicar el perfil en su propio entorno de operación. Por eso, un Access-Accept correcto, una respuesta de política o un mensaje de autorización dinámica prueba una decisión o una solicitud, no que haya cambiado el estado de la interfaz, que se haya activado un filtro o que el usuario haya obtenido un servicio funcional.

Las reglas de gestión de recursos hacen visible esa brecha. La RFC 3169 contempla asignar y liberar recursos compartidos durante una sesión: direcciones, límites de uso simultáneo, puertos y túneles. Señala que la función se dirige principalmente a los recursos locales al NAS. En escenarios con proxy o varios dominios administrativos, el servidor que asignó un recurso remoto —y quizá sus servidores de respaldo— debe conservar la información de ese recurso. Los cambios de autorización en dominios remotos deben usar mecanismos de autorización dinámica.

Decidir el acceso y conservar el registro vigente necesario para recuperar o restaurar un recurso son responsabilidades distintas.

La diferencia importa en una falla. El traspaso a un servidor alternativo puede preservar la política sin reconstruir el límite de túneles o el conjunto de direcciones que mantiene el asignador. Tras reiniciarse, el estado local del NAS puede discrepar del registro del asignador. Una solicitud de desconexión puede llegar sin ejecutarse. Por eso, la RFC 3169 pide sincronización y recuperación, y advierte que la gestión de recursos no debe depender de la corriente de mensajes de contabilidad. Esa corriente puede registrar uso; no se convierte automáticamente en la tabla de bloqueo autoritativa para una asignación activa.

La contabilidad constituye otra vía de evidencia, no un sustituto de las anteriores. La RFC 3169 exige mecanismos de entrega, define como tiempo real que la entrega comience dentro del segundo siguiente al evento desencadenante y pide marcas de tiempo inequívocas. Son requisitos para evaluar protocolos, no resultados observados en una red. Recibir un registro a tiempo no prueba que un paquete llegara, que se capturaran todos los eventos ni que otro sistema reconstruyera correctamente la sesión. Recibir en tiempo real no es lo mismo que poseer una verdad de terreno en tiempo real.

La historia de los protocolos relacionados ayuda a ubicar la lista, pero no prueba que un sucesor la cumpliera por completo. RADIUS ya separaba sus especificaciones de autenticación/autorización y contabilidad. RFC 3169 pide que los protocolos AAA candidatos manejen sus conjuntos de atributos, interoperabilidad, extensibilidad, varios servidores y relaciones entre dominios. Publicada después, la RFC 6733 presenta Diameter como protocolo base para aplicaciones AAA; la autorización dinámica, el transporte de EAP y la protección del transporte también evolucionaron en documentos distintos.

Su existencia no equivale a una auditoría de cada requisito de RFC 3169. Las pautas posteriores de diseño de RADIUS reconocen límites de tamaño y del modelo de datos, en lugar de considerar que un gran espacio de atributos sea una promesa de capacidad ilimitada.

Leída como historia de Internet, la RFC 3169 dibuja fronteras de control. El NAS aporta evidencia de sesión; el servidor AAA tiene el papel de autorización final; el NAS aplica la política; el asignador conserva el estado actual del recurso; y la contabilidad genera otro registro. Pueden comunicarse dentro de una familia de protocolos, pero ningún mensaje aislado demuestra que toda la cadena se completó. Este artículo no afirma tasas de adopción, productos ni despliegues actuales. Conserva la lección más acotada del documento: en una operación distribuida, una decisión central es solo uno de los comprobantes.

Fuentes: RFC 3169; registro actual de RFC 3169; ficha de Datatracker de RFC 3169; modelo NAS de RFC 2881; RADIUS, RFC 2865; contabilidad RADIUS, RFC 2866; extensiones RADIUS, RFC 2869; evaluación de protocolos AAA, RFC 2989; EAP en RADIUS, RFC 3579; autorización dinámica, RFC 5176; guía de diseño RADIUS, RFC 6158; RADIUS sobre TLS, RFC 6614; protocolo base Diameter, RFC 6733; RADIUS/1.1, RFC 9765; Lu Heng, «Cuando el contable aspira al Olimpo».