Réauthentification RADIUS comme alternative au coA RADIUS pour les abonnés DHCP
Les messages CoA (Change of Authorization) RADIUS, spécifiés dans le document RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), permettent d’activer ou de désactiver des services client et de modifier certaines caractéristiques de session client sans déconnecter le client, évitant ainsi toute interruption pour l’abonné. Dans certaines circonstances, il peut être préférable d’utiliser la réauthentification de l’abonné comme méthode pour modifier les services et les caractéristiques de session client sans interruption.
Par exemple, les modes de déploiement client suivants nécessitent tous deux des modifications d’attributs au cours de la durée de vie d’une session.
Abonnés résidentiels – Les abonnés résidentiels peuvent changer de forfait tout au long de la durée d’une session en sélectionnant le service en ligne ou en appelant directement le fournisseur. La modification du plan de service est propagée au serveur local DHCP en modifiant la valeur de l’ID distant de l’agent client DHCP. L’ID distant de l’agent est transmis dans l’option 82, sous-option 2, pour les clients DHCPv4 et dans l’option 37 pour les clients DHCPv6.
Lorsque la réauthentification est configurée, la modification du plan de service est détectée, ce qui déclenche la réauthentification ; le nouveau plan de service et tous les attributs modifiés sont renvoyés par le serveur RADIUS et implémentés pour l’abonné.
Abonnés professionnels : les abonnés professionnels ont souvent besoin de modifier les attributs (en particulier les itinéraires encadrés) au cours d’une session donnée. La modification souhaitée des attributs n’est pas initiée par une modification des plans de service.
Lorsque la réauthentification est configurée, la négociation du renouvellement du bail déclenche la réauthentification. Toute modification des attributs ou des services est indiquée dans le message Accès-Acceptation du serveur RADIUS et mise en œuvre pour l’abonné.
Deux alternatives à l’utilisation de la réauthentification peuvent toutes deux modifier beaucoup plus de caractéristiques de session que ce qui est possible avec la réauthentification. Les demandes de CoA modifient les caractéristiques sans perturber l’abonné. La déconnexion de l’abonné, puis sa reconnexion, peuvent modifier bien d’autres caractéristiques de session, mais elles perturbent évidemment.
Avantages de la réauthentification
Mettez à jour ou modifiez les attributs de session des abonnés et les plans de service sans utiliser de demande de CoA.
Simplifiez l’activation des services suite à des modifications fréquentes initiées 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. Elle peut être déclenchée lorsque le serveur local DHCP reçoit un message de renouvellement, de reliaison, 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 Junos OS version 18.1R1. La prise en charge des messages de découverte et de sollicitation 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 est déclenchée uniquement lorsque le message reçu inclut une modification de la valeur de l’ID distant de l’agent du client DHCP. La valeur de l’attribut inclut le nom du plan de service de l’abonné, de sorte qu’une modification de la valeur signifie un changement de service pour l’abonné.Lorsqu’il est renvoyé avec une valeur de 1 dans le message d’accès-acceptation du serveur RADIUS pour l’abonné lors de la connexion, le VSA de Juniper Networks
reauthentication-on-renew
(26-206) 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 session chaque fois qu’elle est reçue. Une fois que ce VSA a activé la réauthentification, il est vérifié à chaque tentative de réauthentification. Si la valeur est passée à 0, c’est-à-dire si un Access-Accept ultérieur a renvoyé le VSA avec la valeur 0, le processus de réauthentification s’arrête pour cet abonné.La configuration CLI (
reauthenticate
instruction) et le comportement Reauthenticate-On-Renew sont additifs. La désactivation de la réauthentification avec le VSA n’a d’effet que lorsque l’instruction n’estreauthenticate
pas configurée. Lorsque l’instruction est configurée avec l’unereauthenticate
ou l’autre option, elle remplace une valeur VSA de 0. En l’absence de configuration CLI, le VSA peut activer la réauthentification par lui-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.
La demande de réauthentification échoue pour tout ordre d’authentification autre que radius
ou none
. Le processus d’authentification renvoie un accusé de réception négatif (NAK) pour toute requête de ce type.
Cette demande d’accès inclut les attributs d’état et de classe RADIUS qui ont été renvoyés dans le message d’acceptation d’accès. Ces attributs permettent au serveur RADIUS de distinguer la demande de réauthentification des demandes de connexion (authentification).
Le serveur RADIUS renvoie un message Access-Accept à l’authentification avec de nouveaux attributs pour l’abonné. Le processus d’authentification envoie un accusé de réception (ACK) avec les modifications apportées à 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é sur la Figure 1, et la session de l’abonné se poursuit avec les nouvelles valeurs d’attribut. Lorsque la réauthentification inclut une modification du plan de service, le serveur RADIUS renvoie le nouveau plan avec tous les autres attributs modifiés, s’il accepte la demande, comme illustré à 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 conservée avec les attributs et le service d’origine. Pour tout autre code d’erreur, jdhcpd envoie une réponse DHCPv4 NAK ou DHCPv6 (avec la valeur durée de 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 demandes lorsqu’un type de demande différent est déjà en cours pour le même abonné.
Demande en cours |
Demande supplémentaire reçue pour le même abonné |
Action |
---|---|---|
Réauthentification |
CoA (en anglais seulement) |
authd répond au CoA par un NAK. |
CoA (en anglais seulement) |
Réauthentification |
authd met la demande de réauthentification en file d’attente jusqu’à ce que le CoA soit traité, puis traite la demande de réauthentification. |
Réauthentification |
Déconnecter |
authd répond à la déconnexion par un NAK. |
Déconnecter |
Réauthentification |
authd répond à la demande de réauthentification par un NAK et continue de déconnecter l’abonné. |
Étant donné que la famille de réseaux ne s’arrête pas ou ne se redémarre pas dans le cadre de la réauthentification, le contenu de l’abonné n’est pas réévalué en ce qui concerne la mise en miroir de la stratégie de sécurité de l’abonné. Ne pas utiliser comme déclencheur pour une stratégie de sécurité de l’abonné mettant en miroir un attribut susceptible d’être modifié pendant le traitement de la réauthentification.
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 Junos OS version 18.4R1, lorsque le serveur DHCPv6 découvre 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 pas affecter d’adresses pour l’IA dans la requête 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 de la demande client n’est pas approprié pour la liaison se connectant au client. Ce code est également utilisé en cas d’échec de réauthentification (RADIUS Access-Reject).
NoPrefixAvail (6) : aucun préfixe disponible pour l’IA dans la requête client n’est disponible pour le serveur.
Si le client reçoit le code d’état NotOnLink, il peut envoyer une autre demande sans aucune adresse ou redémarrer le processus de négociation. S’il envoie une requête, le sérer local DHCPv6 ignore la demande, s’attendant à ce qu’une nouvelle renégociation commence.
Abonnés à double pile
Dans les versions antérieures à la version 18.1R1 de Junos OS, les abonnés DHCP à double pile sont traités comme des sessions client indépendantes. Chaque pile se renouvelle et obtient de nouveaux services indépendamment.
À partir de la version 18.1R1 de Junos OS, l’authentification et la réauthentification par famille sont prises en charge pour les abonnés à double pile et à session unique. Un abonné à deux piles et à session unique est généralement un foyer disposant de son propre VLAN dans un modèle d’accès 1:1. Le foyer est représenté sous la forme d’un seul abonné avec une seule session dans la base de données de session, 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 s’authentifier à nouveau :
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 reliaison, de découverte ou de sollicitation est reçu pour la session familiale alors qu’elle est dans l’état lié DHCP.
L’attribution d’adresses à la demande entraîne l’attribution d’une adresse distincte pour chaque famille lors de la connexion. L’attribution d’adresses à la demande doit être configurée pour les abonnés à double pile et à session unique, sinon l’authentification par famille et la réauthentification ne peut pas être activée. Pour la réauthentification, cela est vrai, qu’elle soit configurée dans l’interface de ligne de commande ou avec le VSA Reauthenticate-On-Renew (26-206).
L’authentification et la réauthentification sont toutes deux traitées par famille. La première famille qui déclenche le processus est prise en charge 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 de la famille est traitée.
Si une seule famille de sessions uniques à double pile se connecte, une seule authentification est traitée. Les réauthentifications ne sont traitées que pour une seule famille de clients.
Le processus d’authentification 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 qui initie la demande, authd inclut soit le VSA DHCP-Options (26-55), soit le VSA DHCPv6-Options (26-65). En fonction de sa configuration, le serveur RADIUS peut renvoyer des informations uniquement pour la famille à l’origine de la demande (la famille demandeuse) ou pour les deux familles.
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 demanderesse ou à l’autre famille (non demandeuse). 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. Là encore, seules les modifications correspondant à la famille requérante sont écrites dans la base de données de session, ce qui remplace les anciennes valeurs.
Les modifications effectuées lors de la réauthentification sont traitées comme suit :
Attribut (autre que l’adresse) : lorsque l’authentification détermine qu’un ou plusieurs de ces attributs ont été modifiés pour la famille demandeuse, elle stocke les nouvelles valeurs dans la base de données de session. Une fois que authd a notifié jdhcpd, il envoie un accusé de réception au client DHCP avec les nouvelles valeurs d’attribut.
Address or address pool (Address or address pool) : lorsque authd détecte une modification pour la famille demandeuse, il en informe le serveur local DHCP, qui envoie à son tour un NAK (DHCPv4) ou un NAK logique (DHCPv6) au client DHCP.
Si la famille requérante est la seule à être liée, jdhcpd déconnecte l’abonné avec élégance. Si la famille non requérante est également liée, jdhcpd désactive la famille requérante, mais laisse intacte la liaison de la famille non requérante, sans interruption du service à la famille non demandeuse. 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 réauthentification comme d’habitude, et la nouvelle adresse reçue dans l’acceptation d’accès est appliquée à l’abonné.
Si le serveur RADIUS répond à une demande d’authentification ou de réauthentification par un message Access-Rejet, 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 demandeuse, le client détecte la perte de connexion lorsque la famille est terminée et envoie par la suite 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 délai de reconnexion (T2, option 59) n’a pas expiré et que le service n’est pas perdu. Selon la durée du bail, cela peut prendre beaucoup de temps.
Configurez la détection de vivacité pour les deux familles d’adresses afin de réduire le temps nécessaire à la détection de la perte de connexion. Reportez-vous à la section Présentation de la détection d’activité DHCP pour plus d’informations sur la configuration de la détection d’activité.
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 l’option 82, la sous-option 2 ou l’option 37 DHCPv4.
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 sur site client (fonctionne en tant que client ou abonné DHCP).
OLT : terminaison de ligne optique : multiplexeur d’accès DSL (DSLAM) ou autre dispositif d’agrégation.
Périphérique MX Series : fait office de serveur DHCP.

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

Attributs RADIUS pris en charge pour la réauthentification
Le Tableau 2 répertorie les attributs standard RADIUS et les VSA qui peuvent être traités lors de la réauthentification lorsqu’ils sont reçus dans le message d’accès-acceptation RADIUS, et décrit comment l’authentification gère les modifications apportées aux attributs. Le traitement des attributs est cohérent avec le traitement des requêtes CoA. Les caractéristiques de la session de l’abonné qui se réauthentifie ne changent que si de nouvelles valeurs ou de nouveaux attributs sont reçus dans le message Accès-Acceptation.
Numéro d’attribut |
Nom de l’attribut |
Résultat du traitement |
---|---|---|
8 |
adresse IP tramée |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
22 |
Itinéraire cadré |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont ajoutées. |
24 |
État |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
25 |
Classe |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
26-4 |
DNS primaire |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
26-5 |
DNS secondaire |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
26-6 |
Primary-WINS (en anglais) |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
26-7 |
Secondaires-WINS |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
26-55 |
Options DHCP |
La valeur est envoyée au serveur local DHCP pour le traitement des modifications apportées à la configuration DHCP de l’abonné. |
26-65 |
Activer-Service |
Le processus d’authentification compare la liste des services dans le VSA aux services qui sont déjà actifs pour cette session d’abonné.
Par exemple, supposons que les services A et B sont actifs sur la session, mais que le VSA n’inclut que les services B et C. Le service A ne figure pas dans la liste VSA et est désactivé. Le service C est dans la liste mais n’est pas actif actuellement, donc authd active C. Le service B est à la fois déjà actif et sur la liste, il reste donc actif. |
26-161 |
nom_pool_délégué IPv6 |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
26-206 |
Réauthentification lors du renouvellement |
Si la valeur est 1 (enable), authd ajoute la valeur à la base de données de session de l’abonné si elle n’est pas déjà présente. Si la valeur est 0 (désactiver) et qu’une valeur de 1 est déjà présente dans la base de données, authd définit la valeur de la base de données sur 0. Si la valeur du message est manquante ou non valide et qu’une valeur est déjà présente dans la base de données, authd supprime la valeur de la base de données. |
26-207 |
Options DHCPv6 |
La valeur est envoyée au serveur local DHCPv6 pour le traitement des modifications apportées à la configuration DHCP de l’abonné. |
88 |
Piscine encadrée |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
97 |
Préfixe IPv6 encadré |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
100 |
Pool IPv6 encadré |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
123 |
Préfixe IPv6 délégué |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
168 |
Adresse IPv6 encadrée |
Une nouvelle valeur est stockée dans la base de données de session de l’abonné ; Les anciennes données sont écrasées. |
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.