Comment les FAI traquent l’usage du P2P

Un article de 3 pages de Yiming Gong (des télécoms chinoises) nous livre le résultat de cette étude.

Pour faire simple, un FAI peut repérer un de ses clients en « flagrant délit » de P2P grâce à l’analyse du traffic généré par cet abonné :

1 – En analysant les ports utilisés :

Des logiciels de peer-to-peer utilisent en effet par défaut des ports spécifiques :

Limewire utilise les ports tcp: 6346 et udp: 6347
Morpheus utilise les ports tcp: 6346 et udp: 6346
Edonkey utilise les ports tcp: 4662
BearShare utilise les ports tcp: 6346 et udp: 6346
Bittorrent utilise les ports tcp: 6881 et udp: 6889
WinMx utilise les ports tcp: 6699 et udp: 6257
etc.

Ce qui fait déjà un point précis pour tenter d’identifier le client P2P utilisé… sauf pour les nouveaux logiciels clients qui attribuent un port aléatoire.

2 – Analyse du protocole utilisé par le client P2P :

De nombreux programmes open-source et des grands noms comme L7-filter, Cisco’s PDML, Juniper’s netscreen-IDP, Alteon Application Switches, Microsoft Common Application Signatures, et NetScout permettent déjà de le faire en analysant la forme, la teneur et le protocole des paquets de données échangés par le client P2P, pour tenter de trouver le nom du programme utilisé par l’abonné.

Mais une telle recherche est difficilement applicable par les FAI car les signatures changent au fur et à mesure de l’évolution des programmes de P2P.
Les concepteurs des réseaux de partage de fichiers deviennent prudents et commencent à crypter le traffic de leur logiciel (notamment par la technologie SSL), ce qui rend l’analyse beaucoup plus difficile.

Ce type de contrôle nécessite l’analyse complète et en temps réel du réseau, ce qui surchargerait considérablement l’infastructure du fournisseur d’accès et rendrait probablement le réseau instable, donc inutilisable par les abonnés.

Rétablir une qualité de service avec ce système (analyse de tous les paquets de données émis ou reçus par tous les abonnés) semble aussi coûteux qu’inefficace pour les FAI.

Il existe d’autres solutions.

3 – Analyse du comportement du traffic :

a – certains réseaux sont centralisés

Le défunt Napster devait absolument se connecter à un serveur central pour fonctionner. Pour repérer les clients p2p utilisant un réseau de type Napster, il suffit de surveiller les connexions vers ce serveur.

b – certains réseaux P2P sont semi-décentralisés :

exemple typique : eMule (kad/serveur)

Il est possible de repérer les « émuliens » grâce à une connexion sur, par exemple, le serveur Razorback… ou n’importe quelle autre adresse IP connue dans l’infrastructure du réseau.

c – les réseaux décentralisés :

Une méthode pour débusquer les clients P2P décentralisés est identifiée par Yiming Gong. Il suffit d’écouter les ports UDP, et de trouver le « patron », c’est-à-dire la forme et la taille des données envoyées à d’autres IP via ce P2P décentralisé.

Et les résultats semblent satisfaisants pour eDonkey, eMule BearShare, Limewire, Skype, Kazaa, et Shareaza. Ces programmes de P2P sur réseaux décentralisés ont été épinglés par les fai grâce à leur utilisation des ports UDP.

En conclusion :

L’étude est intéressante en ce qu’elle montre que les FAI veulent davantage s’impliquer dans la lutte contre le P2P, pour des raisons essentiellement budgétaires. Le P2P leur coûte beaucoup de bande passante et un faible nombre d’internautes P2Pistes peuvent rapidement asphyxier leur réseau. Mais le résultat de cette étude est aussi pernicieux puisque s’il montre que l’on peut dépister le traffic dirigé sur un réseau P2P, il laisse entendre que l’on peut aussi le bloquer ou le freiner… ce que certains fournisseurs ont déjà commencé à faire.