Files
i2p.www/www.i2p2/pages/techintro_fr.html

832 lines
68 KiB
HTML
Raw Normal View History

{% extends "_layout_fr.html" %}
2011-03-06 23:24:10 +00:00
{% block title %}Présentation d'I2P{% endblock %}
{% block content %}
2011-03-23 09:28:14 +00:00
Traduction de mars 2011. <a href="techintro.html">Version anglaise actuelle</a>
2011-12-21 18:20:26 +00:00
<h1 class="title">I2P: <span style="font-size:medium,">Une plate-forme modulaire pour la communication anonyme</span></h1>
<div id="toc">
<h2>Table des matières</h2>
<ul>
<li><a href="#intro">Introduction</a></li>
<li><a href="#op">Fonctionnement d'I2P</a>
<ul>
<li><a href="#op.overview">Aperçu</a></li>
<li><a href="#op.tunnels">Tunnels</a></li>
2011-03-21 11:22:48 +00:00
<li><a href="#op.netdb">Base de données du réseau</a></li>
<li><a href="#op.transport">Protocoles de transport </a></li>
<li><a href="#op.crypto">Cryptographie</a></li></ul>
</li>
<li><a href="#future">L'avenir</a></li>
<li><a href="#similar">Systèmes similaires</a>
<ul>
<li><a href="#similar.tor">Tor</a></li>
<li><a href="#similar.freenet">Freenet</a></li>
</ul>
</li>
</li>
<li><a href="#app">Appendice A: la couche applicative</a>
<ul>
<li><a href="#app.streaming">Bibliothèque de flux (streaming)</a></li>
<li><a href="#app.naming">Bibliothèque de nommage et carnet d'adresses</a></li>
<li><a href="#app.syndie">Syndie</a></li>
<li><a href="#app.i2ptunnel">I2PTunnel</a></li>
<li><a href="#app.i2pbt">i2p-bt</a></li>
<li><a href="#app.i2psnark">I2PSnark</a></li>
<li><a href="#app.robert">Robert</a></li>
<li><a href="#app.pybit">PyBit</a></li>
<li><a href="#app.i2phex">I2Phex</a></li>
<li><a href="#app.i2pmail">I2Pmail/susimail</a></li>
<li><a href="#app.i2pbote">I2P-Bote</a></li>
<li><a href="#app.i2pmessenger">I2P-messenger</a></li>
</ul>
</li>
</ul>
</div>
<br/>
<h1 id="intro">Introduction</h1>
<p>
2011-03-21 11:22:48 +00:00
I2P est une couche réseau à commutation de paquets, modulaire, à tolérance de panne, auto-adaptative, et anonyme
2011-03-06 23:24:10 +00:00
sur laquelle peuvent fonctionner n'importe quel nombre d'applications conçues pour l'anonymat ou la sécurité.
Chacune de ces applications peut gérer ses propres contraintes d'anonymat, de latence et de débit,
sans avoir à se soucier d'une implémentation correcte d'un
<a href="http://en.wikipedia.org/wiki/Mix_network">réseau croisé (mixnet)</a>
d'accès libre qui leur permet de mêler leur activité au grand groupe d'utilisateurs anonymisés
déjà présents sur I2P.
</p>
<p>
2011-03-06 23:24:10 +00:00
Des applications d'ores et déjà disponibles offrent un large éventail de fonctionnalités Internet classiques
<b>mais anonymes</b>: exploration web, hébergement, chat, partage de fichiers, e-mail,
blogs et publications simultanées, newsgroups, tout comme plusieurs autres applications en cours de développement.
<ul>
2011-03-06 23:24:10 +00:00
<li>Exploration web: en utilisant tout navigateur compatible avec un serveur mandataire (proxy).</li>
<li>Chat: IRC, Jabber, <a href="#app.i2pmessenger">I2P-messenger</a>, ou tout autre compatible proxy.</li>
<li>Partage de fichiers: <a href="#app.i2psnark">I2PSnark</a>, <a href="#app.robert">Robert</a>,
<a href="#app.i2phex">I2Phex</a>, <a href="#app.pybit">PyBit</a>, <a href="#app.i2pbt">I2P-bt</a>
2011-03-06 23:24:10 +00:00
et d'autres.
</li>
2011-03-06 23:24:10 +00:00
<li>E-mail: <a href="#app.i2pmail">susimail</a> et <a href="#app.i2pbote">I2P-Bote</a>.</li>
<li>Newsgroups: via un lecteur de newsgroups compatible proxy.</li>
</ul>
<p>
2011-03-09 12:39:38 +00:00
Contrairement aux sites web hébergés sur des réseaux de distribution de contenu comme
<a href="#similar.freenet">Freenet</a> ou <a href="http://www.ovmj.org/GNUnet/">GNUnet</a>,
les services hébergés sur I2P sont totalement interactifs: il y des moteurs de recherches traditionnels,
des BBS, des blogs sur lesquels vous pouvez déposer des commentaires, des sites pilotés par bases de données,
et des ponts pour interroger les systèmes statiques comme Freenet sans devoir en faire une installation locale.
</p>
<p>
2011-03-09 12:39:38 +00:00
Grâce à toutes ces applications prenant l'anonymat en considération, I2P prend le rôle
de plaque tournante "orientée messages": les applications demandent à envoyer des données
à un identifiant cryptographique (une "destination") et I2P prend soin de s'assurer qu'elles
y parviennent en toute sécurité et anonymat. I2P fournit aussi une bibliothèque simple pour les
<a href="#app.streaming">flux</a> (streaming) pour permettre le transfert fiable et ordonné de messages
de flux anonymes, en offrant de façon transparente un algorithme de contrôle de congestion basé sur TCP
et optimisé pour les applications à haute bande passante au sein réseau.
Bien qu'il y ait eu plusieurs simple mandataires SOCKS disponibles pour attirer des applications existantes
2011-03-21 11:22:48 +00:00
dans le réseau, leur intérêt a été limité car presque toutes exposent intrinsèquement ce qui, du point de vue
2011-03-09 12:39:38 +00:00
de l'anonymat, s'avère être des informations sensibles. La seule façon d'avancer est d'analyser complètement
une application pour s'assurer d'un fonctionnement irréprochable, et pour y aider, nous fournissons
une série d'API dans divers langages, qui permettent d'en faire le plus possible en dehors du réseau.
</p>
<p>
I2P n'est pas un projet de recherche (universitaire, commercial, ou gouvernemental), mais un effort
d'ingénierie dont le but est de faire tout le nécessaire pour assurer
un niveau d'anonymat suffisant à ceux qui en ont besoin. Il est en développement actif
depuis les débuts de 2003 avec un développeur à temps plein et un groupe dédié de
contributeurs à temps partiel répartis dans le monde entier. Tout le travail fourni pour I2P
est "open source" et gratuitement disponible sur le <a href="index_fr.html">site</a>,
pour lequel la plus grande partie du code est publié directement dans le domaine public, bien que
faisant usage de quelques routines cryptographiques sous licences de style BSD. L'équipe d'I2P
ne contrôle pas le cadre légal de publication des applications tierce partie. Il y a plusieurs
applications disponibles sous licence GPL (<a href="#app.i2ptunnel">I2PTunnel</a>,
<a href="#app.i2pmail">susimail</a>, <a href="#app.i2psnark">I2PSnark</a>,
<a href="#app.i2phex">I2Phex</a> et d'autres).
Le <a href="http://www.i2p.net/halloffame">financement</a> d'I2P vient entièrement de dons,
et ne bénéficie pour l'instant d'aucune dispense d'impôts de la part de quelque juridiction que ce soit,
vu que la plupart des développeurs sont anonymes.
</p>
<h1 id="op">Fonctionnement</h1>
<h2 id="op.overview">Aperçu</h2>
<p>
Pour comprendre le fonctionnement d'I2P, quelques concepts fondamentaux sont prérequis.
Tout d'abord, I2P fait une séparation stricte entre le logiciel participant au réseau
(un "routeur") et les point terminaux anonymes (les "destinations") associés aux applications particulières.
Que quelqu'un utilise I2P n'est généralement pas un secret. Ce qui est caché, c'est
c'est tout ce que l'utilisateur en fait, aussi bien qu'à quelle destination particulière le routeur est connecté.
En général, l'utilisateur dispose sur son routeur de plusieurs destinations locales: une, par exemple,
pour se connecter en proxy aux serveurs IRC, une autre pour héberger son propre site Internet
anonyme ("eepsite"), une autre pour une instance I2Phex, une autre encore pour les torrents, etc...
</p>
<p>
Un autre concept majeur est celui de "tunnel".
Un tunnel un chemin orienté passant par une liste de routeurs explicitement sélectionnés.
Un cryptage en couches est utilisé pour que chacun des routeurs n'en puisse décrypter qu'une seule.
L'information décryptée contient l'IP du routeur suivant, avec l'information cryptée à faire suivre.
Chaque tunnel a un point de départ (le premier routeur, appelé "passerelle")
et un point terminal. Les messages ne peuvent être envoyés que dans un seul sens. Pour les réponses,
un autre tunnel est nécessaire.
</p>
2011-12-21 18:20:26 +00:00
<div class="box" style="text-align:center;">
<img src="_static/images/tunnels_fr.png" alt="Schéma de tunnels entrant et sortant"
title="Schéma de tunnels entrant et sortant" />
<br /><br />
Figure 1: Les deux types de tunnels: entrant et sortant.
</div>
2011-12-21 18:20:26 +00:00
<br/>
<p>
2011-03-10 10:59:00 +00:00
Il y deux types de tunnels:
Les <b>tunnels "sortants"</b> expédient des messages depuis le créateur du tunnel, alors
que les <b>tunnels "entrants"</b> ramènent des messages vers le créateur du tunnel.
La combinaison de ces deux tunnels permet aux utilisateurs de s'envoyer des messages les uns aux autres.
L'expéditeur ("Alice" dans l'illustration ci-dessus) crée un tunnel sortant,
et le récepteur ("Bob" ci-dessus) crée un tunnel entrant.
La passerelle d'un tunnel entrant peut recevoir des messages de n'importe quel autre utilisateur
et les envoie jusqu'au point terminal ("Bob").
2011-03-10 16:16:47 +00:00
Le point terminal du tunnel sortant devra pouvoir envoyer le message vers la passerelle du tunnel entrant.
Pour le permettre, l'expéditeur ("Alice") ajoute à son message crypté des instructions cryptées à l'intention
du point terminal sortant. Une fois décryptées par celui-ci, il dispose alors des informations nécessaires
2011-03-21 11:22:48 +00:00
au transfert vers la bonne passerelle entrante (la passerelle vers "Bob").
</p>
<p>
2011-03-10 16:16:47 +00:00
Le troisième concept fondamental est la <b>"base de données"</b> I2P (ou "netDb"):
une paire d'algorithmes utilisés pour le partage des métadonnées du réseau. Les deux types de métadonnées
2011-03-10 16:17:25 +00:00
transportées sont la <b>"routerInfo"</b> et les <b>"jeux de baux"</b> (leaseSets):
2011-03-10 16:16:47 +00:00
la routerInfo donne aux routeurs les données nécessaires pour contacter un autre routeur particulier
2011-03-10 16:17:25 +00:00
(ses clés publiques, adresse de transport, etc...), et les jeux de baux donnent au routeurs les informations
2011-03-10 16:16:47 +00:00
nécessaires pour joindre une destination particulière. Un jeu de baux contient un certain nombre de "baux".
2011-03-10 16:17:25 +00:00
Chacun de ces baux indique une passerelle de tunnel qui permet d'atteindre une destination particulière.
2011-03-10 16:16:47 +00:00
Détail complet des informations contenues dans un bail:
<ul>
2011-03-15 09:56:05 +00:00
<li>Passerelle entrante pour un tunnel permettant d'atteindre une certaine destination.</li>
<li>Moment d'expiration du tunnel.</li>
<li>Paire de clés publiques pour pouvoir crypter les messages (à envoyer à travers le tunnel
et atteindre la destination).</li>
</ul>
2011-03-21 11:22:48 +00:00
Les routeurs envoient eux-mêmes directement leur "routerInfo" à la base de données,
2011-03-15 09:56:05 +00:00
alors que les jeux de baux sont envoyés par des tunnels sortants (ils doivent rester anonymes, pour
empêcher toute tentative de corrélation entre un routeur et ses jeux de baux).
</p>
2011-03-15 09:56:05 +00:00
<p>On peut combiner les trois concepts exposés ci-dessus pour établir des connexions effectives dans le réseau.
</p>
<p>
2011-03-15 09:56:05 +00:00
Pour créer ses propres tunnels entrants et sortants, Alice fait une recherche dans la "netDb" pour obtenir
des "routerInfo".
De cette façon, elle constitue des listes de pairs qu'elle peut utiliser en tant que sauts dans ses tunnels.
Ensuite elle peut envoyer au premier saut un message élaboré, demandant la création d'un tunnel, et de faire passer
cette demande plus loin, jusqu'à ce que le tunnel soit entièrement créé.
</p>
2011-12-21 18:20:26 +00:00
<div class="box" style="text-align:center;">
2011-03-10 16:17:25 +00:00
<img src="_static/images/netdb_get_routerinfo_1_fr.png" alt="Demande d'informations sur d'autres routeurs"
title="Demande d'informations sur d'autres routeurs" />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2011-03-10 16:17:25 +00:00
<img src="_static/images/netdb_get_routerinfo_2_fr.png"
alt="Construction d'un tunnel grâce aux informations sur les routeurs"
title="Construction d'un tunnel grâce aux informations sur les routeurs" />
<br /><br />
Figure 2: Les informations sur les routeurs servent à construire les tunnels.
</div>
2011-12-21 18:20:26 +00:00
<br/>
<p>
2011-03-15 09:56:05 +00:00
Quand Alice désire envoyer un message à Bob, elle recherche tout d'abord dans la netDb
un jeu de baux de Bob, ce qui lui donne ses passerelles entrantes de tunnels.
Elle choisit ensuite un de ses tunnels sortants et y envoie le message avec les
instructions pour le point terminal afin qu'il fasse suivre le message à l'une des
passerelles de tunnels entrants de Bob. Quand le point terminal reçois ces instructions,
il transfère le message comme demandé, et quand la passerelle de tunnel entrant de Bob le reçoit,
elle le transfère dans le tunnel vers le routeur de Bob. Si Alice veut que Bob puisse répondre,
elle doit lui indiquer explicitement sa propre destination en tant qu'élément du message lui-même.
On y parvient en introduisant une couche de haut niveau, ce qui est fait par la bibliothèque de flux
<a href="#app.streaming">flux</a> (streaming).
Alice peut aussi raccourcir le temps de réponse en fournissant dans le message son jeu de baux le plus récent,
en sorte que Bob soit dispensé d'une requête à netDb quand il voudra répondre. Mais ceci est optionnel.
</p>
2011-12-21 18:20:26 +00:00
<div class="box" style="text-align:center;">
2011-03-10 16:17:25 +00:00
<img src="_static/images/netdb_get_leaseset_fr.png" alt="Connexion de tunnels grâce au jeux de baux"
title="Connexion de tunnels grâce au jeux de baux" />
<br /><br />
2011-03-10 16:17:25 +00:00
Figure 3: Les jeux de baux sont utilisés pour connecter les tunnels sortants et entrants.
</div>
2011-12-21 18:20:26 +00:00
<br/>
<p>
2011-03-15 09:56:05 +00:00
De même que les tunnels ont eux-mêmes un cryptage étagé pour empêcher un dévoilement non autorisé
par les pairs au sein du réseau (comme la couche transport le fait elle-même pour protéger des pairs
les contenus en dehors du réseau), il est nécessaire d'ajouter une couche additionnelle
de cryptage de bout en bout pour cacher le message au point terminal sortant et à la passerelle entrante.
Ce cryptage "<a href="#op.garlic">en tête d'ail</a>" (garlic)
fait que le routeur d'Alice va "emballer" de multiples messages dans un seul message
(la tête d'ail="garlic message"), crypté pour une certaine clé publique en sorte que les pairs intermédiaires
ne puissent déterminer ni combien il y a de messages (des gousses ou caïeux si on veut pousser plus loin
l'analogie botanique) dans le bulbe, ni si ces messages sont amers ou sucrés (ce qu'ils disent), ni si ces gousses
vont servir à frotter un plat à cassoulet, finir fondus dans un gigot
ou hachés/grillés sur une dorade (à qui elles sont destinées). Pour une communication typique
de point à point entre Alice et Bob, la tête d'ail va être cryptée avec la clé publique annoncée
dans le jeu de baux de Bob, ce qui permet le cryptage sans donner la clé publique du routeur de Bob.
</p>
<p>
2011-03-15 09:56:05 +00:00
Une autre donnée importante qu'il faut garder à l'esprit, est qu'I2P est entièrement basé sur l'échange
de messages et que quelques messages pourraient se perdre en chemin. Les applications utilisant I2P peuvent
utiliser les interfaces "orientées messages" et s'occuper de leur propre contrôle de congestion et besoins de
fiabilité, mais elles seront mieux servies en utilisant la bibliothèque de <a href="#app.streaming">streaming</a>
fournie en vue de voir I2P comme un réseau "orienté flux".
</p>
2011-03-15 09:56:05 +00:00
<h2 id="op.tunnels">Les tunnels</h2>
<p>
2011-03-15 09:56:05 +00:00
Les tunnels entrants et sortants partagent les mêmes principes de fonctionnement.
La passerelle de tunnel accumule un certain nombre de messages, en les pré-traitant éventuellement
en vue d'une distribution dans le tunnel. Ensuite, elle crypte ces données préparées
et les transfère vers le premier saut. Ce pair et les participants suivants du tunnel
y ajoutent une couche de cryptage après avoir vérifié qu'il ne s'agit pas d'un doublon et avant
de le transférer au pair suivant. Le message arrive éventuellement au point terminal
où les messages sont de nouveau séparés et transférés comme demandé. La différence réside
dans l'action du créateur du tunnel: pour les tunnels entrants, le créateur est le point terminal,
et il déchiffre simplement toutes les couches ajoutées, alors que pour les tunnels sortants,
le créateur est la passerelle, et il pré-déchiffre toutes les couches pour qu'une fois toutes
2011-03-21 11:22:48 +00:00
les couches de cryptage par saut ajoutées, le message arrive en clair au point terminal.
</p>
<p>
2011-03-15 09:56:05 +00:00
Le choix de pairs spécifiques pour passer les messages, ainsi que la définition de leur séquence,
2011-03-21 11:22:48 +00:00
est important pour une bonne compréhension de l'anatomie et des performances d'I2P.
2011-03-15 09:56:05 +00:00
Alors que la base de données dispose de ses propres critères de sélection lors du choix
2011-03-21 11:22:48 +00:00
des pairs à interroger et pour mémoriser les entrées correspondantes, les créateurs de tunnels utilisent
2011-03-15 09:56:05 +00:00
n'importe quels pairs du réseau et dans n'importe quel ordre (et même un nombre de fois indéfini) dans le
même tunnel. Si des données précises de latence et de capacité étaient globalement connues, la sélection et
le tri seraient pilotés par les besoins particuliers du client en relation avec leur modèle de sécurité.
Malheureusement, la latence et les capacités ne sont pas simples à collecter anonymement, et avoir besoin
besoin de pairs sans confiance établie pour fournir ces informations pose de sérieux problèmes d'anonymat.
</p>
<p>
2011-03-15 09:56:05 +00:00
Du point de vue de l'anonymat, la technique la plus simple serait de sélectionner des pairs au hasard
dans la totalité du réseau, de les trier aléatoirement, et de les utiliser dans cet ordre ad vitam æternam.
Mais pour les performances, la plus simple façon serait de ne retenir que les plus rapides disposant de la
réserve de capacité suffisante, de répartir la charge sur différents pairs pour gérer les défaillances
de façon transparente, et de recréer le tunnel chaque fois que l'information de capacité est modifiée.
alors que la première façon est à la fois fragile et inefficace, la seconde demande des informations
indisponibles et n'offre qu'un anonymat insuffisant.
I2P fonctionne plutôt en utilisant une gamme de stratégies de sélection des pairs,
couplée à du code d'évaluation du niveau d'anonymat pour organiser ces pairs selon leur profil.
</p>
<p>
2011-03-21 11:22:48 +00:00
À la base, I2P classe en permanence les pairs avec lesquels il interagit en mesurant indirectement
2011-03-15 09:56:05 +00:00
leur comportement: par exemple, quand un pair répond à une requête netDb en 1,3s,
cette latence d'aller-retour est enregistrée dans les profils pour tous les routeurs impliqués
dans les deux tunnels (entrant et sortant) au travers desquels la requête et la réponse sont passées,
ainsi que le profil du pair. Les mesures directes, telles que la latence de la couche transport ou la congestion,
ne sont pas utilisées en tant que données de profil car elles peuvent être manipulées au routeur mesurant,
l'exposant ainsi à des attaques basiques. En rassemblant ces profils, une série de calculs est lancée
sur chacun pour synthétiser ses performances: sa latence, sa capacité à gérer beaucoup d'activités, s'il est
actuellement surchargé, et à quel point il semble bien intégré au réseau.
Les résultats de ces calculs sont alors comparés pour les pairs actifs afin de
répartir les routeurs en quatre groupes: les rapides à hautes capacités, ceux de hautes capacités, les non
défaillants, et les défaillants. Les seuils de ces groupes sont déterminés dynamiquement, et comme ils n'utilisent
actuellement que des algorithmes assez simples, il y a d'autres possibilités.
</p>
2011-03-15 09:56:05 +00:00
<p> Pour utiliser ces données de profils, la stratégie de sélection la plus simple consiste à
les prendre aléatoirement dans le premier groupe (celui des plus rapides à fortes capacités),
et c'est ce qui est actuellement employé pour les tunnels clients.
Les tunnels exploratoires (utilisés pour les communications avec la base de données et la gestion des tunnels)
prennent les pairs aléatoirement dans le troisième groupe des non défaillants (qui inclut ceux du premier),
ce qui permet une base de sélection plus étoffée avec pour effet l'optimisation de la sélection
via une progression aléatoire. Ces stratégies laissent cependant fuir des informations concernant les pairs
2011-03-21 11:22:48 +00:00
du premier groupe utilisables par des attaques du type collecte de base de données et du type prédécesseur.
2011-03-15 09:56:05 +00:00
En retour, il y a plusieurs alternatives qui bien que n'équilibrant pas la charge aussi uniformément,
bloquent les attaques lancées par certains types d'ennemis.
</p>
<p>
2011-03-15 09:56:05 +00:00
En sélectionnant une clé aléatoire et en triant les pairs selon leur distance "eXORisée" à cette clé,
la fuite d'information est réduite pour les attaques prédécesseur et collecte, suivant le taux de défaillance
des pairs et le renouvellement des seuils des groupes. Une autre stratégie simple pour parer aux
attaques par collecte de la netDb consiste simplement à obliger la passerelle entrante à figer
2011-03-21 11:22:48 +00:00
aléatoirement la position des pairs situés plus loin dans le tunnel. Pour gérer les attaques de prédécesseur
2011-03-15 09:56:05 +00:00
par des adversaires que le client contacte, le point terminal de tunnel devrait aussi rester statique.
La sélection du pair à figer au point le plus vulnérable doit bien sûr être limitée en durée,
2011-03-21 11:22:48 +00:00
car tous les pairs sont susceptibles de défaillance, et donc elle doit soit être ajustée en réaction, ou
2011-03-15 09:56:05 +00:00
préventivement empêchée pour simuler le MTBF (temps moyen entre défaillances) mesuré d'autres routeurs.
Ces deux stratégies peuvent ensuite être combinées, en utilisant un pair vulnérable figé et un tri sur XOR
dans les tunnels eux-mêmes. Une stratégie plus stricte consisterait à définir les pairs précis et leur ordre
dans un tunnel potentiel, en utilisant uniquement de pairs qui accepteraient tous de participer de la même
façon à chaque fois. Ceci diffère du tri basé sur le résultat de l'XOR en ce que le prédécesseur
et le successeur de chaque pair serait toujours les mêmes, alors que le tri sur l'XOR ne permet que de s'assurer
que leur ordre ne change pas.
</p>
<p>
2011-03-15 09:56:05 +00:00
Comme déjà mentionné, I2P, actuellement en version 0.8 inclut la stratégie basée sur les groupes,
avec le tri basé sur le XOR. Une discussion plus poussée des mécanismes impliqués dans les opérations de tunnel
la gestion et la sélection des pairs est disponible sur la page
<a href="tunnel-alt.html">spécification des tunnels</a>.
</p>
2011-03-15 10:57:29 +00:00
<h2 id="op.netdb">Base de données</h2>
<p>
2011-03-15 10:57:29 +00:00
Comme indiqué précédemment, la base de données d'I2P sert à partager les métadonnées du réseau.
Ceci est détaillé sur la page <a href="how_networkdatabase.html">La base de données du réseau</a>,
mais en voici une explication simplifiée:
</p>
<p>
2011-03-15 10:57:29 +00:00
Un certain pourcentage des utilisateurs d'I2P sont crédités du statut de 'floodfill peers', pairs remplisseurs par
diffusion, diffuseurs dans la suite.
Actuellement, les installations d'2P qui on une bonne bande passante et qui sont assez rapides se
déclarent elles-mêmes en tant que diffuseur dès que le nombre de routeurs diffuseurs tombe à un niveau trop faible.
</p>
<p>
2011-03-15 10:57:29 +00:00
Les autres routeurs I2P vont y enregistrer leurs données et recherches en envoyant de simples requêtes
'store' et 'lookup' aux diffuseurs.
2011-03-15 11:32:58 +00:00
Quand un diffuseur reçoit un requête 'store', il la diffuse aux autres diffuseurs en utilisant
l'<a href="http://fr.wikipedia.org/wiki/Kademlia">algorithme Kademlia</a>.
2011-03-15 10:57:29 +00:00
Les requêtes 'lookup' fonctionnent actuellement de façon différente, pour éviter
<a href="how_networkdatabase.html#lookup">un problème de sécurité important</a>.
Lorsqu'une recherche est lancée, le diffuseur ne la diffuse pas, mais y répond lui-même s'il dispose
des données demandées.
</p>
<p>
2011-03-15 10:57:29 +00:00
Deux types d'informations sont stockées dans la netDb.
<ul>
2011-03-15 11:32:58 +00:00
<li><b>routerInfo</b>, un routeur I2P spécifique et la façon de le joindre.</li>
<li><b>leaseSet</b>, une destination spécifique (p.e. un site web I2P, un serveur de messagerie, etc...)</li>
</ul>
2011-03-15 11:32:58 +00:00
Toutes ces infos sont signées par leur propriétaire, et vérifiées par tout routeur I2P qui les utilise
ou les stocke.
2011-03-15 10:57:29 +00:00
De plus, les données contiennent des informations de temps, pour éviter le stockage de vielles entrées
et empêcher d'éventuelles attaques. C'est aussi pourquoi I2P fournit le code nécessaire pour conserver
une heure correcte, en interrogeant de temps en temps des serveurs SNTP (dans le
tourniquet du réservoir <a href="http://www.pool.ntp.org/fr/">pool.ntp.org</a> par défaut)
et en détectant les dérives entre routeurs au niveau de la couche transport.
</p>
<p>
2011-03-15 11:32:58 +00:00
Autres remarques importantes.
<ul>
<li>
2011-03-15 11:32:58 +00:00
<b>Jeux de baux non publiés et cryptés:</b>
<p>
2011-03-15 11:32:58 +00:00
On pourrait souhaiter que seulement une personne particulière puisse joindre une certaine destination.
Ceci est possible par la non publication de la destination dans la base de données.
Il faudra alors transmettre la destination par quelqu'autre moyen. Ou alors en utilisant des jeux de baux
cryptés, uniquement décryptables par les gens pour lesquels ils ont été cryptés.
</p>
</li>
<li>
2011-03-15 11:32:58 +00:00
<b>Amorçage:</b>
<p>
2011-03-15 11:32:58 +00:00
L'amorçage de la base de données est assez simple. Une fois qu'un routeur réussit à recevoir la routerInfo
d'un seul autre pair joignable, il peut interroger ce routeur pour obtenir les informations d'autres routeurs
du réseau. Actuellement, bon nombre d'utilisateurs publient leur routerInfo files sur un site web
pour rendre cette information disponible. I2P se connecte automatiquement à l'un de ces sites pour
collecter des fichiers routerInfo files et d'amorcer.
</p>
</li>
<li>
2011-03-15 11:32:58 +00:00
<b>Adaptativité des recherches:</b>
<p>
2011-03-15 11:32:58 +00:00
Les recherches dans le réseau I2P ne sont pas transmises à d'autres routeurs de la base de données.
Actuellement, ce n'est pas un problème majeur, dans la mesure où le réseau n'est pas très grand.
Cependant, au fur et à mesure de sa croissance, chaque routeur n'aura pas toutes les routerInfo et tous
les jeux de baux de tout le réseau. Ceci provoquera une dégradation du pourcentage de requêtes réussies.
Pour ceci, des améliorations de la base de données sont au programme des prochaines versions.
</p>
</li>
</ul>
</p>
2011-03-15 11:32:58 +00:00
<h2 id="op.transport">Protocoles de transport</h2>
2011-03-15 20:54:03 +00:00
<p> Les communications entre routeurs doivent apporter confidentialité et intégrité
contre des menaces externes tout en certifiant que le routeur contacté est bien celui
qui doit recevoir un message donné. Les particularités sur la façon dont les routeurs communiquent
les uns avec les autres ne sont pas critiques: trois protocoles distincts ont été retenus
pour répondre à ces exigences. </p>
<p> I2P commença avec un protocole basé sur TCP qui depuis a été désactivé.
Puis, pour résoudre le problème du besoin élevé en terme de nombre de communications
(vu qu'un grand nombre de routeurs peuvent cesser de parler avec plusieurs autres), I2P a migré
de TCP vers un protocole <a href="udp.html">basé sur UDP</a> - "Secure
Semireliable UDP", UDP Sécurisé Semi-fiable, ou "SSU". </p>
<p> Comme expliqué dans la <a href="udp.html">spécification de SSU</a>:</p>
<blockquote> Le but de ce protocole est de fournir une livraison sécurisée, authentifiée,
semi-fiable, et non ordonnée, dévoilant uniquement une quantité minimale de données facilement
2011-03-21 11:22:48 +00:00
discernables par les tierces parties. Il doit tolérer un fort taux de communications
2011-03-15 20:54:03 +00:00
tout comme le contrôle de congestion TCP, et inclure la découverte MTU
<a href="http://fr.wikipedia.org/wiki/Path_MTU_discovery">PMTU</a>.
Il doit pouvoir transférer efficacement des données en vrac à un débit suffisant pour l'utilisation résidentielle.
De plus, il doit être compatible avec les techniques de contournement d'obstacles du le réseau
tels que les translateurs d'adresses (NAT) ou les pare-feux. </blockquote>
<p> Suite à l'introduction de SSU, après l'apparition de problèmes de congestion, un nouveau
transport TCP basé sur les <a href="http://en.wikipedia.org/wiki/New_I/O">NIO Java</a> appelé
<a href="ntcp.html">NTCP</a> fut implémenté.
Il est activé pour les connexions sortantes uniquement. Ceux qui configurent leur pare-feu/NAT
pour autoriser les connexions entrantes et précisent l'hôte et le port (même en style DynDNS, etc...)
dans la configuration peuvent recevoir des connexions entrantes.
2011-03-21 11:22:48 +00:00
Comme NTCP est bâti avec les NIO il n'est pas astreint au problème de "une connexion=une tâche" dont souffrait
2011-03-15 20:54:03 +00:00
l'ancien transport TCP. </p>
<p> I2P permet de multiples transports simultanément. Un transport particulier pour une connexion sortante
2011-03-16 20:58:34 +00:00
est sélectionné par des enchères. Chaque transport fait une offre pour obtenir la connexion, et la valeur relative
de l'offre décide de la priorité. Les transports peuvent répondre avec des offres différentes,
2011-03-15 20:54:03 +00:00
suivant s'il y a déjà une connexion établie avec le pair. </p>
<p> L'implémentation actuelle attribuent la plus haute priorité de transport à NTCP pour les connexions sortantes
dans la plupart des cas. SSU est activé à la fois pour les connexions sortantes et entrantes. Votre pare-feu/NAT
et votre routeur I2P doivent être configurés pour autoriser les connexions entrantes NTCP.
Voir les détails <a href="ntcp.html">ici</a> sur la page NTCP. </p>
<h2 id="op.crypto">Cryptographie</h2>
<p> Un petit minimum d'algorithmes cryptographiques de base sont combinés pour fournir
à I2P les protections étagées contre diverses menaces. Au niveau le plus bas, la communication inter routeurs
est protégée par la sécurité de la couche transport: SSU crypte chaque paquet avec
l'<a href="http://fr.wikipedia.org/wiki/Advanced_Encryption_Standard">AES</a>256/
<a href="http://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_%28cryptographie%29#
Encha.C3.AEnement_des_blocs_:_.C2.AB_Cipher_Block_Chaining_.C2.BB_.28CBC.29">CBC</a>
conjugué à un vecteur d'initialisation explicite et un code d'authentification de message
(<a href="http://fr.wikipedia.org/wiki/Keyed-Hash_Message_Authentication_Code">HMAC</a>-MD5-128) après
négociation préalable d'une clé de session via un échange
<a href="http://fr.wikipedia.org/wiki/Diffie-Hellman">Diffie-Hellman</a> à 2048 bits et
une authentification mutuelle avec la clé <a href="http://fr.wikipedia.org/wiki/Digital_Signature_Algorithm">DSA</a>
de l'autre routeur,
plus une vérification locale d'intégrité avec le propre hachage du message.
Les messages de <a href="#op.tunnels">tunnel</a> passés par les transports
disposent de leur propre cryptage étagé en AES256/CBC à VI explicite et sont vérifiés
au point terminal du tunnel à l'aide d'un hachage <a href="http://fr.wikipedia.org/wiki/SHA-256">SHA256</a>
2011-03-21 11:22:48 +00:00
supplémentaire. Divers autres messages sont passés regroupés dans des "garlic messages",
2011-03-15 20:54:03 +00:00
qui sont cryptés en
<a href="http://fr.wikipedia.org/wiki/Cryptosyst%C3%A8me_de_ElGamal">ElGamal</a>/AES+SessionTags
(expliqués ci-dessous).</p>
<h3 id="op.garlic">Messages "Garlic" : en têtes d'ail</h3>
<p> Ces messages sont une extension du cryptage "onion" en couches, permettant aux contenus d'un seul message
de contenir plusieurs "gousses", des messages complets juxtaposés à leurs propres instructions de livraison.
Les messages sont empaquetés chaque fois qu'il seraient sinon passés en clair au travers d'un pair qui n'aurait pas
accès aux informations de routage: par exemple, quand un routeur veut demander à un autre de participer à un
tunnel, ils ajoutent la requête dans un garlic qu'il cryptent à l'intention du routeur destinataire avec sa
clé publique ElGamal 2048 bits publiée dans son jeu de baux, et le font suivre dans un tunnel. Dans un autre
exemple, un client veut envoyer un message à une destination: le routeur du client va joindre ce message de
2011-03-21 11:22:48 +00:00
données (à côté de quelques autres messages) dans un garlic qu'il crypte en ElGamal 2048 à l'intention de la
2011-03-15 20:54:03 +00:00
destination avec sa clé publiée dans son jeu de baux, et l'envoie aux tunnels appropriés.</p>
2011-03-21 11:22:48 +00:00
<p> Les "instructions" attachées à chaque gousse dans la couche de cryptage incluent la possibilité
2011-03-15 20:54:03 +00:00
de demander que cette gousse soit transmise localement, à un routeur distant, ou à un tunnel distant sur un routeur
distant. Il y a des champs dans ces instructions permettant à un pair de demander que la livraison soit retardée
2011-03-21 11:22:48 +00:00
un certain temps ou jusqu'à ce qu'une condition soit remplie, bien qu'ils ne seront pas pris en compte avant que
les <a href="#future.variablelatency">retards variables</a> soient déployés. Il est possible
2011-03-15 20:54:03 +00:00
de router explicitement les messages en tête d'ail sur n'importe quel nombre de sauts sans construire de tunnels,
2011-03-21 11:22:48 +00:00
ou même de rerouter les messages de tunnels en les joignant à un garlic et en le faisant suivre à un certain
2011-03-15 20:54:03 +00:00
nombre de saut avant de le passer au saut suivant du tunnel, mais ces techniques ne sont pas actuellement utilisées
dans l'implémentation en cours. </p>
<h3 id="op.sessiontags">Balises de session</h3>
2011-03-21 11:22:48 +00:00
<p> En tant que système orienté messages non fiable et non ordonné, I2P utilise une simple combinaison
d'algorithmes de cryptage symétriques et asymétriques pour apporter la confidentialité et l'intégrité
2011-03-16 10:37:40 +00:00
des données aux messages garlics. Considérée comme un tout, la combinaison est appelée ElGamal/AES+SessionTags,
mais c'est un poil trop verbeux pour décrire une simple utilisation d'ElGamal 2048 bits, d'AES256, d'SHA256,
et de vecteurs d'initialisation de 32 octets. </p>
<p> La première fois qu'un routeur veut crypter un message garlic à l'usage d'un autre routeur,
il crypte les données de clés d'une session AES256 avec ElGamal et joint la charge utile cryptée en AES256/CBC
2011-03-21 11:22:48 +00:00
après le bloc crypté avec ElGamal. En plus de la charge utile cryptée, la section encryptée en AES contient
2011-03-16 10:37:40 +00:00
la longueur de la charge utile, le hachage de la charge non cryptée, ainsi qu'un certain nombre de balises de
session de 32 octets aléatoires. La fois suivante, plutôt que de crypter une nouvelle clé de session en ElGamal,
2011-03-21 11:22:48 +00:00
il va simplement prendre une des balises précédemment envoyées et crypter la charge en AES comme avant en utilisant
2011-03-16 10:37:40 +00:00
la clé de session associée à la balise, et préfixer la charge cryptée avec la balise. Quand un routeur reçoit
un message garlic, il cherche si les 32 premiers octets correspondent à une balise déjà disponible, auquel cas il
2011-03-21 11:22:48 +00:00
décryptent l'AES. En l'absence de correspondance, il décryptent le premier bloc en ElGamal.</p>
2011-03-16 10:37:40 +00:00
<p> Chaque balise de session est à usage unique, tant pour empêcher une attaque interne de mettre en corrélation
différents messages, que venant d'un point situé entre les mêmes routeurs. L'émetteur d'un message crypté
2011-03-21 11:22:48 +00:00
ElGamal/AES+SessionTag choisit quand et combien de balises il faut envoyer pour en fournir suffisamment au
destinataire afin de couvrir les besoins nécessaires au transfert d'un bouquet de messages.
2011-03-16 10:37:40 +00:00
Les messages garlics peuvent détecter la livraison correcte de balises en joignant un petit message supplémentaire
en tant que gousse (un accusé de réception): quand la tête d'ail arrive au destinataire prévu et est décryptée
avec succès, ce petit message de réussite pré fourni est un de ceux dévoilés dans la gousse, et il contient
les instructions pour le destinataire pour la renvoyer à l'émetteur (via un tunnel entrant, évidement).
Quand celui-ci reçoit ce message d'état de livraison, il sait que les balises de session ont bien été reçues.</p>
<p>Les balises ont une très courte durée de vie, passée laquelle elles sont invalidées faute d'avoir été utilisées.
De plus, leur nombre pour chaque clé est limité, tout comme le nombre de clés lui-même:
s'il en arrive trop, des messages récents ou plus anciens pourraient être perdus. L'émetteur fait un suivi
des messages qui utilisent les balises pour s'assurer qu'ils passent, et dans le cas contraire il se replie sur
l'algorithme ElGamal plus coûteux.</p>
<p> Une alternative consiste à ne transmettre qu'une seule balise de session, et de là,
initialiser un
<a href="http://fr.wikipedia.org/wiki/G%C3%A9n%C3%A9rateur_de_nombres_pseudo-al%C3%A9atoires">
générateur de nombres pseudo-aléatoires</a> (PRNG) déterministe pour déduire quelles balises utiliser ou attendre.
En tenant ce générateur sommairement synchronisé entre l'émetteur et le destinataire (qui calcule par anticipation
par exemple une cinquantaine de balises), la surcharge induite par la fourniture périodique d'un grand nombre de
balises est supprimée, permettant ainsi plus d'options d'arbitrage dans l'espace et le temps, et éventuellement
la réduction du nombre d'encryptages ElGamal nécessaires. Cependant, il dépend de la robustesse du générateur de
fournir la protection contre les menaces internes, bien qu'on puisse minimiser toute faiblesse en limitant le
nombre d'utilisations de chaque générateur. Pour l'instant, il n'a pas de plans immédiats de migration vers ce
système de PRNGs synchronisés. </p>
<h1 id="future">L'avenir</h1>
<p> Bien qu'I2P soit actuellement opérationnel et suffisant dans de nombreux scenarii, il reste plusieurs zones qui
demandent de profondes améliorations pour atteindre les besoins de ceux devant faire face à des adversaires
puissants comme pour l'amélioration de l'utilisation quotidienne par les utilisateurs.
</p>
2011-03-16 10:37:40 +00:00
<h2 id="future.restricted">Les routes réservées</h2>
2011-03-17 21:58:46 +00:00
<p> I2P est une "sur-couche" réseau conçue pour fonctionner sur un réseau commuté par paquets,
2011-03-16 10:37:40 +00:00
exploitant la notion de "point à point" pour offrir l'anonymat et la sécurité.
Alors qu'Internet ne respecte plus le principe du bout en bout (à cause de l'utilisation du NAT),
2011-03-21 11:22:48 +00:00
I2P requiert qu'une portion substantielle du réseau soit joignable: il pourrait y avoir un bon nombre
2011-03-16 10:37:40 +00:00
de pairs utilisant des routes privées, mais I2P n'inclut pas d'algorithme de routage approprié à un scenario
de dégradation dans lequel la plus grande partie des pairs seraient injoignables. Il pourrait cependant fonctionner
sur un réseau utilisant un tel algorithme. </p>
<p> L'utilisation de routes réservées, où il y a des limites aux pairs joignables directement,
induit plusieurs conséquences sur le fonctionnement et l'anonymat, suivant la façon selon laquelle ces routes
sont gérées. Au niveau le plus basique, des routes réservées sont présentes quand un pair se trouve derrière
un pare-feu ou un NAT qui ne permet pas les connexions entrantes. Ceci a été grandement pris en compte depuis la
0.6.0.6 en intégrant le percement de trous distribué dans la couche transport, permettant ainsi aux gens situés
2011-03-21 11:22:48 +00:00
derrière la plupart de pare-feux ou NATs de recevoir des connexions non sollicitées sans aucune configuration.
2011-03-16 20:58:34 +00:00
Cependant, ceci ne réduit pas l'exposition de l'adresse IP du pair aux routeurs du réseau,
car ils peuvent être présentés au pair au travers de l'intermédiaire publié.</p>
<p> Au-delà de la gestion fonctionnelle des routes privées, il y a deux niveaux d'opérations privées qui peuvent être
mis en œuvre pour limiter l'exposition des adresses IP: l'utilisation de tunnels dédiés à la communication et de
2011-03-21 11:22:48 +00:00
'routeurs clients'. Pour le premier, les routeurs peuvent soit construire un nouveau groupe de tunnels ou
2011-03-16 20:58:34 +00:00
réutiliser leur groupe exploratoire, en publiant les passerelles entrantes vers quelques-uns d'entre eux en tant
que partie de leur routerInfo au lieu de leur adresse de transport. Quand un pair veut les contacter, il voit
ces passerelles de tunnel dans la base de données et leur envoient simplement le message concerné via un des tunnels
publiés. Si le pair situé derrière une route privée veut répondre, il peut le faire soit directement (s'il acceptent
de dévoiler leur adresse IP au pair) ou indirectement via leurs tunnels sortants. Quand les routeurs
auxquels le pair a une connexion directe veulent le joindre (p.e. pour faire suivre des messages de tunnels), ils
doivent simplement prioriser leur connexion directe par rapport à la passerelle de tunnels publiée.
Le concept de 'routeur client' étends simplement la route réservée en ne publiant aucune adresse de routeur.
Un tel routeur n'aurait même plus besoin de publier leur routerInfo dans la netDb, mais plutôt de fournir leur
leur routerInfo auto-signée aux pairs qu'il contacterait (nécessaire au transfert de ses clés publiques).
Ces deux niveaux d'opération sur routes privées sont prévus pour la version 2.0 d'I2P. </p>
<p> Il y a des choix à établir pour ceux situés sur des routes privées, vu qu'ils participeraient moins souvent aux
tunnels des autres utilisateurs, et que les routeurs auxquels ils sont connectés pourraient déduire des motifs
de trafic qui ne sont normalement pas exposés. D'un autre côté, si le coût de cette exposition est inférieur à
celui de rendre l'adresse IP disponible, cela peut être intéressant. Ceci, bien sûr, suppose que les pairs contactés
par celui qui est derrière une route réservée ne soient pas hostiles, ou que le réseau soit assez grand pour que la
2011-03-21 11:22:48 +00:00
probabilité de tomber sur un pairs hostile pour se connecter soit suffisamment faible. On pourrait aussi préférer
2011-03-16 20:58:34 +00:00
utiliser des pairs de confiance (et peut-être temporaires).</p>
<h2 id="future.variablelatency">Latence variable</h2>
<p> Même si le gros des efforts initiaux d'I2P ont porté sur une communication à faible latence,
il fut dès le départ conçu en gardant à l'esprit des services à latence variable.
Au niveau le plus bas, les applications s'exécutant sur I2P peuvent offrir l'anonymat du médium des communications
2011-03-21 11:22:48 +00:00
à haute latence tout en mêlant leurs motifs de trafic à du trafic à faible latence. En interne cependant,
I2P peut offrir son propre médium et une haute latence de communication via le cryptage garlic en tête d'ail:
2011-03-16 20:58:34 +00:00
en spécifiant que le message doit être envoyé après un certain délai, à un certain moment, après le passage d'un
certain nombre de messages, ou une autre stratégie combinant ces éléments. Avec le cryptage en couches,
seul le routeur pour lequel la gousse a dévoilé la requête de retard saura que le message demande une haute
2011-03-21 11:22:48 +00:00
latence, au trafic correspondant d'être mélangé ultérieurement à du trafic à faible latence. Une fois la condition
2011-03-16 20:58:34 +00:00
de transmission atteinte, le routeur retenant la gousse (qui peut aussi bien être un message garlic) le fait
simplement suivre comme demandé: à un routeur, à un tunnel, ou plus probablement à une destination cliente.</p>
<p> Il y a un nombre conséquent de manières d'exploiter cette possibilité pour les communications à haute latence
dans I2P, mais pour l'instant, son utilisation est planifiée pour la version 3.0. En attendant, ceux qui ont besoin
de l'anonymat offert par les communications à latence élevée peuvent se tourner vers la couche applicative pour
l'obtenir.</p>
<h2 id="future.open">Questions ouvertes</h2>
<pre>
2011-03-21 11:22:48 +00:00
Comment se débarrasser de la contrainte de temps?
Y a-t-il un moyen plus efficace de gérer les balises de session?
2011-03-16 20:58:34 +00:00
Quelles stratégies de regroupement/mélange devraient-elles être disponibles dans les tunnels?
Quelles autre stratégies de sélection/tri des pairs de tunnels devrait-elles être disponibles?
</pre>
2011-03-16 20:58:34 +00:00
<h1 id="similar">Systèmes similaires</h1>
<p> L'architecture d'I2P repose sur les concepts de logiciel intermédiaire orienté messages, de topologie de table
de hachage décentralisée, de l'anonymat et de la cryptographie des réseaux croisés à routes libres et de
l'adaptabilité des réseaux à paquets commutés. L'apport ne vient cependant pas de nouveaux concepts d'algorithmes,
mais de l'analyse attentive des résultats de recherches et documentations des systèmes existants.
Bien qu'il y ait peu d'efforts similaires qui vaillent d'être analysés en détail, tant au niveau technique que
fonctionnel, il en est néanmoins deux qui sortent du lot: Tor et Freenet.</p>
<p> Voir aussi la page de <a href="how_networkcomparisons.html">comparaisons des réseaux</a>.
</p>
<h2 id="similar.tor">Tor</h2>
2011-03-20 14:48:19 +00:00
<p><i><a href="http://www.torproject.org/">Site officiel</a></i></p>
2011-03-16 20:58:34 +00:00
<p>Au premier coup d'œil, Tor et I2P ont plusieurs ressemblances fonctionnelles et d'anonymat.
Bien que le développement d'I2P ait commencé avant que nous ne fussions au courant des premières étapes du travail
sur Tor, plusieurs des leçons du travail d'origine du routage en oignon et de ZKS furent intégrées
dans sa conception. Plutôt que de construire un système centralisé de confiance, avec des serveurs d'annuaires, I2P
2011-03-21 11:22:48 +00:00
dispose d'une base de données réseau auto-organisée dans laquelle chaque pair assume la responsabilité du profilage
2011-03-16 20:58:34 +00:00
des autres routeurs pour déterminer la meilleure façon d'exploiter les ressources disponibles. Une autre différence
majeure réside dans le fait que bien qu'utilisant tous les deux des chemins étagés et ordonnés, I2P est
fondamentalement un réseau à commutation de paquets alors que Tor est un réseau à commutation de circuits, ce qui
permet à I2P de contourner de façon transparente les congestions et autres défaillances du réseau, de gérer des
chemins redondants, et de faire de l'équilibrage de charge sur les ressources disponibles.
Si Tor offre nativement la fonctionnalité très utile de découverte et de sélection de mandataire de sortie
2011-03-19 08:28:04 +00:00
(outproxy), I2P délègue cette décision de couche applicative... aux applications: dans les faits, I2P a même
externalisé vers la couche applicative la bibliothèque de flux (streaming) "style TCP" permettant ainsi aux
développeurs d'expérimenter diverses stratégies afin d'en tirer les meilleures performances.</p>
2011-03-17 21:58:46 +00:00
<p> Du point de vue de l'anonymat, la comparaison du cœur des réseaux présente beaucoup de similarités.
2011-03-18 19:09:33 +00:00
Il y a malgré tout quelques différences fondamentales. Pour la prise en compte des menaces internes et de la
2011-03-17 21:58:46 +00:00
plupart des menaces externes, les tunnels simplex d'I2P n'exposent au plus que la moitié des données de trafic
que ne le font les circuits duplex de Tor, rien qu'au niveau de l'observation des flux: une requête HTTP et sa
réponse suivent le même chemin dans Tor, alors que dans I2P, les paquets constituant la requête passent par un ou
2011-03-21 11:22:48 +00:00
plusieurs tunnels sortants, et ceux de la réponse empruntent un ou plusieurs tunnels entrants.
2011-03-19 07:53:55 +00:00
Les stratégies de sélection et de tri des pairs dans I2P entrave suffisamment les attaques par prédécesseur,
mais il peut aussi mimer les tunnels duplex de Tor en créant les tunnels entrants et sortants en suivant les
mêmes routeurs.</p>
2011-03-19 08:28:04 +00:00
<p> Une autre faille d'anonymat dans Tor vient de la création télescopique de tunnels: le comptage et les mesures de
2011-03-20 11:33:46 +00:00
timing des paquets dans un circuit passant à travers le nœud ennemi lui permettent l'extraction de données
2011-03-21 11:22:48 +00:00
statistiques pouvant lui révéler sa position dans le circuit. Dans I2P, la création de tunnels unidirectionnels
2011-03-19 07:53:55 +00:00
en un seul message masque cette information. La confidentialité de la position occupée dans un tunnel est
importante car un attaquant pourrait profiter de cette donnée pour lancer une série d'attaques de prédécesseur,
d'intersection, et de confirmation de trafic.
</p>
2011-03-19 07:53:55 +00:00
<p> Le deuxième niveau de mandataires "oignons" de Tor apporte un bon anonymat à faible coût d'entrée, alors q'I2P
ne permettra pas cette topologie avant la version <a href="#future.restricted">2.0</a>. </p>
<p> Globalement, Tor et I2P se complètent mutuellement: Tor se focalise sur la mise à disposition de mandataires
sortants rapides et anonymes, et I2P s'oriente vers un réseau robuste et décentralisé. En théorie, chacune de ces
deux approches sont destinées à des fins différentes, mais étant donné les faibles ressources en développement,
2011-03-21 11:22:48 +00:00
elles ont chacune leurs propres forces et faiblesses. Les développeurs d'I2P ont étudié les étapes nécessaires
2011-03-19 08:28:04 +00:00
à la modification de Tor pour qu'il puisse bénéficier de la conception d'I2P, mais les inquiétudes quand à la
2011-03-20 09:59:34 +00:00
viabilité de Tor en régime de ressources raréfiées suggèrent que l'architecture à commutation de paquets choisie
par I2P est à même d'exploiter plus efficacement des ressources rares. </p>
<h2 id="similar.freenet">Freenet</h2>
2011-03-19 07:53:55 +00:00
<p><i><a href="http://www.freenetproject.org/">Le site</a></i></p>
2011-03-19 08:28:04 +00:00
<p> Freenet a largement contribué aux premières étapes de conception d'I2P, en donnant la preuve de la viabilité
d'une communauté enthousiaste entièrement contenue dans un réseau et en démontrant que les dangers inhérents aux
2011-03-19 08:13:04 +00:00
mandataires sortants pouvaient être évités. La première graine d'I2P germa en tant que couche de communication
2011-03-20 09:59:34 +00:00
pour Freenet visant à séparer les complexités d'une communication point à point sécurisée, anonyme et adaptable,
de celles d'un réservoir de données décentralisé et résistant à la censure.
Le temps passant, les problèmes d'anonymat et d'adaptabilité intrinsèques des algorithmes retenus pour la
conception de Freenet confirmèrent que la visée d'I2P devait strictement s'en tenir à fournir une couche
de communication banalisée plutôt que de rester un composant de Freenet. Après quelques années, les développeurs de
Freenet furent amenés à reconnaître les faiblesses de cette conception déjà fort ancienne qui les conduisait à
y répondre en proposant une couche de "pré-mélange" pour obtenir un anonymat plus solide. En d'autres termes,
Freenet a besoin de fonctionner sur un réseau croisé tel que Tor ou I2P, les nœuds clients demandant et publiant
2011-03-21 11:22:48 +00:00
les données via le réseau croisé sous-jacent sur les nœuds serveurs qui ensuite les ramènent et les stockent
2011-03-20 09:59:34 +00:00
conformément à ses propres algorithmes heuristiques de stockage distribué. </p>
<p> La fonctionnalité de Freenet est très complémentaire à celle d'I2P, car il apporte nativement plusieurs des
outils nécessaires aux systèmes à haute et moyenne latence, quand de son côté I2P apporte le réseau croisé à
faible latence adapté au niveau d'anonymat attendu. La logique de séparation du réseau croisé et du stockage
2011-03-20 11:33:46 +00:00
distribué résistant à la censure paraissant toujours pertinente d'un point de vue de l'allocation des ressources,
de la sécurité, de l'anonymat et de l'ingénierie, on peut espérer que l'équipe de Freenet persévère dans cette
voie, si ce n'est simplement en réutilisant (ou en améliorant, au besoin) des réseaux croisés existants tels qu'I2P
ou Tor.</p>
2011-03-20 09:59:34 +00:00
<p> Il est intéressant de signaler ici les débats et travaux des développeurs de Freenet concernant un "réseau masqué
2011-03-20 11:33:46 +00:00
globalement adaptable" qui utiliserait des routes privées entre pairs ayant des relations de confiance
disparates. Comme l'insuffisance des informations rendues publiques sur la façon de parvenir à faire fonctionner
un tel système empêche d'en faire une analyse exhaustive, les prétentions annoncées en terme d'anonymat et
d'adaptabilité doivent être prises avec beaucoup de réserve. En particulier la pertinence de son utilisation en
2011-03-21 11:22:48 +00:00
milieu hostile peuplé d'adversaires sur-vitaminés a été énormément surestimée, et toute analyse des conséquences de
2011-03-20 11:33:46 +00:00
la rareté des ressources sur l'adaptabilité du réseau a visiblement été oubliée. Restent aussi des questions sur la
vulnérabilité à l'analyse de trafic, la confiance et d'autres sujets, mais l'analyse en profondeur de ce "réseau
croisé globalement adaptable" devra attendre que l'équipe de Freenet en publie la documentation.</p>
2011-03-20 11:33:46 +00:00
<h1 id="app">Appendice A: La couche applicative</h1>
<p>
2011-03-20 11:33:46 +00:00
I2P en lui-même ne fait pas grand chose: il envoie simplement des messages à des destinations distantes et reçoit
des messages pour le compte de destinations locales. Le travail le plus intéressant se passe dans les étages
supérieur. En soi, I2P peut être considéré en tant que couche IP anonyme et sécurisée, et la
<a href="#app.streaming">bibliothèque de flux</a> fournie, comme un étage supérieur TCP anonyme et sécurisé.
Ensuite, <a href="#app.i2ptunnel">I2PTunnel</a> propose un système de délégation générique pour entrer et sortir du
réseau I2P, ainsi qu'une fournée d'applications réseau destinées à donner plus de fonctionnalités aux
utilisateurs.
</p>
2011-03-20 11:35:06 +00:00
<h2 id="app.streaming">Bibliothèque de flux (streaming)</h2>
2011-03-20 14:48:19 +00:00
<p>
La bibliothèque de flux d'I2P peut être considérée comme une interface pour les flux (des connecteurs TCP
en mirroir), et la mise en œuvre prend en charge un
<a href="http://en.wikipedia.org/wiki/Sliding_Window_Protocol">protocole à fenêtre glissante</a> doté de plusieurs
optimisations pour tenir compte du haut délai sur I2P. Les flux individuels peuvent ajuster la taille maximum des
des paquets ainsi que d'autres options, bien que les 4 ko compressés par défaut semblent un choix raisonnable
pour le coût en bande passante de la retransmission des messages perdus et la latence de messages multiples.
</p>
<p>
2011-03-20 14:48:19 +00:00
De plus, au regard du coût assez élevé des messages subséquents, le protocole de planification et de livraison de
la bibliothèque a été optimisé pour faire en sorte que les messages individuels transférés contiennent le plus
possible de l'information disponible. Par exemple, une petite transaction HTTP mandatée par la bibliothèque
peut être pliée en un unique aller-retour: le premier message embarque le SYN, le FIN et la petite charge utile (
une requête HTTP y contient en général), et la réponse contient le SYN, le FIN et le ACK, et aussi la petite charge
(plusieurs réponses HTTP tiennent dans la boîte de sardines). Lorsque un ACK supplémentaire doit être transmis pour
indiquer au serveur que le SYN/FIN/ACK a été reçu, le proxy HTTP local peut immédiatement livrer la réponse
complète au navigateur.</p>
<p>
2011-03-20 14:48:19 +00:00
Globalement, cependant, la bibliothèque de flux revêt beaucoup de ressemblance avec le modèle de TCP avec ses
fenêtres glissantes, ses algorithmes de contrôle de congestion (démarrage lent et évitement), et le comportement
général des paquets (ACK, SYN, FIN, RST, etc...)</p>
2011-03-21 11:22:48 +00:00
<h2 id="app.naming">Bibliothèque de nommage et carnet d'adresses</h2>
2011-04-24 12:29:30 +00:00
<p><i> <a href="naming_fr.html">Détails avancés</a></i></p>
2011-03-21 11:22:48 +00:00
<p><i>Développés par mihi et Ragnarok</i></p>
<p> Le nommage dans I2P a dès les tout débuts fait l'objet de nombreux débats entre les tenants de chaque
possibilités. Cependant, étant donné les demandes de communication sécurisée et de fonctionnement décentralisé aux
principe d'I2P, les traditionnels systèmes du type DNS comme ceux fondés sur des votes à la majorité furent
mis hors-jeu. En lieu et place, I2P s'appuie sur une bibliothèque de fonctions de nommage et une implémentation
de base conçue pour un fonctionner indifféremment grâce à une correspondance entre un nom local et une destination
ou à une application compagnon appelée "carnet d'adresses" (addressbook). Le carnet d'adresses est un système de
nommage sécurisé accessible au lecteur humain, décentralisé et piloté par un réseau de confiance, sacrifiant
uniquement la nécessité des noms humainement lisibles d'être globalement uniques, en n'exigeant seulement que
l'unicité locale. Comme tous les messages dans I2P sont référencés cryptographiquement par leur destination,
des personnes différentes peuvent avoir dans leur propre carnet d'adresses une entrée pour "Alice" se rapportant
à une destination différente. Les utilisateurs peuvent toujours trouver de nouveaux noms en important les carnets
d'adresses publics des pairs spécifiés dans leur réseau de confiance, en ajoutant les entrées procurées par un
tiers ou (si quelques uns organisent une série de carnets publiés en se servant d'une méthode d'enregistrement
premier entré premier servi) ils peuvent décider de considérer ces carnets d'adresses comme des serveurs de noms
fonctionnant à la façon du DNS habituel.</p>
<p> Cependant, I2P ne préconise pas l'utilisation de services semblables à DNS, car les dégâts causé par un
détournement de site peuvent être énormes - et les destinations non sécurisées n'ont aucune valeur.
DNSsec lui-même repose sur les registrars et les autorités de certification, alors qu'avec I2P, les requêtes
envoyées ne peuvent être interceptées ni leurs réponses usurpées car cryptées pour la destination qui n'est elle-
même qu'une paire de clés publiques et un certificat. Les systèmes de style DNS permettent à tout serveur de noms
situé dans le chemin de la requête de lancer des attaques de dénis de service et d'usurpations. L'adjonction aux
réponses d'un certificat les authentifiant signé par quelque autorité de certification centrale résoudrait
le problème de serveur de nom hostile sans apporter de solutions à ceux des attaques de replay ni à l'hypothèse de
l'autorité de certification hostile.</p>
<p> Le nommage par votes est dangereux lui aussi, étant donné l'efficacité des attaques de Sibylle dans les systèmes
anonymes: un attaquant peu créer des pairs en nombre suffisant pour s'assurer l'attribution d'un nom donné.
On pourrait utiliser des méthodes "Proof-of-work" pour donner un prix à l'identité, mais à mesure de la croissance
du réseau, le besoin de contacter tout le monde pour organiser un vote en ligne rendrait la charge du réseau
inenvisageable. Et renoncer à interroger tout le réseau conduirait à avoir différents jeux de réponses.</p>
<p> Comme avec Internet cependant, I2P maintient la structure et le fonctionnement d'un système de nommage en dehors
de la couche de communication (elle-même reprise du modèle IP, comme décrit plus haut). La bibliothèque fournie
inclut une interface de fournisseur de service permettant d'utiliser d'autres systèmes de nommage en fonction
des préférences des utilisateurs.</p>
<h2 id="app.syndie">Syndie</h2>
2011-03-21 11:22:48 +00:00
<p><i> Le vieux Syndie fourni avec I2P a été remplacé par un nouveau qui est distribué séparément.
Voir la page <a href="http://syndie.i2p2.de/">Syndie</a>.</i></p>
<p> Syndie est un système d'agrégation/publication/blogage anonyme et sécurisé. Vous pouvez créer de l'information,
la partager, et lire celle venant de qui vous intéresse, tout ça en prenant en compte vos besoins en sécurité et en
anonymat. Plutôt que d'utiliser un réseau de distribution de contenu spécifique, Syndie est conçu pour fonctionner
sur des réseaux existant, en réalisant la publication via les sites eep, les services Tor masqués, les freesites
Freenet, les sites Internet normaux, les newsgroups de Usenet, les listes de messagerie, les sources RSS, etc...
Les données sont publiées pour permettre le respect de la consultation et de l'archivage via une authentification
par pseudonyme.</p>
<h2 id="app.i2ptunnel">I2PTunnel</h2>
2011-03-21 11:22:48 +00:00
<p><i>Développé par mihi</i></p>
<p> I2PTunnel est assurément l'application I2P la plus appréciée et la plus polyvalente, de part sa capacité à
fournir un mandatement générique pour l'entrée et la sortie du réseau I2P. On peut se représenter I2PTunnel comme
quatre applications mandataires indépendantes: un "client" qui reçoit les connexions TCP et les transfère à une
destination I2P particulière, un "client http" (eepproxy) faisant office de mandataire HTTP qui transfère les
requêtes à la destination appropriée (après une éventuelle recherche dans le service de nommage), un "serveur" qui
reçoit les connexions de flux entrantes à une destination et les transfère au port/hôte TCP voulu et un "serveur
HTTP" qui étend le "serveur" en décortiquant les requêtes et les réponses pour permettre un fonctionnement plus
sûr. Il y a aussi une application "client socks", mais son utilisation est déconseillée pour les raisons
précédemment signalées.</p>
<p> I2P <b>n'est pas</b> un réseau mandataire de sortie: les préoccupations de sécurité et d'anonymat au cœur d'un
réseau croisé qui échange des données avec le monde extérieur ont centré la conception d'I2P pour qu'elle ne dérive
pas de ces préoccupations, et donc ne nécessite pas l'accès à des ressources externes. Cependant, le "client HTTP"
offre une possibilité de connexion pour du mandatage sortant: si le nom d'hôte demandé ne finit pas en ".i2p", elle
sélectionne aléatoirement une destination dans un groupe de mandataires sortants fournis par l'utilisateur et lui
transfère la requête. Ces destinations sont de simples instances de "serveur" I2PTunnel exécutées par des
volontaires ayant délibérément décidé de fonctionner en mandataire sortant. Personne n'est dans ce cas par défaut,
et rien n'indique automatiquement aux autres de passer votre proxy si vous avez décidé de jouer ce rôle.
Bien que les mandataires sortants soient intrinsèquement porteurs de faiblesses, ils démontrent la faisabilité
de l'utilisation d'I2P pour certaines utilisations dans lesquelles le modèle de sécurité resterait suffisant pour
certains utilisateurs.</p>
<p> I2PTunnel active l'utilisation de la plupart des applications. Un "serveur HTTP" pointant sur un serveur web
permet à chacun d'avoir son propre site web anonyme (appelé "eepsite"): un serveur web est fourni avec I2P à cet
effet, mais on peut utiliser n'importe lequel. Chacun peut utiliser un "client" pointant vers un des serveurs IRC
hébergés anonymement, chacun d'entre eux pointant vers son service local IRC et communicant entre services avec
leur propre tunnels "clients". Les utilisateurs ont aussi des tunnels "clients" pointant sur des destinations
POP3 et SMTP <a href="#app.i2pmail">I2Pmail</a> (qui sont également de simples instances "serveur" pointant sur des
serveurs POP3 et SMTP), ainsi que que des tunnels "clients" pour des serveurs CVS sur I2P (pour du développement
anonyme). Il y même eu des gens avec des "clients" mandataires pour accéder à des instances "serveur" pointant sur
un serveur NNTP.</p>
<h2 id="app.i2pbt">i2p-bt</h2>
2011-03-21 11:22:48 +00:00
<p><i>Développé par duck et al</i></p>
<p> i2p-bt est un portage du client BitTorrent python principal destiné à exécuter le tracker et gérer
la communication entre pairs I2P. Les demandes du tracker sont transmises par le mandataire eepproxy aux sites eep
indiqués dans le fichier torrent, et les réponses se rapportent explicitement aux pairs par leur destination: ceci
permet à i2p-bt d'ouvrir une connexion par la <a href="#app.streaming">bibliothèque de flux</a> pour demander les
blocs.</p>
<p> En complément à i2p-bt, un portage I2P de bytemonsoon a été réalisé, en faisant quelques modifications pour en
retirer quelques informations compromettant l'anonymat et prendre du fait que l'IP ne permet pas l'identification
des pairs.</p>
<h2 id="app.i2psnark">I2PSnark</h2>
2011-03-21 11:22:48 +00:00
<p><i>I2PSnark développé par jrandom et al, porté du client <a
href="http://www.klomp.org/snark/">Snark</a> de <a
href="http://www.klomp.org/mark/">mjw</a>.</i></p>
<p> Fourni à l'installation d'I2P, I2PSnark offre un client BitTorrent anonyme simple doté de possibilités
multitorrents, et entièrement interfacé en HTML</p>
<h2 id="app.robert">Robert</h2>
2011-03-21 11:22:48 +00:00
<p><i>Développé par sponge</i></p>
<p>Robert est un client Bittorrent écrit en Python.
Disponible sur <a href="http://bob.i2p/Robert.html">http://bob.i2p/Robert.html</a></p> <!-- TODO: expand -->
<h2 id="app.pybit">PyBit</h2>
2011-03-21 11:22:48 +00:00
<p><i>Développé par Blub</i></p>
<p>PyBit est un client Bittorrent écrit en Python.
Disponible sur <a href="http://pebcache.i2p/">http://pebcache.i2p/</a></p> <!-- TODO: expand -->
<h2 id="app.i2phex">I2Phex</h2>
2011-03-21 11:22:48 +00:00
<p><i>Développé par sirup</i></p>
<p> I2Phex est un portage assez direct du client de partage de fichiers Gnutella Phex. Bien que certaines
fonctionnalités aient été désactivées (comme l'intégration des caches web Gnutella), les fonctions basiques de
partage de fichiers et de chat sont pleinement opérationnelles.</p>
<h2 id="app.i2pmail">I2Pmail/susimail</h2>
2011-03-21 11:22:48 +00:00
<p><i>Développé par postman, susi23 et mastiejaner</i></p>
<p> I2Pmail est plus un service qu'une application: postman offre un service de mail interne et externe par
POP3 et SMTP via des instances I2PTunnel accédant à une série de composants développés avec mastiejaner,
permettant aux gens d'utiliser leur client de messagerie préféré pour envoyer et recevoir du courriel avec un
pseudonyme. Cependant, comme la plupart de ces clients ont la fâcheuse manie d'embarquer dans les messages des
informations compromettant l'anonymat, I2P fournit le client webmail de susi23 construit avec les toutes les
exigences d'anonymat en tête. Le service I2Pmail/mail.i2p offre un filtrage anti-virus transparent et une
prévention de déni de service par des quotas à pénalités incrémentielles. De plus, chaque utilisateur dispose du
contrôle de sa stratégie de traitement par lots avant l'envoi par les mandataires sortants de mail.i2p,
qui sont différents des serveurs de mail SMPT/POP3 de mail.i2p: les mandataires sortants et entrants communiquent
avec les serveurs de mail d'i2p via I2P lui-même, donc la compromission de ces emplacements non anonymes ne
donnerait accès aux comptes de messagerie ou aux motifs/profils d'activité des utilisateurs. En ce moment,
les développeurs travaillent sur un système de messagerie décentralisé, appelé "v2mail".
Plus d'infos sur le site eep <a href="http://hq.postman.i2p/">hq.postman.i2p</a>.</p>
<h2 id="app.i2pbote">I2P-Bote</h2>
2011-03-21 11:22:48 +00:00
<p><i>Développé par HungryHobo</i></p>
<p>
2011-03-21 11:22:48 +00:00
I2P-Bote est une application de messagerie décentralisée. Elle n'utilise pas le concept traditionnel
d'envoi/réception de messages à un serveur. Elle utilise une table de hachage décentralisée Kedemlia pour stocker
les messages. Un utilisateur peut envoyer son message vers la DHT, un autre peut en extraire les siens destinés.</p>
<h2 id="app.i2pmessenger">I2P-messenger</h2>
<p>
2011-03-21 11:22:48 +00:00
I2P-messenger est une application de communication sans serveur cryptée de bout en bout. Pour communiquer, deux
utilisateurs doivent se donner l'un à l'autre leur destination pour se mettre en relation.
</p>
{% endblock %}