Reautenticación de RADIUS como alternativa a la CoA de RADIUS para suscriptores de DHCP

Beneficios de la reautenticación

• Actualice o modifique los atributos de sesión y los planes de servicio del suscriptor sin usar una solicitud de CoA.

• Simplifique la activación de los servicios resultantes de cambios frecuentes iniciados por el suscriptor.

• Habilite la reautenticación por familia en configuraciones de doble pila y sesión única.

• Controle la reautenticación a través de la configuración de CLI o un VSA de RADIUS.

Funcionalidad

La reautenticación se admite tanto para DHCPv4 como para DHCPv6. Se puede activar cuando el servidor local DHCP recibe un mensaje de renovación, revinculación, descubrimiento o solicitud de un cliente DHCP. Los mensajes de detección y solicitud admiten la reautenticación a partir de la versión 18.1R1 de Junos OS. La compatibilidad con los mensajes de descubrimiento y solicitud significa que si un CPE con un cliente enlazado se reinicia y el cliente envía uno de esos mensajes para volver a activar la sesión, la reautenticación permite a authd obtener cualquier actualización que se haya realizado para el suscriptor.

El comportamiento de reautenticación se determina de la siguiente manera:

• La reauthenticate lease-renewal instrucción especifica que la reautenticación se activa cuando se recibe cualquiera de los cuatro mensajes admitidos.

• La reauthenticate remote-id-mismatch instrucción especifica que la reautenticación solo se activa cuando el mensaje recibido incluye un cambio en el valor del ID remoto del agente del cliente DHCP. El valor del atributo incluye el nombre del plan de servicio del suscriptor, por lo que un cambio en el valor significa un cambio en el servicio para el suscriptor.

• El VSA de Juniper Networks reauthentication-on-renew (26-206), cuando se devuelve con un valor de 1 en el mensaje de acceso y aceptación desde el servidor de RADIUS para el suscriptor al iniciar sesión, activa la reautenticación al recibir cualquiera de los cuatro mensajes. Un valor de 0 deshabilita la reautenticación. El valor VSA se almacena en la base de datos de la sesión cada vez que se recibe. Una vez que este VSA ha habilitado la reautenticación, se comprueba en cada intento de reautenticación. Si el valor ha cambiado a 0, es decir, si un Access-Accept posterior devolvió el VSA con un valor de 0, el proceso de reautenticación se detiene para ese suscriptor.

  La configuración de la CLI (reauthenticate instrucción) y el comportamiento de Reauthenticate-On-Renew son aditivos. La deshabilitación de la reautenticación con VSA solo tiene efecto cuando la reauthenticate instrucción no está configurada. Cuando la reauthenticate instrucción se configura con cualquiera de las opciones, anula un valor VSA de 0. En ausencia de la configuración de la CLI, el VSA puede habilitar la reautenticación por sí mismo.

El proceso de reautenticación es casi idéntico al proceso de autenticación original. Cuando se activa la reautenticación, el proceso jdhcpd en el servidor local envía una solicitud de autenticación a authd, que a su vez envía un mensaje de solicitud de acceso al servidor RADIUS para solicitar una segunda autenticación.

Esta solicitud de acceso incluye los atributos de estado y clase de RADIUS que se devolvieron en el mensaje de aceptación de acceso original. Estos atributos permiten que el servidor de RADIUS distinga la solicitud de reautenticación de las solicitudes de inicio de sesión (autenticación).

El servidor RADIUS devuelve un mensaje Access-Accept a authd con nuevos atributos para el suscriptor. El proceso authd envía un acuse de recibo (ACK) con los cambios a jdhcpd, que envía una oferta DHCP al cliente DHCP con los atributos cambiados. La negociación DHCP continúa como de costumbre, como se muestra en la Figura 1, y la sesión del suscriptor continúa con los nuevos valores de atributo. Cuando la reautenticación incluye un cambio en el plan de servicio, el servidor RADIUS devuelve el nuevo plan con cualquier otro atributo cambiado, si acepta la solicitud, como se muestra en la Figura 2. Si el CPE que aloja el cliente DHCP se reinicia durante el proceso de cambio de un plan de servicio, se admite la reautenticación con el nuevo plan sin interrupción del servicio.

Si el servidor RADIUS rechaza una solicitud de reautenticación o agota el tiempo de espera, authd envía un NAK a jdhcpd, que revisa el código de error incluido. Si el código de error indica un tiempo de espera, jdhcpd envía un ACK al cliente DHCP y la sesión del suscriptor se mantiene con los atributos y el servicio originales. Para cualquier otro código de error, jdhcpd envía un DHCPv4 NAK o DHCPv6 REPLY (con el valor de duración establecido en 0) como un NAK lógico, inicia el cierre de sesión del suscriptor y elimina al suscriptor de la base de datos de sesión.

La Tabla 1 describe cómo authd procesa las solicitudes cuando un tipo de solicitud diferente ya está en curso para el mismo suscriptor.

Cuando la reautenticación produce un cambio en la dirección IP o IPv6 de un suscriptor DHCPv6 después de enlazar un cliente, el servidor DHCPv6 evalúa la solicitud de cambio de dirección. El servidor devuelve un código de estado al cliente en la asociación de identidad (IA) de la PDU de respuesta. A partir de la versión 18.4R1 de Junos OS, cuando el servidor DHCPv6 detecta un problema con la dirección, se admite un código de estado para NotOnLink, además de los códigos admitidos anteriormente para NoAddrsAvail y NoPrefixAvail. Estos códigos de estado se definen de la siguiente manera:

• NoAddrsAvail (2): el servidor no puede asignar ninguna dirección para el AI en la solicitud del cliente. Devuelve la IA sin direcciones y NoAddrsAvail.

• NotOnLink (4): el servidor determina que el prefijo para una o varias direcciones en cualquier AI de la solicitud de cliente no es adecuado para el vínculo que se conecta al cliente. Este código también se utiliza en caso de fallo de reautenticación (RADIUS Access-Reject).

• NoPrefixAvail (6): el servidor no tiene prefijos disponibles para la IA en la solicitud del cliente.

Si el cliente recibe el código de estado de NotOnLink, puede enviar otra solicitud sin ninguna dirección o puede reiniciar el proceso de negociación. Si envía una solicitud, el servidor local de DHCPv6 omite la solicitud y espera que comience una nueva renegociación.

Suscriptores de doble pila

En versiones anteriores a Junos OS versión 18.1R1, los suscriptores de DHCP de doble pila se tratan como sesiones de cliente independientes. Cada pila se renueva y obtiene nuevos servicios de forma independiente.

A partir de Junos OS versión 18.1R1, se admite la autenticación y reautenticación por familia para suscriptores de doble pila y sesión única. Un suscriptor de doble pila y sesión única suele ser un hogar con su propia VLAN en un modelo de acceso 1:1. El hogar se representa como un único suscriptor con una sola sesión en la base de datos de sesiones, pero tiene dos enlaces DHCP independientes, uno para cada familia, DHCPv4 y DHCPv6. En consecuencia, authd envía solicitudes de acceso separadas a medida que cada familia en la sesión inicia sesión o intenta volver a autenticarse:

• La autenticación por familia se produce cuando se recibe un mensaje de detección o solicitud mientras una sesión de suscriptor está en el estado de inicio de DHCP.

• La reautenticación por familia se produce cuando la reautenticación y la asignación de direcciones a petición están configuradas y se recibe un mensaje de renovación, revinculación, descubrimiento o solicitud para la sesión familiar mientras está en el estado enlazado a DHCP.

La autenticación y la reautenticación se procesan por familia. La primera familia que activa el proceso se atiende antes de que la otra (segunda) familia active la autenticación o reautenticación. Los mensajes de la segunda familia se omiten hasta que se vincula la primera familia. Luego se procesa la segunda solicitud familiar.

Si solo inicia sesión una familia de la sesión única de doble pila, solo se procesará una autenticación. Las reautenticaciones se procesan solo para una familia de cliente.

El proceso authd clasifica los atributos como pertenecientes a la familia DHCPv4 o DHCPv6 y los etiqueta en consecuencia. Tanto para la autenticación como para la reautenticación, según la familia que inicie la solicitud, authd incluye el VSA de opciones DHCP (26-55) o el VSA de opciones DHCPv6 (26-65). Dependiendo de su configuración, el servidor RADIUS puede devolver información solo para la familia que inició la solicitud (la familia solicitante) o para ambas familias.

Cuando authd recibe atributos en el mensaje Access-Accept, las etiquetas de familia permiten que authd determine qué atributos corresponden a la familia solicitante o a la otra familia (no solicitante). Solo los atributos de la familia solicitante se escriben en la base de datos de la sesión.

Para las solicitudes de reautenticación, authd compara los atributos devueltos con la base de datos de la sesión para determinar si se realizaron cambios en el servidor RADIUS. Nuevamente, solo los cambios que corresponden a la familia solicitante se escriben en la base de datos de la sesión, sobrescribiendo los valores anteriores.

Los cambios durante la reautenticación se procesan de la siguiente manera:

• Atributo (distinto de la dirección): cuando authd determina que uno o más de estos atributos han cambiado para la familia solicitante, almacena los nuevos valores en la base de datos de la sesión. Después de que authd notifica a jdhcpd, envía un ACK al cliente DHCP con los nuevos valores de atributo.

• Dirección o conjunto de direcciones: cuando authd detecta un cambio en la familia solicitante, notifica al servidor local DHCP, que a su vez envía un NAK (DHCPv4) o un NAK lógico (DHCPv6) al cliente DHCP.

  Si la familia solicitante es la única familia enlazada, jdhcpd cierra correctamente la sesión del suscriptor. Si la familia no solicitante también está vinculada, jdhcpd desactiva a la familia solicitante, pero deja intacta la familia no solicitante, sin interrupción en el servicio a la familia no solicitante. La desactivación de la familia solicitante no tiene ningún efecto en una activación posterior de la reautenticación por parte de la familia no solicitante.

  Cuando la familia desactivada envía posteriormente un mensaje de descubrimiento o solicitud para volver a iniciar sesión, se envía una solicitud de acceso para volver a autenticarse como de costumbre, y la nueva dirección recibida en el acceso aceptado se aplica al suscriptor.

Si el servidor RADIUS responde a una solicitud de autenticación o reautenticación con un mensaje de rechazo de acceso, authd notifica al servidor local DHCP, que a su vez envía un NAK (DHCPv4) o un NAK lógico (DHCPv6) al cliente DHCP. La familia solicitante es despedida con gracia; La familia se desactiva y el suscriptor cierra la sesión. Luego, la familia que no solicita se desactiva y se cierra la sesión, pero no se notifica al cliente sobre la terminación.

Si la detección de ejecución se ejecuta en la familia no solicitante, el cliente detecta la pérdida de conexión cuando la familia finaliza y, posteriormente, envía un mensaje de detección o solicitud al servidor local DHCP. Sin embargo, si la detección de ejecución no se está ejecutando, el cliente no detecta pérdida de conexión hasta que expira el tiempo de revinculación (T2, opción 59) y se pierde el servicio. Dependiendo de la duración del contrato de arrendamiento, esto podría llevar mucho tiempo.

Flujo de paquetes

En la siguiente figura se describe la secuencia para la negociación inicial de una sesión de suscriptor entre un cliente DHCP, un servidor DHCP y el servidor RADIUS. El plan de servicio del cliente se especifica en la segunda subcadena del ID remoto contenido en las opciones 82, 2 o 37 de DHCPv6.

• Negociación inicial
• Cambio de plan de servicio

Negociación inicial

La figura 1 ilustra la secuencia de pasos de la negociación inicial entre un cliente DHCP, un servidor DHCP y el servidor RADIUS. En la figura se utilizan los siguientes términos:

CPE: equipo local del cliente (funciona como cliente o suscriptor de DHCP).

OLT: terminador de línea óptica: por ejemplo, un multiplexor de acceso DSL (DSLAM) u otro dispositivo de agregación.

Dispositivo de la serie MX: funciona como servidor DHCP.

Figura 1: Negociación inicial

Cambio de plan de servicio

La Figura 2 ilustra la secuencia de pasos en un cambio de planes de servicio, de un plan de 100 Mbps a un plan de 1 Gbps:

Figura 2: Plan de servicio

Atributos RADIUS admitidos para la reautenticación

En la tabla 2 se enumeran los atributos estándar y VSA de RADIUS que se pueden procesar durante la reautenticación cuando se reciben en el mensaje de aceptación de acceso de RADIUS y se describe cómo authd controla los cambios en los atributos. El procesamiento de atributos es coherente con el procesamiento de solicitudes de CoA. Las características de la sesión de reautenticación del suscriptor sólo cambian si se reciben nuevos valores o atributos nuevos en el mensaje de aceptación de acceso.