udp todo_fr
This commit is contained in:
magma
@ -112,92 +112,80 @@ Traduction en cours (25 fév 2011)
|
||||
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 malgré tout pas être un énorme travail.</p>
|
||||
<p>Ça ne va quand-même pas être un travail énorme.</p>
|
||||
<h4>NIO or NBIO</h4>
|
||||
<b><i>NIO Implemented in I2P 0.6.1.22 ("NTCP")</i></b>
|
||||
<p>In Java 1.4, a set of "New I/O" packages was introduced, allowing Java
|
||||
developers to take advantage of the operating system's nonblocking IO
|
||||
capabilities - allowing you to maintain a large number of concurrent IO
|
||||
operations without requiring a separate thread for each. There is much
|
||||
promise with this approach, as we can scalable handle a large number of
|
||||
concurrent connections and we don't have to write a mini-TCP stack with
|
||||
UDP. However, the NIO packages have not proven themselves to be battle-ready,
|
||||
as the Freenet developer's found. In addition, requiring NIO support would
|
||||
mean we can't run on any of the open source JVMs like <a href="http://www.kaffe.org/">Kaffe</a>,
|
||||
as <a href="http://www.classpath.org/">GNU/Classpath</a> has only limited
|
||||
support for NIO. <i>(note: this may not be the case anymore, as there
|
||||
has been some progress on Classpath's NIO, but it is an unknown quantity)</i></p>
|
||||
<p>Another alternative along the same lines is the <a href="http://www.eecs.harvard.edu/~mdw/proj/java-nbio/">Non
|
||||
Blocking I/O</a> package - essentially a cleanroom NIO implementation
|
||||
(written before NIO was around). It works by using some native OS code
|
||||
to do the nonblocking IO, passing off events through Java. It seems to
|
||||
be working with Kaffe, though there doesn't seem to be much development
|
||||
activity on it lately (likely due to 1.4's NIO deployment).</p>
|
||||
<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 blocantes 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 blocantes, 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">NetworkDB and profile tuning and ejection policy for large
|
||||
nets</h3>
|
||||
<p>Within the current network database and profile management implementation,
|
||||
we have taken the liberty of some practical shortcuts. For instance, we
|
||||
don't have the code to drop peer references from the K-buckets, as we
|
||||
don't have enough peers to even plausibly fill any of them, so instead,
|
||||
we just keep the peers in whatever bucket is appropriate. Another example
|
||||
deals with the peer profiles - the memory required to maintain each peer's
|
||||
profile is small enough that we can keep thousands of full blown profiles
|
||||
in memory without problems. While we have the capacity to use trimmed
|
||||
down profiles (which we can maintain 100s of thousands in memory), we
|
||||
don't have any code to deal with moving a profile from a "minimal profile"
|
||||
to a "full profile", a "full profile" to a "minimal profile", or to simply
|
||||
eject a profile altogether. It just wouldn't be practical to write that
|
||||
code yet, since we aren't going to need it for a while.</p>
|
||||
<p>That said, as the network grows we are going to want to keep these considerations
|
||||
in mind. We will have some work to do, but we can put it off for later.</p>
|
||||
<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 permi 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 suffisament
|
||||
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">Security / anonymity</h2>
|
||||
<h2 id="security">Sécurité / anonymat</h2>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
<h3 id="tunnelId">Per-hop tunnel id & new permuted TunnelVerificationStructure
|
||||
<h3 id="tunnelId">ID de tunnel "par saut" & nouvelle encryption permutée de la structure de vérification des tunnels. TunnelVerificationStructure
|
||||
encryption</h3>
|
||||
<b><i>Addressed in I2P 0.5 as documented <a href="tunnel-alt.html">elsewhere</a></i></b>
|
||||
<p>Right now, if Alice builds a four hop inbound tunnel starting at Elvis,
|
||||
going to Dave, then to Charlie, then Bob, and finally Alice (A<--B<--C<--D<--E),
|
||||
all five of them will know they are participating in tunnel "123", as
|
||||
the messages are tagged as such. What we want to do is give each hop their
|
||||
own unique tunnel hop ID - Charlie will receive messages on tunnel 234
|
||||
and forward them to tunnel 876 on Bob. The intent is to prevent Bob or
|
||||
Charlie from knowing that they are in Alice's tunnel, as if each hop in
|
||||
the tunnel had the same tunnel ID, collusion attacks aren't much work.
|
||||
<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 font 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>Adding a unique tunnel ID per hop isn't hard, but by itself, insufficient.
|
||||
If Dave and Bob are under the control of the same attacker, they wouldn't
|
||||
be able to tell they are in the same tunnel due to the tunnel ID, but
|
||||
would be able to tell by the message bodies and verification structures
|
||||
by simply comparing them. To prevent that, the tunnel must use layered
|
||||
encryption along the path, both on the payload of the tunneled message
|
||||
and on the verification structure (used to prevent simple tagging attacks).
|
||||
This requires some simple modifications to the TunnelMessage, as well
|
||||
as the inclusion of per-hop secret keys delivered during tunnel creation
|
||||
and given to the tunnel's gateway. We must fix a maximum tunnel length
|
||||
(e.g. 16 hops) and instruct the gateway to encrypt the message to each
|
||||
of the 16 delivered secret keys, in reverse order, and to encrypt the
|
||||
signature of the hash of the (encrypted) payload at each step. The gateway
|
||||
then sends that 16-step encrypted message, along with a 16-step and 16-wide
|
||||
encrypted mapping to the first hop, which then decrypts the mapping and
|
||||
the payload with their secret key, looking in the 16-wide mapping for
|
||||
the entry associated with their own hop (keyed by the per-hop tunnel ID)
|
||||
and verifying the payload by checking it against the associated signed
|
||||
hash.</p>
|
||||
<p>The tunnel gateway does still have more information than the other peers
|
||||
in the tunnel, and compromising both the gateway and a tunnel participant
|
||||
would allow those peers to collude, exposing the fact that they are both
|
||||
in the same tunnel. In addition, neighboring peers know that they are
|
||||
in the same tunnel anyway, as they know who they send the message to (and
|
||||
with IP-based transports without restricted routes, they know who they
|
||||
got it from). However, the above two techniques significantly increase
|
||||
the cost of gaining meaningful samples when dealing with longer tunnels.</p>
|
||||
<p>La passerelle dispose encore de plus d'informations que les autre pairs,
|
||||
et sa compromission avec un participant leur permettrait d'indentier 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 transport 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'obtension d'échantillons
|
||||
signifiants dans des tunnels très longs.</p>
|
||||
</li>
|
||||
<ul class="targetlist">
|
||||
<li>
|
||||
@ -322,9 +310,9 @@ Traduction en cours (25 fév 2011)
|
||||
clove exposed includes delay instructions.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<h2 id="performance">Performance</h2>
|
||||
<h2 id="performance">Performances</h2>
|
||||
<p>
|
||||
Performance related improvements are listed on the
|
||||
<a href="performance.html">Performance</a> page.
|
||||
Les améliorations de performances sont répertoriées sur une page dédiée aux
|
||||
<a href="performance.html">performances</a>.
|
||||
</p>
|
||||
{% endblock %}
|
||||
|
||||
Reference in New Issue
Block a user