http://www.cic.unb.br/~rezende/sd.htm > Limites: Trafific S

Traffic Shaping vs. Protocol Encryption

A disputa de interesses dos provedores de internet

Monografia para a disciplina: Informática e Sociedade
Prof. Pedro A. D. Rezende, 2.07

SHOU MATSUMOTO <cardialfly@yahoo.com>
Departamento de Ciência da Computação
Universidade de Brasília
Novembro de 2007




Sumário

Índice de figuras

Lista de Abreviaturas

Resumo

  1. Introdução

  2. BitTorrent

    1. .torrent

    2. Azureus

  3. Traffic Shaping

    1. Objetivos do Traffic Shaping

    2. Causa do surgimento do Traffic Shaping

      1. Caos VS controle

      2. A competição sobre banda é egoísta e injusta

      3. Existem serviços mais e menos prioritários

      4. Recursos são limitados, é necessário distribuí-los

      5. Como tratar diferentes QoS (e.g. P2P e VoIP)?

      6. Disponibilidade de serviço

    3. Inspeção e controle de tráfego

      1. IntServ

      2. DiffServ

    4. Exemplos de ferramentas

    5. IPv6 e Traffic Shaping

  4. Message Header Encryption

    1. Especificação da versão 1.0

      1. Parâmetros Diffie-Hellman (DH)

      2. Variáveis e constantes

      3. Funções

      4. O handshake

      5. Algumas condições opcionais para finalização

    2. Troca de chaves, Diffie-Hellman

    3. RC4

      1. Key-scheduling

      2. Cifragem/decifragem

  5. A atuação da Anatel com as ISP

  6. Novas técnicas de Bloqueio do BitTorrent

  7. Conclusão

  8. Referências


Índice de figuras

Figura 2-1: logotipo do Azureus

Figura 2-2: tela do Azureus no Ubuntu

Figura 5-1: estrutura do cabeçalho IPv


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 “.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:


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:

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:


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:

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:

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:

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:

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:

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 “Acomo o iniciador da conexão TCP e o agente “Bcomo 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.

4.1.2. Variáveis e constantes
4.1.3. Funções


4.1.4. O handshake

O handshake é separado em 5 processos com bloqueio.


  1. A->B: Diffie Hellman, com Ya, PadA;

  2. B->A: Diffie Hellman, com Yb, PadB;

  3. A->B: HASH('req1', S), HASH('req2', SKEY) xor HASH('req3', S), ENCRYPT(VC, crypto_provide, len(PadC), PadC, len(IA)), ENCRYPT(IA);

  4. B->A: ENCRYPT(VC, crypto_select, len(padD), padD), ENCRYPT2(Stream de dados);

  5. 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)

Etapa 3 (finalização por A)

Etapa 4 (finalização por B)

Etapa 5 (finalização por A)


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:

  1. 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)

  2. O emissor seleciona um número aleatório random a e envia ga para o receptor.

  3. O receptor seleciona um número aleatório b e envia gb para o emissor.

  4. O emissor computa (gb)a.

  5. 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:

  1. O array S é preenchido com os valores de 0 à 255.

Na segunda repetição:

  1. É 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.

  2. Troca os valores entre S[i] e S[j].


4.3.2. Cifragem/decifragem

A transformação ocorre com os seguintes passos:

  1. Sendo i e j índices de um array, a rotina incrementa em 1 ao índice i.

  2. Adiciona o valor de S apontado por i com j e armazena o resultado em j.

  3. Troca os valores entre S[i] e S[j].

  4. 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.