Reautenticação RADIUS como alternativa ao RADIUS CoA para assinantes DHCP

Benefícios da reautenticação

• Atualizar ou modificar atributos de sessão do assinante e planos de serviço sem usar uma solicitação de CoA.

• Simplifique a ativação de serviços resultantes de alterações frequentes iniciadas pelo assinante.

• Habilite a reautenticação por família em configurações de pilha dupla e sessão única.

• Controle a reautenticação por meio da configuração da CLI ou de um RADIUS VSA.

Funcionalidade

A reautenticação é compatível com DHCPv4 e DHCPv6. Ele pode ser disparado quando o servidor local DHCP recebe uma mensagem de renovação, reassociação, descoberta ou solicitação de um cliente DHCP. As mensagens de descoberta e solicitação oferecem suporte à reautenticação a partir do Junos OS Release 18.1R1. O suporte para as mensagens de descoberta e solicitação significa que, se um CPE com um cliente vinculado for reinicializado e o cliente enviar uma dessas mensagens para ativar a sessão novamente, a reautenticação permitirá que o authd obtenha todas as atualizações feitas para o assinante.

O comportamento de reautenticação é determinado da seguinte forma:

• A reauthenticate lease-renewal instrução especifica que a reautenticação é disparada quando qualquer uma das quatro mensagens suportadas é recebida.

• A reauthenticate remote-id-mismatch instrução especifica que a reautenticação é disparada somente quando a mensagem recebida inclui uma alteração no valor da ID remota do agente do cliente DHCP. O valor do atributo inclui o nome do plano de serviço do assinante, portanto, uma alteração no valor significa uma mudança no serviço para o assinante.

• O VSA da Juniper Networks reauthentication-on-renew (26-206), quando retornado com um valor de 1 na mensagem Access-Accept do servidor RADIUS para o assinante no login, aciona a reautenticação no recebimento de qualquer uma das quatro mensagens. Um valor de 0 desabilita a reautenticação. O valor VSA é armazenado no banco de dados da sessão sempre que é recebido. Depois que esse VSA tiver habilitado a reautenticação, ele será verificado a cada tentativa de reautenticação. Se o valor tiver sido alterado para 0, ou seja, se um Access-Accept subsequente retornar o VSA com um valor de 0, o processo de reautenticação será interrompido para esse assinante.

  A configuração da CLI (reauthenticate declaração) e o comportamento Reauthenticate-On-Renew são aditivos. Desabilitar a reautenticação com o VSA tem efeito somente quando a reauthenticate instrução não está configurada. Quando a reauthenticate instrução é configurada com qualquer uma das opções, ela substitui um valor VSA de 0. Na ausência da configuração da CLI, o VSA pode habilitar a reautenticação por si só.

O processo de reautenticação é quase idêntico ao processo de autenticação original. Quando a reautenticação é acionada, o processo jdhcpd no servidor local envia uma solicitação de autenticação para authd, que por sua vez envia uma mensagem de solicitação de acesso ao servidor RADIUS para solicitar uma segunda autenticação.

Essa solicitação de acesso inclui atributos de estado e classe RADIUS que foram retornados na mensagem Access-Accept original. Esses atributos permitem que o servidor RADIUS diferencie a solicitação de reautenticação das solicitações de login (autenticação).

O servidor RADIUS retorna uma mensagem Access-Accept para authd com novos atributos para o assinante. O processo authd envia uma confirmação (ACK) com as alterações para jdhcpd, que envia uma oferta DHCP para o cliente DHCP com atributos alterados. A negociação DHCP continua como de costume, como mostra a Figura 1, e a sessão do assinante continua com os novos valores de atributo. Quando a reautenticação inclui uma alteração no plano de serviço, o servidor RADIUS retorna o novo plano com quaisquer outros atributos alterados, se aceitar a solicitação, como mostra a Figura 2. Se o CPE que hospeda o cliente DHCP for reinicializado durante o processo de alteração de um plano de serviço, a reautenticação com o novo plano será suportada sem interrupção no serviço.

Se o servidor RADIUS rejeitar uma solicitação de reautenticação ou atingir o tempo limite, o authd enviará um NAK para o jdhcpd, que analisará o código de erro incluído. Se o código de erro indicar um tempo limite, o jdhcpd enviará um ACK para o cliente DHCP e a sessão do assinante será mantida com os atributos e o serviço originais. Para qualquer outro código de erro, o jdhcpd envia um DHCPv4 NAK ou DHCPv6 REPLY (com o valor de tempo de vida definido como 0) como um NAK lógico, inicia o logout do assinante e exclui o assinante do banco de dados da sessão.

A Tabela 1 descreve como o authd processa solicitações quando um tipo de solicitação diferente já está em andamento para o mesmo assinante.

Quando a reautenticação resulta em uma alteração no endereço IP ou IPv6 de um assinante DHCPv6 após um cliente ser vinculado, o servidor DHCPv6 avalia a solicitação de alteração de endereço. O servidor retorna um código de status para o cliente na associação de identidade (IA) da PDU de resposta. A partir do Junos OS Release 18.4R1, quando o servidor DHCPv6 descobre um problema com o endereço, um código de status para NotOnLink é suportado, além dos códigos anteriormente suportados para NoAddrsAvail e NoPrefixAvail. Esses códigos de status são definidos da seguinte forma:

• NoAddrsAvail (2) — O servidor não pode atribuir nenhum endereço para o IA na solicitação do cliente. Ele retorna o IA sem endereços e NoAddrsAvail.

• NotOnLink (4) — O servidor determina que o prefixo de um ou mais endereços em qualquer IA na solicitação do cliente não é apropriado para o link que se conecta ao cliente. Esse código também é usado no caso de uma falha de reautenticação (RADIUS Access-Reject).

• NoPrefixAvail (6) — O servidor não tem prefixos disponíveis para o IA na solicitação do cliente.

Se o cliente receber o código de status NotOnLink, ele poderá enviar outra solicitação sem nenhum endereço ou reiniciar o processo de negociação. Se ele enviar uma solicitação, o serer local DHCPv6 ignorará a solicitação, esperando que uma nova renegociação comece.

Assinantes Dual-Stack

Em versões anteriores ao Junos OS Release 18.1R1, os assinantes DHCP de pilha dupla são tratados como sessões de cliente independentes. Cada pilha é renovada e obtém novos serviços de forma independente.

A partir do Junos OS Release 18.1R1, a autenticação e a reautenticação por família são suportadas para assinantes de pilha dupla e sessão única. Um assinante de pilha dupla e sessão única é normalmente uma casa com sua própria VLAN em um modelo de acesso 1:1. A família é representada como um único assinante com uma única sessão no banco de dados de sessão, mas tem duas associações DHCP separadas, uma para cada família, DHCPv4 e DHCPv6. Consequentemente, o authd envia solicitações de acesso separadas à medida que cada família na sessão faz login ou tenta se autenticar novamente:

• A autenticação por família ocorre quando uma mensagem de descoberta ou solicitação é recebida enquanto uma sessão de assinante está no estado de inicialização DHCP.

• A reautenticação por família ocorre quando a reautenticação e a alocação de endereço sob demanda são configuradas e uma mensagem de renovação, reassociação, descoberta ou solicitação é recebida para a sessão da família enquanto ela está no estado vinculado ao DHCP.

A autenticação e a reautenticação são processadas por família. A primeira família a acionar o processo é atendida antes que a outra (segunda) família acione a autenticação ou reautenticação. As mensagens da segunda família são ignoradas até que a primeira família seja vinculada. Em seguida, a segunda solicitação da família é processada.

Se apenas uma família da sessão única de pilha dupla fizer login, apenas uma autenticação será processada. As reautenticações são processadas apenas para uma família de clientes.

O processo authd classifica atributos como pertencentes à família DHCPv4 ou DHCPv6 e os marca de acordo. Para autenticação e reautenticação, dependendo de qual família inicia a solicitação, o authd inclui o DHCP-Options VSA (26-55) ou o DHCPv6-Options VSA (26-65). Dependendo de sua configuração, o servidor RADIUS pode retornar informações apenas para a família que iniciou a solicitação (a família solicitante) ou para ambas as famílias.

Quando authd recebe atributos na mensagem Access-Accept, as tags de família permitem que authd determine quais atributos correspondem à família solicitante ou à outra família (não solicitante). Somente os atributos da família solicitante são gravados no banco de dados de sessão.

Para solicitações de reautenticação, o authd compara os atributos retornados ao banco de dados de sessão para determinar se alguma alteração foi feita no servidor RADIUS. Novamente, somente as alterações que correspondem à família solicitante são gravadas no banco de dados de sessão, substituindo os valores antigos.

As alterações durante a reautenticação são processadas da seguinte forma:

• Atributo (diferente de endereço) — Quando authd determina que um ou mais desses atributos foram alterados para a família solicitante, ele armazena os novos valores no banco de dados da sessão. Depois que o authd notifica o jdhcpd, ele envia um ACK para o cliente DHCP com os novos valores de atributo.

• Endereço ou pool de endereços — Quando o authd detecta uma alteração para a família solicitante, ele notifica o servidor local DHCP, que por sua vez envia um NAK (DHCPv4) ou NAK lógico (DHCPv6) para o cliente DHCP.

  Se a família solicitante for a única família vinculada, o jdhcpd normalmente desconectará o assinante. Se a família não solicitante também estiver vinculada, o jdhcpd desativará a família solicitante, mas deixará a vinculação da família não solicitante intacta, sem interrupção no serviço à família não solicitante. A desativação da família solicitante não tem efeito sobre um acionamento subsequente de reautenticação pela família não solicitante.

  Quando a família desativada envia posteriormente uma mensagem de descoberta ou solicitação para fazer login novamente, uma solicitação de acesso é enviada para reautenticação como de costume e o novo endereço recebido no Access-Accept é aplicado ao assinante.

Se o servidor RADIUS responder a uma solicitação de autenticação ou reautenticação com uma mensagem de rejeição de acesso, o authd notificará o servidor local DHCP, que por sua vez envia um NAK (DHCPv4) ou NAK lógico (DHCPv6) para o cliente DHCP. A família solicitante é encerrada graciosamente; a família é desativada e o assinante é desconectado. Em seguida, a família não solicitante é desativada e desconectada, mas o cliente não é notificado sobre o encerramento.

Se a detecção de atividade estiver sendo executada na família não solicitante, o cliente detectará a perda de conexão quando a família for encerrada e, posteriormente, enviará uma mensagem de descoberta ou solicitação ao servidor local DHCP. No entanto, se a detecção de atividade não estiver em execução, o cliente não detectará a perda de conexão até que o tempo de religação (T2, opção 59) expire e o serviço seja perdido. Dependendo da duração do contrato, isso pode levar muito tempo.

Fluxo de pacotes

A figura a seguir descreve a sequência para negociação inicial de uma sessão de assinante entre um cliente DHCP, um servidor DHCP e o servidor RADIUS. O plano de serviço do cliente é especificado na segunda substring na ID remota contida na opção 82 do DHCPv4, subopção 2 ou na opção 37 do DHCPv6.

• Negociação Inicial
• Mudança no plano de serviço

Negociação Inicial

A Figura 1 ilustra a sequência de etapas na negociação inicial entre um cliente DHCP, um servidor DHCP e o servidor RADIUS. Os seguintes termos são usados na figura:

CPE — Equipamento nas instalações do cliente (funciona como cliente DHCP ou assinante).

OLT — Terminador de linha óptica — por exemplo, um multiplexador de acesso DSL (DSLAM) ou outro dispositivo de agregação.

Dispositivo da Série MX — Funciona como o servidor DHCP.

Figura 1: Negociação inicial

Mudança no plano de serviço

A Figura 2 ilustra a sequência de etapas em uma mudança de planos de serviço, de um plano de 100 Mbps para um plano de 1 Gbps.:

Figura 2: Plano de serviço

Atributos RADIUS suportados para reautenticação

A Tabela 2 lista os atributos padrão RADIUS e VSAs que podem ser processados durante a reautenticação quando recebidos na mensagem RADIUS Access-Accept e descreve como authd lida com alterações em atributos. O processamento de atributos é consistente com o processamento de solicitações de CoA. As características da sessão do assinante de reautenticação são alteradas somente se novos valores ou novos atributos forem recebidos na mensagem de aceitação de acesso.