Reautenticação radius como uma alternativa à RADIUS CoA para assinantes DHCP

Benefícios da reauthenticação

• Atualize ou modifique os atributos de sessão e os planos de serviço do assinante sem usar uma solicitação de CoA.

• Simplifique a ativação de serviços resultantes de mudanças frequentes iniciadas por assinantes.

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

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

Funcionalidade

A reauthenticação é suportada tanto para DHCPv4 quanto DHCPv6. Ele pode ser acionado quando o servidor local DHCP recebe uma mensagem de renovação, rebinada, descoberta ou solicitação de mensagem de um cliente DHCP. As mensagens de descoberta e solicitação suportam a reauthenticação a partir do Junos OS Release 18.1R1. O suporte para a descoberta e solicitação de mensagens significa que se um CPE com um cliente vinculado reiniciar e o cliente enviar uma dessas mensagens para aumentar a sessão, a reauthenticação permite que authd obtenha quaisquer atualizações que tenham sido feitas para o assinante.

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

• A reauthenticate lease-renewal declaração especifica que a reauthenticação é desencadeada quando qualquer uma das quatro mensagens apoiadas é recebida.

• A reauthenticate remote-id-mismatch declaração especifica que a reauthenticação só é acionada quando a mensagem recebida inclui uma mudança no valor do ID remoto do agente do cliente DHCP. O valor do atributo inclui o nome do plano de serviço do assinante, de modo que uma mudança de valor significa uma mudança no serviço para o assinante.

• O Juniper Networks reauthentication-on-renew VSA (26-206), quando devolvido com um valor de 1 na mensagem de aceitação de acesso do servidor RADIUS para o assinante no login, desencadeia a reauthenticação no recebimento de qualquer uma das quatro mensagens. Um valor de 0 desativa a reauthenticação. O valor do VSA é armazenado no banco de dados de sessão sempre que ele é recebido. Após este VSA ter habilitado a reauthenticação, ele é verificado em cada tentativa de reauthenção. Se o valor tiver mudado para 0 — isto é, se um Access-Accept subsequente devolver o VSA com um valor de 0 — o processo de reauthenticação para esse assinante.

  A configuração (reauthenticate declaração) do CLI e o comportamento reauthenticato-on-renew são aditivos. Desativar a reauthentação com o VSA só tem um efeito quando a reauthenticate declaração não está configurada. Quando a reauthenticate declaração é configurada com qualquer uma das opções, ela substitui um valor VSA de 0. Na ausência da configuração CLI, o VSA pode permitir a reauthenticação por si só.

O processo de reauthenticação é quase idêntico ao processo de autenticação original. Quando a reauthenticação é desencadeada, o processo jdhcpd no servidor local envia uma solicitação de autenticação ao 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 devolvidos na mensagem original de aceitação de acesso. Esses atributos permitem que o servidor RADIUS distingue a solicitação de reauthenticação das solicitações de login (autenticação).

O servidor RADIUS retorna uma mensagem de aceitação de acesso para authd com novos atributos para o assinante. O processo authd envia um reconhecimento (ACK) com as mudanças para jdhcpd, que envia uma oferta de DHCP ao cliente DHCP com atributos alterados. A negociação do DHCP continua como de costume, como mostrado na Figura 1, e a sessão de assinantes continua com os novos valores de atributo. Quando a reauthenticação inclui uma mudança no plano de serviço, o servidor RADIUS retorna o novo plano com quaisquer outros atributos alterados, se aceitar a solicitação, conforme mostrado na Figura 2. Se o CPE que hospeda o cliente DHCP reiniciar durante o processo de mudança de um plano de serviço, a reauthenticação com o novo plano será suportada sem interrupções no serviço.

Se o servidor RADIUS rejeitar uma solicitação de reauthenticação ou tempos fora, o authd envia um NAK para jdhcpd, que analisa o código de erro incluído. Se o código de erro indicar um tempo limite, o jdhcpd envia uma ACK para o cliente DHCP e a sessão de assinantes é mantida com os atributos e serviço originais. Para qualquer outro código de erro, o jdhcpd envia um DHCPv4 NAK ou DHCPv6 REPLY (com o valor de vida definido para 0) como um NAK lógico, inicia o logotipo do assinante e apaga o assinante do banco de dados da sessão.

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

Quando a reauthenticação resulta em uma mudança no endereço IP ou IPv6 de um assinante DHCPv6 após a vinculação de um cliente, o servidor DHCPv6 avalia a solicitação de mudança de endereço. O servidor devolve um código de status ao 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 a IA na solicitação do cliente. Ele retorna a IA sem endereços e NoAddrsAvail.

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

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

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

Assinantes dual-stack

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

A partir do Junos OS Release 18.1R1, a autenticação e reauthenticação por família são suportadas para assinantes de dupla pilha e sessão única. Um assinante de dupla pilha e sessão única é tipicamente uma casa com sua própria VLAN em um modelo de acesso 1:1. A casa é representada como um único assinante com uma única sessão no banco de dados da sessão, mas tem duas vinculações DHCP separadas, uma para cada família, DHCPv4 e DHCPv6. Consequentemente, o authd envia solicitações de acesso separadas conforme cada família nos logs de sessão ou tenta reauthenticar:

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

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

A autenticação e a reauthenticação são processadas por família. A primeira família a acionar o processo é atendida antes que a outra (segunda) família desencadeie a autenticação ou reauthenticação. Mensagens da segunda família são ignoradas até que a primeira família esteja 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, somente uma autenticação será processada. As reauthenticações são processadas apenas para a única família cliente.

O processo authd classifica atributos como pertencentes à família DHCPv4 ou DHCPv6 e os marca de acordo. Tanto para autenticação quanto para reauthenticaçã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 devolver 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 de aceitação de acesso, as tags da família permitem que authd determine quais atributos correspondem à família solicitante ou à outra família (sem solicitação). Somente os atributos da família de solicitação estão escritos no banco de dados da sessão.

Para solicitações de reauthenticação, o authd compara os atributos devolvidos ao banco de dados da sessão para determinar se alguma alteração foi feita no servidor RADIUS. Novamente, apenas as alterações que correspondem à família de solicitação são escritas no banco de dados da sessão, sobrescrevendo os valores antigos.

As mudanças durante a reauthenticação são processadas da seguinte forma:

• Atributo (que não seja endereço)— Quando o authd determina que um ou mais desses atributos mudaram para a família de solicitações, ele armazena os novos valores no banco de dados da sessão. Após authd notificar o jdhcpd, ele envia uma ACK ao cliente DHCP com os novos valores de atributo.

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

  Se a família solicitante for a única família vinculada, o jdhcpd registra graciosamente o assinante. Se a família não remediante também estiver vinculada, o jdhcpd desativa a família solicitante, mas deixa a ligação da família não remedida intacto, sem interrupção no serviço à família que não solicita. A desativação da família requisitada não tem efeito sobre um desencadeamento subsequente de reauthenticação pela família não exigente.

  Quando a família desativada posteriormente envia uma mensagem de descoberta ou solicitação para fazer login, uma solicitação de acesso é enviada para reauthenticaçã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 reauthenticação com uma mensagem de rejeição de acesso, o authd notifica o servidor local DHCP, que por sua vez envia um NAK (DHCPv4) ou um NAK lógico (DHCPv6) para o cliente DHCP. A família solicitante é terminada graciosamente; a família está desativada e o assinante está logado. Em seguida, a família não solicitante é desativada e registrada, mas o cliente não é notificado sobre a rescisão.

Se a detecção de liveness estiver sendo executada na família sem solicitação, o cliente detecta perda de conexão quando a família é terminada e, posteriormente, envia uma mensagem de descoberta ou solicitação ao servidor local DHCP. No entanto, se a detecção de liveness não estiver sendo executada, o cliente não detectará perda de conexão até que o tempo de rebinagem (T2, opção 59) expira e o serviço seja perdido. Dependendo da duração do aluguel, 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 assinantes entre um cliente DHCP, um servidor DHCP e o servidor RADIUS. O plano de serviço do cliente é especificado na segunda sub-linha no ID remoto contido na opção DHCPv4 82, suboption 2 ou DHCPv6 opção 37.

• 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 termos a seguir são usados na figura:

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

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 reauthenticação

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