309 lines
25 KiB
HTML
309 lines
25 KiB
HTML
{% extends "_layout_fr.html" %}
|
|
{% block title %}À faire / Sur le feu{% endblock %}
|
|
{% block content %}
|
|
<h1>Cibles du project I2P</h1>
|
|
|
|
<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>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="#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>
|
|
</ul>
|
|
<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="#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">Pénalités 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>
|
|
<ul class="targetlist">
|
|
<li>
|
|
<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 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>
|
|
</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>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
|
|
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
|
|
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>
|
|
</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.
|
|
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
|
|
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>
|
|
<h4>NIO or NBIO</h4>
|
|
<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
|
|
<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>
|
|
</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,
|
|
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
|
|
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>
|
|
</li>
|
|
</ul>
|
|
<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,
|
|
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
|
|
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
|
|
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.
|
|
</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é.
|
|
</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>
|
|
</li>
|
|
<ul class="targetlist">
|
|
<li>
|
|
<h3 id="ordering">Position stricte des participants dans les tunnels.</h3>
|
|
<b><i>Implementé dans la v0.6.2</i></b></li>
|
|
</ul>
|
|
<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
|
|
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
|
|
groupe de sélection de pairs d'Alice. Nous pourrions même restreindre le mode de participation de Bob à
|
|
seulement recevoir de Dave et envoyer à Charlie - et l'un d'entre-eux n'est pas disponible
|
|
(surcharge, déconnexion, etc...), éviter de demander à Bob de participer à un tunnel tant qu'ils ne sont pas
|
|
de nouveau disponibles.</p>
|
|
<p>Une analyse plus poussée est nécessaire pour repenser la création du tunnel: pour l'instant,
|
|
nous piochons et ordonnons aléatoirement le premier tiers des pairs (ceux qui ont des capacités élevées et rapides).
|
|
</p>
|
|
<p>L'ajout d'un ordre strict des pairs dans un tunnel améliore aussi l'anonymat des pairs des tunnels à zéro saut,
|
|
car sinon, le fait que la passerelle d'un pair ait toujours la même passerelle serait rédhibitoire.
|
|
Cependant, les pairs avec un tunnel à zéro saut pourraient de temps en temps utiliser un tunnel à un saut
|
|
pour simuler la défaillance du pair passerelle habituellement fiable (donc toutes les
|
|
MTBF*(durée du tunnel)minutes, utiliser un tunnel à un saut).</p>
|
|
</ul>
|
|
<li>
|
|
<h3 id="tunnelLength">Permutation aléatoire des longueurs de tunnels.</h3>
|
|
<b><i>Prise en compte dans I2P v0.5, lire <a href="tunnel-alt.html">là</a>.</i></b></li>
|
|
</ul>
|
|
<ul class="targetlist">
|
|
<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é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>
|
|
<p>C'est pour contrer ce comportement que les longueurs de tunnel doivent être permutées,
|
|
en se servant d'algorithmes basés sur la longueur demandée (par exemple, le changement de longueur de 1/MTBF
|
|
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>
|
|
<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, 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">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">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 ou 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">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
|
|
<a href="performance.html">performances</a>.
|
|
</p>
|
|
Traduction un poil laborieuse de fin février 2011. Toute amélioration est bienvenue. magma
|
|
{% endblock %}
|