Gerenciamento dinâmico de serviços com RADIUS

Benefícios das solicitações da 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 encerramento 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 completar 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ços 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 de 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 Aaa Service Framework nas mensagens de troca de roteador usando UDP. A mensagem de CoA-Request enviada pelo servidor RADIUS tem o mesmo formato do pacote Desconectar-solicitação que é enviado para uma operação de desconexão.

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

• Se a AAA Service Framework mudar com sucesso a autorização, a resposta será um pacote em formato 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 em formato 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 suportadas 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ço, até 12 ativações de serviço 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 escalonamento 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 aceitação e várias solicitações de CoA.

Cada mensagem de solicitação de CoA é independente das solicitações anteriores e futuras da CoA 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 gradualmente uma sessão de assinantes sem afetar os serviços existentes que já estão presentes.

Para serviços baseados em op-script, as sessões de serviço são criadas de forma colaborativa pelos processos de 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, existe uma vantagem em empacotar tantas ativações ou desativações de serviços que se encaixam em uma mensagem RADIUS para usar eficientemente a janela de compromisso. Até que a operação de compromisso seja concluída, o BNG não pode aceitar uma solicitação de CoA subseqüente 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 compromisso 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 única meta-solicitação. Ele adia o processamento de compromisso até que a solicitação final de CoA na transação em massa seja recebida.

O CoA em massa exige que cada solicitação individual contenha uma única instância do Juniper Networks Bulk-CoA-Transaction-Id VSA (26-194). Este VSA identifica solicitações como pertencentes à mesma transação em massa; 26-194 deve 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 sucessivas de 1, 1 e 2. Na prática, o valor do Bulk-CoA-Transaction-Id 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 assinante também pode ser usado em diferentes sessões de assinantes.

Cada solicitação de CoA dentro de uma transação em massa tem seu próprio identificador exclusivo, fornecido por uma única instância do VsA Bulk-CoA-Identifier (26-195) em cada CoA. Uma série crescente de valores para o ID é típica, mas não aplicada. Os valores podem ser reutilizados em uma determinada sessão e entre sessões. A solicitação final de CoA da 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 empurrados para 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 solicitação de desconexão RADIUS e mensagens de 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)

• Disconnect-ACK (41)

• Desconecte-NAK (42)

Qualificações para desconectar

Para que a ESTRUTURA de serviço AAA desconecte um usuário, a mensagem Desconecte-solicitação deve conter um atributo com um ID de sessão contábil. A mensagem desconecte-solicitaçã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 o ID da sessão de contabilidade serão usados para realizar a desconexão. A Estrutura de Serviços AAA lida com a solicitação real.

Troca de mensagens

O servidor RADIUS e a AAA Service Framework 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 operação de alteração de autorização.

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

• Se a Aaa Service Framework desconectar o usuário com sucesso, a resposta será um pacote em formato RADIUS com uma mensagem Disconnect-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 em formato RADIUS com uma mensagem Disconnect-NAK.

Benefícios das desconexões iniciadas pelo raio

Permite que um servidor RADIUS encerre dinamicamente as sessões de assinantes. Esse recurso centralizado de gerenciamento de assinantes simplifica o tratamento de um grande número de assinantes, porque o encerramento da operadora exigiria ações 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 o authd é 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 para authd que inclui o RADIUS Activate-Service VSA (26-65).

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

2. O aplicativo do cliente envia a primeira solicitação de ativação da família de rede para a família de endereços IPv4 ou IPv6. Esta 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 dos 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 para os 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 elimina 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 autorização de RADIUS (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. O login do assinante continua.

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

     1. authd elimina 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 autorização de RADIUS (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 e o serviço é opcional ou necessário:

     1. authd elimina 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 autorização de RADIUS (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. O login do assinante continua.

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 pela primeira vez. Se a primeira solicitação fosse para IPv4, a segunda solicitação só pode ser para IPv6. Se a primeira solicitação fosse para IPv6, a segunda solicitação só pode ser para IPv4.

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

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 elimina 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 autorização de RADIUS (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. O login do assinante continua.

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

     1. authd elimina 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 autorização de RADIUS (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 ativação da primeira família foi bem-sucedida e esse assinante fez login, a falha da segunda solicitação não interrompe o login atual do assinante. Esse evento também não faz com que o usuário faça login com o assinante anterior (primeira solicitação).

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

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

     1. authd elimina 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 autorização de RADIUS (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. O login do assinante continua.

Propósito

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

Ação

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