kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tor update

Browse Source
This commit is contained in:
zzz
2009-01-07 17:52:52 +00:00
parent 284360e49d
commit 11f9071761
1 changed files with 138 additions and 125 deletions
Download Patch File Download Diff File Expand all files Collapse all files

263
www.i2p2/pages/how_networkcomparisons.html
View File

@ -8,15 +8,151 @@ and GNUnet's <a href="http://www.ovmj.org/GNUnet/links.php3">related projects</a
serve that purpose well. That said, a few systems stand out for further
comparison:</p>
<ul>
<li>Morphmix and Tarzan</li>
<li>TOR / Onion Routing</li>
<li>Morphmix and Tarzan</li>
<li>Mixminion / Mixmaster</li>
<li>Freenet</li>
<li>JAP</li>
<li>MUTE / AntsP2P</li>
</ul>
<p><b>(The content of this page is under dispute, several claims still need to be proven.)</b></p>
<p>The content of this page is subject to update, discussion and dispute, and we welcome comments and additions.</p>
<h2>TOR / Onion Routing</h2>
<i><a href="http://www.torproject.org/">[TOR]</a>
<a href="http://www.onion-router.net">[Onion Routing]</a></i>
<p>TOR and Onion Routing are both anonymizing proxy networks,
allowing people to tunnel out through their low latency mix
network. The two primary differences between TOR /
Onion-Routing and I2P are again related to differences in
the threat model and the out-proxy design (though TOR
supports hidden services as well). In addition, Tor
takes the directory-based approach - providing a
centralized point to manage the overall 'view' of the
network, as well as gather and report statistics, as
opposed to I2P's distributed <a href="how_networkdatabase">network
database</a> and <a href="how_peerselection">peer selection</a>.</p>
<p>The I2P/Tor outproxy functionality does have a few
substantial weaknesses against certain attackers -
once the communication leaves the mixnet, global passive
adversaries can more easily mount traffic analysis. In
addition, the outproxies have access to the cleartext
of the data transferred in both directions, and
outproxies are prone to abuse, along with all of the
other security issues we've come to know and love with
normal internet traffic.</p>
<p>However, many people don't need to worry about those
situations, as they are outside their threat model. It
is, also, outside I2P's (formal) functional scope (if people want
to build outproxy functionality on top of an anonymous
communication layer, they can). In fact, some I2P users
currently take advantage of TOR to outproxy.</p>
<p>See also the
<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ComparisonI2P">the TOR FAQ</a>
for a TOR/I2P comparison from the TOR perspective.</p>
<h3>Comparison of TOR and I2P Terminology</h3>
While TOR and I2P are similar in many ways, much of the terminology is different.
<table>
<tr><th align="left">Tor<th align="left">I2P
<tr><td>Cell<td>Message
<tr><td>Client<td>Router or Client
<tr><td>Circuit<td>Tunnel
<tr><td>Directory<td>NetDb
<tr><td>Directory Server<td>Floodfill Router
<tr><td>Entry Guards<td>Fast Peers
<tr><td>Entry Node<td>Inproxy
<tr><td>Exit Node<td>Outproxy
<tr><td>Hidden Service<td>Eepsite or Destination
<tr><td>Hidden Service Descriptor<td>LeaseSet
<tr><td>Introduction point<td>Inbound Gateway
<tr><td>Node<td>Router
<tr><td>Onion Proxy<td>I2PTunnel Client (more or less)
<tr><td>Relay<td>Router
<tr><td>Rendezvous Point<td>somewhat like Inbound Gateway + Outbound Endpoint
<tr><td>Router Descriptor<td>RouterInfo
<tr><td>Server<td>Router
</table>
<h3>Benefits of TOR over I2P</h3>
<ul>
<li>Much bigger user base; much more visibility in the academic and hacker communities; benefits from
formal studies of anonymity, resistance, and performance;
has a non-anonymous, visible, university-based leader</li>
<li>Has already solved some scaling issues I2P has yet to address</li>
<li>Has funding and more developers</li>
<li>More resistant to state-level blocking due to TLS transport layer and bridges
(I2P has proposals for "full restricted routes" but these are not yet implemented)</li>
<li>Big enough that it has had to adapt to blocking and DOS attempts<li>
<li>Designed and optimized for exit traffic, with a large number of exit nodes</li>
<li>Better documentation, has formal papers and specifications, better website, many more translations</li>
<li>More efficient w/ memory usage</li>
<li>TOR client nodes have very low bandwidth overhead</li>
<li>Centralized control reduces the complexity at each
node and can efficiently address Sybil attacks</li>
<li>A core of high capacity nodes provides higher
throughput and lower latency</li>
<li>C, not Java (ewww)</li>
</ul>
<h3>Benefits of I2P over TOR</h3>
<ul>
<li>Designed and optimized for hidden services, which are much faster than in Tor</li>
<li>Fully distributed and self organizing</li>
<li>Peers are selected by continuously profiling and ranking performance,
rather than trusting claimed capacity</li>
<li>Floodfill peers ("directory servers") are varying and untrusted,
rather than hardcoded</li>
<li>Small enough that it hasn't been blocked or DOSed much, or at all<li>
<li>Peer-to-peer friendly<li>
<li>Packet switched instead of circuit switched
<ul>
<li>implicit transparent load balancing of messages
across multiple peers, rather than a single path</li>
<li>resilience vs. failures by running multiple
tunnels in parallel, plus rotating tunnels</li>
<li>scale each client's connections at O(1) instead
of O(N) (Alice has e.g. 2 inbound tunnels that are
used by all of the peers Alice is talking with,
rather than a circuit for each)</li>
</ul></li>
<li>Unidirectional tunnels instead of bidirectional
circuits, doubling the number of nodes a peer has to
compromise to get the same information.</li>
<li>Protection against detecting client activity, even
when an attacker is participating in the tunnel, as
tunnels are used for more than simply passing end
to end messages (e.g. netDb, tunnel management,
tunnel testing)</li>
<li>Tunnels in I2P are short lived, decreasing the number
of samples that an attacker can use to mount an
active attack with, unlike circuits in TOR, which are
typically long lived.</li>
<li>I2P APIs are designed specifically for anonymity and
security, while SOCKS is designed for functionality.</li>
<li>Essentially all peers participate in routing for others</li>
<li>The bandwidth overhead of being a full peer is low,
while in TOR, while client nodes don't require much
bandwidth, they don't fully participate in the mixnet.</li>
<li>Integrated automatic update mechanism</li>
<li>Java, not C (ewww)</li>
</ul>
<h3>Other potential benefits of I2P but not yet implemented</h3>
<ul>
<li>Defense vs. message count analysis by garlic wrapping
multiple messages</li>
<li>Defense vs. long term intersection by adding delays
at various hops (where the delays are not discernable
by other hops)</li>
<li>Various mixing strategies at the tunnel level (e.g.
create a tunnel that will handle 500 messages / minute,
where the endpoint will inject dummy messages if there
are insufficient messages, etc)</li>
</ul>
<h2>Morphmix and Tarzan</h2>
<i><a href="http://www.tik.ee.ethz.ch/~morphmix/">[Morphmix]</a>
@ -130,129 +266,6 @@ comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:</p>
<p>(Original image at <a href="http://dev.i2p.net/~jrandom/wiki/comparison.png">
http://dev.i2p.net/~jrandom/wiki/comparison.png</a>)</p>
<h2>TOR / Onion Routing</h2>
<i><a href="http://www.torproject.org/">[TOR]</a>
<a href="http://www.onion-router.net">[Onion Routing]</a></i>
<p>TOR and Onion Routing are both anonymizing proxy networks,
allowing people to tunnel out through their low latency mix
network. The two primary differences between TOR /
Onion-Routing and I2P are again related to differences in
the threat model and the out-proxy design (though TOR now
supports hidden services). In addition, these networks
take the directory based approach - providing a
centralized point to manage the overall 'view' of the
network, as well as gather and report statistics, as
opposed to I2P's distributed <a href="how_networkdatabase">network
database</a> and <a href="how_peerselection">peer selection</a>.</p>
<p>The following is a more detailed comparison of TOR and
I2P, but in it, one of the really cool features of TOR is
overlooked - the ability to outproxy onto the normal internet.
That feature is a very useful one, and relevant for many
situations.</p>
<p>However, the outproxy functionality does have a few
substantial weaknesses against certain attackers -
once the communication leaves the mixnet, global passive
adversaries can more easily mount traffic analysis. In
addition, the outproxies have access to the cleartext
of the data transferred in both directions, and
outproxies are prone to abuse, along with all of the
other security issues we've come to know and love with
normal internet traffic.</p>
<p>However, most people don't need to worry about those
situations, as they are outside their threat model. It
is, also, outside I2P's functional scope (if people want
to build outproxy functionality on top of an anonymous
communication layer, they can). In fact, some I2P users
currently take advantage of TOR to outproxy.</p>
<p>See also the
<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ComparisonI2P">the TOR FAQ</a>
for a TOR/I2P comparison from the TOR perspective.</p>
<h3>Comparison of TOR and I2P Terminology</h3>
While TOR and I2P are similar in many ways, much of the terminology is different.
<table>
<tr><th align="left">Tor<th align="left">I2P
<tr><td>Cell<td>Message
<tr><td>Client<td>Router or Client
<tr><td>Circuit<td>Tunnel
<tr><td>Directory<td>NetDb
<tr><td>Directory Server<td>Floodfill Router
<tr><td>Entry Guards<td>Fast Peers
<tr><td>Entry Node<td>Inproxy
<tr><td>Exit Node<td>Outproxy
<tr><td>Hidden Service<td>Eepsite or Destination
<tr><td>Hidden Service Descriptor<td>LeaseSet
<tr><td>Introduction point<td>Inbound Gateway
<tr><td>Node<td>Router
<tr><td>Onion Proxy<td>I2PTunnel Client (more or less)
<tr><td>Relay<td>Router
<tr><td>Rendezvous Point<td>somewhat like Inbound Gateway + Outbound Endpoint
<tr><td>Router Descriptor<td>RouterInfo
<tr><td>Server<td>Router
</table>
<h3>Benefits of TOR over I2P</h3>
<ul>
<li>More efficient w/ memory usage</li>
<li>TOR client nodes have very low bandwidth overhead</li>
<li>Centralized control reduces the complexity at each
node and can efficiently address Sybil attacks</li>
<li>A core of high capacity nodes provides higher
throughput and lower latency</li>
<li>C, not Java (ewww)</li>
</ul>
<h3>Benefits of I2P over TOR</h3>
<ul>
<li>Fully distributed and self organizing</li>
<li>Packet switched instead of circuit switched
<ul>
<li>implicit transparent load balancing of messages
across multiple peers, rather than a single path</li>
<li>resilience vs. failures by running multiple
tunnels in parallel, plus rotating tunnels</li>
<li>scale each client's connections at O(1) instead
of O(N) (Alice has e.g. 2 inbound tunnels that are
used by all of the peers Alice is talking with,
rather than a circuit for each)</li>
</ul></li>
<li>Unidirectional tunnels instead of bidirectional
circuits, doubling the number of nodes a peer has to
compromise to get the same information.</li>
<li>Protection against detecting client activity, even
when an attacker is participating in the tunnel, as
tunnels are used for more than simply passing end
to end messages (e.g. netDb, tunnel management,
tunnel testing)</li>
<li>Tunnels in I2P are short lived, decreasing the number
of samples that an attacker can use to mount an
active attack with, unlike circuits in TOR, which are
typically long lived.</li>
<li>I2P APIs are designed specifically for anonymity and
security, while SOCKS is designed for functionality.</li>
<li>The bandwidth overhead of being a full peer is low,
while in TOR, while client nodes don't require much
bandwidth, they don't fully participate in the mixnet.</li>
<li>Java, not C (ewww)</li>
</ul>
<h3>Other benefits of I2P but not yet implemented</h3>
<ul>
<li>Defense vs. message count analysis by garlic wrapping
multiple messages</li>
<li>Defense vs. long term intersection by adding delays
at various hops (where the delays are not discernable
by other hops)</li>
<li>Various mixing strategies at the tunnel level (e.g.
create a tunnel that will handle 500 messages / minute,
where the endpoint will inject dummy messages if there
are insufficient messages, etc)</li>
</ul>
<h2>Mixminion / Mixmaster</h2>
<i><a href="http://mixminion.net/">[Mixminion]</a>
<a href="http://mixmaster.sourceforge.net/">[Mixmaster]</a></i>