Note : Cette page n’est pas à jour. Vous trouverez les plans actuels dans la feuille de route.

Ci-dessous une discussion plus détaillée (quoiqu’encore incomplète) des principales zones de développement dans le réseau I2P central, couvrant les versions plausibles prévues. Les transports stego, le portage sur des dispositifs sans fil ni les outils pour sécuriser la machine locale, ne sont inclus, pas plus que les applications client qui seront essentielles au succès d’I2P. D’autres choses feront probablement surface, plus particulièrement au fur et à mesure qu’I2P sera évalué par des pairs, mais ce sont les « choses principales ». Consultez aussi la feuille de route. Voulez-vous aider ? Impliquez-vous !

Fonctionnalité de base

• NetworkDB et réglage de profil et politique d’éjection pour grands réseaux

  Dans la base de données de réseau actuelle et la mise en œuvre de gestion de profil, nous avons pris la liberté de quelques raccourcis pratiques. Par exemple, nous n’avons pas le code pour laisser tomber les références du pair depuis les seaux-K, comme nous n’avons pas assez de pairs afin de même plausiblement les remplir tous, car au lieu de cela, nous gardons juste les pairs dans n’importe quel seau approprié. Un autre exemple traite des profils les pairs - la mémoire exigée pour maintenir le profil de chaque pair est si petite que nous pouvons garder des milliers de profils pleinement soufflés dans la mémoire sans problèmes. Tandis que nous avons la capacité d’utiliser des profils à coupe basse (que nous pouvons maintenir 100s de milliers dans la mémoire), nous n’avons aucun code à traiter concernant le déplacement d’un profil depuis un "profil minimal" vers un "profil complet", un "profil complet" vers un "profil minimal" ou pour simplement éjectez un profil tout ensemble. Il ne serait simplement pas pratique d’écrire ce code dès maintenant, puisque nous n’allons pas en avoir besoin pendant un certain temps.

  Cela dit, comme le réseau grandit nous allons vouloir garder ces considérations à l’esprit. Nous aurons du travail à faire, mais nous pouvons le remettre à plus tard.

Sécurité / anonymat

• Routes restreintes "full blown n-hop" avec des liens de confiance facultatifs

  La fonction de route restreinte décrite auparavant était simplement un problème fonctionnel - comment laisser communiquer des pairs qui autrement n’en seraient pas capables. Cependant, le concept de permettre des routes restreintes inclut des capacités supplémentaires. Par exemple, si un routeur ne peut pas absolument pas risquer de communiquer directement avec n’importe quels pairs non éprouvés, il peut installer des liens éprouvés à travers ces pairs, les utilisant pour à la fois envoyer et recevoir tous ses messages. Ces pairs cachés qui veulent être complètement isolés refuseraient aussi de se connecter aux pairs qui essayent de s’y connecter (comme démontré par la technique de routage en ail décrite auparavant) - ils peuvent simplement prendre le clou de girofle ail qui a une requête de livraison vers un pair particulier et une route tunnel qui sort le message hors des liens de confiance du pairs caché avec instruction de le faire suivre comme demandé.

• Hashcash pour routerIdentity, destination, et requête de tunnel

  Dans le réseau, nous voudrons une façon de dissuader des gens de consommer trop de ressources ou de créer suffisamment de pairs leur permettant de monter une attaque Sybil. Des techniques traditionnelles comme avoir un pair capable de voir qui demande une ressource ou exécute un pair ne sont pas appropriées à l’usage dans I2P, car faire ainsi mettrait en péril l’anonymat du système. Au lieu de cela, nous voulons rendre certaines requêtes "chères".

  Hashcash est une technique que nous pouvons utiliser pour augmenter anonymement le "coût" de faire certaines activités, telles que la création d’une nouvelle identité de routeur (faite une seule fois par installation), la création d’une nouvelle destination (faite une seule fois lors de la création d’un service), ou la requête vers un pair afin qu’il participe à un tunnel (faite souvent, peut-être 2-300 fois par heure). Nous ne savons pas encore le coût "correct" de chaque type de certificat, mais avec un peu de recherche et d’expérimentation, nous pourrions mettre un niveau de base qui soit suffisamment cher tout en n’étant pas un fardeau excessif pour les gens ayant peu de ressources.

  Il y a quelques autres algorithmes que nous pouvons explorer pour rendre ces requêtes de ressources "non gratuites", et davantage de recherches sur ce front seront appropriées.

• Fonctionnement évolué des tunnels (traitement par lot/mélange/limitation de la bande passante/remplissage)

  Pour les observateurs externes passifs puissants aussi bien que les observateurs de grands attaques par collusion, le routage standard de tunnel est vulnérable aux attaques d’analyse de trafic - simplement en observant la taille et la fréquence des messages étant passés entre les routeurs. Pour se défendre contre ceci, nous voudrons essentiellement rendre certains des tunnels afin d’être leurs propres mélangeurs en cascade - retardant des messages reçus à la passerelle et les transmettant en lots, les réordonnant si nécessaire, et injectant des messages factices (indiscernables d’autre messages de tunnels "réels" par les pairs dans le chemin). Il y a eu une quantité significative de recherche concernant ces algorithmes de sorte que nous pouvons nous pencher sur la mise en œuvre des diverses stratégies de mélange de tunnels.

  En plus des aspects d’anonymat offerts par une opération plus variée des tunnels, Il y a aussi une dimension fonctionnelle. Chaque pair ne peut acheminer qu’une certaine quantité de données pour le réseau et afin d’empêcher qu’un tunnel particulier ne consomme une portion déraisonnable de cette bande passante, il voudra étrangler le tunnel. Par exemple, un tunnel peut être configuré pour s’étrangler après 600 messages (1 par seconde), 2,4 Mo (4 kbps), ou après avoir dépassé une certaine moyenne mobile (8 kbps durant la dernière minute). Les messages excédants peuvent être retardés ou abandonnés immédiatement. Avec ce genre d’étranglement, les pairs peuvent fournir une qualité de service semblable à ATM pour leurs tunnels, refusant d’accepter d’attribuer plus de bande passante que le pair n’a de disponible.

  De plus, nous pouvons vouloir mettre en œuvre le code pour dévier (reroute) dynamiquement des tunnels pour éviter pairs en échec ou injecter des étapes supplémentaires dans le chemin. Ceci peut être fait en acheminement en ail (garlic routing) un message à un pair particulier dans un tunnel avec des instructions afin de redéfinir l’étape suivante dans le tunnel.

• Stop & go mélangé avec tunnels ail

  Au-delà du groupage en lot par-tunnel et de la stratégie de mélange, il y a de nouvelles possibilités pour se protéger contre des attaquants puissants, comme permettre à chacun étape dans le parcours acheminé en ail de définir un retard ou une fenêtre durant lequel il devrait être expédié vers. Ceci permettrait des protections contre l’attaque d’intersection à long terme, car un pair pourrait envoyer un message qui semble parfaitement standard à la plupart des pairs qui le font passer, sauf aux pairs pour lesquels le clou de girofle (clove) exposé inclut des instructions de retard.

Performances

Les améliorations en relevé avec la performance sont listées sur la page Performance.