Resumen

  • La RFC 10065 hace transportable el identificador de grupo entre RADIUS y el modelo YANG de ACL, pero no crea un espacio de nombres universal.
  • La prueba operativa es que AAA, el controlador y todos los puntos de aplicación usen la misma correspondencia vigente.

Un dispositivo se conecta a una red. La autenticación concluye y el servidor devuelve un identificador de grupo. Para que esa etiqueta limite o permita tráfico, varios componentes tienen que interpretarla de manera compatible. La RFC 10065 proporciona una estructura común para representar parte de ese recorrido; no convierte la etiqueta en una autorización autosuficiente.

La diferencia importa porque el identificador puede cruzar interfaces estandarizadas mientras su significado concreto y su traducción a campos de paquetes siguen dependiendo de cada despliegue.

Qué aporta el estándar

La RFC define un módulo YANG de listas de control de acceso basadas en grupos que amplía el modelo ACL del IETF. Permite declarar grupos de usuarios, dispositivos o aplicaciones y referenciarlos como origen o destino de una regla. También admite combinaciones con campos Ethernet, IPv4, IPv6 y de transporte. La entrada puede tener un horario o una recurrencia, utilizando el modelo común de planificación de la RFC 9922.

En el acceso mediado por autenticación, la RFC establece el atributo RADIUS User-Access-Group-ID, tipo 241.12. Su valor es una cadena que representa el identificador del grupo de usuario. Puede viajar en Access-Accept. También puede aparecer en Access-Request como una preferencia que el servidor no tiene obligación de aceptar. Si Access-Accept incluye más de un atributo, la respuesta representa varias pertenencias de grupo.

El patrón ofrece una abstracción útil frente a terminales que cambian de dirección. La política puede referirse a una categoría de acceso y no a una lista permanente de direcciones. Pero el modelo no elimina la necesidad de relacionar identidad, contexto y regla.

La parte que sigue siendo local

En el flujo descrito, el usuario se autentica en el NAS y la solicitud llega al servidor AAA. Si se acepta, este asigna un ID de grupo. Luego el servidor AAA o el NAS informa al controlador de la relación entre ese ID y atributos comunes del paquete, como la quíntupla de red. El controlador mantiene la política y la instala en los puntos de aplicación pertinentes.

La RFC deja expresamente fuera de alcance los detalles de cómo se notifica esa relación. También declara que la definición de los grupos es específica del despliegue. Puede basarse en función, certificado del dispositivo, dirección, ubicación, hora o política local. Una misma persona puede cambiar de grupo cuando cambia alguno de esos datos. El documento no crea un registro mundial de grupos ni decide quién tiene autoridad sobre la pertenencia.

El identificador distingue un grupo dentro del modelo YANG correspondiente, pero eso no crea una identidad global entre redes. Un valor breve puede tener significados distintos en organizaciones diferentes. Que llegue correctamente por RADIUS no demuestra que el controlador y los dispositivos conozcan la misma definición.

El horario no es una sola palanca

El modelo admite un horario que determina cuándo se aplica una regla. A la vez, una organización puede usar la hora como criterio para clasificar usuarios en grupos. En el primer caso cambia la vigencia de la regla; en el segundo, cambia la asignación de grupo. Una prueba en el límite de una jornada debe verificar ambos mecanismos por separado.

Hay dos opciones generales para aplicar la política. El controlador puede traducir la pertenencia a campos convencionales y programar ACL existentes. O un punto de aplicación puede reconocer directamente el grupo. La segunda posibilidad puede requerir capacidades de hardware o software y afectar el rendimiento de reenvío; la RFC identifica este intercambio, pero no publica resultados comparativos para escoger una arquitectura universal.