Opções de sessão para acesso ao assinante

Intervalos de sessão para assinantes

Você pode limitar o acesso ao assinante configurando um tempo limite de sessão ou um tempo limite ocioso. Use um tempo limite de sessão para especificar um período fixo de tempo que o assinante tem permissão para ter acesso. Use um tempo limite ocioso para especificar um período máximo de tempo que o assinante pode ficar ocioso. Você pode usar esses intervalos de tempo separadamente ou juntos. Por padrão, nenhum dos horários está presente.

Nota:

Para todos os tipos de assinantes que não sejam DHCP (como assinantes com túnel L2TP e encerramento de PPP), o valor do tempo de sessão limita a sessão do assinante. Para assinantes DHCP, o valor do tempo de sessão é usado para limitar o leasing quando nenhuma outra configuração de tempo de locação estiver presente. O contrato expira quando o valor do tempo limite expirar. Se esse valor não for fornecido pela CLI ou pelo RADIUS, o contrato de locação DHCP não expira.

O tempo limite ocioso é baseado em estatísticas contábeis para o assinante. O roteador determina a inatividade do assinante monitorando o tráfego de dados, tanto a montante do usuário (ingresso) quanto a jusante até o usuário (saída). O tráfego de controle é ignorado. O assinante não é considerado ocioso enquanto o tráfego de dados for detectado em qualquer direção.

Opcionalmente, você pode especificar que apenas o tráfego de ingresso de assinantes é monitorado; o tráfego de saída é ignorado. Essa configuração é útil nos casos em que o LNS envia tráfego para o peer remoto mesmo quando o peer não está ativo, como quando o LNS não tem keepalives PPP ativados e, portanto, não consegue detectar que o peer não está ativo. Nessa situação, porque por padrão o LAC monitora o tráfego de entrada e saída, ele detecta o tráfego de saída da LNS e não registra o assinante ou atrasa a detecção de inatividade até que o tráfego de saída cesse. Quando você especifica que apenas o tráfego de entrada é monitorado, o LAC pode detectar que o peer está inativo e, em seguida, iniciar o logout.

Quando um período de folga expira, os assinantes não DHCP são graciosamente logados, da mesma forma que uma desconexão iniciada pelo RADIUS ou um logout iniciado pela CLI. Os assinantes do DHCP estão desconectados. O valor do Acct-Terminate-Cause [atributo RADIUS 49] inclui um código de razão de 5 para um tempo limite de sessão e um código de 4 para um tempo limite ocioso.

Você pode configurar essas limitações ao acesso ao assinante por assinante usando os atributos RADIUS Session-Timeout [27] e Idle-Timeout [28]. A RADIUS devolve esses atributos em mensagens de aceitação de acesso em resposta às mensagens de solicitação de acesso do servidor de acesso. A partir do Junos OS Release 19.4R1, o atributo Session-Timeout [27] é suportado em mensagens RADIUS CoA. Esse recurso é útil, por exemplo, quando os assinantes compram acesso à Internet por um período específico de tempo e devem fazer logon quando a sessão expirar.

Quando um CoA chega com o Session-Timeout, o tempo limite é contado a partir do momento em que a sessão é ativada. Isso tem as seguintes consequências:

• Se o valor do atributo for maior do que o tempo de atividade da sessão atual e entre os valores mínimos e máximos de tempo limite, o assinante estará logado quando esse número de segundos tiver passado desde a ativação da sessão. Por exemplo, suponha que a sessão seja ativada às 12:00:00 e o CoA seja recebido às 12:00:30 com um valor de 120 segundos. O assinante está logado às 12h02.

  Outra maneira de ver isso com os mesmos valores é que o tempo de atividade da sessão atual é de 30 segundos e o valor do atributo é de 120 segundos. O assinante está logado quando mais 90 segundos se passaram.

• Se o valor do atributo for maior do que o tempo de atividade da sessão atual, mas menor que o valor mínimo de tempo limite de 60 segundos, o assinante estará logado quando o tempo de atividade chegar a 60 segundos.

• Se o valor do atributo for maior do que o tempo de atividade da sessão atual, mas mais do que o valor máximo de tempo limite de 31.622.400 segundos, o assinante estará logado quando o tempo de atividade chegar a 31.622.400 segundos.

• Se o valor do atributo for menor do que o tempo de atividade da sessão atual, o tempo de sessão não será aplicado. A AAA responde à mensagem da CoA com um NAK. Por exemplo, a sessão não é afetada se o tempo de sessão for de 60 segundos, mas o tempo de atividade é de 100 segundos.

Aplicar um tempo limite de sessão de acordo com as regras acima também depende se todos os outros aspectos da CoA são bem-sucedidos. Por exemplo, se o CoA incluir uma ativação de serviço e essa ativação de serviço falhar, o tempo de sessão não será aplicado. A AAA responde à mensagem da CoA com um NAK.

Nota:

Se o valor do Session-Timeout for 0, o tempo de sessão existente para essa sessão será cancelado.

Os provedores de serviços costumam optar por aplicar as mesmas limitações a um grande número de assinantes. Você pode reduzir o esforço de provisionamento RADIUS para esse cenário definindo as limitações para assinantes em um perfil de acesso em uma base por instância de roteamento. Se você fizer isso, os atributos RADIUS retornaram posteriormente para um determinado assinante logado com o perfil sobrepor os valores por instância de roteamento.

Práticas recomendadas:

Recomendamos que você não configure um tempo limite de sessão para assinantes que recebem serviços de voz. Como o tempo de sessão é baseado apenas no tempo e não na atividade do usuário, é provável que ele interrompa os assinantes usando ativamente um serviço de voz e encerre suas ligações inesperadamente (do ponto de vista do assinante). Esse resultado é uma preocupação especial para as chamadas de serviços de emergência.

Práticas recomendadas:

Recomendamos que você não configure um tempo limite ocioso para assinantes DHCP. Quando o tempo limite expira sem atividade e a conexão é encerrada, o protocolo não tem meios para informar o cliente. Consequentemente, esses assinantes são forçados a reiniciar seu dispositivo CPE da próxima vez que tentarem acessar a Internet.

Contraste o comportamento quando um tempo limite ocioso é configurado para assinantes de PPP. Nesse caso, a expiração do tempo de serviço faz com que a PPP encerre o enlace com o peer. Dependendo do dispositivo CPE, essa rescisão permite que o peer rejunteça automaticamente a conexão sob demanda ou imediatamente. Em ambos os casos, nenhuma intervenção do assinante é necessária.

O intervalo disponível para definir um tempo limite é o mesmo, seja você configurá-lo na CLI ou através dos atributos RADIUS:

• Os intervalos de sessão podem ser definidos de 1 minuto a 527.040 minutos na CLI e o número correspondente de segundos (60 a 31.622.400) no atributo Session-Timeout [27].

• Os intervalos ociosos podem ser definidos por 10 minutos a 1440 minutos na CLI e o número correspondente de segundos (600 a 86.400) no atributo Idle-Timeout [28].

O roteador interpreta os valores nos atributos para estar em conformidade com as faixas suportadas. Por exemplo, para o Session-Timeout [27]:

• Um valor zero é tratado como sem tempo limite.

• Um valor na faixa de 1 a 59 é elevado para 60 segundos.

• Um valor superior a 31.622.400 é reduzido para 31.622.400 segundos.

Para o tempo de inatividade [28]:

• Um valor zero é tratado como sem tempo limite.

• Um valor na faixa de 1 a 599 é elevado para 600 segundos.

• Um valor superior a 86.400 é reduzido para 86.400 segundos.

Em configurações usando VLANs de assinantes criadas dinamicamente, o tempo de inatividade também exclui as VLANs inativas de assinantes quando o limiar de inatividade foi atingido. Além de excluir VLANs dinâmicas inativas, o tempo limite ocioso também remove VLANs dinâmicas quando nenhuma sessão do cliente foi criada (por exemplo, caso nenhuma sessão de cliente seja criada no VLAN dinâmico ou após a ocorrência de um erro durante a criação de sessão ou autenticação do cliente onde nenhuma sessão do cliente é criada no VLAN dinâmico).

Os intervalos de sessão e ociosos para exclusão de VLANs dinâmicas de assinantes são úteis apenas em casos de uso muito limitados; normalmente, nenhum tempo limite é configurado para essa finalidade.

Uma circunstância possível quando podem ser úteis é quando as VLANs dinâmicas não têm protocolo de camada superior que ajuda a determinar quando o VLAN é removido com a remove-when-no-subscribers declaração; por exemplo, quando o VLAN está suportando IP sobre Ethernet sem DHCP em um modelo de acesso comercial com endereços fixos. No entanto, o acesso comercial geralmente é um serviço de nível mais alto do que o acesso residencial e, como tal, normalmente não está sujeito a intervalos devido à inatividade, como poderia ser desejado para assinantes residenciais.

Um tempo limite ocioso pode ser apropriado em determinadas situações de atacado de Camada 2, onde a conexão pode ser regenerada quando qualquer pacote é recebido do CPE.

Ao usar o tempo limite ocioso para a remoção dinâmica de VLAN, tenha em mente o seguinte:

• O período de tempo limite ocioso começa após a criação de uma interface VLAN dinâmica de assinantes ou a atividade de tráfego parar em uma interface VLAN dinâmica de assinantes.

• Se uma nova sessão do cliente for criada ou uma sessão do cliente for reativada com sucesso, o tempo de inatividade do cliente será reiniciado.

• A remoção de VLANs de assinantes inativos funciona apenas com VLANs que foram autenticadas.

Limites para sessões de assinantes por nome de usuário e perfil de acesso

Assinantes legítimos podem compartilhar suas credenciais de login com pessoas não autorizadas, gastando recursos de provedores de serviços sem benefícios para o provedor. A partir do Junos OS Release 18.4R1, você pode controlar ou impedir o compartilhamento de credenciais de login limitando o número de sessões de assinantes ativas permitidas para um nome de usuário específico associado a um perfil de acesso. Você também pode alcançar esse controle com o RADIUS, mas configurar o limite localmente no BNG elimina a dependência de um servidor externo.

Quando você configura um limite, as sessões ativas para a combinação de perfil de usuário/acesso são rastreadas. O número de sessões rastreadas é verificado quando authd recebe uma nova solicitação de login de sessão. Se o número de sessão rastreada corresponde ao limite, a nova tentativa de login será rejeitada e contabilizada como uma solicitação bloqueada.

Quando authd recebe uma solicitação de encerramento de logotipo ou cliente para uma sessão, a contagem de sessões rastreadas é decrementada para essa entrada de perfil de nome de usuário/acesso. Se isso continuar até que não haja sessões ativas para a combinação, a entrada será removida da tabela de limite de sessão. Todas as entradas de perfil de usuário/acesso associadas são removidas da tabela se você excluir o perfil de acesso ou o limite de sessão de sua configuração.

O número total de sessões para um nome de usuário pode exceder o limite configurado para um perfil de acesso específico, porque o mesmo nome de usuário pode ser usado com vários perfis de acesso.

Nota:

Para sessões de assinantes empilhadas, como PPP com VLANs autoconfiguradas, ambos os nomes de usuário na pilha são usados para autenticação e, consequentemente, ambos são contados contra o limite da sessão.

O limite configurado se aplica aos assinantes ativos existentes, mas as sessões existentes não são derrubadas se o número de sessões ativas exceder o limite para um assinante com essa combinação de perfil de usuário e acesso.

Considere uma situação em que cinco sessões estão ativas para uma determinada combinação de perfil de usuário/acesso quando você configura um limite de duas.

1. A contagem de sessões ativas é registrada como cinco na entrada da tabela de limite de sessão para a combinação.

2. Um novo assinante com o mesmo nome de usuário e perfil de acesso tenta fazer login. A tentativa é bloqueada porque o limite de duas sessões já é excedido (cinco > duas).

3. Um assinante existente faz logon, diminuindo a contagem de sessões ativas para quatro.

4. Um novo assinante com o mesmo nome de usuário e perfil de acesso tenta fazer login. A tentativa é bloqueada porque o limite de duas sessões ainda é excedido (quatro > duas).

5. Três assinantes existentes fazem logon, reduzindo a contagem de sessões ativas para um.

6. Um novo assinante com o mesmo nome de usuário e perfil de acesso tenta fazer login. A tentativa é permitida porque o limite de duas sessões ainda não foi atingido (uma < duas).

O projeto do limite de sessão impede um evento de negação de serviço em que um usuário mal-intencionado faz várias tentativas de login com o nome de usuário e o perfil de acesso corretos, mas a senha errada. As inúmeras tentativas de login podem exceder o limite de sessão configurado, mas isso não ocorre porque a contagem de sessões rastreadas só é incrementada quando o estado da sessão do assinante faz a transição para o estado ativo, o que os logins maliciosos não alcançam.

Benefícios de limitar sessões para nomes de usuário com a CLI

• Permite que você limite o número de sessões localmente no roteador, em vez de depender de um servidor RADIUS externo para fornecer o limite.

• Evita alguns ataques de negação de serviço com base em vários logins.

Modificação do nome de usuário do assinante

Para aplicativos de atacado de Camada 2, alguns provedores de serviços de rede empregam modificações de nome de usuário para direcionar os assinantes para a rede empresarial de varejo apropriada. Essa modificação também é chamada de desmontagem de nome de usuário, porque alguns dos caracteres do nome de usuário são retirados e descartados. O restante da seqüência torna-se o novo nome de usuário modificado. O nome de usuário modificado é usado por um servidor AAA externo para autenticação e contabilidade de sessão. Os parâmetros de modificação são aplicados de acordo com um perfil de acesso ao assinante que também determina o contexto do assinante e da sessão; ou seja, o sistema lógico:instância de roteamento (LS:RI) usada pelo assinante. Apenas o sistema lógico padrão (primário) é suportado. Como o atacadista se diferencia entre vários varejistas ao colocar cada um em um LS:RI diferente, os nomes de usuário são adequadamente modificados para cada varejista.

Você pode selecionar até oito caracteres como delimiters para marcar o limite entre as partes descartadas e retidas do nome de usuário original; não há um delimiter padrão. A porção do nome à direita do delimitador selecionado é descartada junto com o delimitador. Ao configurar vários delimiters, uma determinada estrutura de nome de usuário pode resultar em diferentes nomes de usuário modificados. Você pode configurar a direção na qual o nome original é analisado para determinar qual delimiter marca o limite. Por padrão, a direção do parse é da esquerda para a direita.

Considere os seguintes exemplos:

• Você especifica um delimiter, @. O nome de usuário é user1@example.com. Nesse caso, a direção do parse não importa. Em ambos os casos, o único dirigível é encontrado e example.com é descartado. O nome de usuário modificado é user1.

  

• Você especifica um delimiter, @. O nome de usuário é user1@test@example.com. Nesse caso, a direção parse resulta em diferentes nomes de usuário.

  • A direção do parse é da esquerda para a direita — a esquerda mais @ é identificada como o delimitador e test@example.com é descartado. O nome de usuário modificado é user1.

  • A direção do parse é da direita para a esquerda — a direita mais @ é identificada como o delimitador e example.com é descartado. O nome de usuário modificado é user1@test.

  

• Você especifica dois delimiters, @ e /. O nome de usuário é user1@bldg1/example.com. A direção do parse resulta em diferentes nomes de usuário.

  • A direção do parse é da esquerda para a direita — o @ é identificado como o delimiter e bldg1/example.com é descartado. O nome de usuário modificado é user1.

  • A direção do parse é da direita para a esquerda — a/ é identificada como o delimitador e example.com é descartado. O nome de usuário modificado é user1@bldg1.

  

Você pode configurar um perfil de acesso ao assinante para que uma parte de cada string de login do assinante seja despojada e posteriormente usada como nome de usuário modificado por um servidor AAA externo para autenticação e contabilidade de sessão. O nome de usuário modificado aparece, por exemplo, em mensagens RADIUS Access-Request, Acct-Start e Acct-Stop, bem como solicitações de desconexão iniciadas pelo RADIUS e solicitações de alteração de autorização (CoA).

Benefícios da modificação do nome de usuário do assinante

• Permite que provedores de serviços de rede por atacado de Camada 2 direcionem facilmente os assinantes para a rede empresarial de varejo apropriada.