254 lines
11 KiB
HTML
254 lines
11 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}Tunnel Overview{% endblock %}
|
|
{% block content %}
|
|
<p>
|
|
Updated August 2010 for release 0.8
|
|
</p>
|
|
|
|
<h2>Tunnel Overview</h2>
|
|
<p>
|
|
This page contains an overview of I2P tunnel terminology and operation, with
|
|
links to more technical pages, details, and specifications.
|
|
</p>
|
|
<p>As briefly explained in the <a href="how_intro">introduction</a>, I2P builds virtual "tunnels" -
|
|
temporary and unidirectional paths through a sequence of routers. These
|
|
tunnels are classified as either inbound tunnels (where everything
|
|
given to it goes towards the creator of the tunnel) or outbound tunnels
|
|
(where the tunnel creator shoves messages away from them). When Alice
|
|
wants to send a message to Bob, she will (typically) send it out one of
|
|
her existing outbound tunnels with instructions for that tunnel's endpoint
|
|
to forward it to the gateway router for one of Bob's current inbound
|
|
tunnels, which in turn passes it to Bob.</p>
|
|
<p><center>
|
|
<img src="/_static/images/tunnelSending.png" alt="Tunnel" />
|
|
<pre>
|
|
A: Outbound Gateway (Alice)
|
|
B: Outbound Participant
|
|
C: Outbound Endpoint
|
|
D: Inbound Gateway
|
|
E: Inbound Participant
|
|
F: Inbound Endpoint (Bob)
|
|
</pre>
|
|
</center></p>
|
|
|
|
<h2>Tunnel vocabulary</h2>
|
|
<ul>
|
|
<li class="gap"><b>Tunnel gateway</b> - the first router in a tunnel. For inbound tunnels,
|
|
this is the one mentioned in the LeaseSet published in the
|
|
<a href="how_networkdatabase">network database</a>. For outbound tunnels, the
|
|
gateway is the originating router. (e.g. both A and D above)</li>
|
|
<li class="gap"><b>Tunnel endpoint</b> - the last router in a tunnel. (e.g. both C and F above)</li>
|
|
<li class="gap"><b>Tunnel participant</b> - all routers in a tunnel except for the gateway or
|
|
endpoint (e.g. both B and E above)</li>
|
|
<li><b>n-Hop tunnel</b> - a tunnel with a specific number of inter-router jumps, e.g.:
|
|
<ul>
|
|
<li><b>0-hop tunnel</b> - a tunnel where the gateway is also the endpoint</li>
|
|
<li><b>1-hop tunnel</b> - a tunnel where the gateway talks directly to the
|
|
endpoint</li>
|
|
<li><b>2-(or more)-hop tunnel</b> - a tunnel where there is at least one intermediate
|
|
tunnel participant. (the above diagram includes two 2-hop tunnels - one
|
|
outbound from Alice, one inbound to Bob)</li>
|
|
</ul>
|
|
</li>
|
|
<li class="gap"><b>Tunnel ID</b> - A <a href="common_structures_spec.html#type_TunnelId">4 byte integer</a>
|
|
different for each hop in a tunnel, and unique among all tunnels on a router.
|
|
Chosen randomly by the tunnel creator.</li>
|
|
</ul>
|
|
|
|
<h2>Tunnel Build Information</h2>
|
|
<p>Routers performing the three roles (gateway, participant, endpoint) are given
|
|
different pieces of data in the initial
|
|
<a href="tunnel-alt-creation.html">Tunnel Build Message</a>
|
|
to accomplish their tasks:</p>
|
|
|
|
<ul>
|
|
<li class="gap"><b>The tunnel gateway gets:</b>
|
|
<ul>
|
|
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
|
|
messages and instructions to the next hop</li>
|
|
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
|
|
the IV to the next hop</li>
|
|
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
|
|
the reply to the tunnel build request</li>
|
|
<li><b>reply IV</b> - the IV for encrypting
|
|
the reply to the tunnel build request</li>
|
|
<li><b>tunnel id</b> - 4 byte integer (inbound gateways only)
|
|
</li>
|
|
<li><b>next hop</b> - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint)</li>
|
|
<li><b>next tunnel id</b> - The tunnel ID on the next hop</li>
|
|
</ul>
|
|
</li>
|
|
<li class="gap"><b>All intermediate tunnel participants get:</b>
|
|
<ul>
|
|
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
|
|
messages and instructions to the next hop</li>
|
|
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
|
|
the IV to the next hop</li>
|
|
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
|
|
the reply to the tunnel build request</li>
|
|
<li><b>reply IV</b> - the IV for encrypting
|
|
the reply to the tunnel build request</li>
|
|
<li><b>tunnel id</b> - 4 byte integer
|
|
</li>
|
|
<li><b>next hop</b> - what router is the next one in the path</li>
|
|
<li><b>next tunnel id</b> - The tunnel ID on the next hop</li>
|
|
</ul>
|
|
</li>
|
|
<li class="gap"> <b>The tunnel endpoint gets:</b>
|
|
<ul>
|
|
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
|
|
messages and instructions to the the endpoint (itself)</li>
|
|
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
|
|
the IV to the endpoint (itself)</li>
|
|
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
|
|
the reply to the tunnel build request (outbound endpoints only)</li>
|
|
<li><b>reply IV</b> - the IV for encrypting
|
|
the reply to the tunnel build request (outbound endpoints only)</li>
|
|
<li><b>tunnel id</b> - 4 byte integer (outbound endpoints only)
|
|
</li>
|
|
<li><b>reply router</b> - the inbound gateway of the tunnel to send the reply through (outbound endpoints only)</li>
|
|
<li><b>reply tunnel id</b> - The tunnel ID of the reply router (outbound endpoints only)</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Details are in the
|
|
<a href="tunnel-alt-creation.html">tunnel creation specification</a>.
|
|
</p>
|
|
|
|
<h2>Tunnel pooling</h2>
|
|
<p>
|
|
Several tunnels for a particular purpose may be grouped into a "tunnel pool",
|
|
as described in the
|
|
<a href="tunnel-alt.html#tunnel.pooling">tunnel specification</a>.
|
|
This provides redundancy and additional bandwidth.
|
|
The pools used by the router itself are called "exploratory tunnels".
|
|
The pools used by applications are called "client tunnels".
|
|
</p>
|
|
|
|
|
|
|
|
<h2 id="length">Tunnel length</h2>
|
|
<p>As mentioned above, each client requests that their router provide tunnels to
|
|
include at least a certain number of hops.
|
|
The decision as to how many routers
|
|
to have in one's outbound and inbound tunnels has an important effect upon the
|
|
latency, throughput, reliability, and anonymity provided by I2P - the more peers
|
|
that messages have to go through, the longer it takes to get there and the more
|
|
likely that one of those routers will fail prematurely. The less routers in a
|
|
tunnel, the easier it is for an adversary to mount traffic analysis attacks and
|
|
pierce someone's anonymity.
|
|
Tunnel lengths are specified by clients via
|
|
<a href="i2cp.html#options">I2CP options</a>.
|
|
The maximum number of hops in a tunnel is 7.
|
|
</p>
|
|
|
|
|
|
<h3>0-hop tunnels</h3>
|
|
<p>With no remote routers in a tunnel, the user has very basic plausible
|
|
deniability (since no one knows for sure that the peer that sent them the
|
|
message wasn't simply just forwarding it on as part of the tunnel). However, it
|
|
would be fairly easy to mount a statistical analysis attack and notice that
|
|
messages targeting a specific destination are always sent through a single
|
|
gateway. Statistical analysis against outbound 0-hop tunnels are more complex,
|
|
but could show similar information (though would be slightly harder to mount)</p>
|
|
|
|
<h3>1-hop tunnels</h3>
|
|
<p>With only one remote router in a tunnel, the user has both plausible
|
|
deniability and basic anonymity, as long as they are not up against an internal
|
|
adversary (as described on <a href="how_threatmodel">threat model</a>). However,
|
|
if the adversary ran a sufficient number of routers such that the single remote
|
|
router in the tunnel is often one of those compromised ones, they would be able
|
|
to mount the above statistical traffic analysis attack.</p>
|
|
|
|
<h3>2-hop tunnels</h3>
|
|
<p>With two or more remote routers in a tunnel, the costs of mounting the traffic
|
|
analysis attack increases, since many remote routers would have to be compromised
|
|
to mount it.</p>
|
|
|
|
<h3>3-hop (or more) tunnels</h3>
|
|
To reduce the susceptibility to <a href="http://blog.torproject.org/blog/one-cell-enough">some attacks</a>,
|
|
3 or more hops are recommended for the highest level of protection.
|
|
<a href="http://blog.torproject.org/blog/one-cell-enough">recent studies</a>
|
|
also conclude that more than 3 hops does not provide additional protection.
|
|
|
|
|
|
<h3>Tunnel default lengths</h3>
|
|
<p>The router uses 2-hop tunnels by default for its exploratory tunnels.
|
|
Client tunnel defaults are set by the application, using
|
|
<a href="i2cp.html#options">I2CP options</a>.
|
|
Most applications use 2 or 3 hops as their default.
|
|
</p>
|
|
|
|
|
|
|
|
<h2 id="testing">Tunnel testing</h2>
|
|
<p>All tunnels are periodically tested by their creator by sending a
|
|
DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel
|
|
(testing both tunnels at once). If either fails a number of consecutive tests, it is marked as no longer
|
|
functional. If it was used for a client's inbound tunnel, a new leaseSet
|
|
is created.
|
|
Tunnel test failures are also reflected in the
|
|
<a href="how_peerselection.html#capacity">capacity rating in the peer profile</a>.
|
|
</p>
|
|
|
|
|
|
<h2>Tunnel creation</h2>
|
|
<p>Tunnel creation is handled by <a href="how_garlicrouting">garlic routing</a>
|
|
a Tunnel Build Message to a router, requesting that they participate in the
|
|
tunnel (providing them with all of the appropriate information, as above, along
|
|
with a certificate, which right now is a 'null' cert, but will support hashcash
|
|
or other non-free certificates when necessary).
|
|
That router forwards the message to the next hop in the tunnel.
|
|
Details are in the
|
|
<a href="tunnel-alt-creation.html">tunnel creation specification</a>.
|
|
</p>
|
|
|
|
|
|
<h2>Tunnel encryption</h2>
|
|
<p>Multi-layer encryption is handled by <a href="how_garlicrouting">garlic encryption</a>
|
|
of tunnel messages.
|
|
Details are in the
|
|
<a href="tunnel-alt.html">tunnel specification</a>.
|
|
The IV of each hop is encrypted with a separate key as explained there.
|
|
</p>
|
|
|
|
|
|
<h2>Future Work</h2>
|
|
<ul><li>
|
|
Other tunnel test techniques could be used, such as
|
|
garlic wrapping a number of tests into cloves, testing individual tunnel
|
|
participants separately,
|
|
etc.
|
|
</li><li>
|
|
Move to 3-hop exploratory tunnels defaults.
|
|
</li><li>
|
|
In a distant future release,
|
|
options specifying the pooling, mixing, and chaff generation settings may be implemented.
|
|
</li><li>
|
|
In a distant future release,
|
|
limits on the quantity and size of messages allowed during the
|
|
tunnel's lifetime may be implemented (e.g. no more than 300 messages or
|
|
1MB per minute).
|
|
</li></ul>
|
|
|
|
|
|
<h2>See Also</h2>
|
|
<ul>
|
|
<li>
|
|
<a href="tunnel-alt.html">tunnel specification</a>
|
|
</li><li>
|
|
<a href="tunnel-alt-creation.html">tunnel creation specification</a>
|
|
</li><li>
|
|
<a href="tunnel_message_spec.html">tunnel message specification</a>
|
|
</li><li>
|
|
<a href="how_garlicrouting.html">garlic routing</a>
|
|
</li><li>
|
|
<a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a>
|
|
</li><li>
|
|
<a href="i2cp.html#options">I2CP options</a>
|
|
</li>
|
|
</ul>
|
|
{% endblock %}
|