Gestion dynamique des services avec RADIUS

Avantages des requêtes dynamiques Radius

Simplifie la gestion centralisée des sessions d’abonnés en envoyant des modifications non sollicitées aux sessions d’abonnés, y compris les modifications d’attributs, l’activation et la désactivation de services, ainsi que l’arrêt de sessions.

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 CoA (43)

• CoA-ACK (44)

• CoA-NAK (45)

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

Pour terminer le changement d’autorisation d’un utilisateur, vous spécifiez 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 les attributs client de la session (par exemple, les attributs QoS). Le cadre de service AAA gère la requête proprement dite.

Le Tableau 1 présente les attributs d’identification des opérations 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 Service Framework AAA sur le routeur échangent des messages à l’aide d’UDP. Le message de demande CoA envoyé par le serveur RADIUS a le même format que le paquet de demande de déconnexion envoyé pour une opération de déconnexion.

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

• Si le cadre de services AAA modifie l’autorisation avec succès, 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 requête 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 bloc

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

Tous les services d’une demande CoA groupée doivent concerner 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 d’acceptation RADIUS lors de la connexion ou dans les demandes CoA après la connexion.

Pour les services conventionnels basés sur des profils de service dynamiques, vous pouvez facilement intégrer jusqu’à 12 activations de service 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 CoA.

Chaque message de demande CoA est indépendant des demandes CoA précédentes et futures dans la même session d’abonné. Toutes les activations et désactivations de service d’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 une session d’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 en collaboration par les processus authd et essmd, de sorte que la dernière opération initie une validation pour appliquer toutes les interfaces logiques métier statiques résultantes de la demande CoA. Étant donné que le temps de validation est généralement la plus grande partie de l’application d’un service métier statique, il est avantageux d’emballer autant d’activations ou de désactivations de service 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 CoA ultérieure visant à appliquer des services commerciaux supplémentaires pour la même session d’abonné.

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

Le CoA en bloc 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 requêtes comme appartenant à la même transaction en bloc ; 26 à 194 doivent avoir la même valeur dans toutes les demandes CoA de la série en bloc. Chaque transaction groupée successive de 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 ce 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é.

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

Avantages d’un changement d’autorisation initié par Radius

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

Déconnecter les messages

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

La fonctionnalité de demande 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 demande et de réponse RADIUS :

• Demande de déconnexion (40)

• Déconnexion-ACK (41)

• Déconnexion-NAK (42)

Critères d’admissibilité à la déconnexion

Pour que le service Framework 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 présents dans la demande, le routeur utilise les deux attributs. Si l’attribut Nom d’utilisateur (1) est également présent dans la demande, le nom d’utilisateur et l’ID de session de comptabilité sont utilisés pour effectuer la déconnexion. Le cadre de service AAA gère la requête proprement dite.

Échange de messages

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

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

• Si le Service Framework AAA réussit à déconnecter l’utilisateur, la réponse est un paquet au format RADIUS avec un message Disconnect-ACK.

• Si le Service Framework AAA ne peut pas déconnecter l’utilisateur, si la requête est mal formée ou si des attributs sont manquants dans la requête, 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 d’abonnés. Cette fonctionnalité de gestion centralisée des abonnés simplifie la gestion d’un grand nombre d’abonnés, car l’arrêt par l’opérateur nécessiterait autrement une action sur le routeur.

Processus d’activation de la 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, par exemple 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 de la 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 à authd.

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

   3. Le serveur RADIUS envoie un message d’accès-acceptation à authd qui inclut le VSA de service d’activation RADIUS (26-65).

   4. L’authd met en cache les attributs d’activation du service et envoie une subvention à l’application cliente.

2. L’application cliente envoie la première demande 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 du service mis en cache et envoie une demande d’activation pour les 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. La suite d’authd 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.

        Remarque :

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de changement 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.

        Remarque :

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de changement 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.

        Remarque :

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de changement 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 réussit :

     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é, entraînant l’échec de l’activation de la famille dans la première demande, l’application cliente peut envoyer une deuxième demande, mais uniquement pour la famille non demandée la première fois. Si la première demande concernait IPv4, la deuxième demande ne peut concerner qu’IPv6. Si la première demande concernait IPv6, la deuxième demande ne peut concerner qu’IPv4.

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

7. La suite d’authd 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.

        Remarque :

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de changement 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.

        Remarque :

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de changement 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 familiale. Comme 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 des étapes suivantes :

        • Si la première activation familiale a réussi et que l’abonné s’est connecté, l’échec de la deuxième demande n’arrête 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 demande).

        • Si la première activation familiale a échoué, l’échec de la deuxième demande entraîne la résiliation 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.

        Remarque :

        Cette suppression vous permet de réémettre la demande de service à l’aide d’une demande de changement 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 réussit :

     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.

Objet

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

Mesures à prendre

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