I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

reference new DHT paper

Browse Source
This commit is contained in:
zzz
2010-11-14 11:45:58 +00:00
parent 469cc6217d
commit ddc341e477
2 changed files with 61 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
www.i2p2/pages/how_networkdatabase.html
View File

@ -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>

28
www.i2p2/pages/how_threatmodel.html
View File

@ -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>