Réauthentification RADIUS comme alternative à RADIUS CoA pour les abonnés DHCP

Avantages de la réauthentification

• Mettez à jour ou modifiez les attributs de session et les plans de service des abonnés sans utiliser de demande CoA.

• Simplifiez l’activation des services résultant de changements fréquents initiés par les abonnés.

• Activez la réauthentification par famille dans des configurations à double pile et à session unique.

• Contrôlez la réauthentification via une configuration CLI ou un VSA RADIUS.

Fonctionnalité

La réauthentification est prise en charge pour DHCPv4 et DHCPv6. Il peut être déclenché lorsque le serveur local DHCP reçoit un message de renouvellement, de liaison, de découverte ou de sollicitation d’un client DHCP. Les messages de découverte et de sollicitation prennent en charge la réauthentification à partir de la version 18.1R1 de Junos OS. La prise en charge des messages discover et solicit signifie que si un CPE avec un client lié redémarre et que le client envoie l’un de ces messages pour rétablir la session, la réauthentification permet à authd d’obtenir toutes les mises à jour qui ont été effectuées pour l’abonné.

Le comportement de réauthentification est déterminé comme suit :

• L’instruction reauthenticate lease-renewal spécifie que la réauthentification est déclenchée lorsque l’un des quatre messages pris en charge est reçu.

• L’instruction reauthenticate remote-id-mismatch spécifie que la réauthentification n’est déclenchée que lorsque le message reçu inclut une modification de la valeur de l’ID distant de l’agent du client DHCP. La valeur d’attribut inclut le nom du plan de service d’abonné, de sorte qu’une modification de valeur signifie un changement de service pour l’abonné.

• Le VSA de Juniper Networks reauthentication-on-renew (26-206), lorsqu’il est renvoyé avec une valeur de 1 dans le message Access-Accept du serveur RADIUS pour l’abonné lors de la connexion, déclenche une nouvelle authentification à la réception de l’un des quatre messages. La valeur 0 désactive la réauthentification. La valeur VSA est stockée dans la base de données de la session chaque fois qu’elle est reçue. Une fois que ce VSA a activé la réauthentification, il est vérifié à chaque nouvelle tentative d’authentification. Si la valeur est passée à 0, c’est-à-dire si un Access-Accept ultérieur a renvoyé le VSA avec une valeur de 0, le processus de réauthentification s’arrête pour cet abonné.

  La configuration de la CLI (reauthenticate instruction) et le comportement de réauthentification lors du renouvellement sont additifs. La désactivation de la réauthentification auprès du VSA n’a d’effet que lorsque l’instruction n’est reauthenticate pas configurée. Lorsque l’instruction est configurée avec l’une reauthenticate ou l’autre option, elle remplace une valeur VSA de 0. En l’absence de configuration CLI, la VSA peut activer la réauthentification par elle-même.

Le processus de réauthentification est presque identique au processus d’authentification d’origine. Lorsque la réauthentification est déclenchée, le processus jdhcpd sur le serveur local envoie une demande d’authentification à authd, qui à son tour envoie un message de demande d’accès au serveur RADIUS pour demander une deuxième authentification.

Cette demande d’accès inclut les attributs d’état et de classe RADIUS qui ont été renvoyés dans le message d’accès-acceptation d’origine. Ces attributs permettent au serveur RADIUS de distinguer la demande de réauthentification des demandes de connexion (authentification).

Le serveur RADIUS renvoie un message d’accès-acceptation à authd avec de nouveaux attributs pour l’abonné. Le processus authd envoie un accusé de réception (ACK) avec les modifications à jdhcpd, qui envoie une offre DHCP au client DHCP avec les attributs modifiés. La négociation DHCP se poursuit comme d’habitude, comme illustré à la figure 1, et la session d’abonné se poursuit avec les nouvelles valeurs d’attribut. Lorsque la réauthentification inclut un changement de plan de service, le serveur RADIUS renvoie le nouveau plan avec tout autre attribut modifié, s’il accepte la demande, comme indiqué dans la Figure 2. Si le CPE hébergeant le client DHCP redémarre pendant le processus de modification d’un plan de service, la réauthentification avec le nouveau plan est prise en charge sans interruption de service.

Si le serveur RADIUS rejette une demande de réauthentification ou expire, authd envoie un NAK à jdhcpd, qui examine le code d’erreur inclus. Si le code d’erreur indique un délai d’expiration, jdhcpd envoie un accusé de réception au client DHCP et la session de l’abonné est maintenue avec les attributs et le service d’origine. Pour tout autre code d’erreur, jdhcpd envoie un NAK DHCPv4 ou DHCPv6 REPLY (avec la valeur à vie définie sur 0) en tant que NAK logique, initie la déconnexion de l’abonné et supprime l’abonné de la base de données de session.

Le Tableau 1 décrit comment authd traite les requêtes lorsqu’un type de requête différent est déjà en cours pour le même abonné.

Lorsque la réauthentification entraîne une modification de l’adresse IP ou IPv6 d’un abonné DHCPv6 après la liaison d’un client, le serveur DHCPv6 évalue la demande de changement d’adresse. Le serveur renvoie un code d’état au client dans l’association d’identité (IA) de la PDU de réponse. À partir de la version 18.4R1 de Junos OS, lorsque le serveur DHCPv6 détecte un problème avec l’adresse, un code d’état pour NotOnLink est pris en charge en plus des codes précédemment pris en charge pour NoAddrsAvail et NoPrefixAvail. Ces codes d’état sont définis comme suit :

• NoAddrsAvail (2) : le serveur ne peut attribuer aucune adresse à l’IA dans la demande client. Il renvoie l’IA sans adresse et NoAddrsAvail.

• NotOnLink (4) : le serveur détermine que le préfixe d’une ou plusieurs adresses dans un IA dans la demande client n’est pas approprié pour le lien se connectant au client. Ce code est également utilisé en cas d’échec de réauthentification (accès RADIUS-rejet).

• NoPrefixAvail (6) : aucun préfixe n’est disponible sur le serveur pour l’IA dans la requête client.

Si le client reçoit le code d’état NotOnLink, il peut envoyer une autre demande sans adresse ou redémarrer le processus de négociation. S’il envoie une requête, le sérer local DHCPv6 ignore la requête, s’attendant à ce qu’une nouvelle renégociation commence.

Abonnés à double pile

Dans les versions antérieures à Junos OS version 18.1R1, les abonnés DHCP à double pile sont traités comme des sessions client indépendantes. Chaque pile se renouvelle et obtient de nouveaux services de manière indépendante.

À partir de Junos OS version 18.1R1, l’authentification par famille et la réauthentification sont prises en charge pour les abonnés à double pile et à session unique. Un abonné à double pile et à session unique est généralement un ménage disposant de son propre VLAN dans un modèle d’accès 1:1. Le ménage est représenté comme un seul abonné avec une seule session dans la base de données des sessions, mais il possède deux liaisons DHCP distinctes, une pour chaque famille, DHCPv4 et DHCPv6. Par conséquent, authd envoie des demandes d’accès distinctes lorsque chaque famille de la session se connecte ou tente de se réauthentifier :

• L’authentification par famille se produit lorsqu’un message de découverte ou de sollicitation est reçu alors qu’une session d’abonné est à l’état d’initialisation DHCP.

• La réauthentification par famille se produit lorsque la réauthentification et l’attribution d’adresses à la demande sont toutes deux configurées et qu’un message de renouvellement, de reliure, de découverte ou de sollicitation est reçu pour la session famille alors qu’elle est à l’état lié DHCP.

L’authentification et la réauthentification sont traitées par famille. La première famille à déclencher le processus est traitée avant que l’autre (deuxième) famille ne déclenche l’authentification ou la réauthentification. Les messages de la deuxième famille sont ignorés jusqu’à ce que la première famille soit liée. Ensuite, la deuxième demande familiale est traitée.

Si une seule famille de sessions à double pile unique se connecte, une seule authentification est traitée. Les réauthentifications ne sont traitées que pour une seule famille de clients.

Le processus authd classe les attributs comme appartenant à la famille DHCPv4 ou DHCPv6 et les balise en conséquence. Pour l’authentification et la réauthentification, selon la famille à l’origine de la demande, authd inclut soit DHCP-Options VSA (26-55), soit DHCPv6-Options VSA (26-65). Selon sa configuration, le serveur RADIUS peut renvoyer des informations uniquement pour la famille à l’origine de la demande (la famille requérante) ou pour les deux.

Lorsque authd reçoit des attributs dans le message Access-Accept, les balises de famille permettent à authd de déterminer quels attributs correspondent à la famille requérante ou à l’autre famille (non requérante). Seuls les attributs de la famille requérante sont écrits dans la base de données de session.

Pour les demandes de réauthentification, authd compare les attributs renvoyés à la base de données de session pour déterminer si des modifications ont été apportées sur le serveur RADIUS. Encore une fois, seules les modifications correspondant à la famille requérante sont écrites dans la base de données de session, écrasant les anciennes valeurs.

Les modifications apportées lors de la réauthentification sont traitées comme suit :

• Attribut (autre que l’adresse) : lorsque authd détermine qu’un ou plusieurs de ces attributs ont été modifiés pour la famille requérante, il stocke les nouvelles valeurs dans la base de données de session. Une fois qu’authd a notifié jdhcpd, il envoie un accusé de réception au client DHCP avec les nouvelles valeurs d’attribut.

• Adresse ou pool d’adresses : lorsque authd détecte un changement pour la famille requérante, il en informe le serveur local DHCP, qui à son tour envoie un NAK (DHCPv4) ou un NAK logique (DHCPv6) au client DHCP.

  Si la famille requérante est la seule famille liée, jdhcpd déconnecte gracieusement l’abonné. Si la famille non requérante est également liée, jdhcpd désactive la famille requérante, mais laisse intacte l’obligation familiale non requérante, sans interruption du service à la famille non requérante. La désactivation de la famille requérante n’a aucun effet sur le déclenchement ultérieur de la réauthentification par la famille non requérante.

  Lorsque la famille désactivée envoie par la suite un message de découverte ou de sollicitation pour se reconnecter, une demande d’accès est envoyée pour une nouvelle authentification comme d’habitude, et la nouvelle adresse reçue dans l’accès-acceptation est appliquée à l’abonné.

Si le serveur RADIUS répond à une demande d’authentification ou de réauthentification par un message Access-Reject, authd en informe le serveur local DHCP, qui à son tour envoie un NAK (DHCPv4) ou un NAK logique (DHCPv6) au client DHCP. La famille requérante est résiliée gracieusement ; La famille est désactivée et l’abonné est déconnecté. Ensuite, la famille non requérante est désactivée et déconnectée, mais le client n’est pas informé de la résiliation.

Si la détection d’activité est en cours d’exécution sur la famille non requérante, le client détecte la perte de connexion lorsque la famille est terminée, puis envoie un message de découverte ou de sollicitation au serveur local DHCP. Toutefois, si la détection d’activité n’est pas en cours d’exécution, le client ne détecte pas la perte de connexion tant que le temps de reliaison (T2, option 59) n’expire pas et que le service n’est pas perdu. Selon la durée du bail, cela peut prendre beaucoup de temps.

Flux de paquets

La figure suivante décrit la séquence de négociation initiale d’une session d’abonné entre un client DHCP, un serveur DHCP et le serveur RADIUS. Le plan de service du client est spécifié dans la deuxième sous-chaîne de l’ID distant contenu dans DHCPv4 option 82, sous-option 2 ou DHCPv6 option 37.

• Négociation initiale
• Modification du plan de service

Négociation initiale

La figure 1 illustre la séquence des étapes de la négociation initiale entre un client DHCP, un serveur DHCP et le serveur RADIUS. Les termes suivants sont utilisés dans la figure :

CPE : équipement local du client (fonctionne comme le client DHCP ou l’abonné).

OLT : terminateur de ligne optique, par exemple, un multiplexeur d’accès DSL (DSLAM) ou un autre périphérique d’agrégation.

L’équipement MX Series : fonctionne comme le serveur DHCP.

Figure 1 : Négociation initiale

Modification du plan de service

La figure 2 illustre la séquence des étapes d’un changement de plan de service, d’un plan de 100 Mbit/s à un plan de 1 Gbit/s.

Figure 2 : Plan de service

Attributs RADIUS pris en charge pour la réauthentification

Le Tableau 2 répertorie les attributs standard et les VSA RADIUS qui peuvent être traités lors de la réauthentification lorsqu’ils sont reçus dans le message RADIUS Access-Accept, et décrit comment l’authd gère les modifications d’attributs. Le traitement des attributs est cohérent avec le traitement des demandes CoA. Les caractéristiques de la session d’abonné de réauthentification ne changent que si de nouvelles valeurs ou de nouveaux attributs sont reçus dans le message Accès-Acceptation.