Reauthenticação radius como uma alternativa ao 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 reauthenticação por meio da configuração CLI ou de um RADIUS VSA.

Funcionalidade

A reauthentação é suportada tanto para DHCPv4 quanto DHCPv6. Ele pode ser acionado quando o servidor local DHCP recebe uma mensagem renovada, rebinada, descoberta ou solicitação de um cliente DHCP. As mensagens de descoberta e solicitação oferecem suporte à reauthenticaçã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 reinicializar e o cliente enviar uma dessas mensagens para trazer a sessão de volta, a reauthenticação permite que authd obtenha quaisquer atualizações que tenham sido feitas para o assinante.

O comportamento da reauthentização é determinado da seguinte forma:

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

• A reauthenticate remote-id-mismatch declaração especifica que a reauthençã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, portanto, uma mudança de valor significa uma mudança no serviço para o assinante.

• O VSA da Juniper Networks reauthentication-on-renew (26-206), quando devolvido com um valor de 1 na mensagem Access-Accept do servidor RADIUS para o assinante no login, aciona 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 é recebido. Depois que este VSA permitir a reauthenticação, ele é verificado em cada tentativa de reauthenticação. Se o valor tiver mudado para 0 — ou seja, se um Access-Accept subsequente devolver o VSA com um valor de 0 — o processo de reauthenticação para esse assinante.

  A configuração de CLI (reauthenticate declaração) e o comportamento Reauthenticate-On-Renew são aditivos. A desativação da reauthenção com o VSA só afeta quando a reauthenticate declaração não está configurada. Quando a reauthenticate declaração é configurada com qualquer opção, 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 é acionada, 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.

Esta 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 devolve uma mensagem de aceitação de acesso para authd com novos atributos para o assinante. O processo de authd envia um reconhecimento (ACK) com as mudanças no jdhcpd, que envia uma oferta DHCP ao cliente DHCP com atributos alterados. A negociação de 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 reauthençã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 reinicializar durante o processo de mudança de um plano de serviço, a reauthenticação com o novo plano é suportada sem interrupções no serviço.

Se o servidor RADIUS rejeitar uma solicitação de reauthenticação ou um tempo de saída, o authd enviará 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 ao cliente DHCP e a sessão do assinante é 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 exclui o assinante do banco de dados da sessão.

A Tabela 1 descreve como processos authd solicitações quando um tipo de solicitação diferente 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 designar nenhum endereço para a IA na solicitação do cliente. Ele retorna a IA sem endereços e NoAddrsAvail.

• NãoOnLink (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 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 vinculações DHCP separadas, uma para cada família, DHCPv4 e DHCPv6. Consequentemente, a authd envia solicitações de acesso separadas como cada família nos logs de sessão ou tentativas de reauthenticar:

• 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 init DHCP.

• A reauthentação por família ocorre quando a reauthenção e a alocação de endereço sob demanda são configuradas e uma mensagem renovada, 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. As 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, apenas uma autenticação será processada. Reauthenticações são processadas apenas para uma única família de clientes.

O processo de authd classifica atributos como pertencentes à família DHCPv4 ou DHCPv6 e os marca em conformidade. Para autenticação e 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 access-accept, as tags da família permitem que authd determine quais atributos correspondem à família requisitada ou à outra família (sem solicitação). Apenas os atributos da família de solicitação sã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 de sessão para determinar se alguma alteração foi feita no servidor RADIUS. Mais uma vez, apenas as alterações correspondentes à 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 (diferente do endereço)— Quando authd determina que um ou mais desses atributos mudaram para a família solicitante, ele armazena os novos valores no banco de dados de sessão. Após authd notificar o jdhcpd, ele envia uma ACK ao cliente DHCP com os novos valores de atributo.

• Endereço ou pool de endereço — 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 de solicitação for a única família vinculada, o jdhcpd registra o assinante de maneira graciosa. Se a família não remedida também estiver vinculada, o jdhcpd desativa a família solicitante, mas deixa intacta a vinculação da família não remedida, sem interrupção no serviço à família que não solicita. A desativação da família requisitadora não surtiu efeito sobre o desencadeamento subsequente da reauthenticação pela família não requestre.

  Quando a família desativada envia posteriormente 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 reauthenção com uma mensagem de rejeição de acesso, 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 de solicitação é encerrada de maneira graciosa; a família está desativada e o assinante está logado. Em seguida, a família não reemproduto é desativada e registrada, mas o cliente não é notificado sobre o término.

Se a detecção de liveness estiver em execução na família sem solicitação, o cliente detecta a perda de conexão quando a família é encerrada 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 em execução, 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 assinante entre um cliente DHCP, um servidor DHCP e o servidor RADIUS. O plano de serviço do cliente é especificado na segunda subdestritura 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 DHCP ou assinante).

OLT — terminador de linha óptica — por exemplo, um multiplexer 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 de uma mudança de planos de serviço, de um plano de 100 Mbps a 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 sessão de assinantes reauthentantes mudam apenas se novos valores ou novos atributos forem recebidos na mensagem de aceitação de acesso.