Charte D'engagements Pour La Lutte Contre La Piraterie Et Pour Le Développement Des Offres Légales de Musique en Ligne"

VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
CHARTEPOURLEDEVELOPPEMENTDELOFFRELEGALE DEMUSIQUEENLIGNE,LERESPECTDELAPROPRIETE
INTELLECTUELLEETLALUTTECONTRELAPIRATERIENUMERIQUE
ETUDEDESSOLUTIONSDEFILTRAGEDESECHANGES
DEMUSIQUESURINTERNETDANSLEDOMAINE DUPEERTOPEER
RAPPORTDETUDE
REF DOCUMENT
AUTEURS DATE VERSION
A. Brugidou, G. Kahn 09/03/2005 18:19:00
CHARTE.RTF
Page 1/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Historique des modifications

Version 0.1 0.12 Date Auteur Modification apporte Cration et rdaction initiale du document Enrichissement du document pour intgrer les lments issus des auditions et ajout de la synthse Finalisation du corps du document Ajout des annexes Modification de la table des matires Apport de complments sur la synthse
28 aot 2004 A. Brugidou 14 novembre A. Brugidou 2004 11 dcembre A. Brugidou 17 dcembre A. Brugidou 22 dcembre A. Brugidou 04 janvier 05 janvier G. Kahn
0.17 0.20 0.22 V3Jan V4Jan
A. Brugidou, G. Finalisation du document Kahn A. Brugidou, G. Prise en compte de remarques Kahn
V10
09 mars
CHARTE.RTF
Page 2/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Table des matires

1. Introduction ............................................................................................................5 1.1. Charte et mission des experts ...........................................................................5 1.2. Structure de ltude ...........................................................................................6 1.3. Dmarche adopte............................................................................................6 1.4. Technologies du peer-to-peer ...........................................................................7 1.4.1. Introduction.................................................................................................7 1.4.2. Importance du trafic peer-to-peer ...............................................................7 1.5. Autres tendances et volutions technologiques ..............................................10 1.5.1. NAT (Network Address Translation).........................................................10 1.5.2. Encryptage et tunnelling ...........................................................................11 1.5.3. Protocole IP V6.........................................................................................12 2. Synthse ...............................................................................................................13 2.1. Constats gnraux ..........................................................................................13 2.2. Le filtrage.........................................................................................................14 2.3. Lapproche Radar ......................................................................................16 2.4. Sur le plan technique, ncessit dexprimenter.............................................17 2.5. Besoin de mettre en uvre plusieurs solutions en parallle...........................18 3. Analyse des solutions de filtrage .......................................................................19 3.1. Introduction......................................................................................................19 3.2. Modes de dploiement envisageables ............................................................19 3.3. Familles de solutions de filtrage ......................................................................20 3.3.1. Familles identifies dans ltude du SNEP et prslection ......................20 3.3.2. Famille de solutions considres dans la prsente tude........................22 3.4. Filtrage de protocole........................................................................................24 3.4.1. Schma de principe..................................................................................24 3.4.2. Mode Filtrage systmatique ...............................................................25 3.4.3. Mode Filtrage la demande................................................................28 3.5. Filtrage de contenu..........................................................................................32 3.5.1. Schma de principe..................................................................................32 3.5.2. Mode Radar ........................................................................................34 3.6. Filtrage sur le poste client ...............................................................................36 3.6.1. Introduction...............................................................................................36 3.6.2. Schma de principe des solutions serveur central ................................37 3.6.3. Mode Filtrage la demande ...............................................................37 3.6.4. Conclusion................................................................................................38
CHARTE.RTF Page 3/59 IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
3.7. Synthse .........................................................................................................39 4. Exprimentations recommandes......................................................................40 4.1.1. (E1) Solution filtrage poste client, mode la demande ............................40 4.1.2. (E2) Solutions orientes protocole et contenu, observatoire de trafic P2P ........................................................................................................40 5. Annexe 1 Auditions organises.......................................................................43 6. Annexe 4 Etudes de cas ...................................................................................44 6.1. Introduction......................................................................................................44 6.2. Filtrage de protocole P_Cube dans le contexte dun FAI 1 .............................44 6.2.1. Architecture du FAI 1................................................................................44 6.2.2. Solution P_Cube.......................................................................................45 6.2.3. Positionnement des botiers Scnario 1 ................................................45 6.2.4. Positionnement des botiers Scnario 2 ................................................46 6.2.5. Contraintes induites chez le FAI...............................................................46 6.3. Filtrage de poste client dans le contexte dun FAI 1........................................48 6.3.1. Introduction...............................................................................................48 6.3.2. Principe de mise en uvre.......................................................................49 6.3.3. Critres identifis par le FAI 1 pour rpondre aux besoins de filtrage de la charte .......................................................................................................49 6.4. Filtrage de contenus Audible Magic dans le contexte dun FAI 2....................51 6.4.1. Solution Audible Magic .............................................................................51 6.4.2. Architecture du FAI 2................................................................................51 6.4.3. Scnarios de positionnement des botiers................................................52 6.4.4. Dcompte des botiers..............................................................................53 6.4.5. Contraintes induites chez le FAI...............................................................54 6.4.6. Cas dutilisation de la solution de filtrage de contenus.............................55 6.5. Filtrage de protocole Allot dans le contexte dun FAI 3 ...................................55 6.5.1. Architecture du FAI 3................................................................................55 6.5.2. Solution Allot NetEnforcer ........................................................................56 6.5.3. Scnarios de positionnement des botiers................................................56 6.5.4. Dcompte des botiers..............................................................................57 6.5.5. Contraintes induites chez le FAI...............................................................58
CHARTE.RTF
Page 4/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
1. Introduction
1.1. Charte et mission des experts
La "Charte d'engagements pour la lutte contre la piraterie et pour le dveloppement des offres lgales de musique en ligne" a t signe le 27 juillet 2004 sous lgide du Gouvernement franais, entre les fournisseurs d'accs Internet, les distributeurs, les distributeurs en ligne, les socits d'auteurs et les producteurs. Le Ministre de la Culture et de la Communication, le Ministre dlgu lIndustrie et le Ministre dlgu la Recherche ont nomm deux experts, Gilles Kahn, prsident de lInstitut National de Recherche en Informatique et Automatique (INRIA) et Antoine Brugidou, responsable des activits Service Public au sein de la socit de conseil et ingnierie Accenture.
La mission des experts est dfinie au chapitre 4.2 de la charte : Sous lgide de deux experts dsigns par les pouvoirs publics, tudier avant le 1er octobre 2004 les solutions proposes par les industriels de la musique (tude transmise par le SNEP) en matire de filtrage, la demande des internautes, dans le domaine du peer to peer. Si les experts lestiment ncessaire et possible sur les plans techniques, notamment en terme de qualit de service, et conomiques, et sous leur supervision, exprimenter via un ou plusieurs fournisseurs daccs, dans les dlais recommands par les experts, certaines de ces solutions. Un bilan de lexprimentation est tabli de manire proposer, si cest possible sur les plans techniques et conomiques, dans des conditions rellement incitatives, le bnfice dun de ces systmes aux abonns qui le souhaitent. Les conditions de lexprimentation et sa prise en charge financire, ainsi que de lventuel dploiement, seront prcises dans des conventions particulires. Pendant la dure de ltude et de lventuelle exprimentation, les industriels de la musique sabstiennent de solliciter des mesures de filtrage dans toute action contentieuse .
CHARTE.RTF
Page 5/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
1.2. Structure de ltude

La mission des experts dfinie dans la Charte a t dcline en deux volets : Un volet technique avec lanalyse des solutions de filtrage. Son objectif est dtablir un point de vue sur la faisabilit de mise en uvre des solutions de filtrage dans le domaine du peer-to-peer disponibles ce jour, sur la base de ltude mene par le SNEP1, de laudition des diffrents acteurs notamment les fournisseurs de technologies et les FAI, et avec la mise en perspective des modalits prvues par la Charte. Un volet de dfinition des exprimentations, dont lobjectif est de proposer les objectifs dune ou plusieurs exprimentations en grandeur relle, en partenariat avec un ou plusieurs FAI et les fournisseurs de solutions techniques. Ces exprimentations permettront de valider les conclusions du volet prcdent.
Chaque volet fait lobjet dun chapitre particulier du rapport. Par ailleurs, il nous a sembl opportun de rappeler en annexe un ensemble dlments de contexte sur les technologies du peer-to-peer et les principales volutions technologiques qui impactent la problmatique de filtrage.
1.3. Dmarche adopte

Ltude a t mene selon la dmarche suivante : Prparation :

Identification des participants convoquer aux auditions et prises de contact. Formalisation des ordres du jour et convocations.
Auditions individuelles :
Auditions individuelles des diffrentes catgories dacteurs impliqus dans ltude (Cap Gemini, FAI, ayants droits de lindustrie de la musique, fournisseurs de technologie). Collecte des remarques sur les principaux aspects techniques de ltude (familles de solutions envisageables, prslection de solutions et choix de la solution tudie, tude de dimensionnement la cible).
Cette tude a t rendue publique et est par exemple accessible sur le site des Echos (http://www.lesechos.fr/lettrespro/presentation/telecom/flash/rapport_filtrage_capgemini_france.pdf)
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Elaboration de scnarios pour lexprimentation.
Sessions de travail technique complmentaires :
Runions de travail menes afin de dtailler la possibilit et le cas chant les principales modalits techniques de la mise en uvre de solutions de filtrage.
Mise en uvre de sessions plnires : runions contradictoires rassemblant les diffrents acteurs concerns et discussion autour des solutions proposes :
Une premire session portant sur les sujets techniques : revue de ltude mene par le SNEP et analyse des diffrents acteurs. Une seconde session de portant sur le cadrage dune exprimentation : identification et analyse de scnarios dexprimentation.
Synthse :
Rdaction du rapport dtude.
1.4. Technologies du peer-to-peer

1.4.1. Introduction
Ltude de la pertinence de la mise en place de solutions de filtrage des protocoles peer-to-peer suppose de prendre en compte un ensemble dlments de contexte technique : Les technologies du peer-to-peer importance du peer-to-peer au sein du trafic gr par les FAI, impact techniques, volution des protocoles peer-to-peer. Les technologies de lInternet dveloppement dIP V6 et du cryptage, etc.
La socit CacheLogic a publi en juillet dernier une analyse du trafic peer-to-peer. Elle porte sur le premier semestre 2004, et avait pour but de mettre en vidence l'intrt que prsente pour un fournisseur d'accs la gamme de produits de surveillance du trafic sur les rseaux IP. Les FAI franais nayant pas fourni dinformations dtailles sur le trafic peer-to-peer en France, nous reprenons ci-aprs les informations publies dans ltude de CacheLogic2 qui fournissent un ordre de grandeur pertinent.
1.4.2.
Importance du trafic peer-to-peer
Les quatre tableaux ci-dessous, fournis par la socit CacheLogic illustrent limportance et lvolution rapide du trafic vhicul par des protocoles peer-to-peer.
http://www.cachelogic.com/research/index.php
Page 7/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Le diagramme ci-contre montre la proportion du trafic par port TCP et par protocole constat par CacheLogic chez un FAI grand public anglais. Il fait apparatre que la reconnaissance par port nest pas suffisante pour reconnatre le trafic peerto-peer : lutilisation de ports configurables dans les applications peer-to-peer clientes, lallocation dynamique de ports ou lutilisation des ports standard (http, mail, ) par les applications peerto-peer rend inefficace une reconnaissance au niveau du port.3
Le diagramme ci-contre montre la proportion du trafic descendant rparti par protocole, constat par CacheLogic chez un FAI grand public anglais. Il fait apparatre que les flux peer-to-peer reprsentent la majeur partie du trafic chez ce FAI le volume peer-to-peer reprsentant plus du double du trafic http (navigation web) pendant les priodes de pic de charge du soir et plus de dix fois le trafic http pendant les autres priodes. 4
http://www.cachelogic.com/research/slide5.php http://www.cachelogic.com/research/slide3.php
Page 8/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Le diagramme ci-contre montre la proportion du trafic montant rparti par protocole, constat par CacheLogic chez un FAI grand public anglais. Il confirme que le trafic peer-to-peer est par nature un trafic symtrique en matire de ratio trafic descendant / montant (alors que les protocoles traditionnels type http sont asymtriques avec une proportion de trafic descendant beaucoup plus importante). 5
http://www.cachelogic.com/research/slide7.php
CHARTE.RTF
Page 9/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Le diagramme ci-contre montre la proportion du trafic descendant par protocole peer-to-peer en compa-raison entre janvier et juin 2004, constate par CacheLogic chez un FAI grand public anglais. Il fait apparatre que la rpartition du trafic peer-topeer volue rapidement, les utilisateurs changeant de protocole : si lutilisation de Kazaa diminue fortement (passage de 46% 19% en 6 mois), Bittorrent augmente rapidement (passage de 26% 53% en 6 mois). 6
1.5. Autres tendances et volutions technologiques

1.5.1. NAT (Network Address Translation)
Le dploiement de fonctions permettant la connexion de plusieurs quipements quips de carte rseau (USB, Ethernet, WiFi) se fait progressivement avec la monte en puissance du nombre dquipements aptes une connexion rseau ou un accs Internet (PC fixes, PC portables, quipements de type AirPort Express permettant la diffusion de flux audio ou vido vers les matriels audiovisuels, etc.). Ces fonctions sont soit intgres aux botiers fournis par les FAI dans le cadre doffre WiFi par exemple, soit prennent la forme de matriels externes au botier FAI achets par les abonns (routeur / hub et points daccs WiFi) et positionns en aval du modem. Ces solutions fournissent pour la plupart des fonctions de gestion dun plan dadressage IP local (y compris DHCP) et de fonctions NAT (Network Address Translation). Ceci ne prsente pas a priori une contrainte dans le contexte de la Charte, puisque le filtrage se fait la demande de labonn, donc pour ladresse IP fournie par le FAI. Dans un contexte NAT chez un particulier, lensemble des quipements connects au routeur ou point daccs Wifi de labonn seraient bloqus.
http://www.cachelogic.com/research/slide9.php
Page 10/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
1.5.2.
Encryptage et tunnelling
Les solutions de filtrage de protocole se fondent sur la reconnaissance de signatures au niveau des trames rseau changes depuis le poste client de linternaute afin de dterminer sil sagit dun flux peer-to-peer ou non. Par exemple, la maquette mise en uvre dans ltude remise par le SNEP (4.4) a consist paramtrer dans lquipement ALLOT une rgle bloquant de reconnaissance de signatures k a z a a et .torrent dans les messages rseaux. La mise en place de cryptages pourrait rendre inoprante (ou complexifier) la dtection de telles trames. Ce cryptage pourrait tre mis en place : Soit par la modification des protocoles peer-to-peer (en faisant par exemple voluer les trames de connexion ou le suffixe des fichiers) ce qui suppose la fois une modification des applications clientes installes sur les postes de travail des internautes et des serveurs (serveurs Kazaa, eDonkey ou trackers Bittorrent) ; Soit par la mise en place de protocole de tunneling de type SSL/HTTPS ou SSH, par exemple.
Certains protocoles peer-to-peer sont dj encrypts, notamment : FreeNet (Winny) ; SSL (SoftEther, EarthStation5, Filetopia) ; SSH (SoftEther).
Lencryptage et le tunneling gnrent de fait une complexit supplmentaire pour les solutions techniques de filtrage. Nanmoins, la disponibilit du code source des clients, notamment pour les clients dvelopps en mode Open Source ou quivalent (ex : eMule, Bittorrent), permettent danalyser la manire dont ces protocoles sont mis en uvre, et le cas chant de mettre en place une reconnaissance sur la partie amont du protocole (connexion, ngociation, passage en mode crypt) (analyse comportementale). Une telle solution est par exemple mise en place par Allot, qui affirme entre autres filtrer les protocoles SoftEther, EarthStation5 et Filetopia7.
Commentaires Capgemini / Note AFA 091104

Page 11/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
1.5.3.
Protocole IP V6
Lvolution du protocole Internet vers IP V6 va apporter, outre lextension des plages dadressage IP disponibles, des volutions sur les fonctions d'authentification et de scurit de TCP/IP, avec notamment la gnralisation du protocole IPSec et des fonctions de chiffrement DES. IP V6 nest nanmoins ce stade pas encore entirement dploy sur les plates-formes des FAI, et la monte en puissance de ce protocole pour le grand public reste amorcer.
CHARTE.RTF
Page 12/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
2. Synthse
2.1. Constats gnraux
Les techniques de peer to peer sont en constante volution : Comme on peut sy attendre pour un domaine technologique en mergence, les platesformes peer to peer voluent rapidement. Au-del des quelques plates-formes les plus connues, il existe en ralit un trs grand nombre de plates-formes qui utilisent diffrentes techniques rendant toujours plus difficiles le reprage des pirates et le filtrage des changes. En fait cette volutivit sacclre, et une mme plate-forme peut faire voluer son protocole de connexion rapidement et le diffuser en quelques heures laide de lInternet. Il est donc important de comprendre que toute activit danalyse ou de filtrage ne peut tre que fortement volutive et mise jour rgulirement. Il existe plusieurs familles de technologies dignes dintrt capables davoir un impact sur le piratage : Il existe plusieurs technologies qui prtendent rduire lactivit de piratage : le filtrage des protocoles (par ex. Allot, Cisco P_Cube), la cration de leurres (par ex. CoPeerRight), lanalyse des contenus (par ex.AudibleMagic), les solutions poste client (par ex. CyberPatrol, Cisco CSA). Ces technologies sont souvent assez sophistiques et capables de sadapter lvolution technologique des plates-formes. Il semble donc quil existe en vis--vis dun dploiement dapplications peer to peer en pleine explosion, diffrentes socits prsentant des solutions technologiques de haut niveau qui mritent dtre exprimentes. Il est probable que les FAI8 disposent dj doutils danalyse et qu dfaut ils devraient sen procurer : Les technologies mises en avant par le SNEP (Allot) nont pas en fait comme mission premire le filtrage du piratage. Elles ont t conues pour lanalyse du trafic Internet et la mise en uvre dactions permettant de le rguler au mieux dans lintrt dune entreprise ou dun FAI. Ce type doutil, qui permet davoir une analyse approfondie des trafics transitant sur le rseau, prsente un intrt vident pour tout fournisseur ou gros utilisateur de bande passante. Il est difficile dimaginer que les FAI ne disposent daucun outil quivalent.
Fournisseur dAccs Internet

Page 13/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
2.2. Le filtrage
En dpit des ractions de dfense probables la mise en uvre dactions de filtrage ou quivalent peut avoir un effet suprieur un an : Il est vident que si le filtrage des changes (ou quivalent) prenait de lenvergure (au niveau national voire au niveau international) les actions de rsistance se multiplieraient rendant dautant plus difficile leur mise en oeuvre. Pour autant, compte tenu de lvolution des technologies, nous pensons que les actions proposes peuvent avoir un effet sur une dure suprieure une anne, ce qui lchelle des volutions Internet est dj significatif. Ceci est dautant plus vrai que les actions de filtrage couvrent un nombre dinternautes limits (filtrage la demande en France) qui ne suscite pas une raction internationale des plates-formes et des protocoles filtrs. On peut mme penser que, comme pour les virus et les antivirus, les fournisseurs de solution pourront trouver jusqu un certain point (cryptage) des parades technologiques aux rsistances identifies. Les techniques de filtrage sur le poste de travail peuvent aussi permettre de traiter plus facilement ce point (blocage de linstallation ou lexcution des clients peer to peer sur le poste de travail). Il faut constamment garder lesprit que le filtrage la demande obtiendra un nombre dabonns limit : Le raisonnement qui conduit la cration dun abonnement volontaire repose sur plusieurs apprciations :
proposer une offre de filtrage permettra aux internautes dtre sensibiliss aux risques des changes duvres protges (virus, sanctions) et dexercer leur responsabilit en toute connaissance de cause ; certaines personnes utiliseront cet abonnement pour se dbarrasser dun problme dont elles ne souhaitent pas soccuper (exemple les entreprises mais aussi les parents) ; le succs de labonnement filtr sera trs directement li la prise de conscience du caractre illgal des changes duvres protges et des sanctions encourues.
Les opposants ce type de filtrage remarquent que :
les pirates adultes (qui sont nombreux) ne seront pas ncessairement enclins sauto filtrer et les parents auront du mal imposer un abonnement filtr leurs enfants ; lexistence dusages licites dchanges en peer to peer et le fait que les systmes peer to peer naient pas, jusqu prsent, t jugs illgaux en tant que tels pourrait crer une confusion chez les internautes, face la proposition dune offre de filtrage ; lapport dune formule dabonnement limite quelques pourcents de la population apparat bien limit et par ailleurs coteux.
Ainsi, ce jour, les supporters de labonnement volontaire comme leurs opposants semblent tre daccord sur un point : le pourcentage dabonns volontaires ne sera pas lev.
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Cet lment est important car il signifie que les investissements pour raliser du filtrage la demande (si cette approche tait retenue) doivent tre cohrents avec le nombre dinternautes susceptibles de prendre ce type dabonnement.
Le filtrage grande chelle sur le rseau pourrait se heurter une problmatique de mise en uvre : Le filtrage grande chelle du trafic peer to peer sur un trs grand nombre dinternautes pourrait poser un problme de cots de mise en uvre et de maintenance. Compte tenu de lvolution des architectures des FAI, un tel filtrage supposerait la mise en uvre dun nombre significatif de botiers dans le rseau, une administration de ces botiers et probablement des volutions de larchitecture rseau proprement dite ainsi que des volutions au niveau des systmes dinformation.
Le filtrage la demande au niveau des FAI apparat en premire analyse techniquement possible, mais sa mise en uvre supposerait de mener un ensemble de projets techniquement complexes, avec un investissement et des cots de fonctionnement trs significatifs. La mise en uvre dun filtrage la demande chez les FAI suppose la cration dune drivation (ex : routage et tunnels) vers une plate-forme susceptible de traiter lensemble des abonnements filtrs. Ceci suppose des volutions significatives de larchitecture rseau du FAI (politiques de routage, mise en uvre de tunnels L2TP, spcialisation de matriels ou le cas chant dploiement de nouveaux matriels notamment de type BAS, etc.). Il sagirait dune volution significative des architectures des FAI, comparable, pour certains FAI, la cration dun FAI virtuel sur leur rseau. Au-del du rseau, la mise en uvre dun filtrage la demande suppose galement de lancer des projets dvolution du systme dinformation (intgration entre le SI, lOSS et les solutions de filtrage), ainsi que dautres projets non techniques (vente et marketing, etc.).
Le filtrage sur le poste de travail apparat comme techniquement le meilleur compromis pour une offre la demande : Plusieurs technologies sont ds aujourdhui disponibles pour permettre un filtrage la demande sur le poste de travail de linternaute. Le filtrage sur le poste de travail est une solution techniquement plus facile dployer que des solutions impactant larchitecture rseau. Elle est techniquement robuste et plus efficace que le filtrage sur le rseau dans le contexte dune offre la demande. Par ailleurs, les FAI proposent dj des solutions dont la mise en uvre est techniquement comparable (solutions de filtrage parental, dantivirus ou de firewall par exemple). La problmatique de ce type de solution est donc moins technique quoprationnelle. Le mode de commercialisation de cette offre sera dterminant pour son succs.
CHARTE.RTF
Page 15/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
2.3. Lapproche Radar

Au-del des modes de mise en uvre du filtrage dj voqus, il pourrait tre intressant dexplorer une approche de type Radar prventif : Outre le filtrage systmatique envisag dans ltude du SNEP et le filtrage la demande de linternaute figurant dans la charte, on peut imaginer une mise en uvre de type Radar , par rfrence aux systmes utiliss pour le trafic routier. Dans une telle mise en uvre, des mcanismes dobservation et de filtrage seraient mis en place sur certains points dobservation sur le rseau, de manire prenne ( radars fixes ) ou temporaire ( radars mobiles ). Les radars permettraient didentifier les vnements frauduleux et denregistrer les informations ncessaires pour venir alimenter des oprations de sensibilisation voire juridiques.
Au niveau des FAI, une approche du type radar pourrait prsenter des avantages : Les FAI pourraient tirer avantage dune analyse un peu plus systmatique du trafic sous la forme de radars fixes ou mobiles, capables par exemple didentifier les ventuels pirates et de les mettre en garde de faon prvenir des abus. Une logique de radar automatique industriel pourrait tre envisage. Elle permettrait de :
contourner le problme du nombre dinternautes abonns volontaires (tout le monde peut se retrouver identifi par un radar), rduire les problmes de mise en uvre en vitant la mise en place dune drivation et en dimensionnant le nombre de radars une hauteur acceptable par les FAI, donner des moyens dinvestigation et de marketing puissants aux FAI.
Si un certain nombre de technologies semblent exister pour lutter contre le piratage, leur mise en uvre est significativement simplifie dans une approche de type radar o les volumes de botiers sont moins importants, et les impacts sur les architectures des FAI plus facilement matrisables (nombres de radars et localisation). Dans la mesure o certains usages du peer to peer sont lgaux, il parat plus pertinent denvisager une solution de type analyse de contenus .
Nanmoins cette approche soulve des questions de nature juridique et technique :
La mise en place dune approche de type radar est susceptible de soulever des difficults de mise en oeuvre dordre juridique. Ds lors, et si le principe du radar est retenu, une tude de faisabilit juridique plus approfondie devra tre mene afin de dfinir :
sil y a lieu damnager un rgime juridique spcifique, ou si le potentiel lgislatif et rglementaire actuel permet denvisager ce type de contrle sil ny pas lieu dadapter la lgislation, quels sont les critres permettant dassurer le respect des droits prcits (notamment scurit et confidentialit des donnes
Page 16/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
personnelles et le secret de la correspondance et dune manire gnrale le respect de la vie prive) dans le cadre de la mise en oeuvre des radars systmatiques (fixes ou mobiles) afin dassurer leur licit.
Un scnario radar alternatif pourrait consister utiliser des systmes situs en bout de rseau (du type de ceux proposs par CopeerRight Agency ou Advestigo) et non sur le rseau. Ce scnario prsente lavantage de lever, au moins partiellement, la contrainte topographique (pas de limite a priori au territoire observable par un quipement) mais linconvnient de ne pas sauto-alimenter par la simple observation des flux (elle ncessite une recherche proactive).
2.4. Sur le plan technique, ncessit dexprimenter

Seules des exprimentations avec les FAI permettront de mesurer rellement la faisabilit dune solution : La diversit des points de vue quant lapprciation des modalits techniques et des cots de mise en uvre des diffrentes solutions proposes montrent que seules des exprimentations en grandeur relle chez des FAI permettront de mesurer de faon factuelle les cots et les charges de mise en uvre de ces solutions. A ce stade compte tenu des enjeux, ces cots ne nous paraissent pas rdhibitoires et justifient quun travail exprimental plus approfondi soit ralis avec les acteurs techniques les mieux placs pour mesurer les cots de mise en oeuvre et de maintenance de ces solutions (c'est--dire les FAI).
Plusieurs solutions doivent tre values en parallle par plusieurs FAI : Compte tenu de lvolutivit technologique du peer to peer, il nous parat dangereux de ne miser que sur une seule technologie. Outre les critiques que pourraient susciter une telle approche (les pouvoirs publics ont fait le mauvais choix avec le filtrage, il existe des techniques plus efficaces et meilleures), une vritable analyse in situ permettrait de comparer rellement les rsultats aux moyens mis en uvre. Nous recommandons deux exprimentations :
Une solution de type filtrage sur le poste client (type Cyberpatrol ou Cisco CSA), exprimente en mode la demande ; Un Observatoire du Peer to peer sappuyant sur une solution oriente protocole (type Allot ou Cisco P_Cube) et/ou contenu (type Audible Magic ou Advestigo) utilise en mode observation et analyse statistique de trafic ;
CHARTE.RTF
Page 17/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
2.5. Besoin de mettre en uvre plusieurs solutions en parallle

Au total, lapproche doit comprendre un ensemble de solutions mises en uvre en parallle. En effet, il nexiste pas une seule approche possible pour faire face au problme pos : Offres lgales de musique sur Internet, filtrage la demande sur le poste client, mise en uvre de radars chez les FAI, politique de communication forte pour dcourager les pirates, contre-attaques sur le web par la cration de leurres, cest un ensemble de mesures coordonnes qui permettra de rduire le piratage des proportions acceptables. Le caractre fortement volutif des technologies mises en uvre ne permet pas de parier sur une solution en particulier. Les diffrentes approches retenues doivent tre articules pour se renforcer : Le tableau ci-dessous synthtise les diffrentes approches, les conclusions des analyses effectues dans ltude et les recommandations associes : Faisabilit Famille et de pertinence solution Faisabilit Filtrage technique de protocole Filtrage de contenu Filtrage sur le poste client Faisabilit de mise en uvre Observation et analyse de trafic Pertinent Exprimentation recommande Pertinent Exprimentation recommande Non applicable Filtrage systmatiq ue Difficile Filtrage la demande Peu pertinent Radar
Non pertinent Non applicable
Peu pertinent
Non retenu (pas de qualification des contenus) Atudier
Pertinent
Non retenu
Pertinence
Pertinent Dans le cadre dun observatoire de trafic Peer to peer pour tayer des actions de communication
Non retenu
Pertinent Proposable par les FAI Exprimentation recommande Pertinent Option propose par les FAI et souscrite par les internautes Pertinent si le nombre dinternautes souscrivant loption est suffisant
Non applicable
A tudier en prenant en compte les apports additionnels (analyse des flux) A tudier pour dissuader les internautes
CHARTE.RTF
Page 18/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
3. Analyse des solutions de filtrage

3.1. Introduction
Concernant les solutions de filtrage, la Charte signe le 27 juillet voque au 4.2 les solutions proposes par les industriels de la musique (tude transmise par le SNEP) en matire de filtrage, la demande des internautes, dans le domaine du peer-to-peer . En labsence dexpression de besoin formalise ce stade, nous prsentons ci-aprs diffrents modes de dploiement envisageables qui apparaissent pertinents pour lvaluation des solutions de filtrage. Ces modes de dploiement sappuient sur : La Charte signe le 27 juillet ; Ltude transmise par le SNEP ; Les fonctionnalits des solutions technologiques envisages .
Ensuite, ce rapport dtude prsente une analyse des diffrentes solutions de filtrage vis--vis de chacun des modes de dploiement envisageables.
3.2. Modes de dploiement envisageables

Les principaux modes de dploiement envisageables sont les suivants : Filtrage systmatique Ce mode est celui envisag dans ltude transmise par le SNEP :

Filtrage de lensemble des internautes. Filtrage de la totalit du trafic.
Filtrage la demande Ce mode est celui envisag par la Charte :

Filtrage uniquement des internautes en ayant fait la demande. Filtrage de la totalit du trafic gnr par les internautes ayant fait la demande de filtrage.
Radar Ce mode est un des modes proposs lors des auditions par les fournisseurs de solutions :
CHARTE.RTF
Page 19/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Mise en uvre de points dobservation sur le rseau. Ces points dobservation peuvent tre mis en place de manire prenne ( radars fixes ) ou temporaire ( radars mobiles ). Observation de lensemble du trafic passant par les points dobservation. Observation de la totalit des internautes lorigine du trafic observ. Identification dvnements frauduleux (ex : tlchargement effectu par un internaute dun fichier musical protg par des droits dauteurs) et historisation des caractristiques techniques de cet vnement (adresse IP, nom du fichier, protocole P2P utilis, etc.). Fourniture des lments historiss afin dalimenter des oprations de prvention ou juridiques.
3.3. Familles de solutions de filtrage

3.3.1. Familles identifies dans ltude du SNEP et prslection
Ltude fournie par le SNEP9 a identifi cinq familles de solutions :
Rapport_filtrage_capgemini_france.pdf
Page 20/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Caractrisations de certaines solutions effectues dans ltude du SNEP : Les outils doptimisations de rseaux (QoS) : Les outils de QoS (Qualit de Service) sont des appliances (solution packages : matriel et logiciel) permettant la gestion des priorits des flux. Ils ont t conus lorigine pour classer les flux Internet afin de leur donner une priorit destine grer la bande passante dun rseau. Ils peuvent ainsi limiter (le blocage tant un cas particulier de limitation) le dbit pour un type de flux, et garantir ainsi une qualit de service pour les flux de donnes critiques. Limplmentation de la QoS est systmatiquement en coupure , cest dire que le trafic analyser doit passer au travers de lappliance afin dtre trait. Les IDS/IDP (Intrusion Detection and prevention) : Les IDS/IDP sont des appliances qui permettent de dtecter et/ou de prvenir une attaque Internet. Ces outils ne possdent pas la facult de trier les diffrentes sessions par flux ; ils se contentent danalyser chaque paquet afin dy retrouver soit un comportement, soit une signature connue. Il est possible de placer ce type dappliance soit en coupure (comme pour la QoS), soit en port mirroring (redirection du trafic pour analyse). Les Flow-Based Switches Les flow based switches sont des commutateurs qui nagissent plus par reconnaissance exacte du trafic mais par classification par flux. Il est en effet possible de catgoriser les flux gnrs par le trafic Internet en fonction du type de trafic. On diffrencie ainsi le trafic interactif du trafic non interactif qui est typiquement un trafic peer-to-peer. Cependant, la plupart de ces appliances nintervenant pas au niveau applicatif, il est difficile de ne pas impacter dautres trafics comme le FTP passif.
A lissue dune analyse de ces familles de solutions, ltude du SNEP a constitu une prslection : Dune part en cartant les familles de solutions orientes filtrage rseaux, IDS/IDP et filtrage de contenu ; Dautre part, sur les familles QOS et Flow Based Switch, en identifiant une liste rduite de produits en vue dune tude comparative dtaille :
CHARTE.RTF
Page 21/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Enfin, ltude du SNEP a retenu la solution ALLOT pour effectuer un ensemble de tests dont les rsultats ont t documents.
3.3.2.
Famille de solutions considres dans la prsente tude

Analyse des familles identifies dans ltude du SNEP
3.3.2.1.
Au-del des solutions de filtrage de protocole prslectionnes dans ltude du SNEP, nous avons effectu lanalyse suivante : Solution de filtrage rseau : ces solutions ne rpondent effectivement pas aux besoins de filtrage tels que dfinis dans la Charte :
URL et adresse IP : Ces moyens sont adapts pour interdire laccs des sites qui proposent des contenus illgaux mais ne rpondent pas aux impratifs de neutralisation du peer-to-peer. Ports : cest un moyen basique pour filtrer certains ports qui sont spcifiques aux rseaux peer-to-peer, mais des moyens de contournements existent qui rendraient trs rapidement inoprante cette solution si elle constituait lunique filtrage mis en place. Ceci est confort par ltude mene par CacheLogic prsente plus haut.
Solution Filtrage de contenu : il nous a sembl important de considrer ce type de solutions dans la prsente tude. La socit Audible Magic, notamment, dispose dune solution de type industrielle et de partenariats avec des acteurs comme la RIAA aux Etats-Unis et SonyConnect qui la rendent pertinente.
Il est noter que si le filtrage dURL et dadresses IP ne permettent pas de neutraliser le peer to peer eux seuls, il peut apporter une contribution comme tout premier niveau de barrire par exemple pour certains clients des FAI dont le niveau de connaissance techniques serait limit.
CHARTE.RTF
Page 22/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
3.3.2.2.
Familles de solution considres dans la prsente tude
Ainsi, nous avons retenu les familles de solution de filtrage suivantes : Famille de solutions Filtrage de protocole Dfinition Exemple doutils
Solutions permettant didentifier et le cas chant de filtrer des flux sur la base dlments de niveau protocolaire : Protocoles classiques (smtp, http, etc.)
Allot Cisco P_Cube etc.
Protocoles peer-to-peer traditionnels (eDonkey, Bittorrent, Fastrack Kazaa, etc.) Protocoles peer-to-peer crypts (Freenet, SoftEther, EarthStation5, Filetopia, etc.) Audible Magic Advestigo
Filtrage de contenu
Solutions permettant didentifier et le cas chant de filtrer des flux sur la base dlments de niveau contenu : Fichiers musicaux bruts (WAV, MP3, MPC, etc.) Fichiers musicaux dans des formats lis aux solutions de DRM (AAC, WMA, Atrac+, etc.) Archives (ZIP, RAR, ACE, etc.) contenant des images de CD ou des ensemble de fichiers musicaux bruts.
Filtrage sur le poste client
Solutions permettant didentifier et le cas chant dinterdire laccs un ensemble de fonctions sur le poste client de linternaute. Ces fonctions peuvent tre au niveau : Rseau exemple : fermeture de certains ports ou interdiction dchange avec des listes de nom DNS ou dadresses IP rpertoris. Contenu ex. dtection et alerte / interdiction en cas de cration de fichier de type .MP3 par un applicatif (ex : client peer-to-peer lissue dun tlchargement). Applicatif ex. dtection, et alerte ou interdiction du lancement de certaines applications sur le poste client (ex : client eMule)
Firewall poste de travail Solutions de scurit, type Cisco CSA ou SkyRecon Solutions contrle parental, type CyberPatrol
CHARTE.RTF
Page 23/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
3.4. Filtrage de protocole

3.4.1. Schma de principe
Le diagramme suivant, fourni par Allot10, illustre le principe de fonctionnement dune solution de filtrage de protocole :
Provisioning system
Subscribers
RADIUS/DHCP
Billing
Customer Care
Internet IP Core DSLAM BRAS NetEnforcer
Positionnement dun quipement de filtrage en coupure, sur un point du rseau IP du FAI. Intgration avec le SI et lOSS du FAI via une interface de provisioning qui permet dalimenter lquipement avec les informations qui lui sont ncessaires (correspondances adresses IP/internautes fournies par le radius, attribut internaute ayant fait la demande de filtrage en provenance du Customer Care dans le cas dun filtrage la demande, etc).
10
Allot-P2P-solutions.ppt, page 11
Page 24/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
3.4.2.
Mode Filtrage systmatique

Scnario de dploiement original (scnario de ltude du SNEP)
3.4.2.1.
Le scnario de dploiement tudi par le SNEP est le suivant : Solution : Filtrage de protocole Allot Architecture :
DSL option 1 et 3 : botiers de filtrage positionns entre les BAS et le rseau IP Core DSL option 5 : botiers de filtrage positionns aprs le LNS qui concentre les abonns du FAI Cble : botiers de filtrage placer aprs le LNS (comme dans le cas DSL option 5).
Dimensionnement du nombre de botiers pour un dploiement gnralis

Trafic moyen : 26 Kb/s par abonn Un botier Gigabit Allot par BAS Pour France Telecom, et sur la base de lhypothse prise dans ltude du SNEP de 143 BAS, on obtient 143 botiers Gigabit Allot.
Le dtail du scnario tudi figure dans le rapport dtude fourni par le SNEP11.
3.4.2.2.
Difficults poses par ce scnario
Le scnario prsent par le SNEP prsente un ensemble de difficults techniques : Asymtrie du trafic Les FAI ont indiqu dans leurs commentaires sur ltude du SNEP12 que sur beaucoup de rseaux doprateurs, les paquets de donnes ne passent pas ncessairement par les mmes quipements pour les flux descendants et remontants. Cette ingnierie rseau particulire est mise en place pour rpondre deux besoins :
Offrir des latences basses aux abonns, ce qui implique que le routage du paquet se fasse par le chemin le plus court vers et de lInternet. Le chemin daller vers une destination particulire peut tre diffrent du chemin de retour de par la nature du
11
Rapport_filtrage_capgemini_france.pdf 041018 note AFA tude Cap Gemini.doc

Page 25/59 IMPRIME LE: 10/03/05 12:01
12
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
protocole de routage Internet BGP mis en place par le FAI pour sa connectivit interne et/ou externe.
Rpondre des ncessits de partage de charge.
La solution Allot dans la version teste dans ltude SNEP ne permet effectivement pas de filtrer le trafic dans une configuration de rseau asymtrique. Par ailleurs, une modification en profondeur de lingnierie rseau des FAI entranerait de fait des cots supplmentaires importants dans limplmentation qui limitent la pertinence dune telle solution. Note : Allot a indiqu avoir intgr dans le plan dvolution de ses solutions la capacit supporter les flux asymtriques, dont la disponibilit commerciale est prvue en 2005.
Dgradation de la qualit de service Les FAI ont indiqu dans leurs commentaires sur ltude du SNEP13 que les attentes des consommateurs et des pouvoirs publics en ce qui concerne la qualit de service offerte par les fournisseurs daccs Internet sont de plus en plus grandes. Le nouveau cadre rglementaire fixe des exigences lgard des fournisseurs de services de communications lectroniques, dont les FAI. De plus, certains usages ont des exigences de qualit de service suprieures dautres, notamment pour la voix sur IP. Les FAI ont indiqu que des expriences prcdentes ont dmontr que des solutions telles quAllot engendrent gnralement des latences qui sont nfastes pour la qualit de service et sont incompatibles avec une bonne qualit de service. . Une solution installe en coupure induit de fait un dlai de latence dont la valeur et limpact peut tre discute mais qui est incontournable compte tenu de linsertion dun composant supplmentaire (matriel et logiciel, dans le cas dAllot) dans la chane. Par ailleurs, le positionnement de botiers Allot en coupure derrire les BAS (solution tudie par le SNEP) pourrait induire de fait une augmentation du risque de panne logicielle ou matrielle donc un impact ventuel sur la disponibilit du service.
Evolution des architectures FAI vers quipements 10 Gbps Les FAI ont indiqu dans leurs commentaires sur ltude du SNEP14 que les botiers Allot tests dans ltude fonctionnent avec des quipements Gigabit Ethernet mais pas des quipements Ethernet 10 Gbps ce qui induirait des contraintes rendant incompatible la migration par les FAI vers des quipements plus performants.
13
041018 note AFA tude Cap Gemini.doc 041018 note AFA tude Cap Gemini.doc
Page 26/59 IMPRIME LE: 10/03/05 12:01
14
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
La solution Allot teste dans ltude SNEP est effectivement limite 1 Gbps. Allot a annonc pour 2005 un produit supportant 2,5 Gbps full duplex (soit 5 Gbps)15 et par ailleurs tudier une volution vers le 10 Gbps. Son concurrent P-Cube supporte par ailleurs des dbits suprieurs 1 Gbps16.
Contournement du filtrage par protocole par cryptage SSL Les FAI ont indiqu dans leurs commentaires sur ltude du SNEP17 que la tentative de bloquer un protocole conduira les dveloppeurs de logiciels de peer-to-peer faire passer les flux via des sessions dchanges chiffres (protocole https sur le port 443). Le protocole employ tant crypt, cela pourrait aboutir limpossibilit de dtecter les contenus donc de les filtrer. Le blocage du port 443 est peu envisageable puisque cela reviendrait interdire lusage du protocole https donc entraver les changes scuriss (notamment le commerce en ligne). Une des formes de contournement du filtrage de protocole consisterait donc gnraliser lemploi du cryptage de type SSL intgr dans les protocoles et les applications clientes peer-to-peer. Si le cryptage par SSL prsente certes une difficult supplmentaire, Allot affirme savoir filtrer plusieurs applications peer-to-peer utilisant du filtrage par protocole SSL (FileTopia, Softether, etc.) 18. Ceci est ralis en dtectant une signature comportementale du protocole peer-to-peer ltablissement de la session, avant transmission des flux chiffrs.
Positionnement des botiers Les FAI ont indiqu dans leurs commentaires sur ltude du SNEP19 que les options darchitecture et de dimensionnement prises dans ltude un botier Allot par BAS ntaient pas ralistes. Ils ont indiqu, quil faudrait prvoir:
Pour un FAI ayant une architecture avec BAS, au minimum un botier Allot par lien Gigabit BAS Rseau de collecte (hors redondances ncessaires par ailleurs), avec le pr requis davoir une ingnierie rseau nentranant pas de trafic asymtrique. Dans le modle dgroup natif, ou dans un modle o les lments dextrmit sont tout IP, comme cest le cas des cblo-oprateurs ou des fournisseurs utilisant des DSLAMs IP, au minimum un botier Allot par DSLAM ou par CMTS (hors redondances).
15
http://www.allot.com/pages/news_content.asp?intGlobalId=476 http://www.p-cube.com/products/SE2000.shtml 041018 note AFA tude Cap Gemini.doc Allot-P2P-solutions.ppt 041018 note AFA tude Cap Gemini.doc
Page 27/59 IMPRIME LE: 10/03/05 12:01
16
17
18
19
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Les FAI ont indiqu que sur cette base, un chiffre plus proche de la ralit serait de 4000 botiers Allot20 ce qui induirait par ailleurs un modle de cot de la solution de filtrage trs suprieur aux lments modliss dans ltude du SNEP.
3.4.2.3.
Conclusion sur le scnario original
Si des arguments et contre arguments existent, les difficults techniques souleves par les FAI sur le scnario original, combines au manque de support des FAI, le rendent difficilement envisageable dans le contexte de la charte pour un dploiement gnralis dans un contexte grand public, en ltat des techniques, et probablement tant que les solutions de filtrage ne seront pas directement intgres au sein des lments du rseau tels que les routeurs.21
3.4.3.
Mode Filtrage la demande

Scnario de dploiement envisageable
3.4.3.1.
Dans le cas dun service de filtrage peer-to-peer la demande , il est possible denvisager une architecture proposant lacheminement par routage des flux filtrer sur un point de concentration fournissant une architecture ddie au trafic des internautes du FAI ayant fait la demande de filtrage, et localise dans un des data centers du FAI. Lacheminement se ferait par un routage au niveau de lquipement de rattachement de linternaute (BAS, DSLAM IP, ou routeur), qui dirigerait le trafic vers un point dentre de la plate-forme ddie, le cas chant via un tunnel L2TP. Les hypothses partages avec les FAI sur le taux dabonnement au service de filtrage par les internautes (ex. 10% des abonns, la cible et dans un scnario maximaliste) rendent une telle approche techniquement pertinente. Pour chaque FAI, larchitecture ddie serait construite initialement en un point central, avec un cot raisonnable, et elle monterait progressivement en puissance en fonction du nombre de clients du FAI sabonnant au service. La pertinence dun scnario de ce type a t confirme avec les fournisseurs de telles solutions (Cisco, Allot).
20
Note AFA, 041018 note AFA tude Cap Gemini.doc
Note : Un scnario de dploiement sur lensemble dune architecture rseau pourrait en revanche tre envisag dans un contexte de grands utilisateurs, de type entreprises ou universits. La Charte visant principalement le grand public, ces scnarios nont pas t analyss en dtail.
21
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
3.4.3.2.
Elments de dimensionnement - Premire analyse
Un calcul rapide montre que dans le scnario maximaliste partag avec les FAI, le nombre de botiers qui serait ncessaire pour quiper lensemble des FAI franais resterait raisonnable : Sur la base des hypothses suivantes : 6 millions de foyers abonns au haut dbit en France (prvision fin 2004 / dbut 2005) 10% des abonns souscrivent, soit 600 000 foyers Dbit moyen par foyer abonn : 30 Kb/s
Estimation de la quantit thorique de botiers ncessaires : Trafic total filtrer, tous FAI confondus : 30 Kb/s * 600 000 = 17,2 Gb/s de trafic Nombre thorique de botiers Gigabit ncessaires, hors redondance : 18 (soit un botier par Gb/s de trafic).
Le calcul ci-dessus globalise le trafic et ne prend pas en compte les caractristiques induites par le fait que le trafic est rparti entre les diffrents FAI. On pourrait estimer en premire approche que le nombre de botiers rellement ncessaires serait un multiple par quelques units du nombre de botiers thoriques, soit environ une centaine de botiers pour quiper lensemble des FAI franais.
3.4.3.3.
Elments de dimensionnement - approche pour prciser le dcompte
Si lon souhaitait prciser le dcompte, il serait ncessaire deffectuer une analyse dtaille FAI par FAI, en prenant en compte les caractristiques de chacun. Le dcompte dtaill du nombre de botiers ncessaires ne peut se faire sans entrer dans le dtail de larchitecture de chacun des FAI concerns. Sont notamment prendre en compte les spcificits de chaque FAI selon les dimensions suivantes : Option souscrite auprs de France Telecom (accs fourni en gros par France Telecom, dgroupage) Nature (Fast ethernet, Gb ethernet, etc.) et nombre de BAS Nature (DSLAM IP ou non) et nombre de DSLAM Politique de gestion des adresses IP (pool unique, pools multiples et rgles daffectation des pools, etc.)
CHARTE.RTF
Page 29/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Architecture du rseau (rgionalise ou non, etc.).
Des discussions dtailles ont t menes avec des FAI dans le cadre de ltude afin deffectuer un dcompte plus dtaill dans le cadre dune tude de cas . Les engagements de confidentialit demands par les FAI dans le cadre de ces discussions ne permettent pas de faire apparatre ici les hypothses prises, les scnarios envisags et le rsultat du dcompte.
3.4.3.4.
Contraintes de mise en uvre
Le dploiement dune solution de filtrage la demande doit prendre en compte les contraintes suivantes. En matire darchitecture et de rseau : Le dploiement dquipements de filtrage dans larchitecture du FAI. La mise en place dune solution de routage au niveau du BAS de rattachement et / ou lintrieur du rseau, avec le cas chant le dploiement de nouveaux quipements ou la spcialisation dquipements existants pour supporter ce routage. La mise en place des solutions dadministration, dexploitation et de supervision des lments ci-dessus incluant des aspects techniques (ex : solution de supervision) et humains (ex : quipes dexploitation).
En matire de SI, les contraintes identifies sont les suivantes : Intgration de la prise dabonnement la solution de filtrage avec le Systme dInformation (OSS Operations Support Systems - et BSS Business Support Systems).
En matire de cots, les postes prvoir seraient les suivants : Cots dinvestissement fixes :

Ingnierie gnrale Intgration avec les systmes BSS Intgration avec les systmes OSS Gestion des impacts sur le rseau et configuration Vente, Marketing et communication Gestion gnrale du projet de nouveau service de filtrage
Cots dinvestissement variables, fonction du nombre dabonns au filtrage :

Equipements rseau (le cas chant) type BAS, routeurs ou load balancers Equipements de filtrage exemple type Allot ou Cisco P_Cube Installation
Page 30/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Cots rcurrents
Cots rcurrents sur la partie rseau (maintenance des matriels et logiciels, prestations dadministration, exploitation et supervision) Cots rcurrents sur la partie SI (maintenance des matriels et logiciels, maintenance corrective et volutive).
3.4.3.5.
Conclusion
Le scnario de dploiement ci-dessus apparat en premire analyse techniquement pertinent, pour la solution technique, comme pour le nombre de botiers rsultants. Les principes darchitecture cidessus resteraient affiner et dcliner FAI par FAI. Nanmoins, sa mise en uvre ncessiterait de mener un ensemble de projets (rseau, systme dinformation, vente et marketing et communication, etc.) et ncessiterait un investissement et engendrerait des cots de fonctionnement significatifs (matriels et logiciels, projets, oprations). Il est noter quune tude dtaille du bilan conomique supposerait de disposer de donnes dtailles issues des FAI (dtail de larchitecture rseau, dtail du SI, dtail des cots sur chacune des catgories, etc.) - ce qui ne pourrait senvisager que FAI par FAI et avec une volont du FAI de fournir une visibilit sur ces lments dans le cadre dune tude de type business case . Au final, la pertinence conomique (capacit rentabiliser les cots par un revenu de quelques euros par internaute ayant souscrit le service) de ce scnario apparat nanmoins et en premire analyse pour le moins hasardeuse. De plus, les architectures rseau requises pour utiliser ces solutions, et notamment obtenir un routage des flux traiter en un point central du rseau, apparaissent particulirement problmatiques avec le dveloppement de nouveaux services haut dbit bass sur des nouveaux types de flux, tels que la tlphonie sur ADSL, et la tlvision ou vido sur ADSL. A titre dexemple, la tlvision sur ADSL utilise une diffusion de type multicast, ncessitant un routage particulier entre les flux des chanes communs aux diffrents clients, et les flux parallles personnels tels que laccs au web. Il est trs probable que des problmes de non compatibilit apparaissent entre une architecture rseau donnant satisfaction aux solutions de filtrage, et les besoins des nouveaux services haut dbit.
Nous proposons donc de ne pas retenir le scnario Filtrage de protocole filtrage la demande. En revanche, les solutions de fournissant des fonctions de filtrage de protocole peuvent tre galement utilises en mode observation et analyse de trafic ce qui lve un ensemble de contraintes techniques (positionnement en coupure, etc.) et peut senvisager dans des scnarios de dploiements limits (quelques botiers en mode observation, pas dintgration avec le SI, etc.).
CHARTE.RTF
Page 31/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Nous proposons donc de retenir lutilisation dune solution oriente protocole (type Allot ou Cisco P_Cube) en mode observation et analyse de trafic et pour une exprimentation Observatoire du Peer to peer .
3.5. Filtrage de contenu

3.5.1. Schma de principe
Le diagramme suivant, fourni par la socit Advestigo22, illustre le principe de fonctionnement dune solution de filtrage de contenu :
Mise en place sur le rseau de points dcoute non intrusifs (en drivation et non en coupure). Mise en place et maintien jour dune base dempreintes de fichiers originaux, contenant les signatures des fichiers protgs (en loccurrence, des morceaux musicaux).
22
Radars sur le P2P (AdVestigo - 092004).pdf

Page 32/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Comparateur permettant didentifier les contenus peer-to-peer illgaux en comparant les flux couts avec les signatures figurant dans la base dempreintes. Ce comparateur peut tre deux niveaux (contrle par cl de hachage, afin deffectuer un premier niveau danalyse et viter dengorger le comparateur de second niveau qui effectue la comparaison complte). Historisation des vnements dans une base de donnes ( base des constats sur le schma ci-dessus).
Le diagramme suivant, fourni par la socit Audible Magic23, illustre le principe de fonctionnement des points dcoute :
La solution dAudible Magic comprend : Une composante rseau (Network Monitor) qui capture et assemble des paquets IP et les fournit la composante de reconnaissance de contenu. Cette partie fournit galement des fonctions annexes de dconnexion TCP en cas dutilisation en mode filtrage , et les services dadministration de la solution. Une composante logicielle danalyse de contenu (Audible Magic Software) qui effectue la reconnaissance des protocoles peer-to-peer, la comparaison de premier et de second niveau, et la dtermination des rgles appliquer (Content Action Engine).
Le premier niveau (P2P Hash Cache check sur le schma) permet, par une vrification rapide de type hash code, non exhaustive mais ncessitant une puissance de calcul
23
General ISP.pdf
Page 33/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
limite, de sparer les trames ncessitant pas danalyse de niveau 2 des autres trames et viter ainsi de gnrer une charge CPU trop importante au niveau du botier
Le second niveau (Content based fingerprint recognition sur le schma) permet de comparer le contenu des trames aux signatures (fingerprint) de contenus et identifier de manire prcise sil sagit dun change portant sur un contenu connu du botier.
3.5.2.
Mode Radar
Scnario de dploiement
3.5.2.1.
Le mode radar correspond une pratique statistique qui peut tre mise en place diffrents niveaux : Sur les points dchanges entre les principaux backbones ; Au niveau des BAS si le FAI en possde ; Au niveau DSLAM IP ou CMTS.
Audible commercialise des quipements de filtrage capables de traiter des dbits de 2, 50 et 200 Mbits par seconde et par quipement, ainsi quune offre CSA-1000 capable de traiter jusqu un Gigabit par seconde (constitue de plusieurs botiers CSA-200 complter par un quipement dquilibrage de charge) ce qui rend pertinent denvisager un dploiement au niveau BAS ou routeur. Un scnario de dploiement pourrait tre de : Dployer de manire fixe ( Radars fixes ) des quipements de filtrage au niveau de certains BAS (solution de type Gigabit) ou au niveau de DSLAMs IP / CMTS ou encore de routeurs ; Dployer ponctuellement, dans le cadre doprations de mesure de trafic et/ou afin dalimenter des actions de prvention ou juridiques, des quipements de filtrage mis en place de manire temporaire ( Radars mobiles ) sur dautres BAS, DSLAM IP, CMTS ou routeurs.
3.5.2.2.
Elments de dimensionnement
Le nombre dquipements ncessaire dpend de diffrents facteurs : Lambition donne au dploiement (exprimentation, ou support dactions communication ponctuelles, ou mise en place prenne et plus grande chelle). de
Le nombre de radars fixes ou mobiles mettre en place de un (pour une exprimentation ponctuelle) plusieurs milliers (un par DSLAM).
Page 34/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Le dbit observer par radar (dune dizaine de Mb/s un Gb/s sur les architectures actuelles, avec une extension prvue jusqu la dizaine de Gb/s). La nature du trafic observ (part du peer-to-peer dans le trafic observ). La nature des contenus changs en peer-to-peer (proportion de contenus identifis / figurant dans la base de signatures de la solution). La capacit de traitement des quipements (efficacit des algorithmes, etc.).
Compte tenu de ces lments, il est difficile deffectuer un dimensionnement a priori. Audible a recommand deffectuer une exprimentation en contexte rel afin de disposer dlments de retour dexprience pour tayer un dimensionnement. Advestigo a pour sa part fourni les lments de dimensionnement ci-dessous24 : Positionnement au niveau BAS, flux capt de lordre de 1 Gbps, dont 600 Mbps de peer-topeer ; Examen statistique de 10 % du trafic soit 60 Mbps ; Le logiciel Advestigo permettrait de comparer entre 100 000 et 500 000 extraits par jour et par processeur (Intel 3 GHz) pour un catalogue denviron 100 000 titres musicaux et 1 000 films.
3.5.2.3.
Conclusion
Les deux solutions de filtrage de contenus prsentes lors des auditions (Advestigo et Audible Magic) pourraient tre pertinentes pour un fonctionnement en mode Radar , Audible prsentant lavantage de disposer dune offre dj commercialise et de niveau industriel. Les principes prsents ci-dessus restent affiner, afin de : Valider la faisabilit technique dans une architecture FAI reprsentative ; Confirmer le nombre de botiers, et ainsi, estimer le cot dinvestissement ; Apprcier les contraintes oprationnelles lies lexploitation de ces solutions. Valider la faisabilit juridique de cette approche
24
Lutte antipiratage P2P_contribution adVestigo.pdf

Page 35/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Raliser une analyse comparative avec le scnario de positionnement en bout de rseau
Pralablement, nous proposons danalyser les technologies de filtrage de contenu (type Audible ou Advestigo) dans le cadre de lexprimentation Observatoire du peer to peer .
3.6. Filtrage sur le poste client

3.6.1. Introduction
Il existe deux familles de solutions de filtrage sur le poste client : Les solutions avec serveur central - par exemple Cisco Security Agent (CSA) ; Les solutions orientes poste client - par exemple CyberPatrol (ces solutions ont des architectures comparables celles des solutions de contrle parental ou dantivirus).
Pour le peer-to-peer, le filtrage sur le poste client peut senvisager diffrents niveaux : Au niveau port blocage des ports standard utiliss par les clients peer-to-peer (ex : 4661, 4662 pour eDonkey)25 ; Au niveau applicatif blocage du lancement des applications clientes peer-to-peer sur le poste de travail ou filtrage des communications dune application qui ny est pas autorise ; Au niveau fichier, le cas chant blocage du stockage de fichiers mp3 sur le poste client par exemple.
Leffet de cette mesure est faible, les clients peer to peer permettant de reconfigurer les ports utiliss.
25
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
3.6.2.
Schma de principe des solutions serveur central
Le diagramme suivant, fourni par Cisco26, illustre le principe de fonctionnement dune solution de filtrage sur le poste de travail avec serveur central :
Desktop Agent
Desktop Agent Central Security Management

Configuration Reports, Events
Server Agent
Policy / Updates Alerts

Server Agent
SNMP Traps Custom Programs Local File
Desktop Agent
Un module client (Desktop Agent sur le schma) qui contrle les vnements sur le poste client (lancement dapplication, contrle des accs au systme de fichiers, la base de registres, aux objets COM, aux services http, etc.). Il peut agir selon un modle permissif (refuse toute action documente comme nfaste ou interdite, et autorise toutes les autres) ou un modle restrictif (autorise toute action documente comme valide et refuse toutes les autres). Un module serveur (Central security management sur le schma) qui permet dune part sassurer que le module client na pas t inhib sur un PC qui se connecte, denregistrer les alertes remontes par les clients, et dadministrer les rgles de fonctionnement (signatures dapplications, etc.).
3.6.3.
Mode Filtrage la demande
Dans le mode de filtrage la demande , une solution de filtrage sur le poste client est dploye sur les terminaux des internautes qui en font la demande. Ce mode est pertinent pour les solutions orientes poste client type CyberPatrol, et ne ncessite pas linstallation dinfrastructures particulires chez le FAI.
26
Secu_Minculture-181004.ppt
Page 37/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
La base de signatures (ex : signatures des excutables clients des applications de peer-to-peer) est maintenue par lditeur de la solution - selon une approche quivalente celle employe pour les solutions de contrle parental et les solutions anti-virus.
3.6.4.
Conclusion
Les solutions orientes poste client, type CyberPatrol, apparaissent pertinentes pour le mode Filtrage la demande - et ne ncessitent pas dexprimentation particulire. La solution de filtrage avec serveur central prsente lors des auditions (Cisco CSA) apparat pertinente pour un fonctionnement en mode la demande. Les principes prsents ci-dessus restent affiner, afin de : Prouver la faisabilit technique de cette solution en la mettant en uvre en vraie grandeur ; Mesurer les impacts techniques du filtrage ; Fournir les lments techniques permettant destimer le cot dinvestissement ; Apprcier les contraintes oprationnelles lies lexploitation de ces solutions ; Dfinir un ou plusieurs scnarios de gnralisation.
Nous proposons de retenir le scnario Solution filtrage poste client, mode la demande pour une exprimentation.
CHARTE.RTF
Page 38/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
3.7. Synthse
Le tableau suivant prsente le rsultat de lanalyse technique effectue pour chacune des familles de solutions :
Mode de dploiement / Famille de solution
Observation et analyse de trafic
Filtrage systmatique
Filtrage la demande
Radar
Pertinent Filtrage de protocole Exprimentation recommande
Difficile en ltat des techniques
Peu pertinent Techniquement faisable, cot lev, problme de compatibilit avec les volutions du haut dbit, peu raliste Peu pertinent (suppose la dtection de lexhaustivit des contenus), et problmes de mise en uvre similaires au filtrage de protocole Pertinent
Non retenu (lutilisation de protocoles peer-topeer ne constitue pas en soi un acte frauduleux)
Pertinent Filtrage de contenu Exprimentation recommande
Non retenu Trop grande complexit de filtrage
A tudier
Filtrage sur le poste client
N/A
N/A
Exprimentation recommande
N/A
N/A : non applicable.
CHARTE.RTF
Page 39/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
4. Exprimentations recommandes
4.1.1. (E1) Solution filtrage poste client, mode la demande
Nous proposons dorganiser lexprimentation dune solution de filtrage sur le poste client, en mode la demande. Lexprimentation consistera : Mettre en uvre, chez un ou plusieurs FAI, une solution de filtrage sur le poste client de type CyberPatrol ou Cisco CSA ; Dployer cette solution (partie cliente et configuration au niveau du serveur central) pour un ensemble dinternautes volontaires; Exprimenter le fonctionnement du service pendant une dure suffisante (ex : deux trois mois) pour obtenir un retour dexprience technique et oprationnel.
Lobjectif technique de lexprimentation sera : De prouver la faisabilit technique de cette solution en la mettant en uvre lchelle exprimentale ; De mesurer les impacts techniques du filtrage ; De fournir les lments techniques permettant destimer le cot complet dinvestissement ; Dapprcier les contraintes oprationnelles lies lexploitation de ces solutions ; De dfinir un ou plusieurs scnarios de gnralisation.
4.1.2.
(E2) Solutions orientes protocole et contenu, observatoire de trafic P2P
Nous proposons dorganiser lexprimentation de solutions orientes protocole et contenu dans un objectif dobservation et danalyse de trafic, tablissant un observatoire de trafic P2P .
CHARTE.RTF
Page 40/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Lexprimentation consistera : Mettre en uvre, chez un ou plusieurs FAI, une ou plusieurs solutions orientes protocole et/ou contenu dans un mode observation et analyse de trafic (et non filtrage), localise dans les data centers du / des FAI ; Analyser les donnes dobservation du trafic de manire statistique ; Obtenir un retour dexprience technique et oprationnel sur la solution.
Lobjectif technique de lexprimentation sera : De confirmer la faisabilit technique de lobservation et lanalyse du trafic peer to peer en la mettant en uvre lchelle exprimentale ; De confirmer le nombre de botiers, et, ainsi, destimer le cot dinvestissement en cas de prennisation ; Dapprcier les contraintes oprationnelles lies lexploitation de ces solutions ; De dfinir un ou plusieurs scnarios de prennisation de lobservatoire.
Lexprimentation permettra, sur la dimension des internautes : De fournir des lments dinformation sur le trafic peer-to-peer (part de ce trafic, etc.) ; De mesurer les changements de comportement ventuels des internautes.
Lors des auditions ralises par les experts, la socit Audible Magic a propos de contribuer une telle exprimentation, en proposant27 : De dployer cinq quipements Audible Magic (CopySense) pendant une dure de trois mois, en mode observation (et non blocage) ; Danalyser les meta-donnes des contenus identifis afin de dterminer les signatures manquantes dans la base de donnes Audible Magic (contenant date les signatures de 3,8 millions de titres) et dacqurir des signatures additionnelles, le cas chant ; De dfinir, la fin de la priode dexprimentation, un scnario de dploiement gnralis :

Nombre dquipements de filtrage de contenu ; Nombre dquipement dquilibrage de charge (load balancing) ;
27
General ISP.pdf
Page 41/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
De fournir les quipements et les services ncessaires pour raliser les travaux prcdents des tarifs et honoraires significativement rduits.
CHARTE.RTF
Page 42/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
5. Annexe 1 Auditions organises

Le tableau ci-dessous liste les auditions organises dans le cadre de la mission des experts.
Audition
Audition individuelle 1 Audition individuelle 2
Date
23 septembre 2004 27 septembre 2004
Participants
SNEP, UPFI, Cap Gemini, YaCast SNEP, UPFI, Warner Music, Universal Music, EMI, Sony Music, BMG France Session 1 - Microsoft Session 1 Cisco Session 2 Allot Session 3 - Audible Magic Session 4 Advestigo Session 5 CEIS Session 6 - CoPeerRight Agency AFA, Reprsentants des FAI Consommateurs AFA, reprsentants techniques des FAI FAI 1, Cisco, Reprsentants des experts, Cap Gemini FAI 2, Audible Magic, Reprsentants des experts, Cap Gemini FAI 3, Allot, Reprsentants des experts, Cap Gemini
Audition individuelle 3 Audition individuelle 4
22 septembre 2004 18 octobre 2004 23 septembre 2004 5 octobre 2004 5 octobre 2004 7 octobre 2004 28 septembre 2004
Audition collective 5 Audition individuelle 6 Session plnire Runion de travail Runion de travail Runion de travail
7 octobre 2004 20 octobre 2004 21 octobre 2004 26 novembre 2004 6 dcembre 2004 7 dcembre 2004
CHARTE.RTF
Page 43/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
6. Annexe 4 Etudes de cas

6.1. Introduction
Des tudes de cas ont t menes dans le contexte de diffrents FAI et diffrents types solutions de filtrage. Ces tudes ont abord les aspects suivants :
Larchitecture du FAI
Pour une utilisation en mode Filtrage et/ou en mode Monitoring et analyse de trafic :

Scnario de positionnement des solutions Principe de fonctionnement pour lactivation du service ( la demande de linternaute ) Impacts techniques sur larchitecture FAI Nombre de botiers ncessaires Contraintes induites chez le FAI (impact administration, exploitation, ..)
Les tudes menes sont : Solution de filtrage de protocole P_Cube dans le contexte dun FAI 1 Solution de filtrage de contenus Audible Magic dans le contexte dun FAI 2. Solution de filtrage de protocole Allot dans le contexte dun FAI 3 Complments sur la solution de filtrage poste de travail Cisco CSA
Hypothses techniques :
10% des abonns font la demande filtrage (hyp. AFA) 26 30 kb/s trafic moyen par abonn (hypothses de travail pour exemple)
6.2. Filtrage de protocole P_Cube dans le contexte dun FAI 1

6.2.1. Architecture du FAI 1
Larchitecture du FAI 1 est dcoupe de la manire suivante : RTC / DSLAM
CHARTE.RTF
Page 44/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
NAS (bas dbit) / BAS (broadband) Switch ethernet NC (Nuds de collecte) NR (Nud Rgional) NT (Nud de Transit)
Entre un niveau et le niveau suivant, des liens multiples sont tablis afin doptimiser le trafic et fournir une redondance en cas de panne. Les switchs fonctionnant au niveau 2, ils ne prennent pas de dcisions de routage. Les NC fonctionnent au niveau 3 et appliquent des rgles de routage IP BGP. Le trafic montant et descendant peut prendre des routes diffrentes, la majeure partie du trafic est effectivement asymtrique. Larchitecture est rgionalise, notamment pour laffectation des pools dadresses IP.
6.2.2.
Solution P_Cube
La gamme P_Cube est compose de trois matriels : SE100 (10 000 users, 2 x Fast Ethernet) SE 1000 (40 000 users, 2 x Gigabit Ethernet) SE 2000 (100 000 users, 4 x Gigabit Ethernet)
Les matriels P_Cube effectuent de lanalyse protocolaire et fonctionnent en mode sonde, en mode anonyme ou en mode subscriber aware . Ils doivent tre positionns en coupure sur le rseau du FAI et ncessitent une symtrie des flux aller et retour au niveau du mme botier. Les deux scnarios qui suivent nont pas t pr-tablis par Cisco, mais labors au cours de la runion par les experts tiers prsents.
6.2.3.
Positionnement des botiers Scnario 1
Le premier scnario de positionnement consiste positionner les botiers entre les BAS et le premier nud dagrgation, pour lensemble des BAS du FAI.
CHARTE.RTF
Page 45/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Ceci suppose que le FAI mettre en place une politique de routage spcifique appliquer au niveau BAS (source routing), avec modification des priorits de routage afin dassurer le flux retour par un lien connect au mme botier que le lien utilis pour le flux aller. Dans ce scnario de positionnement, un premier dcompte du nombre de botiers ncessaires hors redondance et maintenance serait le suivant : Pour les BAS Gigabit relis en moyenne par 4 liens, 2 botiers SE2000 par BAS soit plusieurs centaines de botiers Pour les BAS Ethernet relis en moyenne par 2 liens, 2 botiers SE100 par BAS soit galement plusieurs centaines de botiers. Soit un total denviron un millier botiers hors redondance et spare (pour maintenance).
6.2.4.
Positionnement des botiers Scnario 2
Le second scnario de positionnement consiste mettre en place une architecture ddie afin de router le trafic des internautes ayant fait la demande de filtrage vers des quipements ddis aux internautes ayant souscrit ce service. Ceci suppose que le FAI mettre en place des BAS ddis (variante 1) ou une solution de routage (variante 2) afin dacheminer le trafic depuis le BAS de rattachement de linternaute vers lquipement LNS. Dans ce scnario de positionnement, un premier dcompte du nombre de botiers ncessaires hors redondance et maintenance serait le suivant : Dans le cas de la variante n1 : En raison de la rgionalisation de larchitecture (POP IP) :
Le nombre de botiers minimum dployer pour couvrir lensemble de larchitecture du FAI serait de un botier par rgion soit une cinquantaine de rgions en plus du nombre de BAS ddi En cas de rpartition gographique non homogne des internautes faisant la demande de filtrage (ex : rgion parisienne), un nombre supplmentaires de botiers serait prvoir.
Dans le cas de la variante n 2 : Dans lhypothse o 10% des abonns font une demande de filtrage la cible et que le trafic est qui-rpartie, 10% du trafic serait concern. Sur cette hypothse, le nombre nominal de botiers ncessaire la cible serait denviron une centaine (soit 10% dun millier), hors impact li la rgionalisation.
6.2.5.
Contraintes induites chez le FAI
En matire de rseau, les contraintes identifies en runion sont les suivantes :
CHARTE.RTF
Page 46/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Dploiement important de matriels P_Cube dans larchitecture du FAI Pour le scnario 1 :
Confection et mise en place de politiques nouvelles de routages spcialises pour la totalit du rseau afin dliminer le trafic asymtrique
Pour le scnario 2 : en fonction de la variante retenue (voir section 3.3) :

Soit le dploiement de BAS ddis (ou spcialisation de BAS existants) Soit le dploiement de solution de routage avec tunnelling vers les LNS
Analyse et mise en place des solutions dadministration, dexploitation et de supervision des lments ci-dessus incluant des aspects techniques (ex : solution de supervision) et humains (ex : quipes dexploitation)
En matire de SI, les contraintes identifies en runion sont les suivantes : Intgration la prise de la solution de filtrage ( travers la solution P_Cube) avec le Systme dInformation (OSS et BSS) (avec impacts techniques et financiers)
En matire de cot, les postes de cots prvoir seraient : Cots dinvestissement fixes :

Ingnierie gnrale Intgration avec les systmes BSS Intgration avec les systmes OSS Marketing et communication

BAS ddi ( dimensionner en dtail) Botier P_Cube (idem) Installation
Cots rcurrents
Cots rcurrents partie rseau (maintenance des matriels et logiciels, prestations dadministration, exploitation et supervision) Cots rcurrents partie SI (maintenance des matriels et logiciels, maintenance corrective et volutive)
En matire de prennit / efficacit :
CHARTE.RTF
Page 47/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Il est ncessaire daccepter le risque dune interruption du filtrage notamment entre lapparition de nouveaux protocoles, principalement les protocoles encrypts, et la disponibilit ( confirmer) de mises jour des logiciels des botiers permettant de les filtrer. Par ailleurs, la capacit filtrer des protocoles encrypts par les solutions de filtrage de protocole est lie soit la reconnaissance des ngociations pralable au passage au mode crypt, soit lexploitation de failles (via une analyse comportementale) dans les changes crypts.
6.3. Filtrage de poste client dans le contexte dun FAI 1

6.3.1. Introduction
Les solution de filtrage sur le poste client a t juge la plus raliste par le FAI 1, aussi bien du point de vue client que de celui des FAI au regard du but recherch. Lorientation propose par le FAI 1 est celle dun filtrage dcentralis directement sur le poste client. Le FAI 1 a indiqu que cette dcentralisation prsentait plusieurs avantages importants : elle vite des modifications profondes et impactantes de linfrastructure technique du FAI. elle vite les risques de dysfonctionnement et de contention des rseaux trs haut dbits des FAI et ce mme dans lavenir. elle donne le choix au client dactiver ou non ce filtrage. elle permet de mutualiser cette fonctionnalit filtrage antiP2P avec dautres logiciels dj prsents sur le poste client (FireWall, Contrle parental ).
Tout en permettant une efficacit comparable celle dune solution rseau, le FAI 1 a indiqu que ce principe permettait en plus un fonctionnement en mode autonome et rduit le risque de dysfonctionnement du rseau. Les solutions de filtrage sur le poste client peuvent gnriquement intervenir trois niveaux : Au niveau port blocage des ports standard utiliss par les clients peer-to-peer (ex : 4661, 4662 pour eDonkey) ; Au niveau applicatif blocage du lancement des applications clientes peer-to-peer sur le poste de travail ou filtrage des communications dune application qui ny est pas autorise ; Au niveau fichier, le cas chant blocage du stockage de fichiers mp3 sur le poste client par exemple.
Le FAI 1 sest intress la mise en uvre de ces solutions au niveau applicatif.
CHARTE.RTF
Page 48/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
6.3.2.
Principe de mise en uvre
Le principe de mise en uvre dune solution de filtrage sur le poste client au niveau applicatif est le suivant : Un agent prsent sur le poste client est responsable de ce filtrage. Cet agent possde une liste dapplicatif autoriss ou non sexcuter ou communiquer. Lors du lancement ou de la tentative de communication dun applicatif, plusieurs possibilits se prsentent :
lapplicatif est prsent dans la liste des applicatifs interdits : lapplicatif ne fonctionnera pas, lutilisateur ne pourra donc pas lutiliser. lapplicatif est prsent dans la liste des applicatifs autoriss : tout se passe normalement pour cet applicatif, rien nest demand lutilisateur. lapplicatif nest prsent dans aucune liste : en fonction du paramtrage de lagent plusieurs cas possibles : 1 - Lagent pose immdiatement la question lutilisateur pour savoir si il faut autoriser lapplicatif sexcuter ou communiquer. Lagent peut mmoriser la rponse pour ne plus poser cette question par la suite. 2 - Lagent peut considrer que tout ce qui est inconnu est interdit et dans ce cas ne pose aucune question et bloque le fonctionnement de lapplicatif. 3 - Lagent demande une identification de lutilisateur, pour sassurer que cest bien ladministrateur de la machine qui est aux commandes, et aprs identification repasse au cas n1.
Ce type de filtrage sapplique tous les types de logiciels et peut donc sappliquer pour les logiciels Peer To Peer. De plus, il est capable de fonctionner mme pour les logiciels encore inconnus ce jour. Ce type de logiciel existe dj aujourdhui et se prsente souvent sous la forme dun FireWall personnel ou dun contrle parental. Ce logiciel est activable et paramtrable par le client. Il permet des parents dinterdire leurs enfants dutiliser des applicatifs permettant de pratiquer des activits illgales comme les logiciels Peer To Peer. Cela va mme plus loin car il peut aller jusqu interdire laccs au FTP ou au newsgroup qui sont dautres moyens de rcuprer des fichiers illgaux.
6.3.3.
Critres identifis par le FAI 1 pour rpondre aux besoins de filtrage de la charte
Les critres identifis par le FAI 1 pour rpondre aux besoins de filtrage de la charte :
CHARTE.RTF
Lagent de filtrage doit sexcuter chaque lancement de lordinateur.

Page 49/59 IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Il ne doit tre paramtrable par lutilisateur quaprs identification de celui-ci. Il doit tre capable de bloquer tous logiciels PeerToPeer existant (et venir pour ce qui est prvisible) Il doit tre transparent lutilisation classique dInternet (Web, Messagerie, ..). Il doit tre simple dutilisation.
Le FAI1 a indiqu quune phase de slection de produit (solution logicielle de filtrage sur le poste de travail) devrait notamment prvoir lobtention dinformations sur : les applications bloques par le produit les mthodes de blocage

Blocage de lexcution Blocage de la communication blocage de port blocage dns blocage par signature
les OS compatibles Les autres applicatifs incompatibles Les langages supports par leur produit et leur documentation sy rapportant Les possibilits de customisation visuelle et fonctionnelle du produit Les possibilits dactivation/dsactivation du produit Les possibilits didentification de lutilisateur Les modalits de mise jour du produit
CHARTE.RTF
Page 50/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
6.4. Filtrage de contenus Audible Magic dans le contexte dun FAI 2

6.4.1. Solution Audible Magic
La solution de filtrage de contenus Audible Magic consiste placer des network appliances CopySense en drivation sur le rseau, partir de ports de routeurs, configurs en miroir des ports de communication. Etant plac en drivation, la panne ventuelle dun tel botier ne pose pas de problme pour la qualit de service. Ce botier est passif, sauf en cas de renvoi de paquets IP de fin de communication ( reset ), dans le contexte dune dtection de contenu filtrer. Il est cependant noter que le trafic tant redirig vers le botier CopySense par les quipements de commutation du FAI, il existe nanmoins des risques. Par ailleurs, les ressources consommes sur les quipements du FAI seront plus importantes. La solution CopySense dtecte les contenus partir dune base centralise de signatures de contenus et dun cache local dans les botiers. La dtection de morceaux de musique se base sur une squence de 20 secondes de musique, indpendante du codec utilis. Dans le cas de protocoles peer-to-peer chiffrs, la solution dtecte potentiellement les protocoles mais pas les contenus. La politique de filtrage, paramtre selon les choix de mise en uvre, pourrait alors couper les sessions peer-to-peer chiffres. La solution saccompagne dun contrat de maintenance des lments de configuration, afin de suivre lvolution des protocoles et des applications clientes de peer-to-peer, et afin de maintenir la base de donnes des signatures de contenus. Un botier CopySense peut supporter environ 300 Mbps de trafic IP.
6.4.2.
Architecture du FAI 2
Le FAI 2 utilise trois types darchitectures rseau, selon les cas, pour ses clients ADSL : 1. Rseau daccs de loprateur historique (DSLAM / ATM / BAS), et backbone IP Gigabit Ethernet propre ; 2. Rseau daccs dun oprateur dgroupeur avec DSLAM IP, et backbone IP Gigabit Ethernet propre ; 3. Rseau daccs propre avec DSLAM IP, et backbone IP Gigabit Ethernet propre.
CHARTE.RTF
Page 51/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
6.4.3.
Scnarios de positionnement des botiers
Le niveau de larchitecture rseau sous la matrise du FAI 2, et commun au trois cas darchitecture prcdents, est le backbone Gigabit Ethernet. Aussi, si le service de filtrage nest pas rendu par les oprateurs fournisseurs de laccs ADSL en gros du FAI 2, celui-ci doit mettre en uvre le filtrage au niveau du backbone. Or, les botiers CopySense ne peuvent traiter unitairement quun trafic de quelques centaines de Mbps. Ceci implique de dsagrger le trafic. Deux scnarios peuvent tre envisags pour l'insertion des botiers CopySense dans larchitecture du FAI 2 : 1. Scnario o lensemble du trafic du FAI serait analys et potentiellement filtr : positionnement des botiers au niveau du backbone, aprs dsagrgation. 2. Scnario o seule une partie du trafic du FAI serait analyse et potentiellement filtre pour les internautes en ayant fait la demande : positionnement des botiers au niveau dune plate-forme ddie, impliquant un routage spcifique des flux des abonns au filtrage, ainsi quune dsagrgation comme dans le cas du scnario 1.
Commentaires relatifs au scnario 1 : Linconvnient de ce scnario est que le trafic total est gr, ce qui implique un nombre important de botiers, et un donc un cot lev. Lintgralit de larchitecture du rseau de FAI 2 est modifier Ce scnario suppose de dsagrger le trafic au niveau du backbone en utilisant plusieurs quipements de type : o Routeur pour dune part ne rcuprer que les flux des abonns filtrer, et dautre part dcomposer des flux de 10 Gbps en 3 flux de 4 Gbps, selon une politique de routage ; Load balancer pour dcomposer les flux 4 Gbps en au maximum 14 flux de 300 Mbps ; Botier CopySense : un par flux de 300 Mbps.
De plus, afin dintercepter tous les flux, y compris ceux entre deux clients du FAI, un routage en fonction de la source (adresse IP) serait requis pour les abonns au filtrage, afin de remonter la plate-forme de filtrage.
CHARTE.RTF
Page 52/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Commentaires relatifs au scnario 2 : Ce scnario suppose de dsagrger le trafic au niveau du backbone en utilisant plusieurs quipements de type : o Routeur pour dune part ne rcuprer que les flux des abonns filtrer, et dautre part dcomposer des flux de 10 Gbps en 3 flux de 4 Gbps, selon une politique de routage ; Load balancer pour dcomposer les flux 4 Gbps en au maximum 14 flux de 300 Mbps ; Botier CopySense : un par flux de 300 Mbps.
Un pool dadresses IP ddi serait utilis pour les abonns au filtrage, et permettait au niveau des routeurs cits ci-dessus de sparer les flux traiter du trafic total. De plus, afin dintercepter tous les flux, y compris ceux entre deux clients du FAI, un routage en fonction de la source (adresse IP) serait requis pour les abonns au filtrage, afin de remonter la plate-forme de filtrage.
Il est noter que le scnario 2 engendre des problmatiques de gestion avec une infrastructure de collecte ADSL IP option 1. En effet, cest loprateur dgroupeur qui attribue les adresses IP pour le compte des abonns de FAI 2. Ainsi, chaque DSLAM de loprateur dgroupeur doit avoir un pool dadresses IP ddi au filtrage.
6.4.4.
Dcompte des botiers
Dans le cas du scnario 2 : Sur un chantillon de 200 000 abonns, dont 10% souscrivent au service de filtrage, et avec lhypothse dun trafic moyen actuel par abonn de 30 Kbps, le trafic filtrer serait de lordre de 600 Mbps. Il faut pouvoir distinguer le trafic gnral du trafic des services de voix sur IP et de vido, qui vont engendrer dans le futur un trafic moyen par abonn de plusieurs centaines de kbps. Sur cette base, deux botiers CopySense seraient suffisants dans un premier temps pour filtrer le trafic correspondant (hors redondance et maintenance), condition de concentrer le trafic filtrer vers un site central.
CHARTE.RTF
Page 53/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Le prix catalogue des botiers CopySense est de 44 000 Euros, soit 4,4 Euros par abonn au filtrage. Il faut ajouter ce cot dinvestissement, celui des routeurs et load balancers requis, le cot dingnierie et de gestion du projet de nouveau service, et les cots rcurrents de maintenance et de suivi oprationnel. Ces cots supplmentaires peuvent tre significatifs et beaucoup plus importants au final que le cot des botiers de filtrage, ramen labonn.
6.4.5.
Les botiers CopySense sont configurs pour traiter les flux en fonction des adresses IP. Ainsi, il est ncessaire dindiquer les adresses IP des abonns filtrer. Or, ces adresses IP sont fournies par le FAI ou loprateur de gros en mode dynamique (DHCP), ce qui exige : soit de rafrachir en permanence la liste des adresses IP au niveau des botiers (peu raliste en mode oprationnel), soit de grer des plages dadresses IP spcifiques pour les clients abonns au filtrage (avec les contraintes correspondantes au niveau de la gestion de lattribution de ces adresses IP).
En matire de rseau, les contraintes identifies sont les suivantes : Ncessit de router les flux des abonns filtrer vers un point central, avec un impact sur la configuration des diffrents routeurs dans le rseau. Risque dincompatibilit avec dautres services ncessitant des infrastructures rseau particulires (ex : voix sur IP, vido et tlvision sur ADSL). Il en rsulterait un manque gagner important pour le FAI en terme de revenu, ainsi quen terme de prise dabonns.
En matire de SI, les contraintes identifies sont les suivantes : Intgration de la prise dabonnement la solution de filtrage ( travers la solution CopySense) avec le Systme dInformation du FAI (OSS et BSS).
En matire de cot, les postes de cots prvoir seraient les suivants : Cots dinvestissement fixes :

Ingnierie gnrale et gestion de projet Intgration avec les systmes BSS Intgration avec les systmes OSS Marketing et communication
CHARTE.RTF

Page 54/59 IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Botiers CopySense Equipements de rseau supplmentaires requis (routeurs, load balancers, ) Installation
Cots rcurrents :
Cots rcurrents sur la partie rseau (maintenance des matriels et logiciels, prestations dadministration, exploitation et supervision) Cots rcurrents sur la partie SI (maintenance des matriels et logiciels, maintenance corrective et volutive).
6.4.6.
Cas dutilisation de la solution de filtrage de contenus
Lutilisation de la solution Copysense pour rendre un service de filtrage aux abonns qui le souhaitent et ceci avec une bonne couverture des diffrents cas de trafic (ex. cas des changes entre le FAI 2 et linternet, ou cas des changes avec tous les clients du FAI 2) apparat difficile mettre en uvre, compte tenu des contraintes darchitecture rseau et des problmes de compatibilit avec les nouveaux services haut dbit (ex. tlphonie, tlvision et vido sur ADSL).
Une utilisation alternative consisterait placer quelques botiers au niveau du backbone, en drivation, et pour analyser une partie seulement du trafic, selon une approche statistique. Le rle de la plateforme de filtrage serait alors en mode radar la demande , au profit des ayant-droits, souhaitant analyser une partie du trafic du FAI. Ce pourrait tre un service rendu par le FAI aux ayant-droits.
6.5. Filtrage de protocole Allot dans le contexte dun FAI 3

6.5.1. Architecture du FAI 3
Le FAI3 dispose de trois types darchitectures : (DSLAM / ATM) appartenant France Telecom + (BAS centraliss / LAC) appartenant au FAI 3 (DSLAM + ATM / BAS centraliss / LAC) appartenant au FAI 3 (DSLAM IP BAS intgrs /Rseau IP) appartenant au FAI3
CHARTE.RTF
Page 55/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
6.5.2.
Solution Allot NetEnforcer
La gamme Allot NetEnforcer est compose des matriels suivants (tableau communiqu lors de laudition Allot):
Modle AC-1010-SP/155M AC-1010-SP/310M AC-1010-SP/620M AC-1010-SP/1000M AC-1020-SP/155M AC-1020-SP/310M AC-1020-SP/620M AC-1020-SP/1000M Dbit/par Interface rseau 155 Mbps 310 Mbps 620 Mbps 1Gbps 155 Mbps 310 Mbps 620 Mbps 1Gbps Policies er (1 niveau) 10,000 10,000 10,000 10,000 10,000 10,000 10,000 10,000 Policies Nombre dinterface (1eme niveau) 80,000 80,000 80,000 80,000 80,000 80,000 80,000 80,000 2 2 2 2 4 4 4 4
Ces matriels fournissent des fonctions danalyse et de filtrage de trafic P2P au niveau protocole. Ils doivent tre positionns en coupure sur le rseau du FAI. A noter que ces matriels prennent en compte les flux chiffrs chiffrs SSL (ex. Winny / Filetopia / Earthstation 5 / SoftEther )ainsi que lasymtrie des flux.
6.5.3.
Scnarios de positionnement des botiers
Deux scnarios sont t identifis pour l'insertion des botiers Allot dans larchitecture du FAI 3 : 3. Scnario o lensemble du trafic du FAI serait analys et potentiellement filtr : Positionnement des botiers au niveau des points de peering (point dchange entre un ou plusieurs FAI ) 4. Scnario o seul une partie du trafic du FAI serait analys et potentiellement filtr pour les internautes en ayant fait la demande : Positionnement des botiers au niveau dune plateforme ddie Commentaires relatifs au scnario 1 : Linconvnient de ce scnario est que le trafic P2P entre abonns du mme FAI3 ne serait pas filtr
CHARTE.RTF
Page 56/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Les botiers seraient positionns en coupure sur des liens critiques pour le FAI induisant un risque potentiel de dgradation de la qualit de service (temps de latence) et de scurit de fonctionnement. Ce dernier point est mitig dune part en raison du fait que les botiers Allot, en cas de dfaillance, basculent en mode pass-through, dautre part en raison de lexistence de stratgies de routage alternatives (passage du trafic par dautres points de peering en cas de dfaillance de lun dentre eux)
Commentaires relatifs au scnario 2 : Lors de lauthentification dun abonn ayant souscrit loption de filtrage du peer to peer, le radius demande au DSLAM douvrir un tunnel L2TP vers un LNS plac en point dentre de la plateforme ddie disposant de la solution de filtrage. Note : pour un fonctionnement sans authentification (radius), lidentification est effectue partir de ladresse MAC de labonn Dans le cas dun mode daccs au rseau sans authentification, il y a ncessit de crer un pool dadresses IP ddi pour ces abonns. Pas de contrainte gographique particulire (notamment : les pools dIP actuels sont grs de manire globale, sans dimension gographique) Des architecture de routage particulires sont dj en place chez le FAI3 (ex : trafic wholesale pour un FAI tiers) Du fait de la mise en place des infrastructure de rseau particulires, ce scnario peut impacter la capacit combiner des services (ex. combinaison contrle parental + firewall + filtrage P2P ) notamment dans le contexte des nouvelles architectures DSLAM IP. Ce scnario induit la mise en place de LNS centralis et ddis, loppos des volutions darchitecture en cours chez les oprateurs. Il ne permettra pas toujours la transparence des services Vs les abonns non filtrs. Enfin, ce scnario induit un surcot important dtudes / validation / intgration pour chaque nouveau service dvelopp par le FAI (les chanes de liaisons sont dupliques).
6.5.4.
Dcompte des botiers
Dans le scnario 1 : Sur la base dune vingtaine de routeurs backbone et dune dizaine de routeurs de peering (deux par site de peering), une vingtaine de boitiers Allot seraient ncessaires pour analyser et filtrer le trafic (hors redondance et maintenance)
Dans le scnario 2 : Sur une base de 200 000 abonns, dont 10% souscrivent le service, et lhypothse dun trafic moyen par abonn de 26 Kb/s, le trafic filtrer serait de lordre de 520 Mb/s
CHARTE.RTF
Page 57/59
IMPRIME LE: 10/03/05 12:01
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Sur cette base, un seul botier Allot serait suffisant pour filtrer le trafic correspondant (hors redondance et maintenance)
6.5.5.
En matire de rseau, les contraintes identifies en runion sont les suivantes : Impact des botiers sur la qualit de service (les botiers sont positionns en coupure) Il est noter que si le botier NetEnforcer introduit, certes, une latence, sa vocation premire est nanmoins de mettre en place des mcanismes de QoS (garantie temps de rponse VoIP). Du point de vue dAllot, le temps de latence peut tre considr comme ngligeable, et ne constitue pas la contrainte premire de mise en uvre de la solution . Risque dincompatibilit avec dautres services ncessitant des infrastructure rseau particulires (ex : VOIP)
En matire de SI, les contraintes identifies en runion sont les suivantes : Intgration la prise de la solution de filtrage ( travers la solution Allot) avec le Systme dInformation (OSS et BSS)
En matire de cot, les postes de cots prvoir seraient : Cots dinvestissement fixes quelque soit le nombre dabonns mais variable en fonction du nombre de services offerts* par les FAI :

Ingnierie gnrale Intgration avec les systmes BSS Intgration avec les systmes OSS Marketing et communication

Botiers Allot LNS ddis Routeurs dagrgation dans le BB Plate-forme de service, eg. Serveurs de Mail & Hbergement de pages Web (partiellement au moins en fonction du niveau de scurit souhait) Installation
Cots rcurrents
Cots rcurrents partie rseau (maintenance des matriels et logiciels, prestations dadministration, exploitation et supervision)
Page 58/59 IMPRIME LE: 10/03/05 12:01
CHARTE.RTF
VERSION : V10
DATE CREATION:
10/03/05 12:00 10/03/05 12:00
RAPPORT DETUDE
DATE MODIF.:
Cots rcurrents partie SI (maintenance des matriels et logiciels, maintenance corrective et volutive)
(*) Un service peut tre soit la cration dun nouveau dbit daccs, soit dun nouveau bundle de service (VoIP+@) par exemple
En matire de prennit / efficacit : Il est ncessaire daccepter le risque dune interruption du filtrage notamment entre lapparition de nouveaux protocoles, principalement les protocoles encrypts, et la disponibilit ( confirmer) de mises jour des logiciels des botiers permettant de les filtrer. Par ailleurs, la capacit filtrer des protocoles encrypts par les solutions de filtrage de protocole est lie soit la reconnaissance des ngociations pralable au passage au mode crypt, soit lexploitation de failles (via une analyse comportementale) dans les changes crypts. Ces lments sont particulirement complexes dans le cas o les flux montants et descendants n'utilisent pas les mmes liens (ce qui est un cas courant).
CHARTE.RTF
Page 59/59
IMPRIME LE: 10/03/05 12:01

Charte D'engagements Pour La Lutte Contre La Piraterie Et Pour Le Développement Des Offres Légales de Musique en Ligne"

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Charte D'engagements Pour La Lutte Contre La Piraterie Et Pour Le Développement Des Offres Légales de Musique en Ligne"

Uploaded by

Copyright:

Available Formats

VERSION : V10

10/03/05 12:00 10/03/05 12:00

AUTEURS DATE VERSION

A. Brugidou, G. Kahn 09/03/2005 18:19:00

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

Historique des modifications

0.17 0.20 0.22 V3Jan V4Jan

A. Brugidou, G. Finalisation du document Kahn A. Brugidou, G. Prise en compte de remarques Kahn

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

Table des matires

10/03/05 12:00 10/03/05 12:00

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

1.2. Structure de ltude

1.3. Dmarche adopte

10/03/05 12:00 10/03/05 12:00

Elaboration de scnarios pour lexprimentation.

Sessions de travail technique complmentaires :

Rdaction du rapport dtude.

1.4. Technologies du peer-to-peer

Importance du trafic peer-to-peer

10/03/05 12:00 10/03/05 12:00

10/03/05 12:00 10/03/05 12:00

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

1.5. Autres tendances et volutions technologiques

10/03/05 12:00 10/03/05 12:00

Commentaires Capgemini / Note AFA 091104

10/03/05 12:00 10/03/05 12:00

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

Fournisseur dAccs Internet

10/03/05 12:00 10/03/05 12:00

Les opposants ce type de filtrage remarquent que :

10/03/05 12:00 10/03/05 12:00

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

2.3. Lapproche Radar

Nanmoins cette approche soulve des questions de nature juridique et technique :

10/03/05 12:00 10/03/05 12:00

2.4. Sur le plan technique, ncessit dexprimenter

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

2.5. Besoin de mettre en uvre plusieurs solutions en parallle

Non pertinent Non applicable

Non retenu (pas de qualification des contenus) Atudier

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

3. Analyse des solutions de filtrage

3.2. Modes de dploiement envisageables

Filtrage de lensemble des internautes. Filtrage de la totalit du trafic.

Filtrage la demande Ce mode est celui envisag par la Charte :

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00

3.3. Familles de solutions de filtrage

Ltude fournie par le SNEP9 a identifi cinq familles de solutions :

10/03/05 12:00 10/03/05 12:00

IMPRIME LE: 10/03/05 12:01

10/03/05 12:00 10/03/05 12:00