Gerenciamento dinâmico de serviços com RADIUS

Benefícios das solicitações dinâmicas Radius

Permite o gerenciamento central simplificado de sessões de assinantes enviando alterações não solicitadas para sessões de assinantes, incluindo alterações em atributos, ativação de serviço, desativação de serviço e encerramento de sessão.

Mensagens de CoA

O suporte dinâmico a solicitações permite que o roteador receba e processe mensagens 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 alteração de autorização de um usuário, especificar 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) a ser executada na sessão do assinante e também incluem quaisquer atributos de cliente para a sessão (por exemplo, atributos de QoS). A Estrutura de Serviço AAA lida com a solicitação real.

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

A Tabela 2 mostra os atributos de sessão para operações de CoA. Quaisquer atributos de cliente adicionais 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 que o pacote Disconnect-Request enviado para uma operação de desconexão.

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

• Se a estrutura de serviço AAA alterar a autorização com êxito, a resposta será um pacote formatado em RADIUS com uma mensagem CoA-ACK e o filtro de dados será aplicado à sessão.

• Se o AAA Service Framework não for bem-sucedido, a solicitação estiver malformada ou os atributos estiverem ausentes, 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 suportadas para melhorar a eficiência de processamento de serviços de assinante baseados em RADIUS no BNG. A funcionalidade de CoA em massa permite o acúmulo de uma série de solicitações de CoA e confirma todas elas juntas, em massa, automaticamente.

Todos os serviços em uma solicitação de CoA em massa devem ser para a mesma sessão de assinante.

As transações de CoA em massa são particularmente valiosas para serviços empresariais. Os serviços de assinante 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 perfis de serviço, até 12 ativações de serviço podem caber facilmente em qualquer uma das mensagens RADIUS. No entanto, os serviços baseados em op-script usados pelas empresas normalmente têm requisitos de dimensionamento 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 assinante pode exigir o uso de uma mensagem Accept-Access e várias solicitações de CoA.

Cada mensagem de solicitação de CoA é independente de solicitações de CoA anteriores e futuras na mesma sessão do assinante. Todas as ativações e desativações de serviço em uma mensagem são processadas antes que uma resposta de CoA seja oferecida. A solicitação de CoA fornece uma maneira de modificar incrementalmente uma sessão de assinante 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 colaborativamente pelos processos authd e essmd, de modo que a última operação inicie uma confirmação para aplicar todas as interfaces lógicas de negócios estáticas resultantes da solicitação CoA. Como o tempo de confirmação é geralmente a maior parte da aplicação de um serviço de negócios estático, há uma vantagem em empacotar quantas ativações ou desativações de serviço couber 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 poderá aceitar uma solicitação de CoA subsequente para aplicar serviços de negócios adicionais para a mesma sessão de assinante.

O CoA em massa melhora a eficiência do processamento de confirmação 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 única meta-solicitação. Ele adia o processamento de confirmação até que a solicitação CoA final na transação em massa seja recebida.

O CoA em massa requer que cada solicitação individual contenha uma única instância do VSA Bulk-CoA-Transaction-Id da Juniper Networks (26–194). Esse 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 sucessivas de 1, 1 e 2. Na prática, o valor 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 assinante.

Cada solicitação de CoA em 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 a ID é típica, mas não imposta. Os valores podem ser reutilizados em uma determinada sessão e entre sessões. A solicitação CoA final na série é identificada por ter um valor de 0xFFFFFFFF para o Bulk-CoA-Identifier.

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

Permite que as alterações nos valores de atributos sejam enviadas dinamicamente para as sessões do assinante, bem como a ativação e desativação dinâmicas dos serviços do assinante.

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 de servidores RADIUS.

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

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

• Desconectar-ACK (41)

• Desconectar-NAK (42)

Qualificações para desconexão

Para que o AAA Service Framework desconecte um usuário, a mensagem Disconnect-Request deve conter um atributo com uma ID de sessão de contabilidade. A mensagem Disconnect-Request 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á os dois atributos. Se o atributo User-Name (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 executar a desconexão. A Estrutura de Serviço AAA lida com a solicitação real.

Troca de mensagens

O servidor RADIUS e o AAA Service Framework trocam mensagens usando UDP. A mensagem Disconnect-Request enviada pelo servidor RADIUS tem o mesmo formato que o pacote CoA-Request enviado para uma operação de alteração de autorização.

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

• Se o AAA Service Framework desconectar o usuário com êxito, a resposta será um pacote formatado em RADIUS com uma mensagem Disconnect-ACK.

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

Benefícios das desconexões iniciadas por raio

Permite que um servidor RADIUS encerre dinamicamente sessões de assinante. Esse recurso de gerenciamento centralizado de assinantes simplifica o manuseio de um grande número de assinantes porque, caso contrário, a terminação do operador exigiria ação no roteador.

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

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 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 da 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 efetuar login.

   1. O aplicativo cliente solicita a 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. O authd armazena em cache os atributos de ativação do serviço e envia uma concessão ao aplicativo cliente.

2. O aplicativo cliente envia a primeira solicitação Network-Family-Activate, para a família de endereços IPv4 ou IPv6. Às vezes, essa solicitação é chamada de solicitação de ativação do cliente.

3. authd revisa os atributos de ativação de serviço armazenados 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 solicitará a ativação apenas dos serviços IPv4. Por sua vez, o SMI envia solicitações aos daemons do servidor associados ao serviço, como cosd ou filterd.

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 obrigató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ço armazenados em cache para o serviço.

        Observação:

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

     2. authd envia um 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 exclui os atributos de ativação de serviço armazenados em cache para o serviço.

        Observação:

        Essa exclusão permite que você emita novamente a solicitação de serviço usando uma solicitação de mudança de autorização (CoA) RADIUS 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 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 obrigatório:

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

        Observação:

        Essa exclusão permite que você emita novamente a solicitação de serviço usando uma solicitação de mudança de autorização (CoA) RADIUS 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 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 um 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 tenha sido necessária e tenha falhado, fazendo com que a ativação da família falhe na primeira solicitação, o aplicativo cliente pode enviar uma segunda solicitação, mas apenas para a família não solicitada na 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, a segunda solicitação só pode ser para IPv4.

6. O AUTHD revisa os atributos de ativação do serviço armazenado em cache e solicita a ativação dos 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 obrigató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ço armazenados em cache para o serviço.

        Observação:

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

     2. authd envia um 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 exclui os atributos de ativação de serviço armazenados em cache para o serviço.

        Observação:

        Essa exclusão permite que você emita novamente a solicitação de serviço usando uma solicitação de mudança de autorização (CoA) RADIUS 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 essa é a segunda solicitação de ativação da família, o resultado da primeira ativação da família determina o que acontece a seguir:

        • Se a primeira ativação da família tiver sido bem-sucedida e esse assinante tiver feito login, a falha da segunda solicitação não interromperá o login do assinante atual. Esse evento também não faz com que authd faça logout do assinante anterior (primeira solicitação).

        • Se a primeira ativação da família não for bem-sucedida, a falha da segunda solicitação fará com que o aplicativo 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 obrigatório:

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

        Observação:

        Essa exclusão permite que você emita novamente a solicitação de serviço usando uma solicitação de mudança de autorização (CoA) RADIUS 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 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 um ACK em resposta à solicitação de ativação da família e a família é ativada.

     3. O login do assinante continua.

Finalidade

Exiba estatísticas e informações de solicitações dinâmicas do RADIUS.

Ação

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