forked from I2P_Developers/i2p.www
Added translation tags to docs/tunnels/*
docs/tunnels/old-implementation has only been tagged at the top, as it covers old details and so is not urgently required.
This commit is contained in:
@@ -1,32 +1,33 @@
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}Unidirectional Tunnels{% endblock %}
|
||||
{% block lastupdated %}July 2011{% endblock %}
|
||||
{% block title %}{% trans %}Unidirectional Tunnels{% endtrans %}{% endblock %}
|
||||
{% block lastupdated %}{% trans %}July 2011{% endtrans %}{% endblock %}
|
||||
{% block accuratefor %}0.8.7{% endblock %}
|
||||
{% block content %}
|
||||
<h2>Overview</h2>
|
||||
<p>
|
||||
<h2>{% trans %}Overview{% endtrans %}</h2>
|
||||
<p>{% trans -%}
|
||||
This page describes the origins and design of I2P's unidirectional tunnels.
|
||||
For further infomrmation see:
|
||||
{%- endtrans %}</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="{{ site_url('docs/how/tunnelrouting') }}">tunnel overview page</a>
|
||||
<a href="{{ site_url('docs/how/tunnel-routing') }}">{% trans %}Tunnel overview page{% endtrans %}</a>
|
||||
<li>
|
||||
<a href="{{ site_url('docs/tunnels/implementation') }}">tunnel specification</a>
|
||||
<a href="{{ site_url('docs/tunnels/implementation') }}">{% trans %}Tunnel specification{% endtrans %}</a>
|
||||
</li><li>
|
||||
<a href="{{ site_url('docs/spec/tunnel_creation') }}">tunnel creation specification</a>
|
||||
<a href="{{ site_url('docs/spec/tunnel-creation') }}">{% trans %}Tunnel creation specification{% endtrans %}</a>
|
||||
</li><li>
|
||||
<a href="{{ site_url('docs/discussions/tunnel') }}">tunnel design discussion</a>
|
||||
<a href="{{ site_url('docs/discussions/tunnel') }}">{% trans %}Tunnel design discussion{% endtrans %}</a>
|
||||
</li><li>
|
||||
<a href="{{ site_url('docs/how/peerselection') }}">peer selection</a>
|
||||
<a href="{{ site_url('docs/how/peer-selection') }}">{% trans %}Peer selection{% endtrans %}</a>
|
||||
</li><li>
|
||||
<a href="{{ url_for('meetings_show', id=125) }}">Meeting 125 (~13:12-13:30)</a>
|
||||
<a href="{{ get_url('meetings_show', id=125) }}">{% trans %}Meeting 125 (~13:12-13:30){% endtrans %}</a>
|
||||
</li>
|
||||
</ul>
|
||||
</p>
|
||||
|
||||
<h2>Review</h2>
|
||||
<h2>{% trans %}Review{% endtrans %}</h2>
|
||||
|
||||
<p>
|
||||
<p>{% trans -%}
|
||||
While we aren't aware of any published research on the advantages of
|
||||
unidirecdtional tunnels,
|
||||
they appear to make it harder to detect a
|
||||
@@ -39,17 +40,19 @@ attacker who has only timing and traffic volume data to infer the path a
|
||||
tunnel is taking.
|
||||
Having the response come back along a different path arguably
|
||||
makes it harder.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
</p><p>
|
||||
When dealing with
|
||||
an internal adversary or most external adversaries, I2P's undirectional tunnels
|
||||
expose half as much traffic data than would be exposed with bidirectional circuits
|
||||
by simply looking at the flows themselves - an HTTP request and response would
|
||||
follow the same path in Tor, while in I2P the packets making up the request
|
||||
would go out through one or more outbound tunnels and the packets making up
|
||||
the response would come back through one or more different inbound tunnels.
|
||||
<p>{% trans -%}
|
||||
When dealing with
|
||||
an internal adversary or most external adversaries, I2P's undirectional tunnels
|
||||
expose half as much traffic data than would be exposed with bidirectional circuits
|
||||
by simply looking at the flows themselves - an HTTP request and response would
|
||||
follow the same path in Tor, while in I2P the packets making up the request
|
||||
would go out through one or more outbound tunnels and the packets making up
|
||||
the response would come back through one or more different inbound tunnels.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
</p><p>
|
||||
<p>{% trans -%}
|
||||
The strategy of using two separate tunnels for inbound and outbound
|
||||
communication is not the only technique available, and it does have anonymity
|
||||
implications. On the positive side, by using separate tunnels it lessens the
|
||||
@@ -64,51 +67,57 @@ additional care must be taken to address the increased speed of predecessor
|
||||
attacks. The tunnel pooling and building process
|
||||
(peer selection and ordering strategies)
|
||||
should minimize the worries of the predecessor attack.
|
||||
|
||||
</p>
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
||||
<h2>Anonymity</h2>
|
||||
<h2>{% trans %}Anonymity{% endtrans %}</h2>
|
||||
|
||||
<p>
|
||||
A recent
|
||||
<a href="http://grothoff.org/christian/i2p.pdf">paper by Hermann and Grothoff</a>
|
||||
<p>{% trans pdf='http://grothoff.org/christian/i2p.pdf' -%}
|
||||
A recent <a href="{{ pdf }}">paper by Hermann and Grothoff</a>
|
||||
declared that I2P's unidirectional tunnels "seems to be a bad design decision".
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The paper's main point is that
|
||||
deanonymizations on unidirectional tunnels take a longer time, which is an
|
||||
advantage, but that an attacker can be more certain in the unidirectional case.
|
||||
Therefore, the paper claims it isn't an advantage at all, but a disadvantage, at least
|
||||
with long-living eepsites.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
</p><p>
|
||||
<p>{% trans -%}
|
||||
This conclusion is not fully supported by the paper. Unidirectional tunnels clearly
|
||||
mitigate other attacks and it's not clear how to trade off the risk of the
|
||||
attack in the paper
|
||||
with attacks on a bidirectional tunnel architecture.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
</p><p>
|
||||
<p>{% trans -%}
|
||||
This conclusion is based on an arbitrary certainty vs. time weighting
|
||||
(tradeoff) that may not be applicable in all cases. For
|
||||
example, somebody could make a list of possible IPs then issue subpoenas to
|
||||
each. Or the attacker could DDoS each in turn and via a simple
|
||||
intersection attack see if the eepsite goes down or is slowed down. So close
|
||||
may be good enough, or time may be more important.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The conclusion is based on a specific weighting of the importance of certainty
|
||||
vs. time, and that weighting may be wrong, and it's definitely debatable,
|
||||
especially in a real world with subpoenas, search warrants, and other methods
|
||||
available for final confirmation.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
</p><p>
|
||||
<p>{% trans -%}
|
||||
A full analysis of the tradeoffs of unidirectional vs. bidirectional
|
||||
tunnels is clearly outside the scope of the paper, and has not been done
|
||||
elsewhere. For example, how does this attack compare to the numerous possible
|
||||
timing attacks published about onion-routed networks? Clearly the authors have not
|
||||
done that analysis, if it's even possible to do it
|
||||
effectively.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
</p><p>
|
||||
<p>{% trans -%}
|
||||
Tor uses bidirectional tunnels and has had a lot of academic review. I2P
|
||||
uses unidirectional tunnels and has had very little review. Does the lack of a
|
||||
research paper defending unidirectional tunnels mean that it is a poor design
|
||||
@@ -123,14 +132,14 @@ clearly needs further investigation and analysis? There are several other reason
|
||||
to consider I2P currently inferior to Tor and other projects (small network
|
||||
size, lack of funding, lack of review) but is unidirectional tunnels really a
|
||||
reason?
|
||||
{%- endtrans %}</p>
|
||||
|
||||
</p><p>
|
||||
<p>{% trans -%}
|
||||
In summary, "bad design decision" is apparently (since the paper does
|
||||
not label bidirectional tunnels "bad") shorthand for "unidirectional
|
||||
tunnels are unequivocally inferior to bidirectional tunnels", yet this
|
||||
conclusion is not supported by the paper.
|
||||
|
||||
</p>
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
||||
{% endblock %}
|
||||
|
Reference in New Issue
Block a user