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

{% extends "_layout_fr.html" %}
{% block title %}Présentation d'I2P{% endblock %}
{% block content %}

  <center>
    <b class="title"> 
    <h1>I2P: <font size="3">Une plate-forme modulaire pour la communication anonyme</font></h1>
    </b> 
  </center>
Traduction (en cours) de mars 2011. <a href="techintro.html">Version anglaise actuelle</a>
  <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>
                <li><a href="#op.netdb">Base de donnée 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>
      </ul>
  </div> 

  <br/>
  <h1 id="intro">Introduction</h1>
  <p>
    I2P est une couche réseau par paquets commutée, modulaire, à tolérance de panne, auto-adaptative, et anonyme 
    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>
    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>
      <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>
        et d'autres.
      </li>
      <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>
    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>
    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 
    dans le réseau, leur intérêt a été limité car preque toutes exposent intrinsèquement ce qui, du point de vue 
    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>
  <center>
    <div class="box">
      <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>
  </center><br/>
  <p>
    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").
    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 
    au tranfert vers la bonne passerelle entrante (la passerelle vers "Bob").
  </p>
  <p>
    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 
    transportées sont la <b>"routerInfo"</b> et les <b>"jeux de baux"</b> (leaseSets): 
    la routerInfo donne aux routeurs les données nécessaires pour contacter un autre routeur particulier 
    (ses clés publiques, adresse de transport, etc...), et les jeux de baux donnent au routeurs les informations 
    nécessaires pour joindre une destination particulière. Un jeu de baux contient un certain nombre de "baux". 
    Chacun de ces baux indique une passerelle de tunnel qui permet d'atteindre une destination particulière.
    Détail complet des informations contenues dans un bail:
    <ul>
      <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>
    Les routers envoient eux-mêmes directement leur "routerInfo" à la base de données, 
    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>
  <p>On peut combiner les trois concepts exposés ci-dessus pour établir des connexions effectives dans le réseau.
  </p>
  <p>
    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>
  <center>
    <div class="box">
      <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;
      <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>
  </center><br/>
  <p>
    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>
  <center>
    <div class="box">
      <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 />
      Figure 3: Les jeux de baux sont utilisés pour connecter les tunnels sortants et entrants.
    </div>
  </center><br/>
  <p>
    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>
    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>
  <h2 id="op.tunnels">Les tunnels</h2>
  <p>
    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 
    les couches de crytpage par saut ajoutées, le message arrive en clair au point terminal.
  </p>
  <p>
    Le choix de pairs spécifiques pour passer les messages, ainsi que la définition de leur séquence,  
    est important pour une bonne compréhention de l'anatomie et des performances d'I2P.
    Alors que la base de données dispose de ses propres critères de sélection lors du choix  
    des pairs à interroger et pour mémoriser les entrées correspondantes, les creators de tunnels utilisent
    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>
    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>
    À la base, I2P classe en permanance les pairs avec lesquels il interagit en mesurant indirectement 
    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>
  <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 
    du premier groupe utilisables par des attaques du type collecte de base de données et du type prédecessur. 
    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>
    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  
    aléatoirement la position des pairs situés plus loin dans le tunnnel. Pour gérer les attaques de prédécesseur 
    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, 
    car tous les pairs sont suceptibles de défaillance, et donc elle doit soit être ajustée en réaction, ou
    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>
    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>
  <h2 id="op.netdb">Base de données</h2>
  <p>
    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>
    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>
    Les autres routeurs I2P vont y enregistrer leurs données et recherches en envoyant de simples requêtes 
    'store' et 'lookup' aux diffuseurs.
    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>.
    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>
    Deux types d'informations sont stockées dans la netDb.
    <ul>
        <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>
    Toutes ces infos sont signées par leur propriétaire, et vérifiées par tout routeur I2P qui les utilise 
    ou les stocke.
    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>
    Autres remarques importantes.
    <ul>
      <li>
        <b>Jeux de baux non publiés et cryptés:</b>
        <p>
          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>
        <b>Amorçage:</b>
        <p>
          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>
        <b>Adaptativité des recherches:</b>
        <p>
            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>
  <h2 id="op.transport">Protocoles de transport</h2>
  <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  
    discernables par les tierses parties. Il doit tolérer un fort taux de communications
    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. 
    Comme NTCP est bati avec les NIO il n'est pas astreint au problème de "une connexion=une tâche" dont souffrait 
    l'ancien transport TCP. </p>
  <p> I2P permet de multiples transports simultanément. Un transport particulier pour une connexion sortante 
    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, 
    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>
    supppémentaire. Divers autres messages sont passés regroupés dans des "garlic messages",
    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 
    données (à côté de quelques autres messages) dans un garlic qu'il crypte en ElGamal 2048 à l'intension de la 
    destination avec sa clé publiée dans son jeu de baux, et l'envoie aux tunnels appropriés.</p>
  <p> Les "instructions" attachées à chaque gousse dans la couche de cryptage incluent la passibilité 
    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
    un certain temps ou jusqu'à ce qu'une condition soit remplie, bien qu'ils ne seront pris en compte 
    que lorsque les <a href="#future.variablelatency">retards nontriviaux</a> soient déployés. Il est possible 
    de router explicitement les messages en tête d'ail sur n'importe quel nombre de sauts sans construire de tunnels, 
    ou même de rerouter les messages de tunnels en les joingnant à un garlic et en le faisant suivre à un certain 
    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>
  <p> En tant que système orienté messages non fiable et non ordonné, I2P utilses une simple combinaison 
    d'algorithmes de cryptage symétriques et assymétriques pour apporter la confidentialité et l'intégrité 
    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 
    après le block crypté avec ElGamal. En plus de la charge utile cryptée, la section encryptée en AES contient
    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, 
    il va simplement prendre une des balises précédement envoyées et crypter la charge en AES comme avant en utilisant 
    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 
    décryptent l'AES. En l'absence de correspondance, il décryptent le premier block en ElGamal.</p>
  <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é 
    ElGamal/AES+SessionTag choisit quand et combien de balises il faut envoyer pour en fournir suffisament au 
    destinataire afin de couvrir les besoins nécessaires au tranfert d'un bouquet de messages.
    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>
  <h2 id="future.restricted">Les routes réservées</h2>
  <p> I2P est une "sur-couche" réseau conçue pour fonctionner sur un réseau commuté par paquets,  
    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), 
    I2P requiert qu'une portion substancielle du réseau soit joignable: il pourrait y avoir un bon nombre  
    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 
    derrière la plupart de pare-feux ou NATs de recevoir des connexions non solicitées sans aucune configuration.
    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 
    'routeurs clients'. Pour le premier, les routeurs peuvent soit construire un nouveau groupe de tunnnels ou 
    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 
    probabilité de tomber sur un pairs hostile pour se connecter soit suffisament faible. On pourrait aussi préférer 
    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 
    à haute latence tout en mélant leurs motifs de trafic à du trafic à faible latence. En interne cependant, 
    I2P peut offrir son propre medium et une haute latence de communication via le cryptage garlic en tête d'ail: 
    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 
    latence, au trafic carrespondant d'être mélangé ultérieurement à du trafic à faible latence. Une fois la condition 
    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>
Comment se débarasser de la contrainte de temps?
Y a-t-il un moyen plus effcace de gérer les balises de session?
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>
  <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>
  <p><i><a href="http://www.torproject.org/">website</a></i></p>
  <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 
    dispose d'une base de donnée réseau auto-organisée dans laquelle chaque pair assume la responsabilité du profilage
    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 
    (outproxy), I2P délègue cette décision de couche applicative... aux applications: en réalité, I2P a même 
    externalisé vers la couche applicative la bibliothèque de flux (streaming) "style TCP" permettant ansi aux 
    développeurs d'expérimenter diverses stratégies afin d'obtenir les meilleures performances.</p>
  <p> Du point de vue de l'anonymat, la comparaison du cœur des réseaux présente beaucoup de similarités. 
    Il y a malgré tout quelques différences fondamentales. Pour la prise en compte des menaces internes et de la
    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 
    plusieur tunnels sortants, et ceux de la réponse empruntent un ou plusieur tunnels entrants. 
    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>
  <p> Une autre faille d'anonymat dans Tor vient de la création télescopique de tunnels: le comptage des paquets  
    et les mesures de timing dans un circuit passent à travers un nœud ennemi permettent l'extraction de données 
    statistiques suivant la position de l'adversaire dans le circuit. Dans I2P, la création de tunnels unidirectionels 
    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>
  <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, 
    elles ont chacunes leurs propres forces et faiblesses. Les développeurs d'I2P ont étudié les étapes nécessaires 
    à la modification de Tor pour qu'il puisse bénéficier de la conception d'I2P, red 
    the steps necessary to modify Tor to take advantage of I2P's design, mais les inquiétudes quand à la 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>
  <p><i><a href="http://www.freenetproject.org/">Le site</a></i></p>
  <p> Freenet a largement contribué aux premières étapes de conception d'I2P, en donnant la preuve de viabilité 
    d'une communauté enthousiaste entièrement contenue dans un réseau et  en démontrant que les dangers inhérents aux 
    mandataires sortants pouvaient être évités. The first seed of I2P began as a replacement communication 
    layer for Freenet, attempting to factor out the complexities of a scalable, 
    anonymous and secure point to point communication from the complexities of 
    a censorship resistant distributed data store. Over time however, some of 
    the anonymity and scalability issues inherent in Freenet's algorithms made 
    it clear that I2P's focus should stay strictly on providing a generic anonymous 
    communication layer, rather than as a component of Freenet. Over the years, 
    the Freenet developers have come to see the weaknesses in the older design, 
    prompting them to suggest that they will require a "premix" layer to offer 
    substantial anonymity. In other words, Freenet needs to run on top of a mixnet 
    such as I2P or Tor, with "client nodes" requesting and publishing data through 
    the mixnet to the "server nodes" which then fetch and store the data according 
    to Freenet's heuristic distributed data storage algorithms. </p>
  <p> Freenet's functionality is very complementary to I2P's, as Freenet natively 
    provides many of the tools for operating medium and high latency systems, 
    while I2P natively provides the low latency mix network suitable for offering 
    adequate anonymity. The logic of separating the mixnet from the censorship 
    resistant distributed data store still seems self evident from an engineering, 
    anonymity, security, and resource allocation perspective, so hopefully the 
    Freenet team will pursue efforts in that direction, if not simply reusing 
    (or helping to improve, as necessary) existing mixnets like I2P or Tor. </p>
  <p> It is worth mentioning that there has recently been discussion and work 
    by the Freenet developers on a "globally scalable darknet" using restricted 
    routes between peers of various trust. While insufficient information has 
    been made publicly available regarding how such a system would operate for 
    a full review, from what has been said the anonymity and scalability claims 
    seem highly dubious. In particular, the appropriateness for use in hostile 
    regimes against state level adversaries has been tremendously overstated, 
    and any analysis on the implications of resource scarcity upon the scalability 
    of the network has seemingly been avoided. Further questions regarding susceptibility 
    to traffic analysis, trust, and other topics do exist, but a more in-depth 
    review of this "globally scalable darknet" will have to wait until the Freenet 
    team makes more information available. </p>

  <h1 id="app">Appendix A: Application layer</h1>

  <p>
    I2P itself doesn't really do much - it simply sends messages to remote destinations 
    and receives messages targeting local destinations - most of the interesting 
    work goes on at the layers above it. By itself, I2P could be seen as an anonymous 
    and secure IP layer, and the bundled <a href="#app.streaming">streaming library</a> 
    as an implementation of an anonymous and secure TCP layer on top of it. Beyond 
    that, <a href="#app.i2ptunnel">I2PTunnel</a> exposes a generic TCP proxying 
    system for either getting into or out of the I2P network, plus a variety of 
    network applications provide further functionality for end users.
  </p>

  <h2 id="app.streaming">Streaming library</h2>
  <p>
    The I2P streaming library can be viewed as a generic streaming interface (mirroring TCP sockets),
    and the implementation supports a 
    <a href="http://en.wikipedia.org/wiki/Sliding_Window_Protocol">sliding window protocol</a>
    with several optimizations, to take into account the high delay over I2P.
    Individual streams may adjust the maximum packet size and 
    other options, though the default of 4KB compressed seems a reasonable tradeoff 
    between the bandwidth costs of retransmitting lost messages and the latency 
    of multiple messages.
  </p>
  <p>
    In addition, in consideration of the relatively high cost of subsequent 
    messages, the streaming library's protocol for scheduling and delivering messages 
    has been optimized to allow individual messages passed to contain as much 
    information as is available. For instance, a small HTTP transaction proxied 
    through the streaming library can be completed in a single round trip - the 
    first message bundles a SYN, FIN, and the small payload (an HTTP request typically 
    fits) and the reply bundles the SYN, FIN, ACK, and the small payload (many 
    HTTP responses fit). While an additional ACK must be transmitted to tell the 
    HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy can 
    deliver the full response to the browser immediately.
  </p>
  <p>
    On the whole, however, the streaming library bears much resemblance to an 
    abstraction of TCP, with its sliding windows, congestion control algorithms 
    (both slow start and congestion avoidance), and general packet behavior (ACK, 
    SYN, FIN, RST, etc).
  </p>

  <h2 id="app.naming">Naming library and addressbook</h2>
  <p><i> For more information see the <a href="naming.html">Naming and Addressbook</a> 
    page.</i></p>
  <p><i>Developed by: mihi, Ragnarok</i></p>
  <p> Naming within I2P has been an oft-debated topic since the very beginning 
    with advocates across the spectrum of possibilities. However, given I2P's 
    inherent demand for secure communication and decentralized operation, the 
    traditional DNS-style naming system is clearly out, as are "majority rules" 
    voting systems. Instead, I2P ships with a generic naming library and a base 
    implementation designed to work off a local name to destination mapping, as 
    well as an optional add-on application called the "addressbook". The addressbook 
    is a web-of-trust driven secure, distributed, and human readable naming system, 
    sacrificing only the call for all human readable names to be globally unique 
    by mandating only local uniqueness. While all messages in I2P are cryptographically 
    addressed by their destination, different people can have local addressbook 
    entries for "Alice" which refer to different destinations. People can still 
    discover new names by importing published addressbooks of peers specified 
    in their web of trust, by adding in the entries provided through a third party, 
    or (if some people organize a series of published addressbooks using a first 
    come first serve registration system) people can choose to treat these addressbooks 
    as name servers, emulating traditional DNS. </p>
  <p> I2P does not promote the use of DNS-like services though, as the damage 
    done by hijacking a site can be tremendous - and insecure destinations have 
    no value. DNSsec itself still falls back on registrars and certificate authorities, 
    while with I2P, requests sent to a destination cannot be intercepted or the 
    reply spoofed, as they are encrypted to the destination's public keys, and 
    a destination itself is just a pair of public keys and a certificate. DNS-style 
    systems on the other hand allow any of the name servers on the lookup path 
    to mount simple denial of service and spoofing attacks. Adding on a certificate 
    authenticating the responses as signed by some centralized certificate authority 
    would address many of the hostile nameserver issues but would leave open replay 
    attacks as well as hostile certificate authority attacks. </p>
  <p> Voting style naming is dangerous as well, especially given the effectiveness 
    of Sybil attacks in anonymous systems - the attacker can simply create an 
    arbitrarily high number of peers and "vote" with each to take over a given 
    name. Proof-of-work methods can be used to make identity non-free, but as 
    the network grows the load required to contact everyone to conduct online 
    voting is implausible, or if the full network is not queried, different sets 
    of answers may be reachable. </p>
  <p> As with the Internet however, I2P is keeping the design and operation of 
    a naming system out of the (IP-like) communication layer. The bundled naming 
    library includes a simple service provider interface which alternate naming 
    systems can plug into, allowing end users to drive what sort of naming tradeoffs 
    they prefer. </p>

  <h2 id="app.syndie">Syndie</h2>
  <p><i> The old Syndie bundled with I2P has been replaced by the new Syndie which 
    is distributed separately. For more information see the <a href="http://syndie.i2p2.de/">Syndie</a> 
    pages.</i></p>
  <p> Syndie is a safe, anonymous blogging / content publication / content aggregation 
    system. It lets you create information, share it with others, and read posts 
    from those you're interested in, all while taking into consideration your 
    needs for security and anonymity. Rather than building its own content distribution 
    network, Syndie is designed to run on top of existing networks, syndicating 
    content through eepsites, Tor hidden services, Freenet freesites, normal websites, 
    usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie 
    is done so as to offer pseudonymous authentication to anyone reading or archiving 
    it. </p>

  <h2 id="app.i2ptunnel">I2PTunnel</h2>
  <p><i>Developed by: mihi</i></p>
  <p> I2PTunnel is probably I2P's most popular and versatile client application, 
    allowing generic proxying both into and out of the I2P network. I2PTunnel 
    can be viewed as four separate proxying applications - a "client" which receives 
    inbound TCP connections and forwards them to a given I2P destination, an "httpclient" 
    (aka "eepproxy") which acts like an HTTP proxy and forwards the requests to 
    the appropriate I2P destination (after querying the naming service if necessary), 
    a "server" which receives inbound I2P streaming connections on a destination 
    and forwards them to a given TCP host+port, and an "httpserver" which extends 
    the "server" by parsing the HTTP request and responses to allow safer operation. 
    There is an additional "socksclient" application, but its use is not encouraged 
    for reasons previously mentioned. </p>
  <p> I2P itself is not an outproxy network - the anonymity and security concerns 
    inherent in a mix net which forwards data into and out of the mix have kept 
    I2P's design focused on providing an anonymous network which capable of meeting 
    the user's needs without requiring external resources. However, the I2PTunnel 
    "httpclient" application offers a hook for outproxying - if the hostname requested 
    doesn't end in ".i2p", it picks a random destination from a user-provided 
    set of outproxies and forwards the request to them. These destinations are 
    simply I2PTunnel "server" instances run by volunteers who have explicitly 
    chosen to run outproxies - no one is an outproxy by default, and running an 
    outproxy doesn't automatically tell other people to proxy through you. While 
    outproxies do have inherent weaknesses, they offer a simple proof of concept 
    for using I2P and provide some functionality under a threat model which may 
    be sufficient for some users. </p>
  <p> I2PTunnel enables most of the applications in use. An "httpserver" pointing 
    at a webserver lets anyone run their own anonymous website (or "eepsite") 
    - a webserver is bundled with I2P for this purpose, but any webserver can 
    be used. Anyone may run a "client" pointing at one of the anonymously hosted 
    IRC servers, each of which are running a "server" pointing at their local 
    IRCd and communicating between IRCds over their own "client" tunnels. End 
    users also have "client" tunnels pointing at <a href="#app.i2pmail">I2Pmail's</a> 
    POP3 and SMTP destinations (which in turn are simply "server" instances pointing 
    at POP3 and SMTP servers), as well as "client" tunnels pointing at I2P's CVS 
    server, allowing anonymous development. At times people have even run "client" 
    proxies to access the "server" instances pointing at an NNTP server. </p>

  <h2 id="app.i2pbt">i2p-bt</h2>
  <p><i>Developed by: duck, et al</i></p>
  <p> i2p-bt is a port of the mainline python BitTorrent client to run both the 
    tracker and peer communication over I2P. Tracker requests are forwarded through 
    the eepproxy to eepsites specified in the torrent file while tracker responses 
    refer to peers by their destination explicitly, allowing i2p-bt to open up 
    a <a href="#app.streaming">streaming lib</a> connection to query them for 
    blocks. </p>
  <p> In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making 
    a few modifications as necessary to strip any anonymity-compromising information 
    from the application and to take into consideration the fact that IPs cannot 
    be used for identifying peers. </p>

  <h2 id="app.i2psnark">I2PSnark</h2>
  <p><i>I2PSnark developed: jrandom, et al, ported from <a
href="http://www.klomp.org/mark/">mjw</a>'s <a
href="http://www.klomp.org/snark/">Snark</a> client</i></p>
  <p> Bundled with the I2P install, I2PSnark offers a simple anonymous BitTorrent 
    client with multitorrent capabilities, exposing all of the functionality through 
    a plain HTML web interface. </p>

  <h2 id="app.robert">Robert</h2>
  <p><i>Developed by: sponge</i></p>
  <p>Robert is a Bittorrent client written in Python.
    It is hosted on <a href="http://bob.i2p/Robert.html">http://bob.i2p/Robert.html</a></p> <!-- TODO: expand -->

  <h2 id="app.pybit">PyBit</h2>
  <p><i>Developed by: Blub</i></p>
  <p>PyBit is a Bittorrent client written in Python.
    It is hosted on <a href="http://pebcache.i2p/">http://pebcache.i2p/</a></p> <!-- TODO: expand -->

  <h2 id="app.i2phex">I2Phex</h2>
  <p><i>Developed by: sirup</i></p>
  <p> I2Phex is a fairly direct port of the Phex Gnutella filesharing client to 
    run entirely on top of I2P. While it has disabled some of Phex's functionality, 
    such as integration with Gnutella webcaches, the basic file sharing and chatting 
    system is fully functional. </p>
  <h2 id="app.i2pmail">I2Pmail/susimail</h2>
  <p><i>Developed by: postman, susi23, mastiejaner</i></p>
  <p> I2Pmail is more a service than an application - postman offers both internal 
    and external email with POP3 and SMTP service through I2PTunnel instances 
    accessing a series of components developed with mastiejaner, allowing people 
    to use their preferred mail clients to send and receive mail pseudonymously. 
    However, as most mail clients expose substantial identifying information, 
    I2P bundles susi23's web based susimail client which has been built specifically 
    with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers transparent 
    virus filtering as well as denial of service prevention with hashcash augmented 
    quotas. In addition, each user has control of their batching strategy prior 
    to delivery through the mail.i2p outproxies, which are separate from the mail.i2p 
    SMTP and POP3 servers - both the outproxies and inproxies communicate with 
    the mail.i2p SMTP and POP3 servers through I2P itself, so compromising those 
    non-anonymous locations does not give access to the mail accounts or activity 
    patterns of the user. At the moment the developers work on a decentralized 
    mailsystem, called "v2mail". More information can be found on the eepsite 
    <a href="http://hq.postman.i2p/">hq.postman.i2p</a>.</p>

  <h2 id="app.i2pbote">I2P-Bote</h2>
  <p><i>Developed by: HungryHobo</i></p>
  <p>
    I2P-Bote is a distributed e-mail application. It does not use the traditional
    e-mail concept of sending an e-mail to a server and retrieving it from a server.
    Instead, it uses a Kademlia Distributed Hash Table to store mails.
    One user can push a mail into the DHT, while another can request the e-mail from the DHT.
  </p>

  <h2 id="app.i2pmessenger">I2P-messenger</h2>
  <p>
    I2P-messenger is an end-to-end encrypted serverless communication application.
    For communication between two users, they need to give each other their destination, to allow the other to connect.
  </p>
{% endblock %}