Sumário
Índice de figuras
Lista de Abreviaturas
|
Anatel |
Agência Nacional de Telecomunicações |
|
DH |
Diffie-Hellman |
|
DiffServ |
Diferentiated Service |
|
IntServ |
Integrated Service |
|
IP |
Internet Protocol |
|
Ipv4 |
Internet Protocol version 4 |
|
IPv6 |
Internet Protocol version 6 |
|
ISP |
Internet Service Provider – provedora de internet |
|
LAN |
Local Area Network |
|
Mbps |
Mega bits por segundo |
|
MITM |
Man In The Middle |
|
MSE |
Message Stream Encryption |
|
NAT |
Network Address Translation |
|
P2P |
Peer-to-Peer |
|
PE |
Protocol Encryption |
|
PHE |
Protocol Header Encryption |
|
PO |
Protocol Obfuscation |
|
QoS |
Quality of Service |
|
TOS |
Type of Service |
|
VoIP |
Voz sobre IP |
Resumo
Protocol Encryption (PE), Message Stream Encryption (MSE), Protocol Header Encryption (PHE) ou Protocol Obfuscation (PO) são nomes alternativos para um conjunto de mecanismos hoje utilizados por alguns softwares P2P para dificultar que os agentes terciários, geralmente os provedores (ISP), identifiquem facilmente o protocolo, em nível de aplicação, utilizado por tais softwares e possam impor regras de tráfego, bloqueando ou inibindo assim o fluxo de pacotes gerados por eles[1][2]. O ato de impor, tecnicamente, restrições ou regras especiais sobre o tráfego na rede é conhecido como Traffic Shaping. Apesar do mecanismo P2P representar uma parcela considerável do fator que atrai clientes a serviços de banda-larga oferecidos pelos ISPs [3]; muitos provedores, por precisarem manter a qualidade de serviço dos aplicativos mais críticos (como VoIP, que exige um tempo de resposta menor), optam por inibir drasticamente o tráfego de dados pelas aplicações P2P, já que estes são grandes “comedores” de banda. O objetivo deste trabalho é apresentar a base para a compreensão do MSE, adotado por clientes BitTorrent (como o Azureus); apresentar conceitos sobre o Traffic Shaping, adotadas por ISP para o controle de tráfego sobre esses protocolos P2P, e mostrar alguns fatores sociais que explicam a adoção desses mecanismos por esses dois lados da disputa de interesses .
Palavras
chave: Protocol Encryption (PE), Message Stream
Encryption (MSE), Protocol Header Encryption (PHE),
Protocol Obfuscation (OE), BitTorrent,
Traffic Shaping, Internet Service Provider e Peer-to-peer.
1. Introdução
Tráfegos P2P para compartilhamento de arquivos ocupam uma parcela significativa da Internet e hoje é um dos serviços que mais atraem a população à conexão banda-larga [1]. Alguns ISP lidam com detecção de origem de tráfegos e oferecem serviços de otimização personalizada, enquanto que outros restringem esses tráfegos para priorizar serviços com mais exigência de qualidade de serviço.
Dos diversos serviços P2P no mercado, em particular os tráfegos BitTorrent são mais intensamente analisados, por ser ele um dos mais populares protocolos P2P em uso e muitos websites a usarem como alternativa para distribuições de arquivos tanto legítimos (como clips de filmes, patches de jogos, arquivos de domínio público ou imagens ISO para distribuições Linux [7]) quanto os ilegais [3].
Por causa desse massivo uso e a sua característica de utilizar grande parte da banda ociosa em uma rede, os clientes baseados no protocolo BitTorrent passaram a ser conhecidos como grandes “comedores” de tráfego. Por isso, diversos ISPs passaram a bloquear ou inibir abusivamente tráfegos sobre pacotes que contenham identificações de protocolo BitTorrent, não importando qual fosse o objetivo de uso daquele momento. Esse abuso era particularmente necessário caso a ISP precisasse garantir qualidade de serviço (QoS) a tráfegos que exijam menos tempo de resposta (como VoIP ou jogos on-line), pois com o uso massivo da banda pelos clientes BitTorrent, sobravam poucos para os outros serviços. Esse tipo de controle (tipicamente granular) de tráfego também é conhecido pelos gerentes de rede como Traffic Shaping.
Entretanto, para os usuários de serviços legítimos do BitTorrent, esse bloqueio era imperdoável. Afinal, muitos usuários pagam para um serviço de acesso ilimitado (claro, limitado à sua banda designada para o serviço). Imagine um cliente pagando um ISP por um serviço de 10Mbps por mês, cujo contrato não impõe maiores restrições sobre dados trafegando por mês. Naturalmente, esse cliente ficaria profundamente decepcionado ao perceber que a ISP ofereceu esse serviço supondo que o cliente utilizaria menos de 10% do serviço, e quando o cliente passa a usar boa parcela dele, recebe uma simpática ligação alertando que o cliente está usando “muito” recurso... A decepção seria mais alta se, após o incidente, o cliente começa a perceber acentuado decréscimo de performance do seu serviço de rede...
O exemplo acima ilustra na verdade dois problemas: o problema da ISP em oferecer mais serviço do que pode suportar e o problema da ISP em controlar o tráfego de forma abusiva. Apesar de muitos, inclusive o Bram Cohen (um dos desenvolvedores do primeiro cliente BitTorrent), preverem a extinção desse tipo de abuso (já que as ISPs não poderiam bloquear um dos seus principais serviços atrativos à banda-larga, tendo o risco de perca drástica de reputação [5]); as reclamações e as angústias dos usuários cresciam consideravelmente. Com isso, alguns desenvolvedores de programas-cliente para o BitTorrent passaram a adotar cifras sobre dados para prevenir vazamento de informação, dificultando assim a determinação de tráfego pelo ISP.
Havendo a cifra desses dados, a detecção do protocolo de origem se torna mais difícil e conseqüentemente sua restrição (ou talvez sua melhoria) é dificultada. Particularmente, o Azureus [4] implementa a cifra sobre os dados de protocolo e sobre toda a stream, com a posterior utilizando um algoritmo CR4 [2]. Vale notar que essa cifra não tem como objetivo tornar o usuário anônimo (e nem usa mecanismos para esse fim). O objetivo da cifra é somente contra “bisbilhotagem”.
Este documento dá a base para a
compreensão da Message Stream Encryption (MSE) adotada
pelo Azureus, popular cliente BitTorrent escrito em linguagem Java.
Adicionalmente, apresenta o conceito básico sobre Traffic
Shaping, sua definição, seus limites, impacto
social, algumas ferramentas em uso, uma avaliação do
aspecto social e o choque de interesses (cliente VS ISP) que causou a
necessidade da cifra e do controle. No capítulo 2, teremos uma
breve introdução sobre o protocolo BitTorrent e uma
explicação sobre o Azureus. A seguir, no capítulo
3, explicaremos o que seria um “Traffic Shaping” e sua
contextualização no IPv6. No capítulo 4, faremos
uma descrição do MSE e finalmente no capítulo 5
faremos uma breve avaliação dos choques entre os
serviços oferecidos pela ISP e a fiscalização da
Anatel. O capítulo 6 e 7 estarão reservados
respectivamente para a visão futura da disputa MSE VS
Traffic Shaping e a conclusão.
2. BitTorrent
O BitTorrent é um protocolo que permite aos usuários fazerem download de arquivos cujo seus índices são publicados geralmente em meios alternativos, como em websites. Essa rede introduziu o conceito "compartilhe o que já baixou", maximizando muito o desempenho e possibilitando downloads rápidos e imediatos minimizando a sobrecarga nos servidores, já que a banda será distribuída entre as pessoas que estão também fazendo download e que já têm e compartilham pedaços do arquivo. Foi criado por Bram Cohen em 2003 e tem sido o alvo primário de empresas que lutam em defesa da propriedade intelectual, devido a alegações de violação de direitos autorais de alguns arquivos transmitidos pela rede [8].
Na rede BitTorrent os arquivos são quebrados em pedaços de geralmente 256Kb [8]. Os clientes BitTorrent distribuem pedaços em ordem aleatória, que serão reconstituídos mais tarde para formar o arquivo final. Cada cliente pode compartilhar um pedaço entre os outros companheiros fazendo o download do mesmo arquivo, acelerando a descarga.
Os pacotes BitTorrent possuem a parte
inicial do pacote contendo o caractere 19 e seguido por 19 Bytes
representando a mensagem “BitTorrent protocol”, sendo então
simples de identificar.
2.1..torrent
Os arquivos “.torrent”, utilizados pelos softwares clientes do BitTorrent contém seguintes referências ao arquivo original:
-
o nome do arquivo, tamanho, e o hash de cada bloco do arquivo (que assegura aos clientes que o arquivo é o que o nome diz ser);
-
o endereço do servidor "tracker", um exemplo de “intermediador” entre clientes compartilhando partes de um arquivo.
O “.torrent” pode ser distribuído aos usuários normalmente através de um website. O cliente que contém o arquivo completo e faz seu upload é conhecido como “seed”. Quando outros usuários obtêm o arquivo completo, eles podem se tornar novas “seeds”. Um dos problemas desse sistema é que se todas as seeds saírem da rede, o arquivo pode tornar-se indisponível para download, mesmo que se tenha o arquivo torrent. Com sorte ainda é possível descarregar todos os blocos de um arquivo mesmo que nenhuma fonte seja completa, uma vez que os blocos são distribuídos em ordem aleatória e é possível que a soma de todos os utilizadores seja completa.
Note que os websites que hospedam os arquivos “.torrent” estão hospedando somente uma espécie de “resumos” ou “referências” ao arquivo distribuído, portanto os websites em si geralmente não têm vínculo direto com possíveis conteúdos distribuídos ilegalmente. Por também não possuir um mecanismo nativo de busca (referente a um mecanismo interno ao protocolo), os softwares clientes que implementam o BitTorrent, sozinhos, não permitem a distribuição em massa.
Cada pessoa que quiser fazer o download
de um arquivo primeiro deve obter o arquivo torrent que aponta para o
arquivo, depois abri-lo no seu cliente BitTorrent. A maioria dos
programas clientes não possuem um mecanismo integrado de
busca, já que o protocolo não trata de busca de
arquivos (.torrent). Depois do download começar, mesmo que o
tracker saia do ar ainda é possível continuar o
download, mas perde-se a informação de quais os
utilizadores estão online e quais os blocos que estão
disponíveis. Assim que um cliente termina de descarregar um
bloco, ele passa automaticamente por um cálculo de "hash"
para verificar a completude do arquivo.
2.2.Azureus
Figura 2 - 1: logotipo do Azureus
Azureus é um cliente BitTorrent escrito em Java. Foi inicialmente proposto para testar o Standard Widget Toolkit (SWT) da ferramenta Eclipse, desenvolvida pela IBM. Os desenvolvedores principais do projeto formaram uma organização conhecida como “Azureus, Inc”.
O logotipo do programa é um sapo azul (Dendrobates azureus). O projeto foi iniciado em Junho de 2003 no Sourceforge.net e agora é um dos mais populares clientes BitTorrent, lançado sob licença GNU GPL [4].
Foi o primeiro cliente BitTorrent a implementar uma versão estável do MSE, em 10 de Fevereiro de 2006. Este documento mostrará o MSE baseado na documentação provida pela equipe do Azureus [2].
Figura 2 - 2: tela do Azureus no Ubuntu
3. Traffic Shaping
Antes de apresentarmos o MSE, mostramos aqui um dos principais fatores da adoção de MSE pelos clientes MSE, incluindo o Azureus.
O Traffic Shaping provê mecanismos de controle de volume de tráfego entrando e saindo de uma rede. Por esse motivo, esse mecanismo é usado em pontos de interface entre redes. É uma tentativa de controle de tráfegos em redes de computadores para garantir performance, baixa latência e razoável banda (propriedades determinantes da QoS – qualidade de serviço). Estas técnicas estão intimamente associadas aos seguintes conceitos:
classificação de tráfego,
disciplina de queue,
políticas de tráfego,
gerenciamento de congestionamento,
QoS
e Justiça (no sentido de tratamento adequado de pacotes).
Para ISP, a simples identificação de protocolos já entregava benefícios sobre a possibilidade de verificação do tipo de tráfego que ocorria em sua rede. Com isso, tornou-se possível estimar o que os clientes estavam fazendo em suas redes e assim direcionar serviços personalizados para o padrão de uso da clientela.
Adicionalmente, esses esquemas podiam alocar qualidades de serviço, medidos com dados sobre latência ou perca de pacotes, de forma suficiente para determinadas aplicações ou usuários, enquanto que a banda restante podia ainda ser utilizada para outros fins. Com isso, abria a possibilidade do ISP em oferecer serviços diferenciais aos clientes, como por exemplo, a oferta de tráfego de mínima latência para o uso em jogos on-line para um cliente que pagasse taxa extra.
Para o ISP, existem 3 categorias de tráfegos:
Sensitivo: tráfegos que necessitam de melhor qualidade de serviço, como baixa latência e erro. São gerados por aplicativos como VoIP, ou jogos on-line. Melhor qualidade é garantida para essa categoria através de priorização no esquema do Traffic Shaping.
Melhor esforço: tráfegos que não exigem tanta qualidade de serviço. Geralmente, aqui entrariam os tráfegos do P2P. Os esquemas de Shaping geralmente alocam a “banda restante” para esse tipo de tráfego.
Indesejável: tráfegos considerados danosos, como os gerados por span, worms, cavalos de Tróia ou outros ataques maliciosos. Quando os tráfegos do P2P são alocados aqui, podemos considerar que é uma restrição ou bloqueio abusivo.
P2P são particularmente problemáticos para o Traffic Shaping dos ISP, pois foram projetados para usar toda a banda disponível, impactando as aplicações que exigem mais qualidade de serviço. Como os diversos aplicativos P2P, incluindo o BitTorrent, consideram pares em uma mesma rede como se estivessem em redes externas, o custo de fluxo de pacotes torna-se alto, uma vez que todos os pacotes trafegarão para fora da rede qualquer que seja o destino.
Isto tem atribuído má reputação aos ISP, fazendo com que alguns até considerem tráfegos P2P como “ataques” à sua rede. Entretanto, como este tipo de aplicação é um grande chamativo aos serviços de banda larga dos ISP, eles não poderiam (nem deviam) impor restrições drásticas ao tráfego P2P, com o risco de perca de clientela e de reputação [3]. Esse foi a visão inicial do Bram Cohen, criador do BitTorrent, sobre o Traffic Shaping do ISP [5]. Para ele, não teria sentido o ISP continuar com o Shaping abusivo.
Entretanto, diversos aplicativos cliente do BitTorrent tiveram de implementar mecanismos de esquiva contra o Shaping pelo fato de diversos ISP ainda continuarem controlando o tráfego do P2P considerando-os como “ataque”.
Claro, essa dualidade de interesses (o desejo do cliente em usufruir o serviço que paga contra a necessidade do gerente em distribuir recursos de forma justa) não ocorreria se todos os serviços das ISP fossem 100% funcionais. Observa-se aqui um problema de estratégia e ética de negócio, algo fora do alcance dos gerentes de rede.
Os tópicos a seguir explicam
melhor o Traffic Shaping.
3.1. Objetivos do Traffic Shaping
O Traffic Shaping tem como objetivo:
o controle granular do tráfego em redes de computadores;
otimizar performance, banda e QoS;
evitar congestionamento
e distribuir eficientemente recursos limitados.
3.2. Causa do surgimento do Traffic Shaping
O Traffic Shaping surgiu por causa de uma necessidade emergente em um ambiente avançado de rede, onde um melhor controle de tráfego era necessário para manter o serviço aceitável pelos usuários. A seguir, mostraremos alguns aspectos que determinaram a necessidade do Traffic Shaping.
3.2.1. Caos VS controle
Em qualquer área de gerenciamento de recurso, é comum haver a dualidade entre o gerenciamento caótico (ou a simples inexistência de gerenciamento) e o gerenciamento esquemático. O Traffic Shaping se enquadra no lado do gerenciamento esquemático, enfrentando o caos que se expande proporcionalmente ao crescimento da aplicação de uma rede.
Um mero conjunto de recursos de rede (nós, cabos, dados, etc) não é o suficiente para definir uma rede, pois a desordem impedirá o funcionamento correto do sistema como todo. Necessitamos de ferramentas e gerentes (de rede) treinados de forma a harmonizar o uso desses recursos. Um fluxo desordenado de informação vindo ou partindo de uma rede pode fazer com que um servidor falhe, causando a caída de serviços cruciais para aquela área em particular.
3.2.2. A competição sobre banda é egoísta e injusta
Sem um controle mínimo, a distribuição de bens em um ambiente de redes se comporta de acordo com lei do “forte devora o fraco”, altamente injusta e egoísta. Qualquer cliente prefere ter o melhor para si em detrimento dos outros; com todos tendo esse tipo de atitude, torna-se impossível a distribuição eficiente dos recursos.
Da mesma forma em que um rei usufruindo todo o recurso da nação implica na degradação do recurso “restante” para o povo, causando a insatisfação (ou fuga) deles; poucos privilegiados em detrimento de muitos prejudicados, em uma rede, causarão clientes insatisfeitos ou perda de contratos.
3.2.3. Existem serviços mais e menos prioritários
Na vida real, existem algumas ações que são mais prioritárias do que outras, exigindo privilégio sobre as outras. Imagine, em uma guerra, que um coronel tenha a necessidade de informar o seu general sobre alguns dados urgentes que decidirão uma batalha, mas está impossibilitado de ir à base porque todos os meios de transporte estavam sendo usados pelos tenentes para atividades pessoais, que não são nada urgentes. Isso seria inaceitável.
De forma semelhante, alguns serviços de rede requerem melhor QoS. Um exemplo seria o VoIP, que necessita de baixo delay e perda de pacotes para poder produzir voz de forma consistente e contínua durante a conversa. Em contrapartida, existem os pacotes menos prioritários, que não exigem tanto QoS (como os pacotes P2P) para que o serviço ainda continue funcionando.
3.2.4. Recursos são limitados, é necessário distribuí-los
Da mesma forma que não se guerreia somente com generais ou somente com soldados, não gerenciamos uma rede para lidar com um ou dois clientes. Precisamos lidar com todos os usuários da rede, logo, um mecanismo eficiente de distribuição de recursos (limitados) é crucial para a sobrevivência da corporação.
3.2.5. Como tratar diferentes QoS (e.g. P2P e VoIP)?
O
Traffic Shaping lida com classificação de pacotes,
possibilitando que serviços de diferentes QoS sejam tratadas
de forma diferenciada (veja DiffServ nos capítulos
posteriores).
3.2.6. Disponibilidade de serviço
Não podemos deixar que um
“estouro” de tráfego deixe um serviço fora do ar.
Se há muita sobrecarga em um ponto, é comum transferir
a carga para outros pontos. O Traffic Shaping deve lidar em controlar
o tráfego de maneira a filtrar entradas violentas de conexões,
retendo-o temporariamente ou desviando-o a um outro ponto, impedindo
que um servidor sobrecarregado “caia”.
3.3. Inspeção e controle de tráfego
Inspeção de tráfego é o ato de procurar por alguns padrões conhecidos em pacotes ou em seus headers. Por exemplo, o “aperto de mão” do BitTorrent começa com o byte ‘19’, seguidos pela string “BitTorrent protocol”. Visto isso, podemos identificar pacotes que fazem parte do serviço P2P BitTorrent.
É comum usarmos Firewalls e dispositivos DPI (Deep Packet Inspection) avançados para a inspeção de pacotes. Os dispositivos DPI possuem a habilidade de extrair informações pertencentes às camadas 2 ao 7 do modelo OSI.
Os pacotes inspecionados podem ser posteriormente:
Marcados (marcação de pacotes)
Bloqueados
Limitados
Reportados (para o administrador do dispositivo/software que fez a inspeção)
Existem duas famosas técnicas que integram regras para a inspeção e seu posterior controle de tráfego. Apresentaremos abaixo o IntServ (Serviço Integrado) e DiffServ (Serviço Diferenciado).
3.3.1. IntServ
Acrônimo de Integrated Service. É uma arquitetura proposta para garantir QoS em transmissões. Atualmente, é mais usada em redes menores. Sua principal característica está em literalmente passar “reservando” o caminho previsto pelo tráfego (reserva de dispositivos e caminho) para saber, de antemão, a qualidade de transmissão. Por causa dessa característica, possui grande overhead, uma vez que roteadores e aplicações devem suportar a arquitetura e realizar a “reserva” de recursos.
O IntServ utiliza o Resource Reservation Protocol (RSVP) para a “reserva. Atualmente, existem 2 modos de serviço para o IntServ:
Guaranteed Service (esquema literal de “reserva”, com garantia rigorosa de QoS);
Controlled Load Service (é um esquema de melhor esforço, pois o QoS não é uma garantia, e sim uma meta – não há a “reserva” propriamente dita).
Os dispositivos IntServ devem guardar muita informação para a “reserva” de caminho, implicando grande overhead na transmissão como todo, proporcional à complexidade estrutural da rede. Uma solução imediata é a IntServ over DiffServ, seja, usar IntServ (em LANs) sobre DiffServ (WANs). Veja abaixo alguns conceitos sobre o DiffServ.
3.3.2. DiffServ
Enquanto o IntServ visa o controle de fluxo sobre conexões individuais, o DiffServ visa o controle de fluxo sobre uma categoria/classe conjunta. Seu funcionamento pode ser ordenado nas seguintes etapas:
Verifica-se o tipo de fluxo.
“Marca” no campo “DS” (campo TOS no IPv4 e TrafficClass no IPv6) do pacote IP um valor DSCP (DiffServ Code Point). Esse processo é conhecido como marcação de pacotes. Note que pode haver remarcação, caso haja inflação.
Usa-se um “classificador” para separar DSCP em classes.
Escala-se pacotes de acordo com a classe.
A divisão de classes deve ser feita de forma cautelosa, uma vez que muita classe implica em maior complexidade e pouca classe implica em menor diferenciação de serviços. Infelizmente foram descobertos alguns softwares que marcam abusivamente para ganhar um aumento superficial de performance. Isso destrói completamente os requisitos exigidos pelo DiffServ para funcionar conforme o proposto. Por exemplo, versões antigas do Windows 2000 marcava bons DSCPs para qualquer pacote.
Como o IntServ é custoso em grandes redes, costumamos usá-lo junto com o DiffServ, sendo o IntServ usado em nível de LAN e o DiffServ conectando diferentes LAN (IntServ over DiffServ).
3.4. Exemplos de ferramentas
Para um bom progresso da gerência (da rede), precisamos de boas ferramentas. Nesta seção, apresentamos algumas ferramentas úteis para efetivar o traffic shaping. Veja abaixo uma breve listagem dos possíveis recursos:
Dispositivos (como switches) multicamadas
Ex. Cisco Catalyst System + Cisco IOS
Iproute2 <http://linux-net.osdl.org/index.php/Iproute2/>. Podem ser necessárias algumas patches adicionais.
netfilter, iptables <http://www.netfilter.org/>. Existem algumas patches que melhoram a usabilidade para este fim.
Firewalls em geral
Ex. IPFilter (ipf) <http://coombs.anu.edu.au/%7Eavalon/>, usado para NAT e firewall.
Cisco Access List
Ambientes integrados para Traffic Shaping
Windows Traffic-Shaper <http://bandwidthcontroller.com/index.html>, um freeware integrado para Traffic Shaping.
Dizendo de forma radical, um firewall de camada de aplicação (com recurso de marcação) já seria uma grande ajuda.
3.5. IPv6 e TrafficShaping
O IPv6 é a versão 6 do IP, um protocolo da camada de rede para transmissões com roteamento em nível de pacotes. considerado o sucessor do IPv4, versão atual utilizado para a internet. A maior mudança comparada às suas versões anteriores é o aumento considerável do número de endereços que o protocolo suporta [17]. A estrutura do cabeçalho de um pacote IPv6 se encontra abaixo:
Figura 5-1: estrutura do cabeçalho Ipv6.
No nosso escopo, estamos interessados em dois novos aspectos do IPv6. O cabeçalho dos pacotes gerados nesse protocolo possui dois campos especiais:
Traffic Class: é similar ao campo TOS do IPv4. É usado no DiffServ para determinar a prioridade daquele pacote [12].
Flow Label: é um campo designado para gerência de QoS. Atualmente, não está em uso.
Juntos, eles formam um mecanismo útil para o Traffic Shaping no aspecto de tratamento eficiente de pacotes previamente marcados (já identificados e classificados). Vale observar aqui que a adoção do IPv6 não facilitará muito a etapa de marcação/classificação dos pacotes; seja, o IPv6 não detectará milagrosamente os pacotes gerados por aplicações P2P.
Uma tática comum para a integração de redes em IPv6 com redes que utilizam IPv4 é o “tunelamento em IPv4”; técnica que, de forma geral, consiste em empacotar um pacote IPv6 dentro de um pacote IPv4. Existem diversos outros mecanismos de interação entre a versão 4 e a versão 6 desse protocolo; entretanto, nenhum funcionaria corretamente quando o nó importante da rede (por exemplo, um gateway) implementar unicamente a versão 6. Isso ocorre pois todos esses métodos precisam, em algum momento, tratar regras do IPv4 e IPv6 juntos.
Com a informação acima; podemos inferir que, em uma conexão ponto-a-ponto (como ocorre nos serviços oferecidos por ISP), se o ponto servidor (o lado que permite o outro a conectar-se à internet – nesse caso o ISP) suportar unicamente o IPv6, torna-se consideravelmente difícil o lado cliente (o outro lado da conexão) usar o IPv4.
Agora que temos um conhecimento
razoável do Traffic Shaping, partiremos para uma análise
mais aprofundada da posição oponente. Veja o próximo
capítulo para uma descrição do mecanismo de MSE.
4. Message Header Encryption
Basicamente, a cifragem se dá através do uso de um segredo compartilhado, que é o hash do arquivo sendo carregado (que geralmente está presente nos arquivos “.torrent”) junto ao uso de um handshake com troca de chaves Diffie-Hellman [6].
A especificação a seguir descreve uma camada adicional para um fluxo bidirecional de dados, evitando vazamento passivo e conseqüentemente a identificação do conteúdo ou do protocolo.
Adicionalmente, esta especificação foi projetada para prover proteção limitada aos ataques MITM e varredura de portas, por requerer um segredo compartilhado “fraco” para completar o handshake. Note que o principal foco está na performance e na invisibilidade dos dados de protocolo, não na autenticação/identificação de pares ou verificação de integridade de dados. Conseqüentemente, não oferecerá proteções contra adversários que já conheçam o IP, a porta, o segredo compartilhado e o protocolo principal das informações.
Para minimizar a sobrecarga aos
sistemas que usam este protocolo, métodos rápidos de
cifragem foram selecionadas em contrapartida aos algoritmos de máxima
segurança [2].
4.1. Especificação da versão 1.0
O campo handshake do cabeçalho é codificado em big-endian, o handshake cifrado deve ser transparente para a camada acima da pilha de protocolos e a codificação “endian” da informação relevante não faz parte desta especificação.
Considere o agente “A” como o iniciador da conexão TCP e o agente “B” como o receptor. Dado isso, definiremos os parâmetros Diffie-Hellman, as variáveis, as constantes, as funções e as condições opcionais para a finalização precoce. Os programas que implementam MSE devem satisfazer esta especificação.
4.1.1. Parâmetros Diffie-Hellman (DH)
Abaixo, descreveremos os parâmetros Diffie-Hellman para especificação do MSE. Para mais detalhes sobre a troca de chaves Diffie-Hellman, veja a seção “Troca de chaves, Diffie-Hellman” deste capítulo.
-
O número primo P é um número de “segurança” com o tamanho de 768 bits. Seu valor seria, em representação hexadecimal:
"0xFFFFFFFFFFFFFFFFC90FDAA22168C234C4
C6628B80DC1CD129024E088A67CC74020BBEA
63B139B22514A08798E3404DDEF9519B3CD3A431
B302B0A6DF25F14374FE1356D6D51C245E485B57
6625E7EC6F44C42E9A63A36210000000000090563". O gerador “G” vale 2 nesta especificação.
Xa e Xb são os inteiros aleatórios de tamanho variável. São elas as chaves privadas para cada lado da conexão e serão descartados após o handshake DH. O tamanho mínimo é de 128 bits. Estima-se que tamanho maior de 180 bits acrescenta pouca segurança que não compensa o crescimento excessivo de peso computacional. Recomenda-se 160 bits, mas valores menores podem ser usados caso o tempo de CPU seja escassa.
Considere a chave pública de A como Ya, que vale (GXa) mod P. Seu tamanho é de 768 bits.
Considere a chave pública de B como Yb, que vale (GXb) mod P. Seu tamanho é de 768 bits.
O “segredo” de DH é “S”, que vale (YaXb) mod P = (YbXa) mod P.
4.1.2. Variáveis e constantes
Considere “PadA” e “PadB” como dados arbitrários com um tamanho aleatório entre 0 e 512 bytes cada.
Considere “PadC” e “PadD” como dados arbitrários com o tamanho entre 0 e 512 bytes, pode ser usado para estender o handshake cifrado em versões futuras. A implementação atual pode atribuir tamanho 0 (zero). Caso este seja usado somente como placeholder, deve ser preenchido com 0 (zeros).
VC é uma constante de verificação que é usado para verificar se o outro lado da comunicação conhece o valor de S e SKEY e portanto derrota ataques de replay para hash SKEY. Nesta versão, VC é uma String de 8 bytes colocados no valor 0x00.
crypto_provide e crypto_select são campos de 32 bits que indicam o modo de cifragem usado. Atualmente, 0x01 significa texto puro (modo plain text) e 0x02 significa RC4. (veja na parte de funções). Os bits restantes estão reservados para algum uso futuro. O par iniciante A deve prover todos os métodos que ele suporta neste campo de bits, mas ele pode escolher em prover somente aqueles que se deseja usar. Dos métodos providos por A, o par receptor B deve marcar o bit correspondente ao único método que se deseja ser usado para aquela sessão em particular.
SKEY = Stream Identifier/Shared secret. É o identificador da stream e um segredo compartilhado usado para abandonar a contexão caso não tenhamos uma stream correspondente. É usado para dificultar adicionalmente os ataques MITM e leitura de portas. Protocolos sem uma propriedade única de stream pode usar um valor constante aqui. Para o BitTorrent, o SKEY é o “torrent info hash” provido no arquivo “.torrent”.
IA = dado inicial de A. Pode ser de tamanho 0 caso se sinta com a necessidade de se esperar a negociação para a cifragem. O par A pode bufferizar até 65535 bytes antes ou durante o handshake DH para concatená-la à 3a etapa. IA é considerado como atômico, logo, sua implementação deve considerar que nada será transmitido à camada acima antes que IA seja completamente transmitido. Por isso, não deve ocorrer uma operação que bloqueie alguma execução dentro do IA. Por exemplo, depois do cabeçalho típico do BitTorrent (“19” seguido por ”BitTorrent protocol” e depois um Handshake), deve-se automaticamente haver um bloqueio em A, já que ele deve esperar B para que envie seu handshake antes de A iniciar o envio dos campos de bits. Neste caso, IA deve conter somente o prefixo e o handshake, mas não os campos de bits (senão, haveria bloqueio dentro de IA).
4.1.3. Funções
len(X) especifica o tamanho do argumento X usando 2 bytes, logo, o tamanho máximo que pode ser especificado é 65535 bytes (isso é importante para o bloco IA).
ENCRYPT() é uma cifra RC4 (veja mais detalhes na seção RC4 deste capítulo), que usa uma das chaves abaixo para o envio de dados:
"HASH('keyA', S, SKEY)" se você é A.
"HASH('keyB', S, SKEY)" se você é B.
Os primeiros 1024 bytes da saída RC4 é descartado. Chamadas consecutivas para o ENCRYPT() por um lado continua a stream de cifras (não há reinicialização ou alteração de chaves). As chaves são usadas para diferenciar semanticamente contextos separados.ENCRYPT2() é o método para as cifras negociadas. As opções disponíveis atualmente são: 0x01 Plaintext (após processado uma quantia especificada da mensagem, cada lado envia informações não-cifradas) e 0x02 RC4-128 (o método ENCRYPT() para o RC4 é continuada sem reinicialização ou mudança de chaves).
HASH(), que tem saída em SHA1 binário (20 bytes). O SHA 1 não será detalhado neste documento.
4.1.4. O handshake
O handshake é separado em 5 processos com bloqueio.
A->B: Diffie Hellman, com Ya, PadA;
B->A: Diffie Hellman, com Yb, PadB;
A->B: HASH('req1', S), HASH('req2', SKEY) xor HASH('req3', S), ENCRYPT(VC, crypto_provide, len(PadC), PadC, len(IA)), ENCRYPT(IA);
B->A: ENCRYPT(VC, crypto_select, len(padD), padD), ENCRYPT2(Stream de dados);
A->B: ENCRYPT2(Stream de dados).
Como o tamanho de PadA e PadB são desconhecidos, B precisará se sincronizar em HASH(‘req1’, S) e A em ENCRYPT(VC).
4.1.5. Algumas condições opcionais para finalização
As condições a seguir podem ser verificadas antes de cada etapa de handshake descrita acima para antecipar possíveis erros e desconectar imediatamente seu par. As condições abaixo são suficientes para considerar o handshake como inválido.
Etapa 2 (finalização por B)
Se A enviou menos de 96 Bytes em 30 segundos
Se A enviou mais de 608 Bytes.
Etapa 3 (finalização por A)
Se B enviou menos de 96 Bytes em 30 segundos
Se B enviou mais de 608 Bytes
Etapa 4 (finalização por B)
Se A não enviou o hash S correto em 628 bytes após o início de conexão (no ponto de sincronização).
Se A não enviou um hash SKEY suportado, após o hash de S.
Se VC não pode ser decodificado corretamente após o hash SKEY.
Se nenhum das opções de crypto_provide é suportado ou se o campo de bits estão “zerados”.
Daqui a diante, a próxima camada do protocolo tomará a decisão do fim de conexão.
Etapa 5 (finalização por A)
Se VC não pode ser decodificado corretamente dentro de 516 bytes após o início de conexão (ponto de sincronização)
Se o método selecionado para cifras não foi provido.
-
Daqui a diante, a próxima camada do protocolo tomará a decisão do fim de conexão.
4.2. Troca de chaves, Diffie-Hellman
Diffie-Hellman (DH) é um protocolo criptográfico que permite que duas entidades sem conhecimento a priori entre si possam estabelecer uma chave secreta compartilhada sobre um canal inseguro de comunicação. Esta chave pode ser usada posteriormente para a comunicação com cifras simétricas [9].
A implementação original do protocolo usa um grupo multiplicativo de inteiros modulo p, onde p é primo e g é uma primitiva (número gerador) em módulo p.
Abaixo, mostramos uma descrição geral do protocolo:
O emissor e o receptor concordam em usar um grupo cíclico G e um elemento gerador g em G (supõe-se que g é conhecido por atacantes)
O emissor seleciona um número aleatório random a e envia ga para o receptor.
O receptor seleciona um número aleatório b e envia gb para o emissor.
O emissor computa (gb)a.
O receptor computa (ga)b.
Como os números inteiros têm
a propriedade associativa sobre a exponenciação, o
emissor e o receptor obtiveram agora números iguais. Podemos
agora usar este número como chave compartilhada para uma cifra
simética.
4.3. RC4
RC4 é um famoso algoritmo de cifra de fluxo utilizado no Secure Socket Layers (SSL). O sistema funciona basicamente por permutações e somas de valores inteiros, o que torna este algoritmo muito simples e rápido. De uma forma geral, o algoritmo consiste em utilizar um array de permutação S que a cada utilização tem os seus valores permutados e misturados com a chave K. Esse array S é utilizado para alterar valores contidos na mensagem de entrada input, provocando uma perturbação pseudo-aleatória nos valores. Esta chave K, utilizada somente na inicialização do array, pode ter até 256 bytes (2048 bits). Neste algoritmo, ao passar a mensagem cifrada pela rotina usando a mesma chave, podemos obter de volta a mensagem original [10].
O algoritmo é dividido em duas partes. O key-scheduling (inicialização) e a cifragem/decifragem propriamente dita. Veja abaixo uma visão simples do algoritmo.
4.3.1. Key-scheduling
O algoritmo key-scheduling é usado para inicializar a permutação no array S. O tamanho da chave e pode variar entre 1 e 256 bytes. Primeiro, S é inicializado com tamanho 256:
Na primeira repetição:
O array S é preenchido com os valores de 0 à 255.
Na segunda repetição:
É somado o valor de j, o valor de S apontado por i e o valor de K (chave) com tamanho keylength apontado por i e armazenado na variável j.
Troca os valores entre S[i] e S[j].
4.3.2. Cifragem/decifragem
A transformação ocorre com os seguintes passos:
Sendo i e j índices de um array, a rotina incrementa em 1 ao índice i.
Adiciona o valor de S apontado por i com j e armazena o resultado em j.
Troca os valores entre S[i] e S[j].
Sendo k outro índice de um array, a saída é então calculada fazendo-se a operação XOR bit-a-bit entre o valor de S apontado por S[i] + S[j] e a mensagem original apontado por k.
5. A atuação da Anatel com as ISP
A Agência Nacional de Telecomunicações (Anatel) é uma autarquia brasileira, administrativamente independente, financeiramente autônoma, não subordinada hierarquicamente a nenhum órgão de governo brasileiro [14].
Para nós, brasileiros comuns, é normal acreditarmos que a Anatel seja a responsável por fiscalizar as ISP sobre as políticas de Traffic Shaping; entretanto, segundo a ABUSAR (Associação Brasileira dos Usuários de Acesso Rápido) [15], a Anatel considera o serviço de acesso à internet como um Serviço de Valor Adicionado, não sendo então um serviço de telecomunicações. A Lei nº9472/97, art.61 confirma, de certo modo, essa afirmação.
Isso significa que a Anatel somente fará a devida fiscalização caso uma organização de telecomunicação esteja provendo também um serviço de internet (o que é ilegal segundo normas da Anatel). Nesse caso, uma organização exclusiva para ISP deve ser fundada [16]. Acredita-se que este seja um dos motivos pelos quais reclamações à Anatel não dêem resultados na redução de abusos de gerência de tráfego pelas ISP e na oferta enganosa de serviços.
6. Novas técnicas de Bloqueio do BitTorrent
As ISP já dotam de técnicas avançadas que bloqueiam tráfegos BitTorrent, tendo ou não o MSE. São técnicas que enviam um pacote de reinicio de sessão (pacote com campo “reset” ativo) para os clientes, forçando que a sessão atual seja finalizada imediatamente e assim falhar a conexão [3].
Existem relatos de que isso possa ser amenizado configurando-se o firewall para descartar essas mensagens de reinicio de sessão, mas isso exige que ambos pares tenham tal configuração cautelosa. Quando um dos lados falha nesse bloqueio, haverá uma conexão semi-aberta, inútil para a transmissão.
O lado do cliente combate essa técnica usando uma técnica conhecida como tunelamento via SSH. Com a sessão SSH utilizada para tráfegos BitTorrent, torna difícil o ISP “empurrar” os pacotes de reinicio de sessão. Claro, essa técnica é um “hack”, uma vez que os softwares clientes convencionais não possuem, sozinhos, tais funcionalidades.
7. Conclusão
A cifra sobre informações de protocolo do BitTorrent pode ser considerada meramente como uma adaptação de técnicas para proteção de mensagens contra vazamento; não sendo ela uma forma de anonimato, como muitos acreditariam ser. Essa cifra foi utilizada para esquivar a detecção de tráfego pelo ISP e conseqüente Traffic Shaping abusivo imposto sobre o BitTorrent. Não sabemos se foi uma abordagem elegante ou não, mas aparentemente os usuários foram satisfeitos.
Visto a grande popularidade dos clientes BitTorrent com o uso de MSE (como BitComet, Azureus, μTorrent, etc.) em detrimento dos clientes que não as implementam (como o cliente “BitTorrent” original), pôde-se considerar que a cifra de dados de protocolos é considerado um sucesso na sociedade, principalmente graças a sua possibilidade a “retro-compatibilidade”.
Isso seria um indicativo para a grande ira dos usuários sobre uma restrição forçada ao uso de um serviço por qual eles estavam pagando. ISP encontrarão mais e mais dificuldades caso tentem avançar no Traffic Shaping contra o BitTorrent, uma vez que alterar parâmetros ou detalhes sobre o mecanismo de cifra do protocolo será mais simples do que as ISPs prepararem rotinas em hardware para filtrar tais tráfegos [6].
O engraçado no Traffic Shaping das ISP é que o controle de degradação (limitar ou bloquear tráfegos) não só é aplicado em tráfegos de “melhor esforço” (as que não são tão prioritárias). Em alguns casos, principalmente quando a ISP é ligada a alguma empresa de telefonia, tráfegos VoIP - que exigem tratamento privilegiado - também são alvos de degradação. Pode-se ver aqui que as políticas de controle de tráfego não estão somente no esquema técnico-gerencial; pois questões de estratégia de negócio também vigoram notavelmente. Em particular, o caso do VoIP pode ser interpretado como uma reação dos serviços de telefonia a um serviço que possa substituí-la.
Vale observar que o uso do IPv6 pode facilitar no controle da qualidade do tráfego, mas não ajudará muito na identificação, isolamento e bloqueio de tráfegos BitTorrent. As facilidades do IPv6 ajuda no tratamento de tráfegos já categorizados, mas não na sua categorização (seja, se já sabemos que tal tráfego é de BitTorrent, o IPv6 facilita a tratá-lo, mas nada ajuda a identificar se um determinado tráfego é oriundo do BitTorrent ou não).
É interessante notarmos também que cada vez mais o BitTorrent passa a se afastar do seu criador original e passa a ser controlado por uma massa mais “independente” e dinâmica – os usuários. A visão de Bram Cohen sobre a desnecessidade do MSE foi literalmente rejeitada pela nova “ditadura”. Parece que a época em que o criador era o centro da aplicação e os usuários simplesmente o seguia já é história.
O que devemos tomar cuidado é que a cada dia as regras passam a ser ditadas pelos usuários, e todo o prestador de serviços precisará se adaptar às exigências diárias destes. O ISP ditar a qualidade de seus serviços para facilitar a gerência de seus recursos parece não ser mais uma proposta aceitável para o mercado dos “usuários”... Afinal, o ISP deveria ser, idealmente, “transparente”.
8. Referências
[1] Wikipedia, Protocol Header Encryption, URL: <http://en.wikipedia.org/w/index.php?title=Protocol_header_encryption&redirect=no>. Acesso em 10/05/2007.
[2] Azureus Wiki, Message Stream Encryption, URL: <http://www.azureuswiki.com/index.php/Message_Stream_Encryption.html>. Acesso em 10/05/2007.
[3] Sandvine Incorporated, P2P Policy Management, URL: <http://www.sandvine.com/solutions/p2p_policy_mngmt.asp>, Acesso em 20/05/2007.
[4] Website do Azureus, URL: <http://azureus.sourceforge.net/>.
[5] Artigo do Bram Cohen, criador do BitTorrent, se opondo ao uso do Protocol Obfuscation em clientes BitTorrent, Obfuscating BitTorrent, URL: <http://bramcohen.livejournal.com/29886.html>. Acesso em 22/04/2007.
[6] Mennecke, Thomas. BitTorrent End to End Encryption and Bandwidth Throttling. Entrevista da equipe do Slyck.com com um representante de desenvolvimento do μTorrent. Publicação – 06/02/2006. URL: <http://www.slyck.com/news.php?story=1083>. Acesso em 20/05/2007.
[7] Referência pública ao BitTorrent em um sítio de grande público, Snag the Red Hat 9 ISOs, via Cash or BitTorrent <http://slashdot.org/linux/03/03/31/1256236.shtml?tid=0>. Acesso em 14/05/2007.
[8] Wikipedia, Traffic Shaping, URL: <http://en.wikipedia.org/w/index.php?title=Traffic_shaping&redirect=no>. Acesso em 10/05/2007.
[9] Wikipedia, Diffie - Hellman key exchange, URL: <http://en.wikipedia.org/w/index.php?title=Diffie-Hellman&redirect=no>. Acesso em 10/05/2007.
[10] Wikipedia, RC4, URL: <http://en.wikipedia.org/wiki/RC4>. Acesso em 10/05/2007.
[11] RFC 1633, Integrated Services in the Internet Architecture: an Overview; IETF URL: <http://tools.ietf.org/html/>. Acesso em 19/06/2007.
[12] RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers; IETF URL: <http://tools.ietf.org/html/>. Acesso em 19/06/2007.
[13] RFC 3260 An Architecture for Differentiated Services; IETF URL: <http://tools.ietf.org/html/>. Acesso em 19/06/2007.
[14] Wikipedia, Agência Nacional de Telecomunicações, URL: <http://pt.wikipedia.org/wiki/Anatel>. Acesso em 03/10/2007.
[15] Portal do ABUSAR (Associação Brasileira dos Usuários de Acesso Rápido), URL: <http://www.abusar.org/apresentacao.html>. Acesso em 03/10/2007.
[16] Resposta Abranet, carta do ABUSAR em resposta a uma dúvida sobre a Anatel. URL: <http://www.abusar.org/resp_abranet.htm>. Acesso em 03/10/2007.
[17] Wikipedia, IPv6, URL: <http://en.wikipedia.org/wiki/Ipv6>. Acesso em 11/12/2007.