Livre Blanc sur le « Peer-to-Peer - April...Livre blanc sur le « Peer-to-Peer » 5 INTRODUCTION...

Cet ouvrage est publié sous l’égide du Syndicat National de l’édition phonographique (SNEP)

27 rue du Dr Lancereaux 75008 Paris

Livre Blanc sur le « Peer-to-Peer »

Comment fonctionne-t-il ?

A qui profite-t-il ?

Comment lutter contre le téléchargement illégal

de fichier protégés

sur les réseaux Peer to Peer ?

Paris 25 octobre 2007

Livre blanc sur le « Peer-to-Peer »

2


3

Avertissement

Le SNEP, particulièrement sensibilisé à la question du téléchargement illégal de fichiers

protégés, s’intéresse naturellement au phénomène du “peer to peer". C’est pourquoi il

lui a paru utile de rassembler dans un même document des éclairages à la fois

techniques, économiques et juridiques.

Toutefois, les contributions figurant dans ce Livre Blanc ont été réalisées en toute

indépendance par leurs auteurs, et leurs contenus respectifs n’engagent que ces derniers.

Elles ont bien sûr, au même titre que les discussions qui les ont accompagnées pendant

un an, nourri la réflexion du SNEP en la matière et orienté la mise au point des

propositions formulées en conclusion de cet ouvrage.


4


5

INTRODUCTION

Lutter contre le téléchargement illégal de fichiers

protégés par les droits d’auteur ou droits voisins

sur les réseaux « peer to peer »


6

Le 21e siècle s’est ouvert sous le signe des technologies de l’information et de leur généralisation progressive.

Dans l’entreprise, les réseaux de communication et les systèmes d’information qui leur sont

associés ont permis l’émergence de nouvelles pratiques professionnelles et sont désormais

reconnus comme créateurs de valeur.

Dans les foyers, les accès à Internet haut débit se développent de façon spectaculaire. Et, là

aussi, de nouvelles pratiques sont apparues comme les échanges directs de « pair à pair » ou

peer to peer.

Le peer to peer, une approche prometteuse

Dans cet univers électronique, le peer to peer s’est ainsi peu à peu imposé comme un véhicule

commode pour des usages et des applications très variés et dont beaucoup sont encore à

inventer.

L’arrivée des nouvelles technologies n’est évidemment pas étrangère au phénomène

d’individualisation de notre société relevé par de nombreux sociologues. Celles-ci ont joué un

rôle majeur dans l’émergence de nouvelles formes d’organisation et de nouveaux moyens

d’échange qui, à leur tour, se traduisent par la mise en place de nouveaux rapports sociaux, de

nouveaux principes de gouvernance, concourrant à l’évolution de notre société. En mouvement

perpétuel, celle-ci doit intégrer des changements de plus en plus rapides. Les progrès déjà

constatés vont être suivis d’autres tant elles sont riches en termes de perspectives offertes.

Seulement, à côté de ces évolutions et progrès incontestables, sont apparus des usages pervers

tels que le téléchargement illégal des fichiers protégés par des droits d’auteurs ou droits voisins.

D’abord marginaux, ils se sont développés de façon spectaculaire. La France étant un des pays

où cet usage reste le plus massif. Ils menacent aujourd’hui les industries culturelles européennes

et ternissent en même temps l’image des technologies dont ils se servent.

Parce que le peer to peer recèle des perspectives prometteuses dans différents domaines du

savoir, il serait absurde de le combattre en tant que tel. Mais, parce qu’il est aujourd’hui

techniquement et juridiquement possible de contrecarrer ces détournements de produits culturels

pour les inscrire dans un cadre respectueux des droits de chacun, c’est-à-dire des créateurs et de

leur public, il serait invraisemblable de ne pas agir.

Le téléchargement illégal de fichiers protégés, un phénomène très développé en

France

Les statistiques sont en effet éloquentes ...


7

En 2003, dans le monde, selon l’Idate, près de 150 milliards de fichiers musicaux se sont

échangés sur les réseaux P2P contre 50 milliards vendus sur support physique.

En France, pour l’année 2005, un milliard de fichiers musicaux ont été téléchargés, soit environ

l’équivalent des ventes physiques de titres1, dont seulement 20 millions sur des plateformes de

téléchargement légal. Pour les films, 120 millions de fichiers ont été téléchargés soit environ

l’équivalent des ventes de DVD en France en 2005.

Ce phénomène s’est poursuivi en 2006 et 2007

Il faut savoir que la France est l’un des pays où les abonnements haut débit sont les moins chers

pour une bande passante donnée, que la proportion des internautes pratiquant le téléchargement

(musique, films, jeux vidéo et logiciels) y est élevée (supérieure à 50 %) mais que celle des

fichiers téléchargés légalement y est en revanche très faible à 15% et, surtout, plus faible que

celle constatée dans la plupart des autres pays. Une large part de la bande passante est par

conséquent occupée par des applications « peer to peer » (90 % selon une étude de la société

Sandvine).

Autre donnée qui doit aujourd’hui interpeller : la baisse importante des revenus de l’industrie

musicale.

Le chiffre d'affaires des producteurs de disques était de 1 302 millions d’euros en 2002, date de

démarrage du haut débit dans l’Hexagone. Il a été en 2006 de 819,2 millions d’euros. Au

premier semestre 2007, le chiffre d'affaires des ventes physiques a encore baissé de – 20 %, et

le marché numérique (téléphonie et Internet) progresse, lui, trop peu : 30 660 milliers d’euros en

2005, 43 545 milliers d’euros en 2006 et 22 973 milliers d’euros en 2007.

Le marché de l’offre légale dématérialisée devrait poursuivre sa croissance. Pour ce qui

concerne la musique, chiffré à 43,5 millions d’euros pour la France en 2006, il devrait atteindre

100 à 120 millions en 2010.

Il est donc impératif d’agir pour que cette offre légale puisse se développer sereinement sans

être parasitée par un piratage intempestif.

Risque d’appauvrissement, voire de tarissement de la création

Car les produits piratés sont purement et simplement soustraits du circuit économique, alors

même qu’ils servent de ‘’faire-valoir’’ voire de ‘’produits d’appel’’ pour les abonnements aux

1 Selon l’IFPI, les ventes physiques de disques en France en 2005 se sont élevées à 24,7 millions de single et 83 millions d’albums.


8

réseaux électroniques.

Difficile alors de ne pas imaginer les conséquences négatives pour ceux, créateurs et plus

généralement industries musicales et cinématographiques, qui se trouvent ainsi, via le

téléchargement illégal de fichiers protégés, dépossédés de leurs richesses : leur situation

économique est d’abord fragilisée et peut, par la suite, être menacée de disparition.

Œuvrer pour contenir et maîtriser ce phénomène, c’est faire comprendre à tous que chacun doit

pouvoir vivre des fruits de son travail, notamment les créateurs.

La pratique du téléchargement illégal de fichiers met en danger la création artistique. Dans un

premier temps, on risque d’assister à une réduction de la diversité des œuvres, au bénéfice

notamment des œuvres les plus commerciales, celles visant une clientèle internationale la plus

large possible et présentant un risque faible car consommée abondamment sur une période

courte. Dans un second temps, se profile une menace de tarissement qui, s’il n’est pas total,

laissera simplement subsister une création monolithique et, somme toute, indigente, car la loi du

plus fort sera plus prégnante que jamais.

Tous ceux qui interviennent dans le processus de production des œuvres sont concernés, c’est-à-

dire non seulement les artistes mais également ceux qui prennent des risques à leurs côtés.

La technologie du « peer to peer » n’est pas en cause

Le Livre Blanc que nous présentons ici n’a pas pour propos de remettre en question le « peer to

peer » qui constitue une technologie très innovante aux potentiels considérables et qui n’a pas à

faire les frais des usages illégaux qui s’appuient sur elle - un peu comme si les constructeurs

automobiles se voyaient accusés des excès de vitesse commis par certains automobilistes.

Il s’agit simplement de souligner auprès des pouvoirs publics les conséquences graves à moyen

et long terme qu’aurait le fait de laisser se développer des usages non respectueux du droit de

propriété des créateurs, éditeurs et producteurs, ou de considérer les ‘’pillages’’ ainsi commis

avec un certain laxisme, alors même qu’il existe des moyens techniques et juridiques pour

endiguer le phénomène.

Pourquoi un Livre Blanc consacré à cette question ?

Notre ambition est ici de montrer que comme toute technologie, le « peer to peer » doit être au

service du bien-être collectif et de l’intérêt général et non être détourné par des intérêts

particuliers et mercantiles de court terme.


9

C’est pourquoi nous avons souhaité aborder la question de la circulation des œuvres sur les

réseaux « peer to peer » dans sa globalité – sans bien sûr prétendre épuiser le sujet.

Et c’est aussi au travers d’une approche pluridisciplinaire rendue possible grâce à la

collaboration de plusieurs universitaires renommés dans leurs disciplines, qu’est né ce Livre

Blanc.

L’ouvrage débute par un important volet technique (parfois déroutant pour le non initié) destiné

à permettre une bonne compréhension de la technologie « peer to peer », notamment dans son

architecture et dans les moyens dont on dispose pour la contrôler. Ensuite sont abordés les

aspects économiques et juridiques de la question du téléchargement illégal au moyen de

logiciels d’échange en « peer to peer », au travers notamment de la loi sur le droit d’auteur et les

droits voisins dans la société de l’information du 1er août 2006.

Que les auteurs qui y ont participé, tout particulièrement Guy Pujolle du Laboratoire de

l’Université Paris 6, sous l’égide duquel ce livre blanc a été réalisé, soient vivement remerciés

pour leurs précieuses et riches contributions qui, nous l’espérons, permettront à beaucoup de

mieux comprendre ce qu’il faut bien considérer comme un phénomène de société.

Des remerciements doivent également être adressés à Frédéric Goldsmith, ancien directeur

juridique du Syndicat national de l’édition phonographique (SNEP) et désormais délégué

général de l’Association des producteurs de cinéma (APC), à qui revient l’initiative de ce livre

blanc, aux côtés d’Ahmed Serhrouchni de l’Ecole nationale supérieure des télécommunications.

Ce sont eux qui, à l’occasion de contacts avec les spécialistes concernés, ont eu l’idée de réunir

leurs compétences et leur expertise dans un ouvrage unique et pluridisciplinaire. Frédéric

Goldsmith est en outre l’auteur du chapitre de conclusion et des propositions qu’il contient,

rédigé à partir d’une synthèse de débats entre contributeurs.

Enfin, ce livre blanc a bénéficié de l’aide précieuse de Françoise Payen, journaliste

indépendante, qui a travaillé à son éditorialisation et à la rédaction de son introduction.

Hervé RONY Directeur Général du SNEP


10


11

Biographie des auteurs Guy Pujolle est professeur à l’Université Paris 6 et responsable de nombreux grands projets de recherche français et européens. Auteur de plus d’une centaine d’articles et de nombreux ouvrages en langues française et anglaise il est également membre du conseil scientifique de France Télécom. Ses recherches portent actuellement sur la conception et le développement des futurs grands réseaux IP qui associeront le fixe et le mobile. Ahmed Serhrouchni est spécialiste en architecture et en sécurité des réseaux de communication. Maître de conférences à l'Ecole nationale supérieure des télécommunications de Paris (ENST), il est également chercheur au laboratoire Traitement et Communication de l'Information (URA 820) du CNRS. Marc-Michel Pic est ingénieur (ENSPM) et docteur en systèmes informatiques (Paris VI-Jussieu). Passionné par l'information et ses applications pratiques, de l'image numérique aux ordinateurs à haute performance en passant par les langages de compilation, il a publié différents articles pour des revues et conférences internationales et participé à des ouvrages collectifs. Il a exercé des responsabilités dans le monde industriel et dans le monde de la recherche (CEA). Il participe à plusieurs comités de normalisation, dont celui concernant MPEG à l'AFNOR/ISO et est membre de Cyberlex. Il a fondé la société AdVestigo en 2002. Anne-Gaëlle Geffroy a rejoint l’équipe numérique du CERNA en 2004 en tant que doctorante. Elle est normalienne et agrégée d’économie. Ses travaux de recherche, et notamment ceux co-écrits avec Olivier Bomsel, portent sur l’économie industrielle des DRMs et sur l’économie de la propriété littéraire et artistique. Ils sont disponibles à l’adresse suivante : http ://www.cerna.ensmp.fr//CVs/Geffroy.html Olivier Bomsel est Professeur d’Economie Industrielle à l’Ecole des Mines de Paris. Il a créé en 1998 l’équipe de recherche sur l’économie numérique au CERNA, le centre d’Economie Industrielle de l’Ecole des mines. Il a depuis publié de nombreux travaux sur l’économie des réseaux et des contenus numériques (http://www.cerna.ensmp.fr/CVs/PubliBomsel.html). Il est également producteur de films et de séries TV. Pierre Sirinelli est professeur à l'université Paris-1 (Panthéon-Sorbonne) et doyen honoraire de la faculté Jean Monnet. Il est par ailleurs président de l'AFPIDA (association pour la protection internationale du droit d'auteur), vice-président de l'ALAI (association littéraire et artistique internationale), directeur du CERDI (centre d'études et de recherche en droit de l'immatériel) et directeur du DESS de droit du numérique et des nouvelles techniques. Il publie très régulièrement des travaux dans ce domaine Frédéric Goldsmith est avocat de formation. Il a travaillé plusieurs années au sein d’un cabinet international, puis a intégré l’ADAMI. Il a rejoint le SNEP (Syndicat national de l’édition phonographique) en 1995 et y a occupé le poste de Directeur des affaires juridiques et sociales et des nouvelles technologies. Il est actuellement Délégué général de l’Association des producteurs de cinéma. Il est l’auteur d’articles sur les questions touchant aux relations entre le numérique et les secteurs de la culture. Il est membre de Cyberlex.


12


13

Chapitre 1

Typologie des réseaux et applications de « peer-to-peer »

Guy Pujolle et Ahmed Serhrouchni


14

1 - Introduction - Problèmes et questions liés à l’émergence des réseaux peer to peer

L’avènement des réseaux Pair-à-Pair (an anglais peer-to-peer) est l’un des événements qui a le

plus marqué le développement d’Internet ces dernières années. La proportion des flux P2P, par

rapport à l’ensemble des flux de communication numérique dans l’Internet, atteint les 80% et

cela posent aujourd’hui le problème de l’adaptation de ces nouvelles applications dans le

contexte de l’Internet.

Ainsi, le développement des réseaux peer-to-peer pose de façon aigue trois séries de questions :

1.1 Questions relatives au modèle de valeurs fondant la pratique de l’Internet ; la

philosophie sous-jacente est une philosophie communautariste dans laquelle les internautes

ne sont plus simplement consommateurs (« clients ») mais aussi acteurs (« serveurs »).

1.2 Questions juridiques : ce sont des questions concernant notamment : (i) le droit d’auteur

(contenus multimédias, logiciels piratés), (ii) la sécurité - les logiciels nuisibles (vers,

espions, etc.) et (iii) la protection des personnes (circulation de documents portant atteinte à

la dignité humaine). Ces questions, qui ont toujours accompagné le développement

d’Internet, sont vite devenues cruciales avec le peer-to-peer. Napster, premier logiciel peer-

to-peer grand public, apparu en juin 1999, a été fermé en 2002, en raison du grand nombre

de copies illégales circulant sur ce réseau. L’émergence de Napster a eu une grande

importance car elle a introduit auprès du grand public le partage de fichiers distribués sans

contrôle. De nos jours, le problème du contrôle des flux d’Internet est posé. La question de

savoir s’il est possible, voire souhaitable, de contrôler Internet, et de quelle façon, est le

sujet de débats d’actualité.

1.3 Questions techniques : les réseaux peer-to-peer font l’objet de nombreuses recherches,

leur impact sur les infrastructures existantes est fort. La recherche dans l’amélioration des

réseaux peer-to-peer et dans l’adaptation des infrastructures conduit à de véritables défis

conceptuels et techniques.

Ces trois types de questions se nourrissent les unes les autres. Par exemple, l’abandon du

modèle Client-Serveur semble être une traduction d’un modèle de valeurs « communautariste »

dans lequel les internautes participeraient activement au développement d’Internet. Par ailleurs,

le fait que Napster, qui reposait sur une architecture centralisée, ait été fermé pour raisons

juridiques a, entre autres, conduit les développeurs et les utilisateurs à favoriser par la suite des


15

architectures décentralisées.

D’autres interrogations se profilent. La première concerne les concepteurs et les utilisateurs des

réseaux peer-to-peer qui font preuve de méfiance vis-à-vis de tout contrôle (toujours le

précédent Napster) ou de tout bridage de leur réseau. Ensuite, les pare-feu des entreprises et de

certains FAI peuvent-ils bloquer les flux peer-to-peer. Les concepteurs en réponse à ces

questions tentent de banaliser au maximum ces flux peer-to-peer pour ne pas qu’on puisse les

repérer. Cette clandestinité crée cependant des soucis dans la recherche d’améliorations de

l’infrastructure.

2. Définitions et principes de fontionnement des applications Peer to Peer

Un réseau est constitué par un ensemble de machines interconnectées permettant ainsi l’échange

d’informations et le partage des ressources physiques (unité centrale, mémoire de stockage,

bande passante, imprimante, etc.), de fichiers, la diffusion d’informations et ainsi de suite. Ces

réseaux ont été initialement conçus pour des architectures client/serveur.

Selon l’architecture client/serveur, il y a une entité centrale plus puissante, le serveur, et

plusieurs entités de puissances inférieures, les clients. Le serveur est l’unité d’enregistrement

centrale aussi bien que le seul fournisseur de services aux clients. Un client ne demande que le

contenu ou l’exécution des services, sans partager aucune de ses ressources propres. Avec ce

modèle, le contrôle et la responsabilité de l’information diffusée dépendent du serveur.

Or cette architecture présente beaucoup d’inconvénients pour la marche d’un réseau, à

commencer par l’existence d’un point central qui représente une certaine fragilité : en cas de

panne le système s’arrête. L’architecture peer-to-peer propose une alternative à l’architecture

client/serveur en offrant de nombreux avantages, comme une plus grande fiabilité, une

répartition du trafic et de la charge, une meilleure résistance aux fautes et un anonymat, entre

autres.

Une application peer-to-peer se déroule sur un ensemble de nœuds (que l’on appelle des pairs)

qui peuvent être aussi bien clients et serveurs ou les deux à la fois. Ces pairs sont reliés entre

eux par des liens de communication. Ces liens de communication peuvent traverser des nœuds

intermédiaires. Ces nœuds et ces liens définissent par eux-mêmes un réseau peer-to-peer qui est

un réseau overlay (ou de recouvrement). Ce réseau de recouvrement est un réseau virtuel placé

au dessus d’une infrastructure physique. Chaque pair comporte un ensemble d’objets (des

fichiers de musique, article, etc..) et des ressources physiques (mémoire de stockage, bande

passante, unité centrale, etc.).


16

Quelques définitions supplémentaires sont nécessaires à la bonne compréhension de ce chapitre.

Un système peer-to-peer est un système reparti utilisant l’architecture de réseaux peer-to-peer.

Un service peer-to-peer est un service fourni par les pairs d’un système peer-to-peer.

L’application peer-to-peer est un service ou un ensemble de services peer-to-peer s’exécutant

sur des pairs au bénéfice des utilisateurs du système.

Le terme peer-to-peer fait référence aux systèmes et applications qui utilisent des ressources

réparties avec l’objectif d’accomplir des tâches critiques d’une façon décentralisée. Le terme

peer-to-peer provient aussi de la relation réciproque entre entités de même statut pour réaliser

des échanges d’objets. Les utilisateurs des systèmes peer-to-peer ont besoin de mécanismes qui

localisent et récupèrent ces objets dans le réseau.

Le mécanisme de Lookup consiste à localiser un objet dans le réseau, spécifié par une clé unique

d’identification et le mécanisme de Search a pour objet de localiser un objet en fonction des

mots-clés d’identification.

3. Classification des systèmes peer-to-peer

Avec la croissance des réseaux, le peer-to-peer suscite de plus en plus l’attention dans la

recherche comme alternative aux réseaux client/serveur. Plusieurs études essayent de classifier

les systèmes peer-to-peer. Trois grandes catégories peuvent être identifiées : centralisé,

décentralisé, et hybride. La catégorie décentralisée peut encore être divisée en décentralisé mais

structuré et en décentralisé et non structuré. La différence principale entre ces systèmes est le

mécanisme utilisé pour rechercher des ressources dans le réseau peer-to-peer.

3.1 - Réseaux peer-to-peer centralisés

Dans les systèmes peer-to-peer centralisés, la description et l’adresse des ressources sont

stockées dans un annuaire d’un serveur central. Ainsi, les nœuds envoient des requêtes au

serveur central pour trouver quels nœuds ont les ressources désirées. Le serveur ne fournit que

la capacité de rechercher et négocie les téléchargements entre clients. De ce fait, le contenu reste

du côté client, ne passant jamais par le serveur. Après avoir reçu une requête d’un pair, l’index

central recherche le meilleur pair dans son annuaire pour répondre à sa requête. Le meilleur pair

est celui qui est le plus économique, le plus rapide ou le plus disponible selon les besoins de

l’utilisateur. Lorsque le nombre de participants devient trop grand ce modèle comporte quelques

inconvénients dus à son infrastructure centralisée, notamment la surcharge de l’annuaire

responsable d’accueillir les informations de tous les participants. Cette catégorie de réseaux


17

peer-to-peer ne peut pas s’étendre à de très grands réseaux. De plus, l’existence d’un centre

unique, même s’il est dupliqué, ne permet pas une bonne fiabilité du réseau. Celui-ci peut

tomber en panne à cause d’un seul nœud. Napster a été l’exemple le plus connu reposant sur ce

modèle.

Napster

Napster est souvent considéré comme le premier réseau peer-to-peer Son architecture est

centralisée : les pairs du réseau annoncent les fichiers dont ils disposent au serveur central et

contactent ce serveur central pour obtenir les coordonnées (adresse IP et numéro de port) d’un

pair possédant les fichiers recherchés.

Chaque utilisateur doit posséder le logiciel Napster sur son ordinateur afin de participer au

partage des fichiers. Étant connecté à l’Internet, le client établit une connexion TCP avec le

Serveur Central Napster et lui déclare les fichiers qu’il souhaite partager. Ce serveur détient

donc un annuaire avec toutes les adresses IP des clients participants connectés à lui, ainsi qu’une

liste des ressources partagées. Ainsi, tout client qui souhaite obtenir un fichier interroge le

Serveur Central. Le Serveur Central lui communique les adresses IP de ceux qui possèdent le

fichier désiré. Le logiciel Napster permet ainsi au client de se connecter directement sur les

ordinateurs qui proposent le fichier.

Le fichier en lui-même ne transite pas par le serveur central, qui fonctionne simplement comme

un moteur de recherche : une fois l’adresse IP trouvée, les ordinateurs clients peuvent se

connecter directement entre eux. Mais il ne s’agit pas d’un réseau totalement « pair à pair »,

dans la mesure où sans le serveur central, le réseau ne peut pas fonctionner.

3.2 - Réseaux peer-to-peer décentralisés et non structurés

Les systèmes décentralisés et non structurés sont ceux au sein desquels il n’existe ni annuaire

centralisé, ni connaissance où se situent les nœuds du réseau (la topologie), ni adresse sur

l’emplacement des fichiers. Le logiciel de P2P Gnutella en est un exemple. Ce réseau est formé

de nœuds qui rejoignent le réseau P2P en suivant quelques règles simples. L’emplacement des

fichiers n’est fondé sur aucune connaissance de la topologie. Pour trouver un fichier, un pair

demande tout simplement à ses voisins qui eux-mêmes vont demander à leurs voisins s’ils n’ont

pas le fichier considéré, et ainsi de suite. Ces architectures non structurées sont extrêmement

résistantes aux nœuds entrant et sortant du système. Par contre, l’actuel mécanisme de recherche

n’est pas adapté aux très grands réseaux (on dit que le réseau ne passe pas à l’échelle) et génère

une charge importante sur les participants du réseau. Les exemples de cette catégorie sont

nombreux comme FreeNet ou Gnutella.


18

Gnutella

Gnutella a été le premier réseau peer-to-peer totalement décentralisé. Succédant à Napster, dont

la centralisation présentait une faiblesse avérée, Gnutella a tiré profit de cette expérience.

Gnutella propose un protocole ouvert, décentralisé pour des recherches distribuées sur un

ensemble de pairs non hiérarchisés. Dans Gnutella, tous les pairs sont à la fois serveur et client.

Ce protocole n’a pas de répertoire centralisé et n’a aucun contrôle sur la topologie ou

l’emplacement des fichiers. Le réseau est formé avec des pairs qui intègrent le réseau en suivant

quelques règles simples. L’emplacement des données n’est fondé sur aucune connaissance de la

topologie. Pour localiser un objet, un client demande à ses voisins qui eux-mêmes demandent à

leurs voisins. Ce genre de systèmes permet simplement l’entrée et la sortie des clients, mais le

mécanisme utilisé passe mal à l’échelle et génère de fortes charges dans le réseau.

La première version de Gnutella utilisait un mécanisme d’inondation pour la recherche, ce qui

pose évidemment un problème dès que le réseau devient très grand. Les versions les plus

récentes de Gnutella utilisent la définition de super-pairs ou ultra-pairs (pairs avec la meilleure

bande passante) pour améliorer la performance du réseau. Cependant, cette solution reste encore

limitée toujours à cause des mécanismes d’inondation même si l’inondation ne se fait que sur

les ultra-pairs et non sur l’ensemble des pairs. De nombreuses applications d’échange de fichiers

implémentent le protocole Gnutella comme Limewire, BearShare, Gnucleos, Phex.

Le protocole Gnutella définit comment les clients sont interconnectés dans le réseau. Il repose

sur l’utilisation de descripteurs (Ping, Pong, Query, QueryHit et Push) pour la communication

entre les clients et d’un ensemble de règles qui gèrent leurs échanges.

Ainsi, lorsqu’un client cherche un objet, il lance une requête (Query) en spécifiant cet objet à

tous ses voisins. Si l’un des voisins possède l’objet en question, il répond à la requête en

renvoyant une réponse (QueryHit) au voisin qui lui a retransmis la requête, spécifiant où l’objet

peut être téléchargé (son adresse IP et son port TCP). La réponse remonte ainsi de proche en

proche jusqu’au client qui a initialisé la requête. Le client initiateur de la requête choisit ensuite

les fichiers à télécharger en envoyant directement une requête de téléchargement au client qui

possède le fichier. Si le nœud qui a reçu la requête ne peut la satisfaire, il propage la requête à

tous ses voisins, sauf celui qui a initialisé le mouvement. En d’autres termes, Gnutella

inonde le réseau pour trouver l’objet désiré. Néanmoins, pour ne pas inonder le réseau

durant un temps trop long, Gnutella utilise un temps maximum (ou temporisateur) pendant

lequel l’inondation se propage.

Lorsqu’un client souhaite rejoindre le réseau, il doit connaître au moins un autre client déjà


19

connecté, et c’est à ce dernier que le nouveau client est rattaché. Étant connecté, un client

envoie périodiquement des requêtes (Ping) à ses voisins. Cela permet de sonder le réseau à la

recherche d’autres clients. Tous les clients qui reçoivent un Ping répondent avec un Pong qui

contient l’adresse et la quantité de données partagée. La responsabilité de déterminer la

fréquence d’émission des Pings revient aux programmes utilisant Gnutella. En effet, des Pings

fréquents permettent d’assurer les liens entre un client et le reste du réseau, puisque dans

l’environnement dynamique que propose Gnutella (les clients rejoignent et quittent le réseau

sans arrêt) la connexion n’est pas fiable.

Toutefois, si un client se trouve derrière un pare-feu, il est impossible d’établir une connexion

TCP avec ce client (serveur dans ce cas) sur lequel se trouvent les fichiers désirés. Afin de

pallier ce problème, le client peut par lui-même établir une connexion TCP, et télécharger les

fichiers vers le client distant. Le descripteur Push joue donc le rôle de « dire » au client serveur

qu’il doit initialiser le transfert.

3.3 - Les réseaux peer-to-peer décentralisés mais structurés

Les systèmes décentralisés mais structurés n’ont toujours pas de serveur central mais ils sont

« structurés » dans le sens où leur topologie est strictement contrôlée et les fichiers sont stockés

dans des endroits spécifiques pour faciliter les recherches. Ils sont dits structurés car les nœuds

participants à l’application P2P sont reliés entre eux selon une structure particulière comme un

anneau. Ce type de réseau a été défini pour rendre des services de routage et de localisation

fondés sur le peer-to-peer.

Les systèmes peer-to-peer décentralisés mais structurés possèdent un algorithme de recherche

pour lequel une ressource donnée se trouve en un endroit parfaitement déterminé à l’avance. Cet

endroit a été calculé pour qu’il soit le plus simple d’accès aux autres peers du réseau.

L’algorithme de recherche est donc complètement déterministe, et les liens entre les pairs sont

faits suivant des règles bien définies. Cette structure permet la découverte efficace des fichiers

partagés. De plus, elle est particulièrement appropriée au développement de réseaux à grande

échelle. Dans cette catégorie, on peut placer Chord, CAN (Content Adressable Network),

Tapestry, Pastry, Kademlia et Viceroy.

Pour trouver un fichier dans un réseau peer-to-peer classique, on fait de l’inondation de requêtes

sur le réseau, en interrogeant tous les ordinateurs connectés jusqu’à trouver un ordinateur qui le

détient. Pour simplifier cette recherche, les concepteurs des réseaux peer-to-peer se sont tournés

vers des structures de données connues. En effet, améliorer les algorithmes de recherche

nécessite d’organiser le réseau, donc de le structurer, ce qui est bien l’objectif de ces réseaux


20

peer to peer décentralisés mais structurés.

Les algorithmes permettant de retrouver les fichiers partagés dans le réseau utilisent des clés

assez complexes et nous renvoyons le lecteur à des livres spécialisés pour en savoir plus. Ils ont

les propriétés suivantes :

• La fiabilité. L’algorithme de découverte et de routage garantit que pour une clé donnée

il est capable de déterminer le pair le plus proche possédant le bon fichier. Dans des

conditions statiques, une réponse négative à une requête signifie que la ressource

requise n’est pas disponible dans la communauté.

• La performance. Le nombre de sauts nécessaires est limité. Par exemple, dans une

communauté d’un million de pairs, la longueur moyenne du chemin à parcourir par une

requête avoisine 5 sauts.

• Le passage à l’échelle. Deux caractéristiques confèrent aux algorithmes de recherche la

possibilité de passer à l’échelle. La première est liée au nombre moyen de sauts

nécessaires au routage des requêtes qui reste petit même dans le cas de communautés

comptant un grand nombre de participants. La seconde est relative aux tables de routage

qui restent elles aussi d’une taille raisonnable en regard du nombre de participants.

• L’équilibre de la charge et du trafic. L’utilisation de fonctions qui permettent de créer

des communautés équilibrées où les pairs ont statistiquement en charge une part égale

de ressources à référencer. De plus, cet équilibre de la charge induit l’équilibre du trafic

au sein de la communauté, dans l’hypothèse où chaque ressource est sollicitée de

manière équivalente.

• La tolérance aux fautes. De par l’absence de centralisation, qui exclut tout point

central, l’algorithmique de recherche présente une bonne tolérance face à des

suppressions aléatoires de nœuds. Les requêtes peuvent être acheminées même si une

partie des nœuds disparaît.

• Le coût de maintenance. La nature dynamique du modèle peer-to-peer nécessite la

mise en place d’un processus de maintenance qui permet de garantir le bon

fonctionnement des algorithmes de recherche. Pour cela, le processus de maintenance,

exécuté de manière asynchrone par chaque pair, vise à vérifier régulièrement que les

entrées des tables de routage sont correctes.


21

3.4 - Les réseaux peer-to-peer hybrides

Les réseaux hybrides permettent de résoudre des problèmes de l’approche purement distribuée

tout en gardant l’efficacité de la solution centralisée. Les réseaux fondés sur ces mécanismes de

localisation et de routage de données peuvent supporter un nombre de pairs de l’ordre du

million. Cette solution combine les caractéristiques des modèles centralisés et décentralisés. La

décentralisation signifie, entre autres, l’extensibilité, la tolérance aux fautes et le passage à

l’échelle. La centralisation partielle implique quelques centres serveurs qui contiennent des

données importantes pour le système. Chaque utilisateur élit son Super-pair, qui est « le serveur

central » pour « des nœuds locaux » et peut communiquer avec d’autres Super-pairs. FastTrack,

KaZaA, BitTorrent, eDonkey/eMule sont quelques exemples que nous allons détailler.

FastTrack

FastTrack est un réseau hybride de partage de fichiers. Les pairs forment un recouvrement

structuré fondé sur l’architecture des super-nœuds (SN) et des nœuds-ordinaires (NO) pour

faciliter les recherches. Les SN forment les nœuds qui ont le plus de bande passante, le plus de

capacité disque et le plus de puissance de traitement. Toutes les requêtes leur sont envoyées.

Ensuite, une recherche fondée sur la diffusion du genre Gnutella est effectuée.

Les principales applications qui implémentent le réseau FastTrack sont KaZaA, Grokster et

Morpheus. Nous allons juste décrire KaZaA qui est certainement l’application peer-to-peer la

plus connue.

KaZaA

Les utilisateurs disposant d’une connexion très rapide sont immédiatement considérés comme

des SN et jouent alors le rôle de serveur. C’est eux qui hébergent la liste des fichiers partagés

par les clients. Les serveurs principaux ne gèrent donc que les connections et la liste des SN.

Cette méthode permet au réseau KaZaA de disposer d’une quantité croissante de serveurs de

recherche avec le nombre de clients présents.

Les SN restent des pairs, et pour cela ils partagent et téléchargent aussi des fichiers. Le temps

d’unité centrale consommé par la fonction des SN est de l’ordre de 10% et le client peut refuser

de devenir SN. Les SN communiquent entre eux pour les recherches. En fonction du

temporisateur des paquets, la recherche est plus au moins profonde sur le réseau. Les échanges

entre clients se font via le protocole HTTP. KaZaA est le client le plus connu du réseau. Une

version « Spyware Free » est disponible et s’appelle KaZaA Lite. Cette version permet aux

clients d’éviter le chargement de logiciels espions. Cependant, elle demande l’utilisation


22

d’uniquement Windows. Il faut également disposer d’Internet Explorer et de Windows Média

Player.

Lorsqu’un NO exécute l’application pour appartenir au réseau, il établit une connexion TCP avec le SN (NO-SN) et

(lui) envoie les données à partager (appelées méta-données) par la suite. Ce mécanisme permet aux SN de maintenir

une table des fichiers partagés parmi les NO. De plus, il existe des connexions parmi les SN (SN-SN). D’une façon

générale l’algorithme utilisé est le suivant :

1- Contacter un SN afin de lui fournir la requête. Selon l’origine, la requête peut directement contacter un SN

ou bien être retransmise par les différents pairs intermédiaires jusqu’à atteindre un SN.

2- Attendre les résultats fournis par le SN. Les résultats obtenus sont sous la forme d’une liste de couples pairs

et ensemble de ressources répondant à la requête.

3- Choisir parmi ces résultats le NO et la ressource répondant le mieux à la requête. Si les résultats fournis ne

sont pas satisfaisants, un élargissement du champ de la requête est possible. En effet, un SN n’étant

responsable que d’une partie des NO, il peut contacter l’ensemble des SN qu’il connaît, afin de leur

soumettre la requête.

4- Établir une connexion TCP directe avec le NO choisi pour récupérer la ressource désirée.

Cela définit les réseaux hybrides puisqu’il associe des caractéristiques des réseaux centralisés et décentralisés. KaZaA

permet l’hétérogénéité parmi les pairs participants et, pour mieux en profiter, on regroupe des pairs en plusieurs

hiérarchies. Les pairs de plus haute hiérarchie doivent respecter : (i) la durée de la connexion, (ii) la bande passante,

(iii) la capacité de l’unité centrale et (iv) la possibilité d’avoir des nœuds avec des adresses IP publiques et privées.

BitTorent

BitTorrent (ou simplement BT) est un réseau peer-to-peer hybride qui permet le partage des

fichiers à travers l’Internet. L’efficacité de ce réseau augmente lorsqu’il y a beaucoup de clients,

puisque plus il y a de clients qui téléchargent, plus il y a de clients qui partagent, et il ne faut pas

attendre dans une file virtuelle pour commencer, à condition qu’au moins une personne partage

le fichier complet désiré.

BT est un protocole open source, et grâce à cela, diverses applications l’implémentent (comme

BitTorrent officiel, Azureus, ABC, BitComet, etc.) dont certains offrent diverses améliorations

en proposant notamment une interface graphique améliorée et divers petits outils, plugins, etc.

Dans un réseau de partage de fichiers, le serveur partage sa bande passante entre les clients qui

souhaitent récupérer les fichiers proposés. Or, plus il y a de clients, plus la bande passante

consommée est importante, ce qui peut très vite devenir une source de problèmes.

Le fonctionnement de BitTorrent est fondé sur la centralisation des informations sur un serveur,

mais soulage la bande passante en permettant aux clients (les pairs) de s’échanger les parties de


23

fichiers qu’ils ont téléchargées. Le serveur est alors une graine (en anglais seed) qui démarre le

processus et envoie au moins une copie entière du fichier originel. On peut même supprimer la

source du serveur au bout d’un certain temps, et laisser les clients s’échanger entre eux (ceux

qui ont un fichier complet devenant eux-mêmes des graines). Ce réseau utilise les techniques de

téléchargement depuis différents pairs pour un même fichier (appelé « multisourcing ») et la

division de fichiers en morceaux, ce qui évite d’attendre un utilisateur ayant les parties

adjacentes à la partie déjà téléchargée (si le fichier est composé de 10 parties et si les 5

premières parties ont été reçues, le client n’est pas obligé d’attendre la partie 6 pour continuer ;

il peut très bien recevoir ensuite la partie 8 ou toute autre partie).

Toutefois, il est toujours nécessaire de centraliser ces informations en un seul et même endroit.

Celui-ci est réalisé par ce qui est appelé le « traqueur » (en anglais tracker), qui énumère toute

l’activité relative aux différents fichiers qu’il référence. L’adresse du traqueur est indiquée dans

le fichier « torrent ». C’est lui qui contient toutes les informations permettant aux clients de

télécharger les contenus. Le traqueur utilise un simple protocole sur une couche au-dessus de

HTTP dans lequel un téléchargeur envoie l’information sur le fichier. Le traqueur répond avec

une liste aléatoire des contacts des clients qui sont en train de télécharger le même fichier. Ces

clients sont appelés les sangsues (en anglais leechers). Les sangsues utilisent ensuite cette

information pour se connecter entre eux.

De plus, le protocole est conçu pour décourager les free-riders. Par rapport à d’autres réseaux

peer-to-peer, BT a plusieurs avantages lors du partage de fichiers. En effet, dès que des parties

du fichier sont téléchargées, elles sont déjà disponibles pour les autres clients. De plus, un

système de « récompense » permet de recevoir plus si l’on donne plus. Celui qui donne peu ou

pas du tout ne recevra rien. C’est ce qui s’appelle la technique « Tit-for-tat ».

Les dernières mises à jour de BT contiennent un moteur de recherche, ce qui manquait à BT. Il

s’agit aussi d’une de ses principales faiblesses. Cette nouveauté fait suite à une mise à jour qui

permet de décentraliser les traqueurs. Pour cela BT utilise le protocole Kademlia qui distribue

les traqueurs. Ce système permet également d’alléger la bande passante nécessaire pour mettre

les fichiers en ligne. Avec des traqueurs décentralisés et un moteur de recherche, BT améliore

considérablement son efficacité.

eDonkey/eMule

Le réseau eDonkey (ou eD2k) est un réseau qui a été développé par MetaMachine en septembre

2000 mais c’est au cours de l’année 2001 qu’il a connu son véritable essor. L’application eD2k

est un réseau peer-to-peer hybride pour le partage des fichiers dont les applications clientes sont


24

exécutées par les pairs situés aux extrémités de la chaîne et qui ne sont donc connectés qu’à un

seul serveur. Les serveurs sont semblables aux super-nœuds de KaZaA, sauf qu’ils ne sont pas

connectés entre eux. eD2k est gratuit et existe en deux versions : Windows et Linux. Dans tous

les cas, il permet le téléchargement de différentes ressources et utilise un protocole de transfert

de fichiers multi source, appelé MFTP (Multisource File Transfert Protocol).

Le projet eMule est né en 2002 à partir d’un utilisateur qui n’était pas content avec les clients

eD2k. Initialement fondé sur le réseau eD2k, depuis la version v.42.1, eMule utilise deux

réseaux différents : (i) le réseau eD2k classique, basé sur les serveurs et (ii) un réseau sans

serveur, basé sur Kademlia. Par nature, les deux réseaux disposent des mêmes fonctions. Ils

permettent tous deux, par des moyens différents, de trouver les autres utilisateurs et les fichiers

désirés.

Chaque client eD2k est préconfiguré avec une liste de serveurs et doit en choisir un pour se

connecter et accéder au réseau. Lorsqu’un client établit une connexion TCP avec un serveur, ce

dernier vérifie si les autres clients peuvent librement communiquer avec le nouveau client. Cela

signifie que les autres clients peuvent établir des connexions TCP directement avec ce nouveau

client. Si la réponse est affirmative, le serveur assigne au nouveau client une identification forte

(high ID). Sinon, le serveur assigne au nouveau client une identification faible (low ID).

Le réseau eD2k est fondé sur le protocole MFTP qui est capable d’optimiser les temps de

téléchargement de fichiers. Sur un système classique, le client ne peut télécharger des fichiers

qu’à partir de pairs sources disposant du fichier complet. Grâce au MFTP, un client peut à la

fois télécharger une partie d’un fichier à partir de plusieurs sources et aussi partager les parties

déjà téléchargées. L’efficacité est évidente puisqu’au moment du téléchargement d’une partie

d’un fichier à partir d’un client, lui aussi, permet déjà le transfert de cette partie aux autres

clients. L’architecture d’eD2k est hybride et est proche du super-nœud/nœud-ordinaire du

réseau FastTrack/KaZaA. Il ne fonctionne pas à partir d’un serveur centralisé de type Napster.

Mais son application en elle-même fonctionne selon un principe centralisé et il n’existe pas sur

son réseau de serveurs qui centralisent sous forme de pointeurs toutes les ressources disponibles

sur chaque client.

De plus, le serveur utilise une base de données qui maintient les informations concernant les

clients et les fichiers. Un serveur eMule ne stocke jamais de fichiers, il joue le rôle d’une table

d’index. L’application eMule ajoute plusieurs nouvelles fonctions et une interface graphique

agréable à eD2k, entre autres l’échange d’informations entre les serveurs, les clients et les

fichiers.


25

4. Conclusion

Les problématiques en jeu dans un réseau peer-to-peer sont nombreuses, et ne se résument pas à

l’algorithme de recherche uniquement. Au contraire, les recherches actuelles fournissent de

nombreuses pistes pour mieux utiliser la topologie sous-jacente, structurer le réseau pour le

rendre plus équilibré ou plus fiable. Les réseaux peer-to-peer permettent de déployer de

nouvelles fonctionnalités comme la fiabilité et la rapidité, de nouveaux protocoles comme la

récupération sur plusieurs sources simultanément et de nouvelles applications comme la

téléphonie, la distribution de canaux de télévision, etc.

Si le peer-to-peer est apparu comme un réseau peu fiable, conçu par des utilisateurs pour

échanger des fichiers souvent illégalement, il devient un véritable domaine de recherche

fournissant des modèles fiables. On peut alors imaginer de nombreuses applications légales pour

distribuer des données : logiciels ou contenus multimédias libres de droits, des attributs aux

nœuds (CPU, bande passante, disque dur, etc.) appartenant à un réseau, ou même des contenus

propriétaires chiffrés avec une gestion payante des droits de déchiffrement.

Ce qui est important, pour prédire l’avenir d’une technologie, c’est sa vitesse d’adoption par les

utilisateurs. Et les utilisateurs n’adoptent pas une technologie mais des applications. Le peer-to-

peer permet d’introduire des applications où l’utilisateur n’est pas seulement un consommateur

mais aussi un fournisseur, où la décentralisation n’est pas un objectif mais un outil, où la

puissance considérable de chaque PC pourrait être un peu mieux utilisée, où l’adresse physique

de la machine est sans importance au contraire de celle de l’utilisateur. Bref, un monde nouveau

pour les applications qui sauront en tirer partie.


26


27

Chapitre 2

Le contrôle des flux circulant sur les réseaux

Guy Pujolle


28

1- Introduction : Le réseau Internet et les protocoles Internet

Le réseau Internet n’en est qu’à son age de pierre. Les premiers protocoles, IP2, TCP3 et UDP4

ont été extrêmement bien conçus à la fin des années 70 pour résister à de nombreuses

propositions d’architectures qui sont arrivées dans les années 80 comme les architectures

constructeur dont les plus connues sont SNA, DNA, DecNet. L’architecture TCP/IP a également

résisté à une attaque beaucoup plus sérieuse de la part de l’ISO (International Standardization

Organization) lorsque la proposition OSI (Open System Interconnection) a été développée.

Même la défense américaine, en tant que grand défenseur de la technologie TCP/IP, avait

annoncé l’abandon des profils TCP/IP au profit de profils OSI. Mais elle a vite fait marche

arrière lorsqu’il s’est avéré que chaque équipementier faisait sa propre pile de protocoles OSI

indépendamment les uns des autres et que l’interconnexion de toutes ces architectures OSI était

extrêmement complexe. Il faut reconnaître que la conception de base des protocoles de

l’Internet était excellente puisque l’une des toutes premières architectures proposées est encore

en vigueur et même a pris une place ultra dominante dans le monde des réseaux. Ceci s’explique

par la grande simplicité du protocole IP et des deux couches transport bien adaptées aux flots

transportés.

IPv4 en attendant IPv6

Cependant, après avoir conquis le monde, cette pile protocolaire a du faire face à de nombreux

problèmes de jeunesse : l’introduction de la qualité de service, de la sécurité, de la gestion de la

mobilité pour ne prendre que les principales fonctionnalités. Pour remplir ces nouvelles

fonctions, il a fallu mettre de nombreuses rustines aux différents protocoles et l’introduction de

la nouvelle version IPv6 qui rassemble ces rustines de façon élégante n’a pas encore été possible

pour une raison de coût, trop élevé pour les entreprises. De plus, la version v4 a réussi le tour de

force d’introduire en son sein toutes les nouvelles fonctionnalités proposées dans le cadre

d’IPv6, d’une manière moins élégante certes mais qui fonctionnent tout à fait correctement.

On considère que les rustines représentent aujourd’hui plus de lignes de codes que les

protocoles de base eux-mêmes. Les améliorations apportées sans cesse font que nous nous

dirigeons vers une pile protocolaire stable, sécurisé et apportant de la qualité de service ainsi

2 L'Internet Protocol (IP) est un protocole utilisé pour le routage des paquets sur les réseaux. Son rôle est de sélectionner le meilleur chemin à travers les réseaux pour l'acheminement des paquets. 3 Transmission Control Protocol (TCP, « protocole de contrôle de transmissions »). Il s’agit d’un protocole de transport fiable, en mode connecté.


29

que la mobilité du terminal. Cette version IPv4 stabilisée ou le protocole IPv6, si ce standard

entrait en vigueur, sera utilisée dans l’Internet en 2010 et représente un passage à l’age de

bronze du monde des réseaux.

Dans ce chapitre, nous allons nous intéresser essentiellement au contrôle de ce nouvel Internet.

On peut prédire, vers 2010, l’apparition de pilotes automatiques des réseaux IP grâce à de

nouvelles techniques en cours de développement, l’intégration d’architectures de sécurité et

l’apparition de protocoles garantissant la qualité de service dans les réseaux. Nous allons

commencer par la qualité de service qui implique un contrôle des flux avant d’aller un peu plus

loin dans les techniques de pilotage automatique.

2- Le contrôle des flux dans la génération Internet actuelle

Le filtrage de flux consiste à reconnaître l’application qui transite dans les paquets. Suivant

l’application, il est possible de rejeter les paquets, les accélérer, les ralentir, les mettre en

attente. Cette reconnaissance est de plus en plus importante puisque la nouvelle génération

d’Internet souhaite contrôler les flux pour leur donner une qualité de service.

2.1 - Les numéros de port

Dans la génération Internet d’aujourd’hui, le filtrage des flux s’effectue sur ce que l’on appelle

un numéro de port. Ce numéro est une valeur qui se trouve dans le paquet IP et qui indique

l’application transportée dans la zone de données du paquet. Par exemple, le port 80 indique un

service HTTP, le port 7 le service ECHO, le 53 le service DNS, le 21 un transfert de fichier

FTP, le 25 le passage d’un message de type SMTP, et ainsi de suite.

Les pare-feu se servent du numéro de port pour déterminer l’application correspondante et

accepter de la laisser passer ou non. Les applications peer-to-peer ont également des numéros de

port. Globalement, les numéros de port sont compris entre 0 et 65535. Entre 0 et 1023, il s’agit

des ports réservés à l’avance par des applications précises et reconnues du monde Internet. Les

ports numérotés entre 1024 et 49151 sont les ports enregistrés et enfin entre 49152 et 65535, il

s’agit des ports dynamiques ou privés (cf. Table 2.1). Les protocoles reconnus sont ceux qui ont

été normalisés par l’IETF5, l’organisme de normalisation d’Internet et les standards IETF

4 User Datagram Protocol (ou UDP, protocole de datagramme utilisateur) est un des principaux protocoles de télécommunication utilisé par Internet. Il fait partie de la couche transport de la pile de protocole TCP/IP 5 Internet Engineering Task Force (IETF).


30

s’appellent des RFC6. Un protocole défini dans un RFC peut avoir un numéro de port reconnu.

Les ports enregistrés correspondent à des protocoles qui n’ont pas besoin d’avoir un RFC. Ces

numéros sont demandés directement à l’organisme qui s’occupe des attributions de numéro de

port, l’IANA, en expliquant la raison de la demande. Enfin les ports dynamiques représentent

une zone franche ou tout un chacun peut prendre autoritairement un numéro de port. Il n’y a

aucun contrôle et rien n’empêche qu’il y ait plusieurs applications sur un même numéro de port.

En fait, ces numéros sont utilisés comme le nom l’indique dynamiquement, c’est-à-dire qu’à un

instant donné on attribue pour la période de temps de la session au maximum un numéro

permettant à deux clients de communiquer en privé.

Tableau 2.1 - Les champs d’adresses privées

Il faut noter que certaines applications peer-to-peer bien connues ont des numéros de port

enregistrés comme BitTorrent (port TCP 6881-6999). Début 2007, on estime qu’environ 80%

du trafic n’utilisent pas de numéro de port reconnu ou enregistré.

2.2 - Les translations d’adresses

Un élément qui complique la gestion des ports provient des translations d’adresses ou NAT

(Network Address Translation). En effet, quand un particulier ou une entreprise a plusieurs

machines à connecter, il ne lui est donné en général qu’une seule adresse IP qui est dite

publique. Cette adresse publique est routable7, c’est-à-dire qu’un routeur est capable de

déterminer la direction à prendre pour aller vers cette adresse. Comme les adresses publiques ne

sont pas assez nombreuses pour toutes les machines à connecter, les opérateurs n’en décernent

qu’un nombre très limité aux utilisateurs. Par exemple, derrière un modem ADSL s’il y a

plusieurs machines connectées, elles doivent se partager une adresse IP routable unique. Pour

cela on utilise un NAT qui consiste à donner des adresses privées parmi des champs réservés

dans l’adresse IP et à faire correspondre à cette adresse privée, l’adresse publique plus un

numéro de port de telle sorte que, aussi bien pour les paquets entrants que sortants, il est

6 Request for Comments (RFC). 7 Un routeur est un matériel de communication de réseau informatique destiné au routage. Son travail est de limiter les domaines de diffusion et de déterminer le prochain nœud du réseau auquel un paquet de données doit être envoyé, afin que ce dernier atteigne sa destination finale le plus rapidement possible. Ce processus nommé routage intervient à la couche 3 (couche réseau) du modèle OSI (Open Systems Interconnection).


31

possible de faire le lien avec le terminal ayant une adresse privée.

2.3 –Reconnaissance des applications P2P

Les applications peer-to-peer ainsi que certaines autres applications, comme les applications

RPC8 ont été construites pour travailler sur des ports dynamiques : l’application démarre sur un

numéro de port enregistré puis continue sur un numéro de port fixé entre les deux terminaux

communiquant. Il est donc très difficile de déterminer la nature d’une application qui utilise un

port dynamique puisque le numéro de port a été choisi de façon aléatoire. Il faut en général être

capable de suivre l’évolution de la connexion à partir de son début, en repérant l’application par

son numéro de port initial puis en gardant en mémoire ses changements de port. Cette solution

est cependant assez complexe puisqu’il faut arriver à retrouver dans les paquets du flot

l’information de changement et noter la nouvelle valeur du port. Comme nous allons le voir,

plus loin, la nouvelle génération d’équipement de filtrage ne se sert plus du numéro de port mais

de la reconnaissance de la syntaxe du flot, ce qui va permettre une meilleure détermination des

applications.

3- Les pare-feu

Les pare-feu constituent des remparts indispensables pour se protéger des accès extérieurs. Ils

sont aujourd’hui couramment employés, à la fois par les particuliers et par les entreprises. Les

pare-feu opèrent en mettant en place des règles de filtrage. Ils inspectent tous les paquets qui

transitent et vérifient s’ils sont conformes à la politique de sécurité implémentée par les règles

de filtrage. Si c’est le cas, les paquets sont autorisés à traverser le pare-feu et à poursuivre leur

acheminement vers leur destinataire. Au contraire, si ce n’est pas le cas, alors les paquets sont

détruits.

Les pare-feu les plus classiques distinguent cinq éléments qui caractérisent les flux : l’adresse IP

de la source, le port utilisé par la source, l’adresse IP du destinataire, le port utilisé par le

destinataire et enfin le protocole de transport spécifié dans un paquet. Une règle de filtrage

mentionne donc la valeur de chacun de ces cinq éléments, et ordonne une action à entreprendre

lorsque toutes les valeurs sont valides. L’action entreprise est soit d’autoriser soit d’interdire le

paquet, c’est-à-dire respectivement de laisser passer le paquet ou bien de le détruire.

Typiquement, un pare-feu adopte pour politique de bloquer tous les paquets pour lesquels

aucune règle d’acceptation ne convient. La politique inverse, qui laisse passer les paquets pour

8 Remote Procedure Call (RPC). Il s’agit d’un protocole permettant de lancer une procédure d'un programme sur un ordinateur distant.


32

lesquels il n’y a pas de règle indiquée, est dangereuse pour un réseau puisque ces paquets

peuvent porter des attaques.

Un sixième élément peut être pris en compte dans les pare-feu : l’état d’une connexion.

Les pare-feu avec et sans état

Lorsqu’une communication est établie avec les cinq éléments mentionnés précédemment, on

considère que la connexion est à l’état actif ou établi. Autrement, l’état est considéré comme

inactif. On distingue donc deux catégories de pare-feu :

- les pare-feu sans état : ils ne maintiennent pas l’état des connexions, et se contentent du

5-uplets pour autoriser ou interdire les flux qui transitent sur le réseau ;

- les pare-feu avec état : ils maintiennent l’état des connexions et sont capables de

distinguer si une communication s’effectue sur un port déjà ouvert ou bien sur un port

que le paquet demande d’ouvrir.

La notion d’état est utile pour les protocoles à ports dynamiques : avec des applications

exploitant ces protocoles comme les applications peer-to-peer, une communication s’établit sur

un port fixe vers un destinataire, puis lorsque ce dernier est contacté, il convient avec l’émetteur

de poursuivre la communication sur un autre port arbitrairement sélectionné. De cette façon, le

destinataire reste disponible pour servir un autre correspondant qui tenterait de le joindre

ultérieurement sur le port fixe.

Face à cette situation, seul un pare-feu avec état est capable d’autoriser l’usage du port

dynamique. Pour cela, il lui faut analyser les paquets et déterminer s’ils sont liés ou non à une

connexion préalablement établie. Imaginons par exemple, un protocole peer-to-peer dans lequel

un destinataire demande à la source de remplacer le port statique initial par un port dynamique

qu’il lui impose. Trois étapes successives se déroulent : la source émet un premier paquet vers

un port fixé du destinataire. Puis le destinataire lui répond en précisant le port sur lequel il

souhaite poursuivre la communication, et la source reprend la communication en utilisant le port

mentionné. Pour le pare-feu sans état, seules les deux premières étapes sont possibles

puisqu’elles peuvent correspondre à une règle statique simplement basée sur le 5-uplets initial.

L’ouverture d’un port dynamique lui est impossible, car aucune règle n’en permet la définition

(à moins d’être totalement permissive, et d’ouvrir tous les ports possibles, mais ce n’est pas une

politique de sécurité satisfaisante). En revanche, pour le pare-feu avec état, la troisième étape est

possible. En effet, ce type de pare-feu est capable d’analyser les flux et de déterminer que le

port dynamique sur lequel la source tente de communiquer correspond à la demande qui a été


33

faite précédemment par la destination. La gestion des états offre une performance accrue dans le

traitement des paquets, mais elle a un coût car elle introduit une latence supplémentaire pour le

pare-feu, qui doit en outre savoir analyser les protocoles correctement (et pour cela connaître

leur syntaxe).

L’état est facilement discernable avec le protocole TCP, puisque ce dernier positionne des bits

qui indiquent si la connexion est nouvelle, se poursuit ou bien se termine. Au contraire, le

protocole UDP ne fournit pas ces indications. Pourtant, le pare-feu ne peut pas attribuer

éternellement le statut d’actif à une connexion UDP. Généralement, il alloue le statut actif à une

connexion UDP pendant un certain délai. Passé ce délai, la connexion est considérée comme

perdue et devient par conséquent inactive. Toutefois, cette manière de procéder est très

approximative, et ne convient pas aux applications de téléphonie sur IP qui utilisent très

majoritairement le protocole UDP pour transporter la parole. En effet, si lors d’une

communication, les intervenants cessent de parler, le silence correspondant n’est pas transmis,

et aucun paquet ne sera transporté durant cet intervalle de temps. Le pare-feu risque de

considérer ce silence comme une terminaison de la communication, ce qui serait une décision

erronée.

Un pare-feu est utile pour centraliser la politique de sécurité au sein d’un équipement unique.

De cette manière, la gestion du contrôle des applications autorisées n’est pas laissée aux

utilisateurs, mais est à la charge du réseau, ce qui réduit les possibilités de contourner les règles

imposées au sein d’une entreprise.

Les fonctionnalités d’un NAT (Network Address Translation) sont très souvent implémentées

en parallèle avec les fonctionnalités de pare-feu. En effet, l’opération réalisée par le NAT

comme par le pare-feu doit s’appliquer au niveau d’une passerelle, point de jonction entre le

réseau local privé et le réseau public. En outre, dans ces deux fonctions, une notion de filtrage

est requise : lorsque les flux traversent le réseau, le boîtier NAT détecte l’adresse IP source

privée et la translate avec une adresse IP publique, tandis que le pare-feu inspecte l’adresse IP

source pour s’avoir si l’utilisateur est autorisé à émettre des flux. Dans le même temps, le pare-

feu détecte les ports et protocoles utilisés par l’application pour opérer un filtrage avec une

granularité plus forte. Autrement dit, l’analyse des paquets est un mécanisme partagé par la

fonction de NAT comme par la fonction de pare-feu, ce qui justifie leur couplage.


34

4- Le filtrage applicatif des données.

Tous les réseaux utilisent aujourd’hui le protocole IP pour la couche réseau et les protocoles

TCP ou UDP pour la couche de transport. Dans un cadre classique la majorité des flux sont

reconnus par leur numéro de port et peuvent être traités.

Pour opérer les modifications d’adresses IP et de port requises par la translation d’adresse, le

boîtier NAT doit impérativement connaître le format et la syntaxe des protocoles sous-jacents :

en l’occurrence pour l’adressage IP, c’est le protocole IP qui est utilisé (couche de niveau

réseau), et pour le port, c’est le protocole TCP ou bien UDP qui est utilisé (couche de niveau

transport). Cependant, les attaquants ou ceux qui utilisent des applications P2P cherchent à

modifier les numéros de port de façon non voyante ou de plus en plus d’utiliser des ports connus

pour réaliser leur communication. Par exemple, une application P2P qui utilise le port 80, a

priori réservé à l’application HTTP, ne sera pas arrêtée puisque le coupe-feu interprétera de

façon erronée cette information. Il faut donc trouver de nouvelles solutions permettant de filtrer

les flux mais sans utiliser le numéro de port.

L’idée poursuivie depuis une dizaine d’années consiste à reconnaître la syntaxe du flux : la

position des 0 et des 1 permet de déterminer exactement l’application transportée dans un

paquet. En effet, chaque protocole à des spécificités qui sont reconnaissables. Le filtrage sur la

syntaxe est néanmoins beaucoup plus complexe que la reconnaissance du numéro de port, car

les protocoles sont très nombreux et chaque jour de nouveaux protocoles entrent en

fonctionnement.

La réponse apportée dans ce cadre est donc une solution de filtrage de tous les protocoles

utilisés par les applications.

Les passerelles de niveau applicatif (ALG).

Une nouvelle gamme de passerelles multimédias a été mise en œuvre pour permettre la

reconnaissance des flux : on les appelle ALG (Application Layer Gateways). Il existe un grand

nombre de solutions commerciales de ce type, embarqué le plus souvent au sein d’un pare-feu :

les flux sont filtrés et s’ils sont reconnus, les modifications nécessaires au bon fonctionnement

du NAT sont opérées parallèlement à l’acceptation de ces flux à traverser le pare-feu.

C’est dans cet esprit que le projet libre Netfilter sous Linux (http://www.netfilter.org), propose la reconnaissance d’un

très grand nombre de protocoles, des couches basses aux couches les plus hautes. Les modules de reconnaissance sont

également disponibles pour les protocoles H.323 et SIP correspondant à la signalisation téléphonique, c’est-à-dire le

passage de paquets qui ont pour but lors de l’arrivée au destinataire de déclencher une sonnerie. Deux modules sont


35

nécessaires, le premier (ip_conntrack) réalisant le suivi de connexion (car les flux utilisent des ports qui sont

dynamiques et doivent être détectés durant la communication) et le second (ip_nat) réalisant la translation d’adresse.

La technologie Netfilter est accessible par défaut dans toutes les distributions actuelles de Linux, avec la commande

iptables. Elle est fournie avec un ensemble de filtres pour la reconnaissance des protocoles les plus standards. Selon

les distributions Linux, le module de suivi de connexion n’est pas toujours fourni, mais peut être complété facilement

avec la technologie patch-o-matic qui automatise les mises à jour de Netfilter.

Cette solution est simple à mettre en place et transparente au niveau de l’application des utilisateurs. En effet,

l’application n’a pas à modifier la structure des paquets envoyés, c’est le boîtier qui se charge, en émission (du réseau

local vers le réseau Internet), de les rendre valides, et en réception (du réseau Internet vers le réseau local) de les

distribuer au terminal adéquat. Mais le boîtier NAT a une tâche beaucoup plus lourde à accomplir puisqu’il doit filtrer

des protocoles complexes, de niveau applicatif, ce qui réclame des ressources de traitements conséquents. Cette

fonctionnalité implique donc à la fois la reconnaissance des protocoles, mais aussi des traitements pour remonter

jusqu’au niveau applicatif des paquets qui peuvent considérablement freiner les transmissions. On peut donc lui

préférer d’autres solutions alternatives.

5- Filtrage de nouvelle génération

Nous avons examiné la première solution de reconnaissance par l’utilisation du numéro de port.

Même si cette indication continue à être utilisée pour réguler les flots des utilisateurs standards,

elle ne permet pas de détecter les applications qui se veulent pirate, donc les applications P2P et

les attaques. Il faut alors utiliser des filtres de nouvelle génération que nous allons décrire dans

cette section.

Une application peut en cacher une autre

Les solutions de filtrage et de reconnaissance des ports dynamiques de la première génération

que nous avons introduits dans la section précédente, ne sont toutefois pas suffisantes, car

certaines applications peer-to-peer sont capables de se connecter sur un port ouvert. Par

exemple, un tunnel peut être réalisé sur le port 80, qui gère le protocole HTTP. À l’intérieur de

l’application HTTP, un flot de paquets d’une autre application peut passer. Le pare-feu voit

entrer une application HTTP, qui, en réalité, délivre des paquets d’une autre application.

Une entreprise ne peut pas bloquer tous les ports, sans quoi ses applications ne pourraient plus

se dérouler. On peut bien sûr essayer d’ajouter d’autres facteurs de détection, comme

l’appartenance à des groupes d’adresses IP connues, c’est-à-dire à des ensembles d’adresses IP

qui ont été définies à l’avance. De nouveau, l’emprunt d’une adresse connue est assez facile à

mettre en œuvre. De plus, les flots provenant des applications peer-to-peer peuvent transiter par

des ports qu’il est impossible de bloquer comme les ports DNS sinon le réseau lui-même ne

pourrait plus fonctionner.


36

Une solution beaucoup plus puissante de filtrage, consiste à examiner les flots non plus aux

niveaux 3 ou 4 (adresse IP ou adresse de port) mais au niveau applicatif. Cela s’appelle un filtre

applicatif. L’idée est de reconnaître directement sur le flot de paquets l’identité de l’application

plutôt que de se fier à des numéros de port et de pister les ports dynamiques. Cette solution

permet d’identifier une application insérée dans une autre et de reconnaître les applications sur

des ports non conformes. La difficulté avec ce type de filtre réside dans la mise à jour des filtres

chaque fois qu’une nouvelle application apparaît. Le pare-feu muni d’un tel filtre applicatif peut

toutefois interdire toute application non reconnue, ce qui permet de rester à un niveau de

détection et de sécurité élevé.

Lorsqu’un utilisateur est connecté, tout son flot de paquets transite systématiquement via le

filtre. Les paquets sont donc tous interceptés par ce dernier et suivent un cycle de cheminement

parfaitement déterminé.

Les filtrages de nouvelle génération utilisent les signatures des protocoles, c’est-à-dire un

moyen de reconnaissance du protocole par l’intermédiaire d’un certain nombre d’éléments qui

produisent une signature qui est unique pour chaque application. A ces éléments

différentiateurs, il est possible d’associer des éléments plus classiques comme les adresses, les

numéros de ports, etc. que l’on appelle parfois les attributs du protocole. On pourra donc filtrer

sur la signature et les attributs comme rechercher une application peer-to-peer d’un certain type

travaillant avec un site d’une certaine adresse et utilisant, par exemple, un numéro de port

dynamique déterminé.

Il n’y a pas deux protocoles qui possèdent la même signature. En mettant en place des filtres qui

syntaxiquement permettent de déterminer la signature, il est possible d’identifier les flots sur le

réseau. L’avantage de cette nouvelle technologie est de pouvoir reconnaître des flots fortement

encapsulés et en quelque sorte cachés. Cette technique n’utilise plus la notion de port ou si elle

l’utilise ce n’est que pour mettre en place une technique de filtrage simplifiée en vérifiant que la

signature correspond bien au numéro de port quand celui-ci a une signification.

Les difficultés de cette technologie proviennent de la mise à jour des filtres avec l’apparition de

nouvelles applications et en particulier de nouvelles applications peer-to-peer. Mais cette mise à

jour peut-être faite quotidiennement avec des mécanismes aujourd’hui assez classiques dans la

mise à jour de logiciel.

Ces filtres sont appelés filtres de niveau 7 ou filtres applicatifs. Ils vont remplacer petit à petit

les filtres de niveau 4 ou filtre de transport travaillant essentiellement sur les numéros de port.

Une solution pour traverser les filtres sans être reconnu est de chiffrer les informations


37

nécessaires à la détermination de la signature. Cependant, pour cela, il faut au préalable ouvrir la

connexion et mettre en accord les deux correspondants sur des clés de chiffrement communes.

Cela laisse le temps de suivre la connexion qui se met en place et de l’identifier. Pour que le

chiffrement puisse être réellement opérationnel, il faut que les deux correspondants se mettent

d’accord au préalable sur les clefs de chiffrement à utiliser, ce qui limite de nouveau la taille du

groupe pouvant utiliser cette solution de traversée des filtres sans être reconnu. Il est également

à noter que les filtres doivent intervenir le plus tôt possible dans la chaîne de transmission. En

effet, les chiffrements interviennent en général dans les tunnels, par exemple un tunnel IPSec, et

plus le filtre se trouve près de la machine terminal, et plus est forte la chance que le flot ne soit

pas chiffré. Pour contrer le chiffrement, il suffit de détruire tous les paquets dont il n’est pas

possible de déterminer l’application et donc en particulier les paquets chiffrés.

De nombreux filtres applicatifs sont commercialisés depuis quelques années avec des qualités

plus ou moins bonnes en fonction de l’implémentation des éléments de filtrage et de leur mise à

jour automatique. Des logiciels libres de filtrage autour de Linux en particulier sont disponibles

mais assez complexes à utiliser aujourd’hui.

6- Le contrôle des filtres et de l’Internet

Une fois le flot reconnu, il est possible de décider des actions à mettre en œuvre comme détruire

le flot concerné, le ralentir, l’accélérer, le compresser, le chiffrer, etc. Ces actions sont réalisées

par ce que l’on peut nommer des agents, plus ou moins intelligents. Ces agents sont des

composants logiciels capables de mettre en exécution des règles que l’on appelle classiquement

des politiques (du mot anglais policy) ou encore règles de politique.

6.1 – Définition des politiques de régulation du trafic

Une politique s’exprime sous la forme « si condition, alors action ». Par exemple, « si

l’application est de type parole téléphonique, alors mettre les paquets en priorité Premium » ou

encore « si l’application est un peer-to-peer de type xx et que les adresses IP appartiennent à la

classe yy alors supprimer les paquets ». Une politique peut se définir à différents niveaux. Le

niveau le plus haut correspond à celui de l’utilisateur, la détermination d’une politique

s’effectuant par une discussion entre l’utilisateur et l’opérateur. On utilise pour cette discussion

soit le langage naturel, soit des règles déjà préparées par l’opérateur du réseau. Dans ce dernier

cas, l’utilisateur ne peut que choisir parmi ces règles la politique la plus proche de ce qu’il

souhaite voir appliquer. On parle alors de politique définie au niveau « business ». Cette

politique doit être traduite dans un langage de niveau réseau permettant de déterminer le


38

protocole réseau de gestion de la qualité de service et son paramétrage. Enfin, il faut traduire ce

langage de niveau réseau en un langage de bas niveau correspondant à la programmation des

nœuds du réseau, ce que l’on peut appeler la configuration du nœud.

Une normalisation importante a été effectuée sur ces différents niveaux de langage, business,

réseau et configuration à l’IETF et au DMTF (Distributed Management Task Force).

L’objectif de ce travail de normalisation des modèles d’information liés aux différents niveaux

de langage est d’obtenir un modèle général qui puisse se décliner en modèles d’information par

domaine, ainsi qu’une représentation indépendante des équipements et des implémentations.

6.2 – Le contrôle de l’application des politiques

Le contrôle par politique est donc un contrôle qui s’appuie sur l’application de règles de

politique dans un réseau et la meilleure façon d’appliquer ce contrôle est de configurer les filtres

suivant les règles définies par le gestionnaire du réseau. Cette configuration peut être plus ou

moins automatique suivant le niveau de définition de la politique. Si l’on est au niveau de la

configuration des nœuds, le travail est plus ou moins manuel et effectué par un ingénieur qui

configure les équipements du réseau par l’intermédiaire d’une programmation de bas niveau.

L’automatisation est obtenue en partant d’un niveau beaucoup plus haut dans lequel le

gestionnaire du réseau définit les règles de politique au niveau business et c’est le système qui

effectue automatiquement les traductions nécessaires pour avoir du code de configuration qui

est introduit dans les équipements de réseau.

Cette automatisation a dans un premier temps été réalisée dans un environnement centralisé. Les

nœuds du réseau prennent le nom de PEP (Policy Enforcement Point). Les politiques y sont

appliquées pour gérer les flux des utilisateurs. Le PDP (Policy Decision Point) est le point qui

prend les décisions et choisit les politiques à appliquer aux PEP. La communication entre le

PEP et le PDP s’effectue par le biais d’un protocole comme NetConf (Network Configuration)

qui est suffisamment générique, parce qu’employant un format XML, pour s’adapter à toute

sorte d’équipements de réseau. Le système comporte également une console utilisateur, qui

contient des outils de gestion des politiques. Ces derniers permettent notamment d’entrer les

politiques dans une base de données, nommée Policy Repository, qui entrepose les règles de

politique que le PDP vient rechercher pour les appliquer aux nœuds du réseau. Cette

architecture est décrite à la figure suivante.


39

Figure - Architecture d’un système géré par politique

Des variantes de ce schéma de base peuvent inclure plusieurs PDP susceptibles de gérer un

même nœud de transfert du réseau. Dans ce cas, les PDP ont des rôles différents. Une autre

variante correspond à une décentralisation des fonctions du PDP dans des PDP locaux, appelés

LPDP (Local Policy Decision Point). En règle générale, un PDP gère un seul domaine

administratif, et les règles de politique sont communes à la configuration de l’ensemble des

nœuds du domaine.

Un problème de cohérence se pose lorsque le client émetteur et le client récepteur ne se trouvent

pas dans le même domaine administratif. Dans ce cas, les PDP des deux domaines doivent

négocier pour se mettre d’accord sur les règles de politique à adopter pour que la

communication se déroule de bout en bout avec la qualité voulue.

7- La nouvelle architecture de contrôle

La solution décrite à la section précédente est une solution centralisée qui n’est pas vraiment

satisfaite par sa lourdeur et sa fragilité ainsi que par sa difficulté de passer à l’échelle. Une

nouvelle architecture a été cr�

Livre Blanc sur le « Peer-to-Peer - April...Livre blanc sur le « Peer-to-Peer » 5 INTRODUCTION...

Documents

Transcript of Livre Blanc sur le « Peer-to-Peer - April...Livre blanc sur le « Peer-to-Peer » 5 INTRODUCTION...