Note: This page is not up-to-date. See the roadmap for current plans.

Ci-dessous une discussion plus détaillée (quoique encore incomplete) des zones majeures de développement futur sur le cœur du réseau I2P, enjambant les releases plausiblement planifiées. Ceci n'inclut pas de transports stego, portage sur des dispositifs sans fil, ou outils pour sécuriser la machine locale, cela n''inclue non plus les d'applications clientes qui seront essentielles dans le succès de I2P. Il y a probablement d'autres choses qui viendront, d'autant plus qu''I2P obtient davantage de reviews, mais ce sont les principales 'grandes choses'. Voyez aussi la roadmap. 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 fonctionnalité 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.

  • Opération avancée de tunnel (traitant par lot/mixage/étranglement/étoffement)

    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 des autres diverses opérations de tunnel, Il y a aussi une dimension fonctionnelle. Chaque pair a seulement une certaine quantité de données qu''il peut guider (router) pour le réseau, et afin d'empêcher n'importe quel tunnel de consommer une portion déraisonnable de cette bande passante, il voudra inclure quelques étrangleurs sur le tunnel. Par exemple, un tunnel peut être configuré pour s''étrangler lui-même après le passage de 600 messages (1 par seconde), 2.4 MB (4 KBps), ou avoir excédé une certaine moyenne mouvante (8 KBps durant la dernière minute). Les messages en excès peuvent être retardés ou abandonnés sommairement. Avec ce type d''étranglement, les pairs peuvent fournir du soutient de QoS semblable à l''ATM pour leurs tunnels, refusant d'accorder d''allouer davantage de bande passante que les pairs en ont 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 oignon

    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 rapport avec la performance sont listées sur la page Performance.