Gerenciamento dinâmico de serviços com RADIUS

Benefícios das solicitações do Radius Dynamic

Permite o gerenciamento central simplificado das sessões de assinantes enviando alterações não solicitadas às sessões de assinantes, incluindo mudanças nos atributos, ativação de serviços, desativação de serviços e terminação de sessão.

Mensagens de CoA

O suporte dinâmico à solicitação permite que o roteador receba e processe mensagens de CoA não solicitadas de servidores RADIUS externos. As mensagens de CoA iniciadas pelo RADIUS usam os seguintes códigos em mensagens de solicitação e resposta:

• Solicitação de CoA (43)

• CoA-ACK (44)

• CoA-NAK (45)

Qualificações para mudança de autorização

Para concluir a mudança de autorização para um usuário, você especifica atributos de identificação e atributos de sessão. Os atributos de identificação identificam o assinante. Os atributos de sessão especificam a operação (ativação ou desativação) para realizar na sessão do assinante e também incluem quaisquer atributos do cliente para a sessão (por exemplo, atributos QoS). A estrutura de serviço AAA lida com a solicitação real.

A Tabela 1 mostra os atributos de identificação das operações de CoA.

A Tabela 2 mostra os atributos da sessão para as operações da CoA. Quaisquer atributos adicionais do cliente que você incluir dependem de seus requisitos de sessão específicos.

Troca de mensagens

O servidor RADIUS e a estrutura de serviço AAA no roteador trocam mensagens usando UDP. A mensagem CoA-Request enviada pelo servidor RADIUS tem o mesmo formato do pacote Desconecte-Solicitação que é enviado para uma operação de desconexão.

A resposta é uma CoA-ACK ou uma mensagem CoA-NAK:

• Se a Estrutura de Serviços AAA mudar com sucesso a autorização, a resposta será um pacote formatado por RADIUS com uma mensagem CoA-ACK, e o filtro de dados é aplicado à sessão.

• Se a estrutura de serviço AAA não tiver sucesso, a solicitação estiver malformada ou os atributos estiverem faltando, a resposta será um pacote formatado em RADIUS com uma mensagem CoA-NAK.

Transações de CoA em massa

A partir do Junos OS Release 17.2R1, as solicitações de CoA em massa são apoiadas para melhorar a eficiência de processamento dos serviços de assinantes baseados em RADIUS no BNG. A funcionalidade CoA em massa permite o acúmulo de uma série de solicitações de CoA e compromete todos eles juntos, em massa, automaticamente.

As transações de CoA em massa são particularmente valiosas para serviços empresariais. Os serviços de assinantes baseados em RADIUS usam os VSAs da Juniper Networks, Activate-Service (26-65) e Deactivate-Service (26-66). Os VSAs são fornecidos em mensagens RADIUS-Accept durante o login ou em solicitações de CoA após o login.

Para serviços convencionais e dinâmicos baseados em perfil de serviços, até 12 ativações de serviços podem se encaixar facilmente em qualquer mensagem RADIUS. No entanto, os serviços baseados em script de operações usados pelas empresas normalmente têm requisitos de escalabilidade que excedem a capacidade de qualquer mensagem. Isso significa que especificar e ativar todos os serviços necessários em uma determinada sessão de assinantes pode exigir o uso de uma mensagem de acesso aceito e várias solicitações de CoA.

Cada mensagem de solicitação da CoA é independente de solicitações de CoA anteriores e futuras na mesma sessão de assinantes. Todas as ativações e desativações de serviços em uma mensagem são processadas antes que uma resposta à CoA seja oferecida. A solicitação da CoA fornece uma maneira de modificar incrementalmente uma sessão de assinantes sem afetar os serviços existentes que já estão presentes.

Para serviços baseados em script de op, as sessões de serviço são criadas de forma colaborativa pelos processos authd e essmd de modo que a última operação inicie um compromisso de aplicar todas as interfaces lógicas de negócios estáticas resultantes a partir da solicitação da CoA. Como o tempo de comprometimento é geralmente a maior parte da aplicação de um serviço de negócios estático, há uma vantagem em empacotar tantas ativações ou desativações de serviços que se encaixam em uma mensagem RADIUS para usar com eficiência a janela de confirmação. Até que a operação de confirmação seja concluída, o BNG não pode aceitar uma solicitação de CoA subsequente para aplicar serviços comerciais adicionais para a mesma sessão de assinantes.

A CoA em massa melhora a eficiência do processamento de compromissos usando uma única ação de confirmação para todos os serviços na transação em massa. A transação em massa tem o efeito de gerenciar uma série de solicitações como uma meta-solicitação única. Ele adia o processamento de confirmação até que a solicitação final de CoA na transação em massa seja recebida.

A CoA em massa exige que cada solicitação individual contenha uma única instância do VSA da Juniper Networks Bulk-CoA-Transaction-Id (26-194). Este VSA identifica solicitações como pertencentes à mesma transação em massa; 26-194 devem ter o mesmo valor em todas as solicitações de CoA na série em massa. Cada transação em massa sucessiva na sessão deve ter um identificador diferente; por exemplo, três transações em massa sucessivas podem ter IDs de 1, 2 e 1, mas não podem ter IDs sucessivos de 1, 1 e 2. Na prática, o valor de Id de transação em massa normalmente é incrementado para várias transações em massa, mas isso não é necessário. Um valor de ID usado em uma determinada sessão de assinantes também pode ser usado em diferentes sessões de assinantes.

Cada solicitação de CoA em uma transação em massa tem seu próprio identificador único, fornecido por uma única instância do VSA (26-195) em cada CoA. Uma série crescente de valores para a ID é típica, mas não aplicada. Os valores podem ser reutilizados em uma determinada sessão e entre as sessões. A solicitação final de CoA na série é identificada por ter um valor de 0xFFFFFFFF para o Bulk-CoA-Identifier.

Benefícios da mudança de autorização iniciada pelo Radius

Permite que mudanças nos valores de atributos sejam dinamicamente empurradas para as sessões de assinantes, bem como ativação dinâmica e desativação de serviços de assinantes.

Desconectar mensagens

Para controlar centralmente a desconexão de assinantes de acesso remoto, o recurso de solicitação dinâmica RADIUS no roteador recebe e processa mensagens não solicitadas dos servidores RADIUS.

O recurso de solicitação dinâmica usa o formato existente de mensagens de solicitação de desconexão RADIUS e resposta. A desconexão iniciada pelo RADIUS usa os seguintes códigos em suas mensagens de solicitação e resposta RADIUS:

• Solicitação de desconexão (40)

• Desconecte-ACK (41)

• Desconectamento-NAK (42)

Qualificações para desconectar

Para que a estrutura de serviços AAA desconecte um usuário, a mensagem de solicitação de desconexão deve conter um atributo com um ID de sessão de contabilidade. A mensagem de solicitação de desconexão pode conter um atributo Acct-Session-Id (44) ou um atributo Acct-Multi-Session-Id (50) para o ID da sessão ou ambos. Se os atributos Acct-Session-Id e Acct-Multi-Session-Id estiverem presentes na solicitação, o roteador usará ambos os atributos. Se o atributo Nome do usuário (1) também estiver presente na solicitação, o nome de usuário e a ID da sessão de contabilidade serão usados para realizar a desconexão. A estrutura de serviço AAA lida com a solicitação real.

Troca de mensagens

O servidor RADIUS e a estrutura de serviço AAA trocam mensagens usando UDP. A mensagem de solicitação de desconexão enviada pelo servidor RADIUS tem o mesmo formato do pacote CoA-Request que é enviado para uma mudança na operação de autorização.

A resposta de desconexão é uma desconecte-ACK ou uma mensagem Desconecte-NAK:

• Se a estrutura de serviço AAA desconectar com sucesso o usuário, a resposta será um pacote formatado em RADIUS com uma mensagem Desconecte-ACK.

• Se a estrutura de serviço AAA não puder desconectar o usuário, a solicitação estiver malformada ou os atributos estiverem faltando na solicitação, a resposta será um pacote formatado por RADIUS com uma mensagem Disconnect-NAK.

Benefícios das desconexões iniciadas pelo radius

Permite que um servidor RADIUS encerre dinamicamente as sessões de assinantes. Esse recurso centralizado de gerenciamento de assinantes simplifica o manuseio de um grande número de assinantes porque a rescisão da operadora exigiria ação no roteador.

Processo de ativação da família de serviços e rede

Quando um assinante faz login, o authd precisa ativar a família de endereços correspondente após a autenticação do assinante. O aplicativo do cliente, como DHCP ou PPP, pode solicitar a ativação de uma única família de rede, IPv4 ou IPv6, ou pode solicitar sequencialmente que ambas as famílias sejam ativadas. A ativação bem-sucedida da família de rede está relacionada à ativação de serviços associados. As etapas a seguir descrevem o processo quando authd está configurado para usar o RADIUS para autenticação:

1. Um assinante tenta fazer login.

   1. O aplicativo do cliente solicita autenticação do authd.

   2. authd envia uma mensagem de solicitação de acesso ao servidor RADIUS.

   3. O servidor RADIUS envia uma mensagem de aceitação de acesso ao authd que inclui o RADIUS Activate-Service VSA (26-65).

   4. authd caches os atributos de ativação de serviço e envia uma doação para o aplicativo do cliente.

2. O aplicativo do cliente envia a primeira solicitação network-family-Activate para a família de endereços IPv4 ou IPv6. Essa solicitação é às vezes referida como a solicitação de ativação do cliente.

3. authd analisa os atributos de ativação de serviços em cache e envia uma solicitação de ativação para os serviços apropriados para a infraestrutura de gerenciamento de assinantes (SMI). Por exemplo, se a solicitação for para a família IPv4, ela solicita ativação apenas dos serviços IPv4. Por sua vez, a SMI envia solicitações aos daemons de servidor associados ao serviço, como cosd ou filtrado.

4. O que authd faz a seguir depende se a solicitação de ativação do serviço falha e se o serviço é opcional ou necessário.

   • Quando a ativação do serviço falha devido a um erro de configuração e o serviço é opcional:

     1. authd exclui os atributos de ativação de serviços em cache para o serviço.

        Nota:

        Essa exclusão permite que você reemitir a solicitação de serviço usando uma solicitação de alteração DE RADIUS de autorização (CoA) ou um comando CLI, sem interferência do serviço com falha.

     2. authd envia uma ACK em resposta à solicitação de ativação da família e a família é ativada.

     3. Os lucros do login do assinante.

   • Quando a ativação do serviço falha devido a um erro de configuração e o serviço é necessário:

     1. authd exclui os atributos de ativação de serviços em cache para o serviço.

        Nota:

        Essa exclusão permite que você reemitir a solicitação de serviço usando uma solicitação de alteração DE RADIUS de autorização (CoA) ou um comando CLI, sem interferência do serviço com falha.

     2. authd envia um NACK em resposta à ativação da família, o que faz com que o aplicativo do cliente encerre o login do assinante.

   • Quando a ativação do serviço falha devido a um erro de não configuração, o serviço é opcional ou necessário:

     1. authd exclui os atributos de ativação de serviços em cache para o serviço.

        Nota:

        Essa exclusão permite que você reemitir a solicitação de serviço usando uma solicitação de alteração DE RADIUS de autorização (CoA) ou um comando CLI, sem interferência do serviço com falha.

     2. authd envia um NACK em resposta à ativação da família, o que faz com que o aplicativo do cliente encerre o login do assinante.

   • Quando a ativação do serviço for bem sucedida:

     1. authd ativa o serviço.

     2. authd envia uma ACK em resposta à solicitação de ativação da família e a família é ativada.

     3. Os lucros do login do assinante.

5. A menos que a ativação do serviço fosse necessária e falhasse, fazendo com que a ativação da família falhasse na primeira solicitação, o aplicativo do cliente pode enviar uma segunda solicitação, mas apenas para a família não solicitada da primeira vez. Se a primeira solicitação foi para IPv4, a segunda solicitação só pode ser para IPv6. Se a primeira solicitação foi para iPv6, então a segunda solicitação só pode ser para IPv4.

6. authd analisa os atributos de ativação de serviços em cache e as solicitações de ativação dos serviços associados à família de endereços solicitados.

7. O que authd faz a seguir depende se a solicitação de ativação do serviço falha e se o serviço é opcional ou necessário.

   • Quando a ativação do serviço falha devido a um erro de configuração e o serviço é opcional:

     1. authd exclui os atributos de ativação de serviços em cache para o serviço.

        Nota:

        Essa exclusão permite que você reemitir a solicitação de serviço usando uma solicitação de alteração DE RADIUS de autorização (CoA) ou um comando CLI, sem interferência do serviço com falha.

     2. authd envia uma ACK em resposta à solicitação de ativação da família e a família é ativada.

     3. Os lucros do login do assinante.

   • Quando a ativação do serviço falha devido a um erro de configuração e o serviço é necessário:

     1. authd exclui os atributos de ativação de serviços em cache para o serviço.

        Nota:

        Essa exclusão permite que você reemitir a solicitação de serviço usando uma solicitação de alteração DE RADIUS de autorização (CoA) ou um comando CLI, sem interferência do serviço com falha.

     2. authd envia um NACK em resposta à ativação da família. Como esta é a segunda solicitação de ativação familiar, o resultado da ativação da primeira família determina o que acontece a seguir:

        • Se a primeira ativação da família foi bem sucedida e esse assinante entrou, a falha da segunda solicitação não interrompe o login atual do assinante. Este evento também não faz com que authd registre o assinante anterior (primeira solicitação).

        • Se a primeira ativação da família não tiver sido bem sucedida, a falha da segunda solicitação faz com que o aplicativo do cliente encerre o login atual do assinante.

   • Quando a ativação do serviço falha devido a um erro de não configuração, o serviço é opcional ou necessário:

     1. authd exclui os atributos de ativação de serviços em cache para o serviço.

        Nota:

        Essa exclusão permite que você reemitir a solicitação de serviço usando uma solicitação de alteração DE RADIUS de autorização (CoA) ou um comando CLI, sem interferência do serviço com falha.

     2. authd envia um NACK em resposta à ativação da família, o que faz com que o aplicativo do cliente encerre o login do assinante.

   • Quando a ativação do serviço for bem sucedida:

     1. authd ativa o serviço.

     2. authd envia uma ACK em resposta à solicitação de ativação da família e a família é ativada.

     3. Os lucros do login do assinante.

Propósito

Exibir estatísticas e informações da solicitação dinâmica do RADIUS.

Ação

• Para exibir estatísticas de solicitação dinâmica do RADIUS: