Grupos de Trabalho - Documento GT-ER

Arquiteturas para Auto-Provisionamento e Seleção de ISP em Operadoras de CATV


Comitê Gestor da Internet no Brasil
Grupo de Trabalho de Engenharia e Operação de Redes


Reinaldo Penno Filho
NortelNetworks
Universidade Federal do Rio de Janeiro
fevereiro 2000


Objetivo deste Documento

Este documento é um informativo para a comunidade da Internet do Brasil. A distribuição deste documento é ilimitada.

Sumário

1. Introdução
2.
Rede com tecnologia de camada 2 ou 3 e login através de DHCP
3. Rede com tecnologia de camada 2 e login através de PPPoE
4.
Rede com tecnologia de camada 2 ou 3 e login através de uma página web
          4.1
Network Address Translation (NAT)
5. Rede com tecnologia de camada 2 ou 3 e login através de L2TP
6.
Bibliografia


1. Introdução

Em 2000 a Agência Nacional de Telecomunicações (Anatel) no Brasil publicou um anexo à resolução N.º 190, de 29 de novembro de 1999 onde permite que, entre outros, operadoras de TV a cabo prestem serviços de valor adicionado.  Esses serviços de valor adicionado, na maioria quase total dos casos práticos, significa transmissão de dados bidirecional através dos protocolos padronizados pelo Internet Engineering Task Force [IETF]. 

Apesar dessa resolução ser algo inovador e importante para o Brasil e permita que as operadoras de TV a cabo ofereçam novos serviços a seus assinantes, o modelo utilizado é tão flexível que da noite para o dia as operadoras, que não tinham muita experiência na área de transmissão de dados, se viram tendo que solucionar  inúmeros problemas relacionados a roteamento, provisionamento, endereçamento, segurança, etc.

Um dos problemas mais comum é o chamado aqui pelo autor de auto-provisionamento e seleção de ISP.  Basicamente o problema a ser solucionado é  tornar a seleção do ISP e serviços associados (Firewall, QoS, VPNs, etc), pelo usuário de cable modem, o mais simples possível.

Entretanto, algumas premissas devem ser respeitadas para não restringir o escopo do serviço que pode ser prestado, a saber:
  • Vários usuários podem compartilhar o mesmo PC ligado a um cable modem, por exemplo em um ambiente residencial.
  • Diversos PCs de diferentes usuários podem compartilhar o mesmo cable modem, por exemplo em um condomínio.
  • Um usuário pode ter contas em diferentes ISPs
  • Um usuário pode ter várias contas em um mesmo ISP com diferentes serviços agregados (Firewall, QoS, VPNs, etc)
  • O endereço IP utilizado pelo usuário em um determinado momento deve preferencialmente ser fornecido a partir do bloco do ISP que está fornecendo o acesso.

Tendo em mente o que foi dito acima, vamos discutir os principais cenários para auto-provisionamento e seleção de ISP.

Diagrama

2. Rede com tecnologia de camada 2 ou 3 e login através de DHCP

Nesse modelo a rede pode passar os pacotes IP transparentemente [ANSI/IEEE Std 802.1D] ou pode fazer o encaminhamento baseado em rotas. Portanto, a maior vantagem desse modelo reside no fato do CMTS (Cable Modem Termiantion System) poder ser tanto um dispositivo de camada 2 como de camada 3. Além desta, podemos citar outras duas: a ausência de um software cliente no PC do usuário e, para usuários que não compartilham seus PCs, o login ser totalmente transparente.

Por outro lado, os usuários que compartilham o mesmo PC devem assinar o mesmo ISP e ter os mesmos serviços agregados, pois esses parâmetros estão associados ao endereço MAC da placa de rede do PC, e não a um usuário específico. Isso faz com que o lucro da operadora associado a serviços diferenciados seja bem menor.

Existe a possibilidade de diferenciação dos usuários, mas isso exige o provisionamento dinâmico do servidor DHCP e substituição do perfil do usuário no agregador por outro.

Elaborando mais um pouco sobre o serviço de DHCP, vale citar que a seleção de um novo endereço para um cliente é baseado na subrede de onde a mensagem foi recebida (se o campo "giaddr" for zero) ou no endereço do agente que repassou a mensagem (quando "giaddr" for diferente de zero) . O caso onde clientes de uma mesma subrede física recebem endereços IPs de subredes lógicas diferentes (multineting) é mencionada na recomendação do protocolo DHCP [RFC2132], mas os detalhes de implementação são deixados a cargo de cada fabricante. Portanto, não são todos os servidores DHCP que possuem essa característica e além disso pode haver problemas de interoperabilidade.

Os passos para o auto-provisionamento e seleção do ISP são os seguinte:

  1. Usuário liga o PC e é enviada um requisição de endereço IP através de DHCP.
  2. Como o endereço MAC da placa de rede do usuário não está associada a nenhum ISP, o servidor DHCP atribui um endereço privado [RFC1918] provisório para que o usuário possa fazer o auto-provisionamento.
  3. O usuário então acessa um formulário web onde escolhe o ISP de sua preferência, o pacote de serviços (QoS, VPN, etc) e preenche um campo com o endereço MAC da sua placa de rede.
  4. O usuário então submete esse formulário ao servidor web que através de scripts, ou outro mecanismo, provisiona o servidor DHCP  e o agregador.
  5. No próximo login (depois de reboot) ou quando o PC enviar outra requisição DHCP decorrente da proximidade de expiração do tempo de permanência do endereço IP original (reservado), o usuário receberá um IP da faixa do ISP.

Caso um PC seja compartilhado por vários usuários que assinem ISP diferentes (ou o mesmo ISP, mas com serviços diferentes), é necessário que os passos 4 e 5 acima sejam feitos sempre que houver troca de usuários no PC.


3. Rede com tecnologia de camada 2 e login através de PPPoE

Nesse modelo a rede deve passar os pacotes transparentemente pois uma sessão fim-a-fim de camada dois deve ser feita entre o usuário e o agregador. O acesso através de PPPoE [RFC2516] em redes de TV a cabo é muito similar ao acesso discado, sendo que no modelo discado quem faz o papel de agregador físico é o servidor de acesso remoto.  Em ambos os casos é estabelecida uma sessão PPP fim-a-fim, seguida por uma atenticação, validação do usuário e empréstimo do endereço IP pela duração da conexão. A diferença fundamental é que ao invés de discar, o usuário executa um cliente PPPoE na sua máquina, preenche os campos de usuário e senha (veja figura abaixo) e abre uma sessão com o agregador em menos de 1 segundo.

Tela de login

O protocolo PPPoE é relativamente novo, mas basicamente sua função é encapsular pacotes PPP em quadros Ethernet que serão desencapsulados pelo agregador (veja figura abaixo).

Diagrama

O protocolo PPPoE possui dois estágios: sessão e descobrimento. Os pacotes PPP de sessão são encapsulados dentro do quadro ethernet com o Ethertype igual a 0x 88 64.  Ja o  Ethertype (0x 88 63)  é usado durante o estágio de descobrimento, onde o cliente PPPoE do usuário tenta identificar o dispositivo que terminará a sessão PPPoE. O leitor que quiser mais detalhes sobre o protocolo PPPoE é aconselhado a ler a  recomendação [RFC2516]. 

Uma das desvantagens desse modelo é a necessidade de instalação de um software no PC do usuário[1]. Entretanto, a distribuição do software pode ser feita através da página de provisionamento e sua instalação pelo próprio usuário, já que os clientes PPPoE no mercado são extremamente fáceis de instalar e operar. Não obstante, esse modelo possui vantagens importantes quando comparado com os demais: 

  1. o endereço IP do usuário pode ser dado pelo ISP
  2. o usuário possui controle sobre algumas variáveis da conexão
  3. é possível utilizar padrões já estabelecidos para o protocolo PPP
  4. a diferenciação dos usuários que compartilham o mesmo PC é fácil e imediata

O item número 1 é muito importante, pois a maioria dos ISPs faz estatísticas de aceso e restrição às páginas de conteúdo diferenciado baseado no endereço IP de origem. Portanto, se o endereço IP dos usuários fizer parte do bloco alocado para a operadora ao invés do bloco alocado para o ISP, as estatísticas de acesso (usuários vs não usuários) deixarão de ser confiáveis e um outro mecanismo de acesso as páginas internas deverá ser empregado, pois agora todos os usuários serão identificados (mascarados) como sendo da operadora.

O item número 2 permite que o usuário controle algumas variáveis como compressão e desconexão por inatividade. Uma das vantagens disso é que se o usuário desligar seu PC, sua sessão será desfeita. Nos modelos onde não existe uma sessão fim-a-fim entre o PC e o agregador, caso o usuário desligue o PC, seu perfil continuará válido até que expire o tempo de empréstimo (DHCP) ou de inatividade (Radius). 

O item número três se confunde um pouco com o dois, mas uma das recomendações que podemos ressaltar é o fato da senha não ser transmitida em claro através da rede (CHAP).

O item número 4 está intimamente ligado a possibilidade de prestação de serviços diferenciados a usuários diferentes (ou até a um mesmo usuário em momentos diferentes). Nesse caso basta o usuário que está utilizando o PC fechar o cliente PPPoE , outro usuário sentar no seu lugar, executar o cliente, preencher outro nome  e senha e se conectar. O usuário que acabou de se conectar pode, por exemplo,  ter um tratamento diferenciado no agregador (mais banda, rede virtual privada, etc) associado a seu nome e senha.

Os passos para o auto-provisionamento e seleção do ISP nesse modelo são os seguinte:

  1. Usuário liga o PC e é enviada um requisição de endereço IP através de DHCP.
  2. Como o endereço MAC da placa de rede do usuário não está associada a nenhum ISP, o servidor DHCP atribui um endereço privado [RFC1918] provisório para que o usuário possa fazer o auto-provisionamento.
  3. O usuário então acessa um formulário web onde escolhe o ISP de sua preferência e pacote de serviços (QoS, VPN, etc)
  4. O usuário então submete esse formulário ao sistema onde seus dados são usados para provisionar, através de scripts ou método semelhante, um servidor Radius e o agregador.
  5. O usuário então é redirecionado para uma página web onde é instruído a  transferir o cliente PPPoE para sua máquina. Após a transferência, o usuário instala o cliente e realiza um reboot seu PC.
  6. Nesse momento é possível verificar a existência de uma nova interface no sistema (interface virtual associada ao cliente PPPoE).
  7. O usuário então executa o cliente PPPoE, entra com seu nome e senha, aperta o botão conectar e pronto, já pode navegar na Internet.

Nos passos acima, o agregador sabe, através do nome do usuário, em qual servidor Radius deve fazer a autenticação e qual pacote de serviço o usuário foi requisitado. Por exemplo, se o nome do usuário for reinaldo@silver.isp2.com.br, o agregador sabe que deve usar um dos servidores Radius do ISP2 para fazer a autenticação e que o pacote de serviços do usuário é o silver.

Ainda existe a possibilidade das características da sessão serem transferidas, durante o estágio de autenticação, do servidor Radius para o agregador, ao invés de ficarem armazenadas neste. Nesse caso o usuário pode se conectar apenas como reinaldo@isp2.com.br, pois haverá um par valor-atributo (AV-pair) que descreve o tratamento (pacote de serviços) que esse usuário comprou.


4. Rede com tecnologia de camada 2 ou 3 e login através de uma página web

Esse método é o mais polêmicos pois suas vantagens e desvantagens são extremamente polarizadas. Para entendê-lo melhor, devemos dividir o login do usuário em dois estágios: o primeiro se dá através de DHCP, onde o PC do usuário recebe um endereço IP associado a seu endereço MAC e o segundo, onde o usuário entra seu nome e senha em um formulário web e é autenticado contra um servidor Radius. Deve ser ressaltado que o endereço IP fornecido ao usuário no primeiro estágio deve pertencer ao bloco de endereços do mesmo ISP[2] que fornecerá os parâmetros de serviço, através do servidor Radius, no segundo estágio. Portanto, os dois estágios devem estar em sincronia, ou seja, um usuário que recebeu o endereço IP do bloco de um determinado  ISP não deve, no segundo estágio, ser autenticado e conseqüentemente receber parâmetros de serviço, de outro ISP.

Logo, quando um usuário utiliza mais de um ISP ou um PC é compartilhado por usuários que utilizam ISPs diferentes, para garantir que os dois estágios estejam em sincronia é necessário que o servidor DHCP seja provisionado sempre que houver troca do ISP a ser utilizado no segundo estágio.

Além disso, sabendo que nenhuma sessão é estabelecida entre o usuário e o agregador, alguns problemas devem ser abordados:

  1. O CMTS deve prover segurança para o tráfego entre usuários ou o roteamento deve ser configurado de modo que todo o tráfego sempre sempre pelo agregador.
  2. O nome e senha do usuário são enviados em claro através da rede, a não ser que um servidor web seguro seja utilizado.
  3. O usuário deve explicitamente avisar ao agregador, através de um formulário web ou algo semelhante, quando não quiser mais utilizar a rede. Caso contrário, seu perfil permanecerá armazenado no agregador até ser retirado por inatividade.
  4. Se muitos usuários utilizarem a mesma página web para validar seus dados, deve-se assegurar que o cliente Radius utilizado para enviar as requisições é escalável.

Por outro lado,  a rede pode ou não passar os pacotes transparentemente entre o usuário e o agregador e não há necessidade de instalação de um cliente no PC do usuário, já que o login efetivamente se dá através de uma página web. Além disso, a ausência de um software cliente no PC do usuário dispensa  kits de instalação e suporte associados.

Os passos para o auto-provisionamento e seleção do ISP nesse modelo são os seguinte: 

  1. Usuário liga o PC e é enviada um requisição de endereço IP através de DHCP.
  2. Como o endereço MAC da placa de rede do usuário não está associada a nenhum ISP, o servidor DHCP atribui um endereço privado [RFC1918] provisório para que o usuário possa fazer o auto-provisionamento.
  3. O usuário então acessa um formulário web onde escolhe o ISP de sua preferência e o pacote de serviços (QoS, VPN, etc)
  4. O usuário submete esse formulário ao sistema onde seus dados são usados para provisionar, através de scripts ou método semelhante, um servidor Radius, um servidor DHCP e o agregador.
  5. No próximo login (depois de reboot) ou quando o PC enviar outra requisição DHCP decorrente da proximidade de expiração do tempo de permanência do endereço IP original (reservado), o usuário receberá um IP da bloco do ISP escolhido previamente.
  6. O usuário então acessa, ou é direcionado para a página de provisionamento, onde coloca seu nome e senha para ser autenticado em um servidor Radius. O servidor Radius nesse caso fornece para o agregador os dados referentes ao usuário e dos serviços que lhe devem ser prestados.


4.1  Network Address Translation (NAT)


Existem algumas variações deste modelo baseadas no uso de NAT [RFC1631]. Basicamente durante o primeiro estágio o usuário recebe um endereço reservado [RFC1918] ou do bloco designado ao operador da CATV e, depois da autenticação no segundo estágio, o agregador (ou um dispositivo externo) realiza NAT entre o endereço fornecido pelo servidor Radius e o endereço inicial. Em um primeiro momento estas variações oferecem um certo apelo, mas se analisadas apropriadamente, fica claro que só devem ser utilizadas em último caso devido aos problemas decorrentes do uso de NAT.  Entre esses problemas, podemos destacar:

  1. Consultas inversas a servidores DNS não funcionam apropriadamente, o que causa diversos problemas relacionados a segurança e reutilização serial de endereços.

  2. Usuários não poderão utilizar clientes IPsec em seus PCs, pois a tradução de endereços, por definição, é vista pelo protocolo IPsec como um ataque de interceptação (man-in the-middle-attack) . Isso significa que funcionários que utilizam esses clientes para se conectar à sua corporação e estabelecer uma rede virtual privada, não poderão fazer isso através da rede do operador de CATV.

  3. Aplicativos baseados no protocolo H.323 [H.323] (Internetphone, Netmeeting, etc) não funcionarão aproriadamente. H.323 é um protocolo complexo, usa portas dinâmicas e inclui vários fluxos UDPs. Os endereços e portas negociados entre os participantes de uma sessão multimídia são transmitidos dentro do fluxo de dados (payload) da conexão de mais alto nível. Por exemplo, o endereço e porta da conexão H.245 é negociada dentro do fluxo de dados do protocolo Q.931. Isso torna NAT particularmente difícil, pois requer modificação de endereços dentro do fluxo de dados. Para piorar, é possível no protocolo Q.931, por exemplo, requisitar que a conexão H.245 seja encriptada, o que torna inviável o uso de NAT.
  4. O uso de NAT necessita de um poder de processamento intenso mesmo com a ajuda de um algoritmo de ajuste de checksum otimizado, pois cada pacote de dados está sujeito a procura na tabela de tradução e modificações.

Além dos problemas mencionados acima, existem outros relacionados a QoS , troca de tabelas de roteamento, Secure DNS [RFC2535] e outros aplicativos populares como ICQ [ICQ]. Portanto, NAT só deve ser considerado quando não houver outra opção.


5. Rede com tecnologia de camada 2 ou 3 e login através de L2TP

Essa solução é normalmente utilizada quando a rede entre o PC do usuário e o agregador não tem capacidade de passar pacotes IP transparentemente.  Como uma sessão é estabelecida entre o usuário e o agregador, as mesmas vantagens mencionadas para o modelo com PPPoE também são válidas. Outro fato importante é que o Windows2000 possui um cliente L2TP nativo, portanto não é necessário a instalação de um cliente especial pelo usuário[3]. A maior desvantagem desse modelo é que a escalabilidade do agregador é afetada pelo fato do protocolo L2TP exigir maior processamento.

Os passos para o auto-provisionamento e seleção do ISP nesse modelo são os seguinte:

  1. Usuário liga o PC e é enviada um requisição de endereço IP através de DHCP.
  2. Como o endereço MAC da placa de rede do usuário não está associada a nenhum ISP, o servidor DHCP atribui um endereço privado [RFC1918] para que o usuário possa fazer o auto-provisionamento.
  3. O usuário então acessa um formulário web onde escolhe o ISP de sua preferência e pacote de serviços (QoS, VPN, etc)
  4. O usuário então submete esse formulário ao sistema onde seus dados são usados para provisionar, através de scripts ou método semelhante, um servidor Radius e o agregador.
  5. O usuário então é redirecionado para uma página web onde é instruído a  transferir o cliente L2TP para sua máquina. Após a transferência, o usuário instala o cliente e , se necessário, realiza um reboot seu PC.
  6. O servidor DHCP atribui então um primeiro endereço privado [RFC1918] para que o usuário possa abrir um túnel para o agregador.
  7. O usuário então executa o cliente L2TP, entra com seu nome e senha, aperta o botão conectar, recebe um segundo endereço IP e pronto, já pode navegar na Internet.


6.Bibliografia

[ANSI/IEEE Std 802.1D]: 1993, Information technology - Telecommunications and information exchange between systems - Local area networks - Media access control(MAC) bridges.

[H.323] ITU-T Recommendation H.323 (02/98) - Packet-based multimedia communications systems

[ICQ] https://www.mirabilis.com

[RFC1631] Egevang, K. and  P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.

[RFC2131] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.

[RFC2661] A. Valencia, W. M. Townsley, W. Palter, et. al. "Layer Two Tunneling Protocol",  RFC2661, August 1999.


[1] Esse modelo não funciona com produtos que adotam soluções proprietárias e não atendem a recomendação DOCSIS 1.0 ou superior, ou seja, não possuem a capacidade de bridging.

[2] É claro que podem haver modelos onde a autenticação (base de usuários e parâmetros associados) pode ser terceirizada.

[3] Apesar de que com os assistentes de instalação hoje em dia, isso é uma tarefa relativamente fácil.