Gestion dynamique des services avec RADIUS

Avantages des requêtes dynamiques Radius

Permet une gestion centralisée simplifiée des sessions d’abonnés par l’envoi de modifications non sollicitées aux sessions d’abonnés, y compris les modifications d’attributs, l’activation, la désactivation et la désactivation de service, et la clôture de session.

CoA Messages

La prise en charge dynamique des requêtes permet au routeur de recevoir et de traiter des messages CoA non sollicités provenant de serveurs RADIUS externes. Les messages CoA initiés par RADIUS utilisent les codes suivants dans les messages de demande et de réponse :

• Demande de CoA (43)

• CoA-ACK (44)

• CoA-NAK (45)

Critères d’admissibilité au changement d’autorisation

Pour effectuer la modification de l’autorisation d’un utilisateur, vous devez spécifier des attributs d’identification et des attributs de session. Les attributs d’identification identifient l’abonné. Les attributs de session spécifient l’opération (activation ou désactivation) à effectuer sur la session de l’abonné et incluent également tous les attributs client de la session (par exemple, les attributs QoS). Le service AAA Service Framework gère la demande proprement dite.

Le tableau 1 présente les attributs d’identification des opérations de CoA.

Le tableau 2 présente les attributs de session pour les opérations CoA. Tous les attributs client supplémentaires que vous incluez dépendent de vos exigences de session particulières.

Échange de messages

Le serveur RADIUS et le cadre de services AAA sur le routeur échangent des messages à l’aide du protocole UDP. Le message CoA-Request envoyé par le serveur RADIUS a le même format que le paquet Disconnect-Request envoyé pour une opération de déconnexion.

La réponse est soit un message CoA-ACK, soit un message CoA-NAK :

• Si AAA Service Framework modifie correctement l’autorisation, la réponse est un paquet au format RADIUS avec un message CoA-ACK et le filtre de données est appliqué à la session.

• Si AAA Service Framework échoue, si la demande est mal formée ou si des attributs sont manquants, la réponse est un paquet au format RADIUS avec un message CoA-NAK.

Transactions CoA en vrac

À partir de la version 17.2R1 de Junos OS, les requêtes CoA groupées sont prises en charge afin d’améliorer l’efficacité du traitement des services d’abonnés basés sur RADIUS sur le BNG. La fonctionnalité CoA groupée permet d’accumuler une série de requêtes CoA et de les valider toutes ensemble, en masse, automatiquement.

Tous les services d’une requête CoA groupée doivent être destinés à la même session d’abonné.

Les transactions CoA en vrac sont particulièrement précieuses pour les services aux entreprises. Les services d’abonnés basés sur RADIUS utilisent les VSA de Juniper Networks, Activate-Service (26-65) et Deactivate-Service (26-66). Les VSA sont fournis dans les messages RADIUS-Accept lors de la connexion ou dans les requêtes CoA après la connexion.

Pour les services classiques dynamiques basés sur des profils de services, jusqu’à 12 activations de service peuvent facilement tenir dans l’un ou l’autre des messages RADIUS. Toutefois, les services basés sur des scripts opérationnels utilisés par les entreprises ont généralement des exigences de mise à l’échelle qui dépassent la capacité de l’un ou l’autre message. Cela signifie que la spécification et l’activation de tous les services nécessaires dans une session d’abonné donnée peuvent nécessiter l’utilisation d’un message d’acceptation d’accès et de plusieurs demandes de CoA.

Chaque message de demande de CoA est indépendant des demandes de CoA précédentes et futures dans la même session d’abonné. Toutes les activations et désactivations de service dans un message sont traitées avant qu’une réponse CoA ne soit proposée. La demande CoA permet de modifier de manière incrémentielle la session d’un abonné sans affecter les services existants déjà présents.

Pour les services basés sur des scripts op, les sessions de service sont créées conjointement par les processus authd et essmd, de sorte que la dernière opération lance une validation pour appliquer toutes les interfaces logiques métier statiques résultantes de la requête CoA. Étant donné que le temps de validation est généralement la partie la plus importante de l’application d’un service d’entreprise statique, il est avantageux d’emballer autant d’activations ou de désactivations de services que possible dans un message RADIUS pour utiliser efficacement la fenêtre de validation. Tant que l’opération de validation n’est pas terminée, le BNG ne peut pas accepter une demande de CoA ultérieure pour appliquer des services d’entreprise supplémentaires à la même session d’abonné.

Le CoA groupé améliore l’efficacité du traitement des validations en utilisant une seule action de validation pour tous les services de la transaction groupée. La transaction groupée a pour effet de gérer une série de requêtes comme une seule méta-requête. Il reporte le traitement de validation jusqu’à ce que la dernière demande de CoA de la transaction groupée soit reçue.

Le CoA groupé exige que chaque requête individuelle contienne une seule instance du VSA Bulk-CoA-Transaction-Id de Juniper Networks (26–194). Ce VSA identifie les demandes comme appartenant à la même transaction groupée ; 26 à 194 doivent avoir la même valeur dans toutes les demandes de certificat d’autorisation de la série en vrac. Chaque transaction groupée successive dans la session doit avoir un identifiant différent ; Par exemple, trois transactions groupées successives peuvent avoir des ID de 1, 2 et 1, mais ne peuvent pas avoir d’ID successifs de 1, 1 et 2. En pratique, la valeur Bulk-CoA-Transaction-Id est généralement incrémentée pour plusieurs transactions en bloc, mais cela n’est pas obligatoire. Une valeur d’ID utilisée dans une session d’abonné donnée peut également être utilisée dans différentes sessions d’abonnés.

Chaque demande de CoA au sein d’une transaction groupée possède son propre identifiant unique, fourni par une seule instance de l’identificateur CoA en bloc VSA (26-195) dans chaque CoA. Une série croissante de valeurs pour l’ID est typique, mais n’est pas appliquée. Les valeurs peuvent être réutilisées au sein d’une session donnée et entre les sessions. La dernière demande de CoA de la série est identifiée par une valeur de 0xFFFFFFFF pour le Bulk-CoA-Identifier.

Avantages de la modification d’autorisation initiée par Radius

Permet d’envoyer dynamiquement les modifications des valeurs d’attribut aux sessions des abonnés, ainsi que l’activation et la désactivation dynamiques des services aux abonnés.

Messages de déconnexion

Pour contrôler de manière centralisée la déconnexion des abonnés à l’accès à distance, la fonction de requête dynamique RADIUS du routeur reçoit et traite les messages non sollicités des serveurs RADIUS.

La fonctionnalité de requête dynamique utilise le format existant des messages de demande et de réponse de déconnexion RADIUS. La déconnexion initiée par RADIUS utilise les codes suivants dans ses messages de requête et de réponse RADIUS :

• Demande de déconnexion (40)

• Disconnect-ACK (41)

• Déconnexion-NAK (42)

Qualifications requises pour Disconnect

Pour que l’infrastructure de services AAA déconnecte un utilisateur, le message Disconnect-Request doit contenir un attribut avec un ID de session de comptabilité. Le message Disconnect-Request peut contenir un attribut Acct-Session-Id (44) ou un attribut Acct-Multi-Session-Id (50) pour l’ID de session, ou les deux. Si les attributs Acct-Session-Id et Acct-Multi-Session-Id sont tous deux présents dans la requête, le routeur utilise les deux attributs. Si l’attribut Nom d’utilisateur (1) est également présent dans la requête, le nom d’utilisateur et l’ID de session comptable sont utilisés pour effectuer la déconnexion. Le service AAA Service Framework gère la demande proprement dite.

Échange de messages

Le serveur RADIUS et AAA Service Framework échangent des messages à l’aide du protocole UDP. Le message Disconnect-Request envoyé par le serveur RADIUS a le même format que le paquet CoA-Request envoyé pour une opération de changement d’autorisation.

La réponse de déconnexion est un message Disconnect-ACK ou Disconnect-NAK :

• Si AAA Service Framework déconnecte l’utilisateur avec succès, la réponse est un paquet au format RADIUS avec un message Disconnect-ACK.

• Si AAA Service Framework ne parvient pas à déconnecter l’utilisateur, si la demande est mal formée ou si des attributs sont manquants dans la demande, la réponse est un paquet au format RADIUS avec un message Disconnect-NAK.

Avantages des déconnexions initiées par Radius

Permet à un serveur RADIUS de mettre fin dynamiquement aux sessions des abonnés. Cette fonctionnalité de gestion centralisée des abonnés simplifie la gestion d’un grand nombre d’abonnés, car autrement la résiliation par l’opérateur nécessiterait une action sur le routeur.

Processus d’activation d’une famille de services et de réseaux

Lorsqu’un abonné se connecte, authd doit activer la famille d’adresses correspondante après l’authentification de l’abonné. L’application cliente, telle que DHCP ou PPP, peut demander l’activation d’une seule famille de réseaux, IPv4 ou IPv6, ou demander séquentiellement l’activation des deux familles. L’activation réussie d’une famille de réseaux est liée à l’activation des services associés. Les étapes suivantes décrivent le processus lorsque authd est configuré pour utiliser RADIUS pour l’authentification :

1. Un abonné tente de se connecter.

   1. L’application cliente demande l’authentification de l’authentification.

   2. authd envoie un message de demande d’accès au serveur RADIUS.

   3. Le serveur RADIUS envoie un message d’accès-acceptation à l’authentification qui inclut le VSA RADIUS Activate-Service (26-65).

   4. Authd met en cache les attributs d’activation du service et envoie une autorisation à l’application cliente.

2. L’application cliente envoie la première requête Network-Family-Activate, pour la famille d’adresses IPv4 ou IPv6. Cette demande est parfois appelée demande d’activation du client.

3. authd examine les attributs d’activation des services mis en cache et envoie une demande d’activation des services appropriés à l’infrastructure de gestion des abonnés (SMI). Par exemple, si la demande concerne la famille IPv4, elle demande l’activation des services IPv4 uniquement. À son tour, le SMI envoie des requêtes aux démons serveur associés au service, tels que cosd ou filterd.

4. Ce que l’authentification fait ensuite dépend de l’échec de la demande d’activation du service et du caractère facultatif ou obligatoire du service.

   • Lorsque l’activation du service échoue en raison d’une erreur de configuration et que le service est facultatif :

     1. authd supprime les attributs d’activation de service mis en cache pour le service.

        Note:

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de modification d’autorisation (CoA) RADIUS ou d’une commande CLI, sans interférence du service défaillant.

     2. authd envoie un accusé de réception en réponse à la demande d’activation de la famille et la famille est activée.

     3. La connexion de l’abonné se poursuit.

   • Lorsque l’activation du service échoue en raison d’une erreur de configuration et que le service est requis :

     1. authd supprime les attributs d’activation de service mis en cache pour le service.

        Note:

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de modification d’autorisation (CoA) RADIUS ou d’une commande CLI, sans interférence du service défaillant.

     2. authd envoie un NACK en réponse à l'activation de la famille, ce qui entraîne la résiliation de la connexion de l'abonné par l'application cliente.

   • Lorsque l’activation du service échoue en raison d’une erreur de non-configuration et que le service est facultatif ou obligatoire :

     1. authd supprime les attributs d’activation de service mis en cache pour le service.

        Note:

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de modification d’autorisation (CoA) RADIUS ou d’une commande CLI, sans interférence du service défaillant.

     2. authd envoie un NACK en réponse à l'activation de la famille, ce qui entraîne la résiliation de la connexion de l'abonné par l'application cliente.

   • Lorsque l’activation du service est réussie :

     1. authd active le service.

     2. authd envoie un accusé de réception en réponse à la demande d’activation de la famille et la famille est activée.

     3. La connexion de l’abonné se poursuit.

5. À moins que l’activation du service n’ait été requise et n’ait échoué, ce qui a entraîné l’échec de l’activation de la famille lors de la première demande, l’application cliente peut envoyer une deuxième demande, mais uniquement pour la famille qui n’a pas été demandée la première fois. Si la première requête concernait IPv4, la seconde ne peut concerner qu’IPv6. Si la première requête concernait IPv6, la seconde ne peut concerner qu’IPv4.

6. Authd examine les attributs d’activation des services mis en cache et demande l’activation des services associés à la famille d’adresses demandée.

7. Ce que l’authentification fait ensuite dépend de l’échec de la demande d’activation du service et du caractère facultatif ou obligatoire du service.

   • Lorsque l’activation du service échoue en raison d’une erreur de configuration et que le service est facultatif :

     1. authd supprime les attributs d’activation de service mis en cache pour le service.

        Note:

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de modification d’autorisation (CoA) RADIUS ou d’une commande CLI, sans interférence du service défaillant.

     2. authd envoie un accusé de réception en réponse à la demande d’activation de la famille et la famille est activée.

     3. La connexion de l’abonné se poursuit.

   • Lorsque l’activation du service échoue en raison d’une erreur de configuration et que le service est requis :

     1. authd supprime les attributs d’activation de service mis en cache pour le service.

        Note:

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de modification d’autorisation (CoA) RADIUS ou d’une commande CLI, sans interférence du service défaillant.

     2. authd envoie un NACK en réponse à l’activation de la famille. Étant donné qu’il s’agit de la deuxième demande d’activation de la famille, le résultat de la première activation de la famille détermine la suite :

        • Si la première activation de la famille a réussi et que l’abonné s’est connecté, l’échec de la deuxième demande n’interrompt pas la connexion de l’abonné actuel. Cet événement n’entraîne pas non plus la déconnexion de l’abonné précédent (première requête).

        • Si la première activation de la famille a échoué, l’échec de la deuxième demande entraîne la résiliation par l’application cliente de la connexion de l’abonné actuel.

   • Lorsque l’activation du service échoue en raison d’une erreur de non-configuration et que le service est facultatif ou obligatoire :

     1. authd supprime les attributs d’activation de service mis en cache pour le service.

        Note:

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de modification d’autorisation (CoA) RADIUS ou d’une commande CLI, sans interférence du service défaillant.

     2. authd envoie un NACK en réponse à l'activation de la famille, ce qui entraîne la résiliation de la connexion de l'abonné par l'application cliente.

   • Lorsque l’activation du service est réussie :

     1. authd active le service.

     2. authd envoie un accusé de réception en réponse à la demande d’activation de la famille et la famille est activée.

     3. La connexion de l’abonné se poursuit.

But

Affichez des statistiques et des informations dynamiques sur les requêtes RADIUS.

Action

• Pour afficher les statistiques dynamiques des requêtes RADIUS :