forked from I2P_Developers/i2p.www
merge of '76b5699dc93ccf3df02121c9908808982fdac15a'
and 'a4e3d0835b46727aff75cd52a642f0bf652d624b'
This commit is contained in:
magma
@ -1,190 +1,190 @@
|
||||
{% extends "_layout_fr.html" %}
|
||||
{% block title %}À faire / Sur le feu{% endblock %}
|
||||
{% block title %}À faire / Sur le feu{% endblock %}
|
||||
{% block content %}
|
||||
<h1>Cibles du project I2P</h1>
|
||||
Traduction en cours (25 fév 2011)
|
||||
<p>Vous trouverez ci-dessous une exposition plus détaillée (bien que toujours incomplète)
|
||||
des principales zones du développement du cœur du réseau I2P, embrassant les
|
||||
nouvelles versions éventuellement planifiées. Ceci n'inclu ni le transport stéganographique,
|
||||
ni les outils de sécurisation de la machine locale et l'adaptation aux périphériques radio (WiFi), pas plus que les applications clientes
|
||||
qui sont tous essentiels pour le succès du réseau I2P. Il y a probablement d'autres choses qui
|
||||
viendront, particulièrement quand I2P sera mieux testé, mais il s'agit là des principaux
|
||||
|
||||
<p>Vous trouverez ci-dessous une exposition plus détaillée (bien que toujours incomplète)
|
||||
des principales zones du développement du cœur du réseau I2P, embrassant les
|
||||
nouvelles versions éventuellement planifiées. Ceci n'inclut ni le transport stéganographique,
|
||||
ni les outils de sécurisation de la machine locale et l'adaptation aux périphériques radio (WiFi), pas plus que les applications clientes
|
||||
qui sont tous essentiels pour le succès du réseau I2P. Il y a probablement d'autres choses qui
|
||||
viendront, particulièrement quand I2P sera mieux testé, mais il s'agit là des principaux
|
||||
"gros morceaux". Voir aussi la <a href="roadmap_fr.html">feuille de route</a>. Vous voulez nous aider? <a href="getinvolved.html">Engagez-vous!</a></p>
|
||||
<br />
|
||||
<h2>Fonctionalités centrales <font size="-1"><a href="#core">[hop]</a></font></h2>
|
||||
<h2>Fonctionnalités centrales <font size="-1"><a href="#core">[hop]</a></font></h2>
|
||||
<ul class="targetlist">
|
||||
<li><a href="#nat">Pontage du Pare-feu/NAT via une route réservée à 1 saut.</a></li>
|
||||
<li><a href="#nat">Pontage du Pare-feu/NAT via une route réservée à 1 saut.</a></li>
|
||||
<li><a href="#transport">Couche transport de haut-niveau par UDP, NBIO, ou NIO.</a></li>
|
||||
<li><a href="#netdb">Base de donnée réseau, ajustement de profil et stratégie d'éjection pour les grands réseaux.</a></li>
|
||||
<li><a href="#netdb">Base de donnée réseau, ajustement de profil et stratégie d'éjection pour les grands réseaux.</a></li>
|
||||
</ul>
|
||||
<h2>Sécurité / anonymat <font size="-1"><a href="#security">[zyva]</a></font></h2>
|
||||
<h2>Sécurité / anonymat <font size="-1"><a href="#security">[zyva]</a></font></h2>
|
||||
<ul class="targetlist">
|
||||
<li><a href="#tunnelId">ID de tunnel "par saut" & nouvelle encryption permutée de la structure de vérification des tunnels.</a></li>
|
||||
<li><a href="#tunnelId">ID de tunnel "par saut" & nouvelle encryption permutée de la structure de vérification des tunnels.</a></li>
|
||||
<li><a href="#ordering">Position stricte des participants dans les tunnels.</a></li>
|
||||
<li><a href="#tunnelLength">Longueur des tunnels aléatoirement permutée.</a></li>
|
||||
<li><a href="#fullRestrictedRoutes">Routes réservées à n-sauts évoluées avec liens de confiance optionnels.</a></li>
|
||||
<li><a href="#hashcash">Hashcash pour routerIdentity, destination, et demande de tunnel.</a></li>
|
||||
<li><a href="#batching">Fonctionnement étendu des tunnels (batching/mixing/throttling/padding)</a></li>
|
||||
<li><a href="#stop">Mélange de Stop & go pour les <a href="http://www.i2p2.de/how_garlicrouting.html">"garlics"</a> et les tunnels</a></li>
|
||||
<li><a href="#tunnelLength">Longueur des tunnels aléatoirement permutée.</a></li>
|
||||
<li><a href="#fullRestrictedRoutes">Routes réservées à n-sauts évoluées avec liens de confiance optionnels.</a></li>
|
||||
<li><a href="#hashcash">Pénalités (Hashcash) pour les requêtes routerIdentity, destination, et demande de tunnel.</a></li>
|
||||
<li><a href="#batching">Fonctionnement évolué des tunnels (regroupement/mélange/étranglement/remplissage)</a></li>
|
||||
<li><a href="#stop">Mélange de Stop & Go pour les "garlics" et les tunnels.</a></li>
|
||||
</ul>
|
||||
<h2>Performances <font size="-1"><a href="performance.html">[doigt]</a></font></h2>
|
||||
<h2 id="core">Fonctionalités centrales</h2>
|
||||
<h2 id="core">Fonctionalités centrales</h2>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
<h3 id="nat">Pontage du Pare-feu/NAT via une route réservée à 1 saut.</h3>
|
||||
<h3 id="nat">Pontage du Pare-feu/NAT via une route réservée à 1 saut.</h3>
|
||||
</li>
|
||||
<b><i>Implémenté dans I2P 0.6.0.6</i></b>
|
||||
<p>La fonctionalité permettant aux routeurs de participer pleinement aux réseau
|
||||
même lorsqu'ils se trouvent derrière un pare-feu ou un traducteur d'adresses réseau (NAT) hors de contrôle nécessite quelques
|
||||
opérations avec une route réservée (car ces pairs ne peuvent pas recevoir
|
||||
de connexions entrantes). Pour y parvenir, il y a deux façons de considérer les pairs:</p>
|
||||
<b><i>Implémenté dans I2P 0.6.0.6</i></b>
|
||||
<p>La fonctionnalité permettant aux routeurs de participer pleinement aux réseau
|
||||
même lorsqu'ils se trouvent derrière un pare-feu ou un traducteur d'adresses réseau (NAT) hors de contrôle nécessite quelques
|
||||
opérations avec une route réservée (car ces pairs ne peuvent pas recevoir
|
||||
de connexions entrantes). Pour y parvenir, il y a deux façons de considérer les pairs:</p>
|
||||
</ul>
|
||||
<ul>
|
||||
<li><b>Pairs disposant d'interfaces joignables</b> - ils n'ont rien de particulier à faire.</li>
|
||||
<li><b>Pairs ne disposant pas d'interfaces joignables</b> - ces pairs doivent créer
|
||||
un tunnel pointant sur eux dans lequel la passerelle est un des pairs avec lesquels ils ont établi une connexion
|
||||
et qui, lui, dispose d'une interface publiquement joignable et a accepté de jouer le rôle "d'entremetteur".</li>
|
||||
<li><b>Pairs disposant d'interfaces joignables</b> - ils n'ont rien de particulier à faire.</li>
|
||||
<li><b>Pairs ne disposant pas d'interfaces joignables</b> - ces pairs doivent créer
|
||||
un tunnel pointant sur eux dans lequel la passerelle est un des pairs avec lesquels ils ont établi une connexion
|
||||
et qui, lui, dispose d'une interface publiquement joignable et a accepté de jouer le rôle "d'entremetteur".</li>
|
||||
</ul>
|
||||
<ul class="targetlist">
|
||||
<p>Pour ce faire, les pairs privés se connectent simplement à quelques autres,
|
||||
créent un tunnel à travers chacun d'eux, et en publient une référence dans leur
|
||||
structure RouterInfo de la base de donnée du réseau.</p>
|
||||
<p>Pour ce faire, les pairs privés se connectent simplement à quelques autres,
|
||||
créent un tunnel à travers chacun d'eux, et en publient une référence dans leur
|
||||
structure RouterInfo de la base de donnée du réseau.</p>
|
||||
<p>Lorsque quelqu'un souhaite joindre un routeur particulier, il doit d'abord obtenir
|
||||
sa "RouterInfo" à partir de la base de donnée, et il saura s'il peut se connecter
|
||||
sa "RouterInfo" à partir de la base de donnée, et il saura s'il peut se connecter
|
||||
directement (cas du pair cible public) ou indirectement. Les connexions directes se passent
|
||||
normalement, alors que les indirectes se font via les tunnels publiés.</p>
|
||||
<p>Quand un routeur veut seulement envoyer un ou deux messages à un pair caché,
|
||||
il peut simplement utiliser le tunnel indirect publié pour envoyer les données utiles. Cependant,
|
||||
si le routeur doit converser souvent avec le pair privé (par exemple en tant que participant
|
||||
à un tunnel), il doit envoyer un message "routé-à-la-garlic" à travers le tunnel
|
||||
indirect au pair caché, qui le déballe pour y trouver... un message destiné au routeur originaire.
|
||||
Le pair caché établit alors une connexion sortante
|
||||
au routeur originaire et à partir de là ces deux
|
||||
normalement, alors que les indirectes se font via les tunnels publiés.</p>
|
||||
<p>Quand un routeur veut seulement envoyer un ou deux messages à un pair caché,
|
||||
il peut simplement utiliser le tunnel indirect publié pour envoyer les données utiles. Cependant,
|
||||
si le routeur doit converser souvent avec le pair privé (par exemple en tant que participant
|
||||
à un tunnel), il doit envoyer un message "routé-à-la-garlic" à travers le tunnel
|
||||
indirect au pair caché, qui le déballe pour y trouver... un message destiné au routeur originaire.
|
||||
Le pair caché établit alors une connexion sortante
|
||||
au routeur originaire et à partir de là ces deux
|
||||
routeurs peuvent converser directement sur cette nouvelle connexion.</p>
|
||||
<p>Ce scénario ne peut bien sûr fonctionner que si le pair originaire peut recevoir des connexions
|
||||
(c'est-à-dire qu'il ne soit pas lui-même caché). Cependant, s'il est caché lui aussi, il peut indiquer dans
|
||||
le message initial de revenir par son propre tunnel d'entrée.</p>
|
||||
<p>Ceci n'est pas destiné à fournir aux pairs un moyen de dissimuler leur adresse IP,
|
||||
mais plutôt pour permettre à ceux opérant derrière un pare-feu ou un NAT de participer normalement
|
||||
au réseau. La dissimulation d'adresse IP demande plus de travail, comme
|
||||
décrit <a href="#fullRestrictedRoutes">plus bas</a>.</p>
|
||||
<p>Avec cette méthode, n'importe quel routeur peut participer à tout rôle dans un tunnel.
|
||||
Dans un but d'efficacité, opérer en pair caché est un mauvais choix pour officier en tant que passerelle d'entrée,
|
||||
et dans un tunnel donné, deux pairs voisins ne devraient pas être cachés. Mais ça n'est pas indispensable.</p>
|
||||
<p>Ce scénario ne peut bien sûr fonctionner que si le pair originaire peut recevoir des connexions
|
||||
(c'est-à-dire qu'il ne soit pas lui-même caché). Cependant, s'il est caché lui aussi, il peut indiquer dans
|
||||
le message initial de revenir par son propre tunnel d'entrée.</p>
|
||||
<p>Ceci n'est pas destiné à fournir aux pairs un moyen de dissimuler leur adresse IP,
|
||||
mais plutôt pour permettre à ceux opérant derrière un pare-feu ou un NAT de participer normalement
|
||||
au réseau. La dissimulation d'adresse IP demande plus de travail, comme
|
||||
décrit <a href="#fullRestrictedRoutes">plus bas</a>.</p>
|
||||
<p>Avec cette méthode, n'importe quel routeur peut participer à tout rôle dans un tunnel.
|
||||
Dans un but d'efficacité, opérer en pair caché est un mauvais choix pour officier en tant que passerelle d'entrée,
|
||||
et dans un tunnel donné, deux pairs voisins ne devraient pas être cachés. Mais ça n'est pas indispensable.</p>
|
||||
</ul>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
<h3 id="transport">Couche transport de haut-niveau par UDP, NBIO, ou NIO.</h3>
|
||||
<b><i>UDP et NIO sont implémentés dans I2P</i></b>
|
||||
<p>La communication TCP standard dans Java nécessite habituellement des appels de socket
|
||||
bloquants, et pour pour empêcher un socket de bloquer le bloquer tout le système, ces
|
||||
appels sont faits dans leur propres tâches. Notre transport TCP actuel
|
||||
est implémenté de façon naïve - pour chaque pair en relation, nous avons
|
||||
une tâche de lecture et une tâche d'écriture. Celle de lecture boucle simplement sur
|
||||
un paquet d'appels read(), construit les messages I2NP et les ajoute à notre file d'attente
|
||||
interne entrante. Il y a une file d'attente de messages sortants par connexion. La tâche d'écriture en extrait les messages
|
||||
et passe les données à travers les appels write().</p>
|
||||
<p>Nous effectuons ceci assez efficacement d'un point de vue charge UC - à tout moment,
|
||||
presque toutes ces tâches sont au repos, bloquées dans l'attente de grain à moudre.
|
||||
Cependant, chacune d'entre elles consomme des ressources réelles (par exemple sur de très vieux
|
||||
noyaux Linux, chacune sera souvent mise en œuvre en tant que processus fork()'ed).
|
||||
À mesure de la croissance du réseau, le nombre de pairs auxquels chaque routeur voudra s'adresser
|
||||
augmentera (souvenez-vous, I2P est entièrement connecté, c'est-à-dire que chaque pair doit savoir
|
||||
comment passer des messages à tous les autres. Le support des routes réservées
|
||||
ne réduira probablement pas sensiblement le nombre de connexions
|
||||
nécessaires). Ce qui veut dire que dans un réseau de 100000 routeurs, chaque routeur
|
||||
aura jusqu'à 199998 tâches rien que pour s'occuper des connexions TCP!</p>
|
||||
<p>Évidement, ça ne marchera pas. Nous avons besoin d'une couche transport adaptative.
|
||||
<b><i>UDP et NIO sont implémentés dans I2P</i></b>
|
||||
<p>La communication TCP standard dans Java nécessite habituellement des appels de socket
|
||||
bloquants, et pour pour empêcher un socket de bloquer le bloquer tout le système, ces
|
||||
appels sont faits dans leur propres tâches. Notre transport TCP actuel
|
||||
est implémenté de façon naïve - pour chaque pair en relation, nous avons
|
||||
une tâche de lecture et une tâche d'écriture. Celle de lecture boucle simplement sur
|
||||
un paquet d'appels read(), construit les messages I2NP et les ajoute à notre file d'attente
|
||||
interne entrante. Il y a une file d'attente de messages sortants par connexion. La tâche d'écriture en extrait les messages
|
||||
et passe les données à travers les appels write().</p>
|
||||
<p>Nous effectuons ceci assez efficacement d'un point de vue charge UC - à tout moment,
|
||||
presque toutes ces tâches sont au repos, bloquées dans l'attente de grain à moudre.
|
||||
Cependant, chacune d'entre elles consomme des ressources réelles (par exemple sur de très vieux
|
||||
noyaux Linux, chacune sera souvent mise en œuvre en tant que processus fork()'ed).
|
||||
À mesure de la croissance du réseau, le nombre de pairs auxquels chaque routeur voudra s'adresser
|
||||
augmentera (souvenez-vous, I2P est entièrement connecté, c'est-à-dire que chaque pair doit savoir
|
||||
comment passer des messages à tous les autres. Le support des routes réservées
|
||||
ne réduira probablement pas sensiblement le nombre de connexions
|
||||
nécessaires). Ce qui veut dire que dans un réseau de 100000 routeurs, chaque routeur
|
||||
aura jusqu'à 199998 tâches rien que pour s'occuper des connexions TCP!</p>
|
||||
<p>Évidement, ça ne marchera pas. Nous avons besoin d'une couche transport adaptative.
|
||||
Dans Java, nous disposons de deux approches principales:</p>
|
||||
<h4>UDP</h4>
|
||||
<b><i>Implémenté dans I2P 0.6 ("SSU") tel que documenté <a href="udp.html">ailleurs</a>.</i></b>
|
||||
<p>L'envoi et la réception de datagrammes UDP sont des opérations sans connexion - si
|
||||
<b><i>Implémenté dans I2P 0.6 ("SSU") tel que documenté <a href="udp.html">ailleurs</a>.</i></b>
|
||||
<p>L'envoi et la réception de datagrammes UDP sont des opérations sans connexion - si
|
||||
on communique avec 100000 pairs, on colle simplement les paquets UDP dans une file
|
||||
d'attente et on fait avec une seule tâche pour les extraire et les pousser dans le tuyau
|
||||
(et pour recevoir, une seule tâche en tire les paquets UDP reçus et les ajoute dans une file d'entrée).</p>
|
||||
<p>L'ennui, c'est que l'utilisation de UDP fait perdre les avantages de TCP (réordonnancement, gestion de la congestion,
|
||||
découverte du MTU, etc). Mettre ce code en œuvre demandera un travail important,
|
||||
mais I2P n'a pas besoin d'être aussi solide que TCP. Précisément,
|
||||
lorsque j'ai fait des mesures au simulateur et en réel sur Internet,
|
||||
la plupart des messages transférés tenaient facilement dans un seul paquet UDP
|
||||
non fragmenté, et les plus gros messages prenaient 20 à 30 paquets.
|
||||
Comme <i>mule</i> le mit en évidence, TCP ajoute une surcharge certaine quand il s'agit de gérer
|
||||
autant de petits paquets, vu que les ACKs sont du même ordre de grandeur.
|
||||
Avec UDP, nous pouvons optimiser le transport tant pour l'efficacité que pour la souplesse
|
||||
en prenant en compte les besoins spécifiques d'I2P.</p>
|
||||
<p>Ça ne va quand-même pas être un travail énorme.</p>
|
||||
d'attente et on fait avec une seule tâche pour les extraire et les pousser dans le tuyau
|
||||
(et pour recevoir, une seule tâche en tire les paquets UDP reçus et les ajoute dans une file d'entrée).</p>
|
||||
<p>L'ennui, c'est que l'utilisation de UDP fait perdre les avantages de TCP (réordonnancement, gestion de la congestion,
|
||||
découverte du MTU, etc). Mettre ce code en œuvre demandera un travail important,
|
||||
mais I2P n'a pas besoin d'être aussi solide que TCP. Précisément,
|
||||
lorsque j'ai fait des mesures au simulateur et en réel sur Internet,
|
||||
la plupart des messages transférés tenaient facilement dans un seul paquet UDP
|
||||
non fragmenté, et les plus gros messages prenaient 20 à 30 paquets.
|
||||
Comme <i>mule</i> le mit en évidence, TCP ajoute une surcharge certaine quand il s'agit de gérer
|
||||
autant de petits paquets, vu que les ACKs sont du même ordre de grandeur.
|
||||
Avec UDP, nous pouvons optimiser le transport tant pour l'efficacité que pour la souplesse
|
||||
en prenant en compte les besoins spécifiques d'I2P.</p>
|
||||
<p>Ça ne va quand-même pas être un travail énorme.</p>
|
||||
<h4>NIO or NBIO</h4>
|
||||
<b><i>NIO implémenté dans I2P 0.6.1.22 ("NTCP")</i></b>
|
||||
<b><i>NIO implémenté dans I2P 0.6.1.22 ("NTCP")</i></b>
|
||||
<p>Java 1.4 propose un jeu de paquetage "New I/O", permettant aux
|
||||
développeurs de tirer avantage des possibilités d'E/S non bloquantes du système d'exploitation
|
||||
- vous pouvez maintenir un grand nombre d'opérations d'E/S simultanées sans avoir besoin de définir une tâche
|
||||
dédiée pour chacune. Cette approche est très prometteuse, car nous pouvons utiliser un grand nombre de connexion
|
||||
simultanées et nous n'avons pas besoin d'écrire une mini-pile TCP pour UDP. Cependant, selon les développeurs
|
||||
de Freenet les paquetages NIO n'ont passé l'épreuve du feu. De plus, le recours aux NIO impliquerait une
|
||||
incompatibilité avec les JVM open-sources telles que <a href="http://www.kaffe.org/">Kaffe</a>, car
|
||||
<a href="http://www.classpath.org/">GNU/Classpath</a> ne les supporte que partiellement. <i>(note: ça ne devrait
|
||||
pas durer car il y a eu quelques progrès dans les NIO de Classpath, bien qu'en quantité inconnue)</i></p>
|
||||
<p>Dans la même veine, il y a l'alternative du paquetage
|
||||
développeurs de tirer avantage des possibilités d'E/S non bloquantes du système d'exploitation
|
||||
- vous pouvez maintenir un grand nombre d'opérations d'E/S simultanées sans avoir besoin de définir une tâche
|
||||
dédiée pour chacune. Cette approche est très prometteuse, car nous pouvons utiliser un grand nombre de connexion
|
||||
simultanées et nous n'avons pas besoin d'écrire une mini-pile TCP pour UDP. Cependant, selon les développeurs
|
||||
de Freenet les paquetages NIO n'ont passé l'épreuve du feu. De plus, le recours aux NIO impliquerait une
|
||||
incompatibilité avec les JVM open-sources telles que <a href="http://www.kaffe.org/">Kaffe</a>, car
|
||||
<a href="http://www.classpath.org/">GNU/Classpath</a> ne les supporte que partiellement. <i>(note: ça ne devrait
|
||||
pas durer car il y a eu quelques progrès dans les NIO de Classpath, bien qu'en quantité inconnue)</i></p>
|
||||
<p>Dans la même veine, il y a l'alternative du paquetage
|
||||
<a href="http://www.eecs.harvard.edu/~mdw/proj/java-nbio/">Non blocking IO</a> -
|
||||
essentiellement une implémentation NIO de salle blanche (écrite avant la parution des NIO).
|
||||
Il utilise du code natif du SE pour faire les E/S non bloquantes, en présentant les évènements via Java.
|
||||
Il semble fonctionner avec Kaffe, mais il a peu d'activité de développement à son sujet (probablement
|
||||
à cause de la parution des NIO de Java 1.4).</p>
|
||||
essentiellement une implémentation NIO de salle blanche (écrite avant la parution des NIO).
|
||||
Il utilise du code natif du SE pour faire les E/S non bloquantes, en présentant les évènements via Java.
|
||||
Il semble fonctionner avec Kaffe, mais il a peu d'activité de développement à son sujet (probablement
|
||||
à cause de la parution des NIO de Java 1.4).</p>
|
||||
</li>
|
||||
</ul>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
<h3 id="netdb">Base de donnée réseau, ajustement de profil et stratégie d'éjection pour les grands réseaux.</h3>
|
||||
<p>Dans l'implémentation actuelle de la base de donnée réseau et de la gestion de profil,
|
||||
<h3 id="netdb">Base de donnée réseau, ajustement de profil et stratégie d'éjection pour les grands réseaux.</h3>
|
||||
<p>Dans l'implémentation actuelle de la base de donnée réseau et de la gestion de profil,
|
||||
on s'est permis quelques raccourcis pratiques. Par exemple, nous n'avons pas de code pour
|
||||
nettoyer les références aux pairs dans les K-buckets, vu que nous n'avons pas assez de pairs pour avoir ne
|
||||
serait-ce qu'une petite chance d'en remplir une. Alors on garde les pairs dans n'importe quelle liste appropriée.
|
||||
Un autre exemple avec les profils de pairs: la quantité de mémoire nécessaire pour maintenir chaque profil est suffisamment
|
||||
faible pour que nous puissions garder des milliers de profils bien détaillés sans aucun problème.
|
||||
Comme nous avons la possibilité d'utiliser des profils réduits (dont nous pouvons maintenir des centaines de
|
||||
milliers en mémoire), nous n'avons pas non-plus le code qui ferait la conversion de détaillé en réduit et vice-versa,
|
||||
ni même la purge des deux. Ça ne serait pertinent d'écrire ce code maintenant car nous sommes loin d'en avoir besoin
|
||||
nettoyer les références aux pairs dans les K-buckets, vu que nous n'avons pas assez de pairs pour avoir ne
|
||||
serait-ce qu'une petite chance d'en remplir une. Alors on garde les pairs dans n'importe quelle liste appropriée.
|
||||
Un autre exemple avec les profils de pairs: la quantité de mémoire nécessaire pour maintenir chaque profil est suffisamment
|
||||
faible pour que nous puissions garder des milliers de profils bien détaillés sans aucun problème.
|
||||
Comme nous avons la possibilité d'utiliser des profils réduits (dont nous pouvons maintenir des centaines de
|
||||
milliers en mémoire), nous n'avons pas non-plus le code qui ferait la conversion de détaillé en réduit et vice-versa,
|
||||
ni même la purge des deux. Ça ne serait pertinent d'écrire ce code maintenant car nous sommes loin d'en avoir besoin
|
||||
avant longtemps.</p>
|
||||
<p>Ceci dit, nous devons quand même garder ça en tête car la taille du réseau grandit.
|
||||
Il restera du travail, mais on peut le remettre à plus tard.</p>
|
||||
<p>Ceci dit, nous devons quand même garder ça en tête car la taille du réseau grandit.
|
||||
Il restera du travail, mais on peut le remettre à plus tard.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<h2 id="security">Sécurité / anonymat</h2>
|
||||
<h2 id="security">Sécurité / anonymat</h2>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
<h3 id="tunnelId">ID de tunnel "par saut" & nouvelle encryption permutée de la structure de vérification des tunnels.</h3>
|
||||
<b><i>Depuis I2P v0.5 et documenté <a href="tunnel-alt.html">là</a>.</i></b>
|
||||
<p>À l'heure actuelle, quand Alice initie un tunnel entrant à quatre sauts commençant par Elvis,
|
||||
<h3 id="tunnelId">ID de tunnel "par saut" & nouvelle encryption permutée de la structure de vérification des tunnels.</h3>
|
||||
<b><i>Depuis I2P v0.5 et documenté <a href="tunnel-alt.html">là</a>.</i></b>
|
||||
<p>À l'heure actuelle, quand Alice initie un tunnel entrant à quatre sauts commençant par Elvis,
|
||||
puis passant par Dave, puis Charlie,puis Bob, et se terminant chez elle, Alice (A<--B<--C<--D<--E),
|
||||
tous les cinq sont au fait qu'ils participent au tunnel "123", car
|
||||
les messages en font état (TunnelID commun). Nous voulons donner à chaque saut un
|
||||
les messages en font état (TunnelID commun). Nous voulons donner à chaque saut un
|
||||
identifiant unique de saut de tunnel: Charlie recevra des messages sur le tunnel 234
|
||||
et les transmettra à Bob par le tunnel 876. Le but est d'empêcher Bob ou
|
||||
et les transmettra à Bob par le tunnel 876. Le but est d'empêcher Bob ou
|
||||
Charlie de savoir qu'ils participent au tunnel d'Alice, car quand chaque saut
|
||||
a le même tunnelID pour un tunnel donné, les attaques par coalition sont simples à mettre en œuvre.
|
||||
a le même tunnelID pour un tunnel donné, les attaques par coalition sont simples à mettre en œuvre.
|
||||
</p>
|
||||
<p>L'ajout d'un TunnelID unique par saut n'est pas difficile, mais c'est insuffisant:
|
||||
Si Dave et Bob sont contrôlés par le même attaquant, ils ne pourraient plus identifier un tunnel
|
||||
par leur participation commune via l'information TunnelID, mais seraient quand-même capable de le
|
||||
faire par simple comparaison des corps de messages et des structures de vérification.
|
||||
Pour l'empêcher, le tunnel doit appliquer un cryptage étagé tout au long du chemin,
|
||||
à la fois sur la charge utile et les structures de vérification (utilisées pour empêcher les attaques
|
||||
par marquages). On a besoin de modifications simples du TunnelMessage, et aussi d'inclure par saut, des clés
|
||||
secrètes générées pendant la création du tunnel et passées à la passerelle du tunnel.
|
||||
Nous devons définir une longueur maximale de tunnel (p.e. 16 sauts)
|
||||
et indiquer à la passerelle de chiffrer le message pour chacune des 16 clés,
|
||||
en ordre inverse, et de crypter la signature du hachage de la charge utile (cryptée) à chaque étape.
|
||||
La passerelle envoie alors ce message au premier saut chiffré 16 fois, accompagné d'un plan
|
||||
à 16 entrée chiffré 16 fois. Le premier saut déchiffre le plan et la charge utile avec leur clef secrète
|
||||
pour chercher dans le plan l'entrée associée à son propre saut (indiquée par le tunnelID unique par saut)
|
||||
et pour vérifier la charge utile en la confrontant au hachage signé associé.
|
||||
Si Dave et Bob sont contrôlés par le même attaquant, ils ne pourraient plus identifier un tunnel
|
||||
par leur participation commune via l'information TunnelID, mais seraient quand-même capable de le
|
||||
faire par simple comparaison des corps de messages et des structures de vérification.
|
||||
Pour l'empêcher, le tunnel doit appliquer un cryptage étagé tout au long du chemin,
|
||||
à la fois sur la charge utile et les structures de vérification (utilisées pour empêcher les attaques
|
||||
par marquages). On a besoin de modifications simples du TunnelMessage, et aussi d'inclure par saut, des clés
|
||||
secrètes générées pendant la création du tunnel et passées à la passerelle du tunnel.
|
||||
Nous devons définir une longueur maximale de tunnel (p.e. 16 sauts)
|
||||
et indiquer à la passerelle de chiffrer le message pour chacune des 16 clés,
|
||||
en ordre inverse, et de crypter la signature du hachage de la charge utile (cryptée) à chaque étape.
|
||||
La passerelle envoie alors ce message au premier saut chiffré 16 fois, accompagné d'un plan
|
||||
à 16 entrée chiffré 16 fois. Le premier saut déchiffre le plan et la charge utile avec leur clef secrète
|
||||
pour chercher dans le plan l'entrée associée à son propre saut (indiquée par le tunnelID unique par saut)
|
||||
et pour vérifier la charge utile en la confrontant au hachage signé associé.
|
||||
</p>
|
||||
<p>La passerelle dispose encore de plus d'informations que les autre pairs,
|
||||
et sa compromission avec un participant leur permettrait d'identifier leur participation à un tunnel donné.
|
||||
De toute façon, les pairs voisins savent qu'ils participent au même tunnel, car ils savent à qui ils
|
||||
envoient un message (et avec les transports IP sans routes réservées, ils savent aussi de qui ils reçoivent).
|
||||
Malgré tout, les deux techniques ci-dessus augmentent très sensiblement le coût d'obtention d'échantillons
|
||||
signifiants dans des tunnels très longs.</p>
|
||||
et sa compromission avec un participant leur permettrait d'identifier leur participation à un tunnel donné.
|
||||
De toute façon, les pairs voisins savent qu'ils participent au même tunnel, car ils savent à qui ils
|
||||
envoient un message (et avec les transports IP sans routes réservées, ils savent aussi de qui ils reçoivent).
|
||||
Malgré tout, les deux techniques ci-dessus augmentent très sensiblement le coût d'obtention d'échantillons
|
||||
signifiants dans des tunnels très longs.</p>
|
||||
</li>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
@ -194,7 +194,7 @@ Traduction en cours (25 fév 2011)
|
||||
<ul class="targetlist">
|
||||
<p>Comme Connelly <a href="http://dev.i2p/pipermail/i2p/2004-July/000335.html">a proposé</a>
|
||||
de s'occuper du problème de l'<a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">attaque par
|
||||
predécesseur</a> <a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">(mise à jour 2008)</a>,
|
||||
prédécesseur</a> <a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">(mise à jour 2008)</a>,
|
||||
conserver l'ordre des pairs au sein d'un tunnel (autrement dit,
|
||||
chaque fois qu'Alice crée un tunnel à l'aide de Bob et de Charlie,le saut suivant Bob sera toujours
|
||||
Charlie), nous en sommes protégés car Bob ne peut pas obtenir une connaissance substantielle du
|
||||
@ -219,9 +219,9 @@ Traduction en cours (25 fév 2011)
|
||||
<p>Sans la permutation de longueur de tunnel, s'il advenait que quelqu'un puisse de quelque façon
|
||||
détecter qu'une destination se trouve à un certain nombre de sauts, il pourrait mettre à profit
|
||||
cette information pour identifier le routeur se trouvant à cette destination,
|
||||
par l'attaque du prédecesseur. Par exemple, si tout le monde a des tunnels à deux saut, si Bob
|
||||
reçois un message de tunnel de Charlie et le transfère à Alice, Bob déduit qu'
|
||||
Alice est le routeur final du tunnel. Si Bob pouvait identifier la destination à laquelle mène
|
||||
par l'attaque du prédécesseur. Par exemple, si tout le monde a des tunnels à deux saut, si Bob
|
||||
reçois un message de tunnel de Charlie et le transfère à Alice, Bob déduit qu'Alice est
|
||||
le routeur final du tunnel. Si Bob pouvait identifier la destination à laquelle mène
|
||||
ce tunnel (au moyen d'une collusion avec la passerelle et en collectant tous les baux de la base de donnée
|
||||
du réseau), il trouverait le routeur hébergeant la destination (et sans les routes réservées, ça indiquerait
|
||||
l'adresse IP de la destination).</p>
|
||||
@ -230,85 +230,79 @@ Traduction en cours (25 fév 2011)
|
||||
pour les tunnels à zéro saut passés en revue ci-dessus).</p>
|
||||
|
||||
<li>
|
||||
<h3 id="fullRestrictedRoutes">Routes réservées à n-sauts
|
||||
évoluées avec liens de confiance optionnels.</h3>
|
||||
<h3 id="fullRestrictedRoutes">Routes réservées à n-sauts
|
||||
évoluées avec liens de confiance optionnels.</h3>
|
||||
<p>La fonctionnalité de route réservée décrite précédemment était simplement
|
||||
un défaut de fonctionnement: comment laisser des pairs communiquer, qui sans cela ne le pourraient pas.
|
||||
Cependant, l'idée d'autoriser des routes réservées apporte de nouvelles possibilités.
|
||||
Par exemple, si un routeur ne peut absolument pas prendre le risque de communiquer
|
||||
directement avec des pairs sans confiance pré-établie, ils peuvent monter des liens de confiance avec ces pairs,
|
||||
using them to both send and receive all of its messages.
|
||||
Those hidden peers who want to be completely isolated would also refuse
|
||||
to connect to peers who attempt to get them to (as demonstrated by the
|
||||
garlic routing technique outlined before) - they can simply take the garlic
|
||||
clove that has a request for delivery to a particular peer and tunnel
|
||||
route that message out one of the hidden peer's trusted links with instructions
|
||||
to forward it as requested.</p>
|
||||
directement avec des pairs sans confiance pré-établie, il peut monter des liens de confiance à travers eux,
|
||||
pour les utiliser pour à la fois envoyer et recevoir tous ses messages.
|
||||
Ces pairs cachés qui souhaitent rester complètement isolés devraient aussi refuser de se connecter
|
||||
aux pairs qui les y invitent (comme démontré dans le schéma de la technique de routage en gousse d'ail "garlic
|
||||
routing" exposée précédemment) - ils peuvent simplement prendre la gousse ("clove") qui présente une requête
|
||||
d'envoi à un pair particulier, et router le message dans un tunnel vers un des liens de confiance
|
||||
du pair caché, avec les instructions pour le faire suivre comme demandé.</p>
|
||||
</li>
|
||||
<li>
|
||||
<h3 id="hashcash">Hashcash for routerIdentity, destination, and tunnel request</h3>
|
||||
<p>Within the network, we will want some way to deter people from consuming
|
||||
too many resources or from creating so many peers to mount a <a href="http://citeseer.ist.psu.edu/douceur02sybil.html">Sybil</a>
|
||||
attack. Traditional techniques such as having a peer see who is requesting
|
||||
a resource or running a peer aren't appropriate for use within I2P, as
|
||||
doing so would compromise the anonymity of the system. Instead, we want
|
||||
to make certain requests "expensive".</p>
|
||||
<p><a href="http://www.hashcash.org/">Hashcash</a> is one technique that
|
||||
we can use to anonymously increase the "cost" of doing certain activities,
|
||||
such as creating a new router identity (done only once on installation),
|
||||
creating a new destination (done only once when creating a service), or
|
||||
requesting that a peer participate in a tunnel (done often, perhaps 2-300
|
||||
times per hour). We don't know the "correct" cost of each type of certificate
|
||||
yet, but with some research and experimentation, we could set a base level
|
||||
that is sufficiently expensive while not an excessive burden for people
|
||||
with few resources.</p>
|
||||
<p>There are a few other algorithms that we can explore for making those
|
||||
requests for resources "nonfree", and further research on that front is
|
||||
appropriate.</p>
|
||||
<h3 id="hashcash">Pénalités (Hashcash) pour les requêtes routerIdentity, destination, et demande de tunnel.</h3>
|
||||
<p>Dans le réseau, nous avons besoin de dissuader les gens de consommer
|
||||
de trop nombreuses ressources ou de créer trop de pairs dans le but de lancer une
|
||||
<a href="http://citeseer.ist.psu.edu/douceur02sybil.html">attaque de Sibylle</a>. Les techniques
|
||||
traditionnelles telles permettre à un pair de voir qui demande une ressource ou est un autre pair
|
||||
ne sont pas pertinentes dans I2P, car cela compromettrait l'anonymat du système. Nous nous tournons vers
|
||||
la méthode consistant à rendre certaines requêtes coûteuses.</p>
|
||||
<p><a href="http://www.hashcash.org/">Hashcash</a> est une technique que nous pouvons utiliser
|
||||
pour anonymement accroitre le coût de certaines activités, telles que créer une nouvelle identité de routeur
|
||||
(faite une seule fois pendant l'installation), créer une nouvelle destination (faite une seule fois
|
||||
à la création d'un service), ou demander qu'un pair participe à un tunnel (faite souvent, peut-être 200 à 300
|
||||
fois par heure). Nous ne connaissons encore pas le coût "correct" de chaque type de certificat,
|
||||
mais avec un peu de recherche et d'expérimentation, nous devrions pouvoir élaborer un "tarif" qui sera dissuasif
|
||||
tout en restant une charge abordable pour ceux dotés de peu de ressources.</p>
|
||||
<p>Il y a peu d'autres algorithmes à explorer pour enlever la gratuité des ces requêtes,
|
||||
et des recherches plus approfondies dans ce domaine sont souhaitables.</p>
|
||||
</li>
|
||||
<li>
|
||||
<h3 id="batching">Advanced tunnel operation (batching/mixing/throttling/padding)</h3>
|
||||
<p>To powerful passive external observers as well as large colluding internal
|
||||
observers, standard tunnel routing is vulnerable to traffic analysis attacks
|
||||
- simply watching the size and frequency of messages being passed between
|
||||
routers. To defend against these, we will want to essentially turn some
|
||||
of the tunnels into its own mix cascade - delaying messages received at
|
||||
the gateway and passing them in batches, reordering them as necessary,
|
||||
and injecting dummy messages (indistinguishable from other "real" tunnel
|
||||
messages by peers in the path). There has been a significant amount of
|
||||
<a href="http://freehaven.net/doc/sync-batching/sync-batching.pdf">research</a>
|
||||
on these algorithms that we can lean on prior to implementing the various
|
||||
tunnel mixing strategies.</p>
|
||||
<p>In addition to the anonymity aspects of more varied tunnel operation,
|
||||
there is a functional dimension as well. Each peer only has a certain
|
||||
amount of data they can route for the network, and to keep any particular
|
||||
tunnel from consuming an unreasonable portion of that bandwidth, they
|
||||
will want to include some throttles on the tunnel. For instance, a tunnel
|
||||
may be configured to throttle itself after passing 600 messages (1 per
|
||||
second), 2.4MB (4KBps), or exceeding some moving average (8KBps for the
|
||||
last minute). Excess messages may be delayed or summarily dropped. With
|
||||
this sort of throttling, peers can provide ATM-like QoS support for their
|
||||
tunnels, refusing to agree to allocate more bandwidth than the peer has
|
||||
available.</p>
|
||||
<p>In addition, we may want to implement code to dynamically reroute tunnels
|
||||
to avoid failed peers or to inject additional hops into the path. This
|
||||
can be done by garlic routing a message to any particular peer in a tunnel
|
||||
with instructions to redefine the next-hop in the tunnel.</p>
|
||||
<h3 id="batching">Fonctionnement évolué des tunnels (regroupement/mélange/étranglement/remplissage)</h3>
|
||||
<p>Du point de vue d'observateurs passifs externes et puissants comme d'une grande coalition interne,
|
||||
le routage en tunnel standard est vulnérable aux attaques par analyse de trafic (à simplement
|
||||
regarder la taille et la fréquence des messages passant entre les routeurs).
|
||||
Pour nous en prémunir, nous modifions principalement quelques uns des tunnels
|
||||
au niveau de leurs propres éléments constituants: retarder les messages reçus sur la passerelle
|
||||
et les transférer regroupés, les réordonner si nécessaire,
|
||||
et injecter des messages fictifs (indiscernables des autre "vrais" messages de tunnel
|
||||
par les pairs du chemin). Il y a eu sur ces algorithmes un gros travail de
|
||||
<a href="http://freehaven.net/doc/sync-batching/sync-batching.pdf">recherche</a>
|
||||
sur lequel nous pouvons nous appuyer pour commencer à implémenter les diverses
|
||||
de mélange de tunnel.</p>
|
||||
<p>En plus des aspects d'anonymat du mode opératoire plus varié des tunnels,
|
||||
il y a aussi une dimension fonctionnelle. Chaque pair n'a qu'une partie des
|
||||
données qui sont destinées au réseau, et pour éviter qu'un tunnel donné
|
||||
ne consomme trop de bande passante, il peut y introduire quelques freins. Par exemple,
|
||||
un tunnel peut être configurer pour ralentir après avoir passé 600 messages (1 par
|
||||
seconde), 2,4Mo (4kb/s), ou dépasser quelque peu la moyenne mobile (8kb/s pendant
|
||||
dernière minute). Les messages en excès peuvent se voir retardés brutalement ignorés. Avec
|
||||
ce genre de régulation, les pairs peuvent offrir une QoS de genre ATM à leurs tunnels,
|
||||
en refusant d'allouer plus de bande passante qu'ils n'en disposent.</p>
|
||||
<p>En complément, nous pourrions implémenter du code destiné à re-router dynamiquement des tunnels
|
||||
pour éviter les pairs défaillants ou pour introduire des sauts supplémentaires dans le chemin.
|
||||
ceci peut être réalisé en envoyant un message routé "à la garlic" à un pair particulier du tunnel
|
||||
pour lui fournir les instructions destinées à redéfinir le saut suivant du tunnel.</p>
|
||||
</li>
|
||||
<li>
|
||||
<h3 id="stop">Stop & go mix w/ garlics & tunnels</h3>
|
||||
<p>Beyond the per-tunnel batching and mixing strategy, there are further
|
||||
capabilities for protecting against powerful attackers, such as allowing
|
||||
each step in a garlic routed path to define a delay or window in which
|
||||
it should be forwarded on. This would enable protections against the long
|
||||
term intersection attack, as a peer could send a message that looks perfectly
|
||||
standard to most peers that pass it along, except at any peers where the
|
||||
clove exposed includes delay instructions.</p>
|
||||
<h3 id="stop">Mélange de Stop & Go pour les <a href="http://www.i2p2.de/how_garlicrouting.html">"garlics"</a> et les tunnels.</h3>
|
||||
<p>Au-delà de la stratégie de regroupement et de mélange par tunnel, il y a d'autres moyens de se
|
||||
protéger des attaques des attaquants puissants, comme permettre à chaque saut
|
||||
dans un chemin routé en gousse d'ail de définir un délai ou un intervalle au bout ou pendant lequel il
|
||||
devrait être transféré. Ceci protègerait des attaques contre les intersections de longue durée,
|
||||
car un pair pourrait envoyer un message qui paraitrait parfaitement standard à la plupart
|
||||
des pairs qui le font suivre, sauf à ceux où la gousse exposée inclus des instructions de délai.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<h2 id="performance">Performances</h2>
|
||||
<p>
|
||||
Les améliorations de performances sont répertoriées sur une page dédiée aux
|
||||
Les améliorations de performances sont répertoriées sur une page dédiée aux
|
||||
<a href="performance.html">performances</a>.
|
||||
</p>
|
||||
Traduction un poil laborieuse de fin février 2011. Toute amélioration est bienvenue. magma
|
||||
{% endblock %}
|
||||
|
||||
Reference in New Issue
Block a user