reference new DHT paper

www.i2p2/pages/how_networkdatabase.html

@@ -3,7 +3,7 @@
 {% block content %}
 
 <p>
-  Updated July 2010, current as of router version 0.8
+  Updated November 2010, current as of router version 0.8.1
 </p>
 
 <h2>Overview</h2>
@@ -557,7 +557,7 @@
 </p>
 
 
-<h3>Sybil Attack (Full Keyspace)</h3>
+<h3 id="sybil">Sybil Attack (Full Keyspace)</h3>
 <p>
   An attacker may mount a
   <a href="http://citeseer.ist.psu.edu/douceur02sybil.html">Sybil attack</a>
@@ -703,6 +703,38 @@ This attack becomes more difficult as the network size grows.
   for a discussion of the vulnerabilities of peer selection for tunnels.
 </p>
 
+<h3>Information Leaks</h3>
+<p>
+  (Reference:
+  <a href="https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf">In Search of an Anonymouns and Secure Lookup</a> Section 3)
+</p>
+<p>
+  This paper addresses weaknesses in the "Finger Table" DHT lookups used by Torsk and NISAN.
+  At first glance, these do not appear to apply to I2P. First, the use of DHT by Torsk and NISAN
+  is significantly different from that in I2P. Second, I2P's network database lookups are only
+  loosely correlated to the <a href="how_peerselection">peer selection</a> and
+  <a href="how_tunnelrouting">tunnel building</a> processes; only previously-known peers
+  are used for tunnels.
+  Also, peer selection is unrelated to any notion of DHT key-closeness.
+</p>
+<p>
+  Some of this may actually be more interesting when the I2P network gets much larger.
+  Right now, each router knows a large proportion of the network, so looking up a particular
+  Router Info in the network database is not strongly indicative of a future intent to use
+  that router in a tunnel. Perhaps when the network is 100 times larger, the lookup may be
+  more correlative. Of course, a larger network makes a Sybil attack that much harder.
+</p>
+<p>
+  However, the general issue of DHT information leakage in I2P needs further investigation.
+  The floodfill routers are in a position to observe queries and gather information.
+  Certainly, at a level of <i>f</i> = 0.2 (20% malicious nodes, as specifed in the paper)
+  we expect that many of the Sybil threats we describe
+  (<a href="how_threatmodel.html#sybil">here</a>,
+  <a href="#sybil">here</a> and
+  <a href="#sybil-partial">here</a>)
+  become problematic for several reasons.
+</p>
+
 
 <h2 id="history">History</h2>
 <p>

www.i2p2/pages/how_threatmodel.html

@@ -2,7 +2,7 @@
 {% block title %}I2P's Threat Model{% endblock %}
 {% block content %}
 
-Updated August 2010, current as of router version 0.8
+Updated November 2010, current as of router version 0.8.1
 <h2>What do we mean by "anonymous"?</h2>
 
 <p>Your level of anonymity can be described as "how hard it is for someone
@@ -105,6 +105,7 @@ to review.
 <li><a href="#harvesting">Harvesting attacks</a></li>
 <li><a href="#traffic">Identification Through Traffic Analysis</a></li>
 <li><a href="#sybil">Sybil attacks</a></li>
+<li><a href="#buddy">Buddy Exhaustion attacks</a></li>
 <li><a href="#crypto">Cryptographic attacks</a></li>
 <li><a href="#floodfill">Floodfill attacks</a></li>
 <li><a href="#netdb">Other Network Database attacks</a></li>
@@ -206,6 +207,10 @@ Partial defenses implemented in I2P:
 Limits on the number of tunnels routed through a single peer
 </li><li>
 Prevention of peers from the same /16 IP range from being members of a single tunnel
+</li><li>
+For eepsites or other hosted services, we support
+simultaneous hosting on multiple routers, or
+<a href="http://www.i2p2.i2p/how_threatmodel#intersection">multihoming</a>
 </li></ul>
 
 Even in total, these defenses are not a complete solution.
@@ -504,6 +509,27 @@ for more Sybil discussion.
 </p>
 
 
+<h3 id="buddy">Buddy Exhaustion attacks</h3>
+<p>
+  (Reference:
+  <a href="https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf">In Search of an Anonymouns and Secure Lookup</a> Section 5.2)
+</p>
+<p>
+By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure
+that a tunnel is formed wholly from its set of colluding routers.
+The chances of success are enhanced if there is a large number of colluding routers,
+i.e. a <a href="#sybil">Sybil attack</a>.
+This is somewhat mitigated by our
+<a href="how_peerselection">peer profiling</a> methods used to monitor the performance
+of peers.
+However, this is a powerful attack as the number of routers approaches
+<i>f</i> = 0.2, or 20% malicious nodes, as specifed in the paper.
+The malicous routers could also maintain connections to the target router and provide
+excellent forwarding bandwidth for traffic over those connections, in an attempt
+to manipulate the profiles managed by the target and appear attractive.
+Further research and defenses may be necessary.
+</p>
+
 
 <h3 id="crypto">Cryptographic attacks</h3>