Reautenticación RADIUS como alternativa al CoA RADIUS para suscriptores DHCP

Beneficios de la reautenticación

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

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

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

• Controle la reautenticación mediante la configuración de CLI o un VSA de RADIUS.

Funcionalidad

La reautenticación es compatible con DHCPv4 y DHCPv6. Se puede activar cuando el servidor local DHCP recibe un mensaje de renovación, reenlace, descubrimiento o solicitud de un cliente DHCP. Los mensajes de detección y solicitud admiten la reautenticación a partir de Junos OS versión 18.1R1. 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 restablecer la sesión, la reautenticación permite a authd obtener las actualizaciones que se hayan 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 alguno de los cuatro mensajes admitidos.

• La reauthenticate remote-id-mismatch instrucción especifica que la reautenticación sólo se activa cuando el mensaje recibido incluye un cambio en el valor del identificador 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 (26-206) de Juniper Networks reauthentication-on-renew , cuando se devuelve con un valor de 1 en el mensaje de acceso-aceptación del servidor 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 sesión cada vez que se recibe. Después de que este VSA haya 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 devuelve el VSA con un valor de 0, el proceso de reautenticación se detiene para ese suscriptor.

  La configuración de CLI (reauthenticate instrucción) y el comportamiento Reauthenticate-On-Renew son aditivos. La desactivación de la reautenticación con VSA sólo surte efecto cuando la reauthenticate instrucción no está configurada. Cuando la reauthenticate instrucción se configura con cualquiera de las opciones, invalida un valor VSA de 0. En ausencia de la configuración de 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 atributos de estado y clase RADIUS que se devolvieron en el mensaje Access-Accept original. Estos atributos permiten al servidor RADIUS distinguir la solicitud de reautenticación de las solicitudes de inicio de sesión (autenticación).

El servidor RADIUS devuelve un mensaje de aceptación de acceso a authd con nuevos atributos para el suscriptor. El proceso authd envía una confirmación (ACK) con los cambios a jdhcpd, que envía una oferta DHCP al cliente DHCP con atributos modificados. 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 nueva autenticación incluye un cambio en el plan de servicio, el servidor RADIUS devuelve el nuevo plan con cualquier otro atributo modificado, si acepta la solicitud, como se muestra en la figura 2. Si la 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 interrupciones en el 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 una 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 NAK DHCPv4 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 el suscriptor de la base de datos de sesión.

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

Cuando la reautenticación da como resultado 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 Junos OS versión 18.4R1, cuando el servidor DHCPv6 descubre 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 IA en la solicitud del cliente. Devuelve el IA sin direcciones y NoAddrsAvail.

• NotOnLink (4): el servidor determina que el prefijo para una o más direcciones en cualquier IA en la solicitud de cliente no es apropiado para el enlace que conecta con el cliente. Este código también se utiliza en caso de que se produzca un error de reautenticación (RADIUS Access-Reject).

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

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

Suscriptores de doble pila

En versiones anteriores a Junos OS versión 18.1R1, los suscriptores 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, la autenticación por familia y la reautenticación son compatibles para los suscriptores de doble pila y una sola sesión. Un suscriptor de sesión única de doble pila 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 sesión, pero tiene dos enlaces DHCP separados, 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 descubrimiento o solicitud mientras una sesión de suscriptor está en el estado de inicio 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, reenlace, descubrimiento o solicitud para la sesión familiar mientras se encuentra en el estado enlazado a DHCP.

Tanto la autenticación como la reautenticación se procesan por familia. La primera familia que desencadena el proceso es atendida antes de que la otra (segunda) familia active la autenticación o reautenticación. Los mensajes de la segunda familia se ignoran hasta que la primera familia está enlazada. Luego se procesa la segunda solicitud de familia.

Si solo inicia sesión una familia de sesión única de doble pila, solo se procesa una autenticación. Las reautenticaciones se procesan solo para una familia de clientes.

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, dependiendo de la familia que inicie la solicitud, authd incluye DHCP-Options VSA (26-55) o DHCPv6-Options VSA (26-65). Según su configuración, es posible que el servidor RADIUS devuelva 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 family permiten que authd determine qué atributos corresponden a la familia solicitante o a la otra familia (no solicitante). Sólo los atributos de la familia solicitante se escriben en la base de datos de sesión.

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

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 sesión. Después de que authd notifica a jdhcpd, envía un ACK al cliente DHCP con los nuevos valores de atributo.

• Direcciones o grupo de direcciones: cuando authd detecta un cambio para 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 que está vinculada, 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 unión de 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 la 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 la aceptación de acceso 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 terminada con gracia; La familia se desactiva y el suscriptor cierra sesión. A continuación, la familia no solicitante se desactiva y se cierra la sesión, pero no se notifica al cliente sobre la terminación.

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

Flujo de paquetes

En la figura siguiente se describe la secuencia de 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 la opción 82 de DHCPv4, subopción 2, o DHCPv6 opción 37.

• Negociación inicial
• Cambio en el plan de servicio

Negociación inicial

La figura 1 ilustra la secuencia de pasos en 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 en las instalaciones del cliente (funciona como cliente o suscriptor 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 el servidor DHCP.

Figura 1: Negociación inicial

Cambio en el 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 de RADIUS y los VSA 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 la autenticación 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 suscriptor que se vuelve a autenticar sólo cambian si se reciben nuevos valores o atributos nuevos en el mensaje Access-Accept.