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

Tempos limite da sessão do assinante

Você pode limitar o acesso do 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 tempos limite separadamente ou em conjunto. Por padrão, nenhum tempo limite está presente.

Observação:

Para todos os tipos de assinantes diferentes do DHCP (como assinantes com túnel L2TP e terminados por PPP), o valor de tempo limite da sessão limita a sessão do assinante. Para assinantes DHCP, o valor de tempo limite da sessão é usado para limitar a concessão quando nenhuma outra configuração de tempo de concessão está presente. A concessão expira quando o valor do tempo limite expira. Se esse valor não for fornecido pela CLI ou RADIUS, a concessão de DHCP não expirará.

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 upstream do usuário (entrada) quanto downstream para o usuário (saída). O tráfego de controle é ignorado. O assinante não é considerado ocioso, desde que o tráfego de dados seja detectado em qualquer direção.

Opcionalmente, você pode especificar que apenas o tráfego de entrada do assinante seja 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 de PPP habilitados e, portanto, não pode detectar que o peer não está ativo. Nessa situação, como por padrão o LAC monitora o tráfego de entrada e saída, ele detecta o tráfego de saída do LNS e não desconecta 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 dos períodos de tempo limite expira, os assinantes não DHCP são normalmente desconectados, de forma semelhante a uma desconexão iniciada pelo RADIUS ou um logout iniciado pela CLI. Os assinantes DHCP são desconectados. O valor Acct-Terminate-Cause [atributo RADIUS 49] inclui um código de motivo de 5 para um tempo limite de sessão e um código de 4 para um tempo limite de ociosidade.

Você pode configurar essas limitações para o acesso do assinante por assinante usando os atributos RADIUS Session-Timeout [27] e Idle-Timeout [28]. O RADIUS retorna esses atributos em mensagens Access-Accept em resposta a mensagens Access-Request 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 e devem fazer logout quando a sessão expirar.

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

• Se o valor do atributo for maior que o tempo de atividade da sessão atual e entre os valores mínimo e máximo de tempo limite, o assinante será desconectado 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 é desconectado às 12:02:00.

  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 é desconectado quando mais 90 segundos se passarem.

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

• Se o valor do atributo for maior que o tempo de atividade da sessão atual, mas maior que o valor máximo de tempo limite de 31.622.400 segundos, o assinante será desconectado quando o tempo de atividade atingir 31.622.400 segundos.

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

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

Observação:

Se o valor de Tempo limite da sessão for 0, qualquer tempo limite de sessão existente para essa sessão será cancelado.

Os provedores de serviços geralmente optam 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 por instância de roteamento. Se você fizer isso, os atributos RADIUS retornados posteriormente para um assinante específico conectado com o perfil substituirão os valores por instância de roteamento.

Melhores práticas:

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

Melhores práticas:

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 de informar o cliente. Consequentemente, esses assinantes são forçados a reiniciar seu dispositivo CPE na próxima vez que tentarem acessar a Internet.

Compare o comportamento quando um tempo limite ocioso é configurado para assinantes PPP. Nesse caso, a expiração do tempo limite faz com que o PPP encerre o link com o peer. Dependendo do dispositivo CPE, essa terminação permite que o peer tente novamente a conexão automaticamente 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, independentemente de você configurá-lo na CLI ou por meio dos atributos RADIUS:

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

• Os tempos limite ociosos podem ser definidos para 10 minutos a 1440 minutos no 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 os intervalos suportados. Por exemplo, para Session-Timeout [27]:

• Um valor zero é tratado como sem tempo limite.

• Um valor no intervalo de 1 a 59 é aumentado para 60 segundos.

• Um valor que excede 31.622.400 é reduzido para 31.622.400 segundos.

Para tempo limite ocioso [28]:

• Um valor zero é tratado como sem tempo limite.

• Um valor no intervalo de 1 a 599 é aumentado para 600 segundos.

• Um valor que excede 86.400 é reduzido para 86.400 segundos.

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

Os tempos limite de sessão e ociosidade para excluir VLANs dinâmicas de assinantes são úteis apenas em casos de uso muito limitados; Normalmente, nenhum tempo limite é configurado para essa finalidade.

Uma possível circunstância em que eles podem ser úteis é quando as VLANs dinâmicas não têm um protocolo de camada superior que ajude a determinar quando a VLAN é removida com a remove-when-no-subscribers instrução; por exemplo, quando a VLAN está suportando IP sobre Ethernet sem DHCP em um modelo de acesso de negócios com endereços fixos. No entanto, o acesso empresarial é geralmente um serviço de nível superior ao acesso residencial e, como tal, normalmente não está sujeito a tempos limite devido à inatividade, como pode ser desejado para assinantes residenciais.

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

Ao usar o tempo limite ocioso para remoção dinâmica de VLAN, lembre-se do seguinte:

• O período de tempo limite ocioso começa depois que uma interface VLAN de assinante dinâmico é criada ou a atividade de tráfego é interrompida em uma interface VLAN de assinante dinâmico.

• Se uma nova sessão de cliente for criada ou uma sessão de cliente for reativada com êxito, o tempo limite de inatividade do cliente será redefinido.

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

Limites de 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 do provedor de serviços sem benefício 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 obter 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 nome de usuário/perfil de 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ões rastreadas corresponder ao limite, a nova tentativa de login será rejeitada e contada como uma solicitação bloqueada.

Quando o authd recebe uma solicitação de logout ou encerramento do cliente para uma sessão, a contagem de sessões rastreadas é diminuída para essa entrada de nome de usuário/perfil de 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 nome de usuário/perfil de acesso associadas serã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 de 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.

Observação:

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

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

Considere uma situação em que cinco sessões estão ativas no momento para uma determinada combinação de nome de usuário/perfil de acesso ao configurar 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 está bloqueada porque o limite de duas sessões já foi excedido (cinco > duas).

3. Um assinante existente faz logout, 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 foi excedido (quatro > duas).

5. Três assinantes existentes fazem logout, 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 design de limite de sessão evita 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 com 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 é incrementada somente 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 limitar 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ção de nome de usuário para direcionar assinantes à rede corporativa de varejo apropriada. Essa modificação também é chamada de remoção de nome de usuário, porque alguns dos caracteres no nome de usuário são removidos e descartados. O restante da string se torna o novo nome de usuário modificado. O nome de usuário modificado é usado por um servidor AAA externo para autenticação de sessão e contabilidade. Os parâmetros de modificação são aplicados de acordo com um perfil de acesso do assinante que também determina o contexto do assinante e da sessão; ou seja, a instância lógica system:routing (LS:RI) usada pelo assinante. Apenas o sistema lógico padrão (primário) é suportado. Como o atacadista diferencia entre vários varejistas colocando cada um em um LS:RI diferente, os nomes de usuário são modificados adequadamente para cada varejista.

Você pode selecionar até oito caracteres como delimitadores para marcar o limite entre as partes descartadas e retidas do nome de usuário original; Não há delimitador padrão. A parte do nome à direita do delimitador selecionado é descartada junto com o delimitador. Ao configurar vários delimitadores, 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 delimitador marca o limite. Por padrão, a direção da análise é da esquerda para a direita.

Considere os seguintes exemplos:

• Você especifica um delimitador, @. O nome de usuário é user1@example.com. Nesse caso, a direção da análise não importa. Em ambos os casos, o delimitador único é encontrado e example.com é descartado. O nome de usuário modificado é user1.

  

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

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

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

  

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

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

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

  

Você pode configurar um perfil de acesso de assinante para que uma parte de cada string de login do assinante seja removida e subsequentemente usada como um nome de usuário modificado por um servidor AAA externo para autenticação de sessão e contabilidade. 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 os provedores de serviços de rede de atacado de Camada 2 direcionem facilmente os assinantes para a rede empresarial de varejo apropriada.