From cc5e3a373c43b481e7b4744c21f79b9d0b57e744 Mon Sep 17 00:00:00 2001
From: magma <magma@mail.i2p>
Date: Tue, 12 Apr 2011 15:06:43 +0000
Subject: [PATCH] the frog that says Ni

---
 www.i2p2/pages/how_threatmodel_fr.html | 123 ++++++++++++-------------
 1 file changed, 58 insertions(+), 65 deletions(-)

diff --git a/www.i2p2/pages/how_threatmodel_fr.html b/www.i2p2/pages/how_threatmodel_fr.html
index b90f5986..3e0805a2 100644
--- a/www.i2p2/pages/how_threatmodel_fr.html
+++ b/www.i2p2/pages/how_threatmodel_fr.html
@@ -89,7 +89,7 @@ Les pages sur la <a href="how_networkcomparisons.html">comparaison des réseaux<
 <li><a href="#sybil">Attaques de Sibylle</a></li>
 <li><a href="#buddy">Attaques de listage d'amis</a></li>
 <li><a href="#crypto">Attaques cryptographiques</a></li>
-<li><a href="#floodfill">Attaques d'innondation</a></li>
+<li><a href="#floodfill">Attaques d'inondation</a></li>
 <li><a href="#netdb">Autres attaques de base de données</a></li>
 <li><a href="#central">Attaques des ressources centralisées</a></li>
 <li><a href="#dev">Attaques de développement</a></li>
@@ -143,8 +143,9 @@ DataMessage+DeliveryStatusMessage).</p>
 <p>Sans camouflage du protocole ou latences plus élevées, des adversaires globaux actifs peuvent obtenir des 
 informations significatives. Les gens soucieux de ces attaques pourraient augmenter la latence (en utilisant des 
 <a href="todo_fr#stop">retards non négligeables</a> ou les 
-<a href="todo#batching">stratégies de traitement par lots</a>), le camouflage de protocole, ou d'autres 
-<a href="todo#batching">techniques</a> de routage en tunnel avancées, mais celles-ci ne sont pas implémentées dans I2P.
+<a href="todo_fr#batching">stratégies de traitement par lots</a>), le camouflage de protocole, ou d'autres 
+<a href="todo_fr#batching">techniques</a> de routage en tunnel avancées, mais celles-ci ne sont pas implémentées dans 
+I2P.
 </p>
 
 <p>Références:
@@ -197,7 +198,7 @@ mais plusieurs applications et services utilisent par défaut des tunnels à 2 s
 
 </p><p>
 Dans le futur, on peut envisager d'utiliser pour les pairs qui peuvent se le permettre, utiliser des délais importants 
-(via les <a href="todo#stop">retards volontaires</a> et les <a href="todo#batching">stratégies de traitement par 
+(via les <a href="todo_fr#stop">retards volontaires</a> et les <a href="todo_fr#batching">stratégies de traitement par 
 lots</a>). De plus, ceci ne vaut que pour les destinations que d'autres gens connaissent - un groupe privé dont la 
 destination n'est connue que par des pairs de confiance n'a pas à s'inquiéter, car un adversaire ne peut pas les 
 "pinguer" pour monter une attaque.</p>
@@ -208,75 +209,67 @@ destination n'est connue que par des pairs de confiance n'a pas à s'inquiéter,
 
 
 
-<h3 id="dos">Denial of service attacks</h3>
+<h3 id="dos">Déni de service</h3>
 
-<p>There are a whole slew of denial of service attacks available against I2P,
-each with different costs and consequences:</p><ul>
-<li><b>Greedy user attack:</b> This is simply
-    people trying to consume significantly more resources than they are 
-    willing to contribute.  The defense against this is:<ul>
-    <li>Set defaults so that most users provide resources to the network.
-    In I2P, users route traffic by default. In sharp distinction to
-    <a href="https://torproject.org/">other networks</a>,
-    over 95% of I2P users relay traffic for others.
+<p>Il y a tout un groupe d'attaques de déni de service disponibles contre I2P, chacune ayant ses propres coûts et 
+conséquences :</p><ul>
+<li><b>L'attaque du goinfre :</b> c'est simplement celui qui essaye de consommer beaucoup plus de ressources qu'il n'en 
+fournit. Les parades : <ul>
+    <li>Définir les réglages par défaut de telle sorte que les utilisateurs fournissent des ressources au réseau. Dans 
+I2P, les utilisateurs font par défaut du routage de trafic. À la différence radicale avec 
+d'<a href="https://torproject.org/">autres réseaux</a>, jusqu'à 95% des utilisateurs d'I2P relaient du trafic pour les 
+autres.
    </li>
-    <li>Provide easy configuration options so that users may increase their
-    contribution (share percentage) to the network. Display easy-to-understand
-    metrics such as "share ratio" so that users may see what they are contributing.
+    <li>Fournir des options de configuration simples à utiliser pour que les utilisateurs puissent augmenter leur 
+contribution au réseau (pourcentage de partage). Afficher des mesures simples à comprendre comme le ratio de partage 
+pour permettre aux utilisateur de voir en quoi ils contribuent.
    </li><lil>
-     Maintain a strong community with blogs, forums, IRC, and other means of communication.
+     Maintenir une forte communauté grâce à des blogs, des forums, l'IRC, et autres moyens de communication.
    </li></ul>
-<li><b>Starvation attack:</b> A hostile user may attempt to harm the network by
-    creating a significant number of peers in the network who are not identified as
-    being under control of the same entity (as with Sybil).  These nodes then 
-    decide not to provide any resources to the network, causing existing peers 
-    to search through a larger network database or request more tunnels than 
-    should be necessary. 
-    Alternatively, the nodes may provide intermittent service by periodically
-    dropping selected traffic, or refusing connections to certain peers.
-    This behavior may be indistinguishable from that of a heavily-loaded or failing node.
-    I2P addresses these issues by maintaining <a href="how_peerselection.html">profiles</a> on the 
-    peers, attempting to identify underperforming ones and simply ignoring 
-    them, or using them rarely.
-    We have significantly enhanced the
-    ability to recognize and avoid troublesome peers; however there are still
-    significant efforts required in this area.
+<li><b>L'attaque de la famine :</b> l'utilisateur hostile peut tenter de vicier le réseau en créant un grand nombre de 
+pairs n'étant bien sûr pas identifiés comme contrôlés par la même entité (comme avec l'attaque de Sibylle). Ces nœuds 
+décident alors comme un seul homme de ne fournir aucunes ressources au réseau, conduisant alors les autres pairs à 
+faire leurs recherches dans une base de données plus grande ou demander plus de tunnels qu'il ne serait nécessaire. 
+L'apprenti nazillon pourrait aussi fournir un service erratique en abandonnant régulièrement une sélection de trafic ou 
+en refusant les connexions à certains pairs. Ce comportement peut être indiscernable de celui d'un nœud surchargé ou 
+défaillant. I2P gère ces problèmes en maintenant des <a href="how_peerselection.html">profils</a> sur les pairs, en 
+tentant d'identifier les nœuds anémiés pour les ignorer purement et simplement, ou les utiliser rarement. Nous avons 
+sensiblement amélioré la capacité à reconnaître et éviter les pairs à performances réduites, mais il reste pas mal 
+d'efforts à fournir de ce côté là.
 </li>
-<li><b>Flooding attack:</b> A hostile user may attempt to flood the network,
-    a peer, a destination, or a tunnel.  Network and peer flooding is possible,
-    and I2P does nothing to prevent standard IP layer flooding.  The flooding of
-    a destination with messages by sending a large number to the target's various
-    inbound tunnel gateways is possible, but the destination will know this both
-    by the contents of the message and because the tunnel's tests will fail.  The
-    same goes for flooding just a single tunnel.  I2P has no defenses for a network
-    flooding attack.  For a destination and tunnel flooding attack, the target
-    identifies which tunnels are unresponsive and builds new ones.  New code could
-    also be written to add even more tunnels if the client wishes to handle the
-    larger load.  If, on the other hand, the load is more than the client can
-    deal with, they can instruct the tunnels to throttle the number of messages or
-    bytes they should pass on (once the <a href="todo#batching">advanced tunnel
-    operation</a> is implemented).</li>
-<li><b>CPU load attack:</b> There are currently some methods for people to 
-    remotely request that a peer perform some cryptographically expensive 
-    operation, and a hostile attacker could use these to flood that peer with
-    a large number of them in an attempt to overload the CPU.  Both using good 
-    engineering practices and potentially requiring nontrivial certificates 
-    (e.g. HashCash) to be attached to these expensive requests should mitigate
-    the issue, though there may be room for an attacker to exploit various
-    bugs in the implementation.</li>
-<li id="ffdos"><b>Floodfill DOS attack:</b> A hostile user may attempt to harm the network by
-    becoming a floodfill router. The current defenses against unreliable,
-    intermittent, or malicious floodfill routers are poor.
-    A floodfill router may provide bad or no response to lookups, and
-    it may also interfere with inter-floodfill communication.
-    Some defenses and
-    <a href="how_peerselection">peer profiling</a> are implemented,
-    however there is much more to do.
-    For more information see the
-    <a href="how_networkdatabase.html#threat">network database page</a>.
+<li><b>Attaque par inondation :</b> l'utilisateur hostile peut tenter de noyer le réseau, un pair, une destination ou 
+un tunnel. l'inondation d'un pair ou du réseau est possible, et I2P ne fait rien pour empêcher le bombardement de la 
+couche IP. La tentative de faire boire un bouillon de messages à une destination par plusieurs de ses passerelles de 
+tunnels entrants est également possible, mais elle en sera avertie aussi bien par le contenu des messages que par 
+l'échec des tests de tunnels. La même analyse concerne aussi les tentatives d'engorgement d'un tunnel donné. I2P n'a 
+pas de défense contre les attaques par inondation. Quand la cible est une destination ou un tunnel, elle identifie le 
+tunnel constipé et en crée d'autres. Du nouveau code pourrait permettre d'ajouter encore plus de tunnels si le client 
+souhaite gérer la charge plus forte. D'un autre côté, si la charge est supérieure à ce que le client peut gérer, il 
+pourrait indiquer aux tunnels de brider le nombre de messages ou d'octets qu'ils devraient passer (une fois les 
+<a href="todo_fr#batching">fonctions de tunnels avancées</a> implémentées).</li>
+<li><b>Attaques de charge CPU :</b> il existe actuellement quelques méthodes pour demander à un pair distant 
+d'exécuter de coûteux calculs cryptographiques, et un attaquant pourrait essayer d'en surcharger un pair pour mettre 
+son UC à genoux. L'utilisation de bonnes pratiques d'ingénierie, éventuellement conjointes à des certificats peu 
+courants (p.e. les pénalités HashCash) rattachées à ces requêtes de travaux coûteux, devraient limiter le problème, 
+bien qu'il puisse rester des possibilités pour un attaquant d'exploiter divers bogues dans l'implémentation.</li>
+<li id="ffdos"><b>Attaque DOS de diffusion :</b> un autre attaquant (ou le même, décidément sa mère à confondu la salle 
+d'accouchement et les chiottes) pourrait essayer de perturber le réseau en devenant un routeur diffuseur. Les 
+protections actuelles contre les diffuseurs non fiables, intermittents ou pervers sont faibles. Un diffuseur peut 
+fournir de mauvaises réponses aux requêtes ou pas de réponse du tout, et il peut aussi interférer avec la communication 
+inter-diffuseurs. Quelques défenses et le <a href="how_peerselection">profilage de pairs</a> sont implémentés, mais il 
+ne reste pas grand chose à faire. Pour plus d'informations, voir la page 
+<a href="how_networkdatabase.html#threat">base de données du réseau</a>.
 </li>
 </ul>
 
+
+
+
+
+
+
+
+
 <h3 id="tagging">Tagging attacks</h3>
 <p>Tagging attacks - modifying a message so that it can later be identified 
 further along the path - are by themselves impossible in I2P, as messages