{% extends "_layout.html" %}
{% block title %}Tunnel Overview{% endblock %}
{% block content %}
<p>
Updated July 2011 for release 0.8.7
</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 style="text-align: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>
</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="unidirectional-tunnels.html">Unidirectional Tunnels</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 %}