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

tunnel edits

Browse Source
This commit is contained in:
zzz
2010-09-03 02:15:31 +00:00
parent 3f9e7f1209
commit 9d94e9bc0c
3 changed files with 211 additions and 82 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
www.i2p2/pages/i2np_spec.html
View File

@ -132,20 +132,36 @@ Cleartext:
| reply_iv | | reply_iv |
+ + + +
| | | |
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
|flag| request_time | send_message_id | |flag| request_time | send_msg_id
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
| padding... | |
+----+----+----+--// +----+ +
| 29 bytes padding |
+ +
| |
+ +----+----+
| |
+----+----+----+----+----+----+
encrypted:
ElGamal encrypted:
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
| toPeer | | toPeer |
+ + + +
| | | |
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
| encrypted data ... | | encrypted data ... |
~ ~
| |
+----+----+----+----+----+----+----+----+
ElGamal and AES encrypted:
+----+----+----+----+----+----+----+----+
| encrypted data ... |
~ ~
| |
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
{% endfilter %} {% endfilter %}
</pre> </pre>
@ -190,12 +206,12 @@ send_message_id :: Integer
padding :: Data padding :: Data
length -> 29 bytes length -> 29 bytes
source -> random source -> random
total length: 222 total length: 222
encrypted:
ElGamal encrypted:
toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity
length -> 16 bytes length -> 16 bytes
@ -205,6 +221,14 @@ encrypted_data :: ElGamal-2048 encrypted data (see notes)
total length: 528 total length: 528
ElGamal and AES encrypted:
encrypted_data :: ElGamal and AES encrypted data
length -> 528
total length: 528
{% endfilter %} {% endfilter %}
</pre> </pre>
@ -226,7 +250,7 @@ The two padding bytes from the block (the zero bytes at locations 0 and 257) are
unencrypted: unencrypted:
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
| random data... | | random data... |
~ ~
| | | |
+ +----+ + +----+
| |ret | | |ret |
@ -241,7 +265,7 @@ bytes 0-526: random data
byte 527 : reply byte 527 : reply
encrypted: encrypted:
bytes 0-527: AES-encrypted record(note: same size as BuildRequestRecord!) bytes 0-527: AES-encrypted record(note: same size as BuildRequestRecord)
total length: 528 total length: 528

91
www.i2p2/pages/tunnel-alt-creation.html
View File

@ -17,9 +17,13 @@ for an overview of the process, including peer selection and ordering methods.
the path of peers in the tunnel, rewritten in place, and transmitted the path of peers in the tunnel, rewritten in place, and transmitted
back to the tunnel creator. This single tunnel message is made up back to the tunnel creator. This single tunnel message is made up
of a variable number of records (up to 8) - one for each potential peer in of a variable number of records (up to 8) - one for each potential peer in
the tunnel. Individual records are asymmetrically encrypted to be the tunnel. Individual records are asymmetrically
<a href="how_cryptography.html#elgamal">(ElGamal)</a>
encrypted to be
read only by a specific peer along the path, while an additional read only by a specific peer along the path, while an additional
symmetric layer of encryption is added at each hop so as to expose symmetric layer of encryption
<a href="how_cryptography.html#AES">(AES)</a>
is added at each hop so as to expose
the asymmetrically encrypted record only at the appropriate time.</p> the asymmetrically encrypted record only at the appropriate time.</p>
<h3 id="number">Number of Records</h3> <h3 id="number">Number of Records</h3>
@ -37,7 +41,7 @@ with the desired amount of tunnel length obfuscation.
In the current network, most tunnels are 2 or 3 hops long. In the current network, most tunnels are 2 or 3 hops long.
The current implementation uses a 5-record VTBM to build tunnels of 4 hops or less, The current implementation uses a 5-record VTBM to build tunnels of 4 hops or less,
and the 8-record TBM for longer tunnels. and the 8-record TBM for longer tunnels.
The 5-record VTBM (which fits in 3 1KB tunnel messaages) reduces network traffic The 5-record VTBM (which, when fragmented, fits in three 1KB tunnel messaages) reduces network traffic
and increases build sucess rate, because smaller messages are less likely to be dropped. and increases build sucess rate, because smaller messages are less likely to be dropped.
<p> <p>
The reply message must be the same type and length as the build message. The reply message must be the same type and length as the build message.
@ -56,7 +60,7 @@ Also specified in the
bytes 72-103: AES-256 tunnel layer key bytes 72-103: AES-256 tunnel layer key
bytes 104-135: AES-256 tunnel IV key bytes 104-135: AES-256 tunnel IV key
bytes 136-167: AES-256 reply key bytes 136-167: AES-256 reply key
bytes 168-183: reply IV bytes 168-183: AES-256 reply IV
byte 184: flags byte 184: flags
bytes 185-188: request time (in hours since the epoch) bytes 185-188: request time (in hours since the epoch)
bytes 189-192: next message ID bytes 189-192: next message ID
@ -73,14 +77,24 @@ message ID that the message (or reply) should use.</p>
Bit order: 76543210 (bit 7 is MSB) Bit order: 76543210 (bit 7 is MSB)
bit 7: if set, allow messages from anyone bit 7: if set, allow messages from anyone
bit 6: if set, allow messages to anyone, and send the reply to the bit 6: if set, allow messages to anyone, and send the reply to the
specified next hop in a tunnel message specified next hop in a Tunnel Build Reply Message
bits 5-0: Undefined bits 5-0: Undefined
</pre> </pre>
Bit 7 indicates that the hop will be an inbound gateway (IBGW). Bit 7 indicates that the hop will be an inbound gateway (IBGW).
Bit 6 indicates that the hop will be an outbound endpoint (OBEP). Bit 6 indicates that the hop will be an outbound endpoint (OBEP).
If neither bit is set, the hop will be an intermediate participant.
<h4 id="encryption">Request Encryption</h4> <h4>Request Record Creation</h4>
<p>
Every hop gets a random Tunnel ID.
The current and next-hop Tunnel IDs are filled in.
Every record gets a random tunnel IV key, and reply IV.
The layer and reply key pairs are generated.
</p>
<h4 id="encryption">Request Record Encryption</h4>
<p>That cleartext record is <a href="how_cryptography.html#elgamal">ElGamal 2048 encrypted</a> with the hop's <p>That cleartext record is <a href="how_cryptography.html#elgamal">ElGamal 2048 encrypted</a> with the hop's
public encryption key and formatted into a 528 byte record:</p><pre> public encryption key and formatted into a 528 byte record:</p><pre>
@ -95,6 +109,12 @@ The two padding bytes from the block (the zero bytes at locations 0 and 257) are
<p>Since the cleartext uses the full field, there is no need for <p>Since the cleartext uses the full field, there is no need for
additional padding beyond <code>SHA256(cleartext) + cleartext</code>.</p> additional padding beyond <code>SHA256(cleartext) + cleartext</code>.</p>
<p>
Each 528-byte record is then iteratively encrypted
(using AES decryption, with the reply key and reply IV for each hop) so that the router identity will only be in cleartext
for the hop in question.
</p>
<h3 id="tunnelCreate.hopProcessing">Hop Processing and Encryption</h3> <h3 id="tunnelCreate.hopProcessing">Hop Processing and Encryption</h3>
<p>When a hop receives a TunnelBuildMessage, it looks through the <p>When a hop receives a TunnelBuildMessage, it looks through the
@ -108,9 +128,17 @@ are dropped.</p>
<p>After deciding whether they will agree to participate in the tunnel <p>After deciding whether they will agree to participate in the tunnel
or not, they replace the record that had contained the request with or not, they replace the record that had contained the request with
an encrypted reply block. All other records are <a href="how_cryptography.html#AES">AES-256/CBC an encrypted reply block. All other records are <a href="how_cryptography.html#AES">AES-256
encrypted</a> with the included reply key and IV (though each is encrypted</a> with the included reply key and IV. Each is
encrypted separately, rather than chained across records).</p> encrypted separately, rather than chained across records.</p>
<p>
Each hop knows only its own response.
If it agrees, it will maintain the tunnel until expiration,
even if it will not be used,
as it cannot know whether all other hops agreed.
</p>
<h4 id="tunnelCreate.replyRecord">Reply Record Specification</h4> <h4 id="tunnelCreate.replyRecord">Reply Record Specification</h4>
@ -145,19 +173,23 @@ The padding is placed before the status byte:
This is also described in the This is also described in the
<a href="i2np_spec.html#msg_TunnelBuildReply">I2NP spec</a>. <a href="i2np_spec.html#msg_TunnelBuildReply">I2NP spec</a>.
<h3 id="tunnelCreate.requestPreparation">Request Preparation</h3> <h3 id="tunnelCreate.requestPreparation">Tunnel Build Message Preparation</h3>
<p>When building a new request, all of the records must first be <p>When building a new Tunnel Build Messaage, all of the Build Request Records must first be
built and asymmetrically encrypted. Each record should then be built and asymmetrically encrypted using
decrypted with the reply keys and IVs of the hops earlier in the <a href="how_cryptography.html#elgamal">ElGamal</a>.
path. That decryption should be run in reverse order so that the Each record is then
premptively decrypted with the reply keys and IVs of the hops earlier in the
path, using
<a href="how_cryptography.html#AES">AES</a>.
That decryption should be run in reverse order so that the
asymmetrically encrypted data will show up in the clear at the asymmetrically encrypted data will show up in the clear at the
right hop after their predecessor encrypts it.</p> right hop after their predecessor encrypts it.</p>
<p>The excess records not needed for individual requests are simply <p>The excess records not needed for individual requests are simply
filled with random data by the creator.</p> filled with random data by the creator.</p>
<h3 id="tunnelCreate.requestDelivery">Request Delivery</h3> <h3 id="tunnelCreate.requestDelivery">Tunnel Build Message Delivery</h3>
<p>For outbound tunnels, the delivery is done directly from the tunnel <p>For outbound tunnels, the delivery is done directly from the tunnel
creator to the first hop, packaging up the TunnelBuildMessage as if creator to the first hop, packaging up the TunnelBuildMessage as if
@ -168,7 +200,7 @@ If no outbound tunnel is available in that pool, an outbound exploratory tunnel
At startup, when no outbound exploratory tunnel exists yet, a fake 0-hop At startup, when no outbound exploratory tunnel exists yet, a fake 0-hop
outbound tunnel is used.</p> outbound tunnel is used.</p>
<h3 id="tunnelCreate.endpointHandling">Endpoint Handling</h3> <h3 id="tunnelCreate.endpointHandling">Tunnel Build Message Endpoint Handling</h3>
<p> <p>
For creation of an outbound tunnel, For creation of an outbound tunnel,
@ -184,10 +216,12 @@ or
(the type of message and number of records must match that of the request) (the type of message and number of records must match that of the request)
and delivers it to the and delivers it to the
reply tunnel specified within the request record. That reply tunnel reply tunnel specified within the request record. That reply tunnel
forwards the reply records down to the tunnel creator for forwards the Tunnel Build Reply Message back to the tunnel creator,
processing, as below.</p> <a href="tunnel-alt.html#tunnel.operation">just as for any other message</a>.
The tunnel creator then
processes it, as described below.</p>
<p>The reply tunnel was specified by the creator as follows: <p>The reply tunnel was selected by the creator as follows:
Generally it is an inbound tunnel from the same pool as the new outbound tunnel being built. Generally it is an inbound tunnel from the same pool as the new outbound tunnel being built.
If no inbound tunnel is available in that pool, an inbound exploratory tunnel is used. If no inbound tunnel is available in that pool, an inbound exploratory tunnel is used.
At startup, when no inbound exploratory tunnel exists yet, a fake 0-hop At startup, when no inbound exploratory tunnel exists yet, a fake 0-hop
@ -196,10 +230,10 @@ inbound tunnel is used.</p>
<p> <p>
For creation of an inbound tunnel, For creation of an inbound tunnel,
when the request reaches the inbound endpoint (also known as the when the request reaches the inbound endpoint (also known as the
tunnel creator), there is no need to generate an explicit Reply Message, and tunnel creator), there is no need to generate an explicit Tunnel Build Reply Message, and
the router processes each of the replies, as below.</p> the router processes each of the replies, as below.</p>
<h3 id="tunnelCreate.replyProcessing">Reply Processing by the Request Creator</h3> <h3 id="tunnelCreate.replyProcessing">Tunnel Build Reply Message Processing</h3>
<p>To process the reply records, the creator simply has to AES decrypt <p>To process the reply records, the creator simply has to AES decrypt
each record individually, using the reply key and IV of each hop in each record individually, using the reply key and IV of each hop in
@ -267,9 +301,12 @@ update</a>
<h2 id="future">Future Work</h2> <h2 id="future">Future Work</h2>
<ul> <ul>
<li> <li>
It appears that, in the current implementation, the originator leaves one record empty In the current implementation, the originator leaves one record empty
for itself, which is not necessary. Thus a message of n records can only build a for itself. Thus a message of n records can only build a
tunnel of n-1 hops. This is to be researched and verified. tunnel of n-1 hops.
This appears to be necessary for inbound tunnels (where the next-to-last hop
can see the hash prefix for the next hop), but not for outbound tunnels.
This is to be researched and verified.
If it is possible to use the remaining record without compromising anonymity, If it is possible to use the remaining record without compromising anonymity,
we should do so. we should do so.
<li> <li>
@ -279,7 +316,11 @@ Therefore the request time field is unused.
This should be researched and possibly changed. This should be researched and possibly changed.
<li> <li>
Further analysis of possible tagging and timing attacks described in the above notes. Further analysis of possible tagging and timing attacks described in the above notes.
</ul> </li><li>
The Bloom filter rotation time should be evaluated.
</li><li>
Use only VTBM; do not select old peers that don't support it.
</li></ul>
{% endblock %} {% endblock %}

158
www.i2p2/pages/tunnel-alt.html
View File

@ -3,18 +3,18 @@
{% block content %} {% block content %}
This page documents the current tunnel implementation. This page documents the current tunnel implementation.
Updated July 2010 for release 0.8 Updated September 2010 for release 0.8
<h2>1) <a name="tunnel.overview">Tunnel overview</a></h2> <h2><a name="tunnel.overview">Tunnel overview</a></h2>
<p>Within I2P, messages are passed in one direction through a virtual <p>Within I2P, messages are passed in one direction through a virtual
tunnel of peers, using whatever means are available to pass the tunnel of peers, using whatever means are available to pass the
message on to the next hop. Messages arrive at the tunnel's message on to the next hop. Messages arrive at the tunnel's
gateway, get bundled up and/or fragmented into fixed sizes tunnel messages, </i>gateway</i>, get bundled up and/or fragmented into fixed-size tunnel messages,
and are forwarded on to the next hop in the tunnel, which processes and verifies and are forwarded on to the next hop in the tunnel, which processes and verifies
the validity of the message and sends it on to the next hop, and so on, until the validity of the message and sends it on to the next hop, and so on, until
it reaches the tunnel endpoint. That endpoint takes the messages it reaches the tunnel endpoint. That <i>endpoint</i> takes the messages
bundled up by the gateway and forwards them as instructed - either bundled up by the gateway and forwards them as instructed - either
to another router, to another tunnel on another router, or locally.</p> to another router, to another tunnel on another router, or locally.</p>
@ -27,8 +27,8 @@ out to the remote endpoint.</p>
<p>The tunnel's creator selects exactly which peers will participate <p>The tunnel's creator selects exactly which peers will participate
in the tunnel, and provides each with the necessary configuration in the tunnel, and provides each with the necessary configuration
data. They may have any number of hops, but may be constrained with various data. They may have any number of hops.
proof-of-work requests to add on additional steps. It is the intent to make It is the intent to make
it hard for either participants or third parties to determine the length of it hard for either participants or third parties to determine the length of
a tunnel, or even for colluding participants to determine whether they are a a tunnel, or even for colluding participants to determine whether they are a
part of the same tunnel at all (barring the situation where colluding peers are part of the same tunnel at all (barring the situation where colluding peers are
@ -49,31 +49,88 @@ available for client applications, exposing TCP-esque operation,
including message reordering, retransmission, congestion control, etc.</p> including message reordering, retransmission, congestion control, etc.</p>
<p> <p>
An overview of I2P terminology is An overview of I2P tunnel terminology is
<a href="how_tunnelrouting.html">on the tunnel overview page</a>. <a href="how_tunnelrouting.html">on the tunnel overview page</a>.
</p> </p>
<h2>2) <a name="tunnel.operation">Tunnel operation</a></h2> <h2><a name="tunnel.operation">Tunnel Operation (Message Processing)</a></h2>
<h3>Overview</h3>
<p>Tunnel operation has four distinct processes, taken on by various <p>After a tunnel is built, <a href="i2np.html">I2NP messages</a> are processed and passed through it.
peers in the tunnel. First, the tunnel gateway accumulates a number Tunnel operation has four distinct processes, taken on by various
of tunnel messages and preprocesses them into something for tunnel peers in the tunnel. <ol><li>First, the tunnel gateway accumulates a number
delivery. Next, that gateway encrypts that preprocessed data, then of I2NP messages and preprocesses them into tunnel messages for
forwards it to the first hop. That peer, and subsequent tunnel delivery. </li><li>Next, that gateway encrypts that preprocessed data, then
forwards it to the first hop. </li><li>That peer, and subsequent tunnel
participants, unwrap a layer of the encryption, verifying that it isn't participants, unwrap a layer of the encryption, verifying that it isn't
a duplicate, then forward it on to the next peer. a duplicate, then forward it on to the next peer.
Eventually, the message arrives at the endpoint where the messages </li><li>Eventually, the tunnel messages arrive at the endpoint where the I2NP messages
bundled by the gateway are split out again and forwarded on as originally bundled by the gateway are reassembled and forwarded on as
requested.</p> requested.</li></ol></p>
<p>Tunnel IDs are 4 byte numbers used at each hop - participants know what <p>
tunnel ID to listen for messages with and what tunnel ID they should be forwarded Intermediate tunnel participants do not know whether they are in an
on as to the next hop, and each hop chooses the tunnel ID which they receive messages inbound or an outbound tunnel; they always "encrypt" for the next hop.
on. Tunnels themselves are short-lived (10 minutes). Therefore, we take advantage of symmetric AES encryption
Even if subsequent tunnels are built using the same sequence of to "decrypt" at the outbound tunnel gateway,
peers, each hop's tunnel ID will change.</p> so that the plaintext is revealed at the outbound endpoint.
</p>
<p>
<center>
<img src="/_static/images/tunnels.png" alt="Inbound and outbound tunnel schematic" title="Inbound and outbound tunnel schematic" />
</center>
</p>
<h3>2.1) <a name="tunnel.preprocessing">Message preprocessing</a></h3> <table><tr>
<th>Role</th>
<th>Preprocessing</th>
<th>Encryption Operation</th>
<th>Postprocessing</th>
</tr>
<tr><td>Outbound Gateway (Creator)</td>
<td>Fragment, Batch, and Pad</td>
<td>Iteratively encrypt (using decryption operations)</td>
<td>Forward to next hop</td>
</tr>
<tr><td>Participant</td>
<td>&nbsp;</td>
<td>Decrypt (using an encryption operation)</td>
<td>Forward to next hop</td>
</tr>
<tr><td>Outbound Endpoint</td>
<td>&nbsp;</td>
<td>Decrypt (using an encryption operation) to reveal plaintext tunnel message</td>
<td>Reassemble Fragments, Forward as instructed to Inbound Gateway or Router</td>
</tr>
<tr><td colspan="4"><hr></td></tr>
<tr><td>Inbound Gateway</td>
<td>Fragment, Batch, and Pad</td>
<td>Encrypt</td>
<td>Forward to next hop</td>
</tr>
<tr><td>Participant</td>
<td>&nbsp;</td>
<td>Encrypt</td>
<td>Forward to next hop</td>
</tr>
<tr><td>Inbound Endpoint (Creator)</td>
<td>&nbsp;</td>
<td>Iteratively decrypt to reveal plaintext tunnel message</td>
<td>Reassemble Fragments, Receive data</td>
</tr>
</table>
<h3><a name="tunnel.gateway">Gateway Processing</a></h3>
<h4><a name="tunnel.preprocessing">Message Preprocessing</a></h4>
<p>A tunnel gateway's function is to fragment and pack <p>A tunnel gateway's function is to fragment and pack
<a href="i2np.html">I2NP messages</a> into fixed-size <a href="i2np.html">I2NP messages</a> into fixed-size
@ -86,9 +143,23 @@ Tunnel messages contain the following:
<li>A 16 byte IV (initialization vector)</li> <li>A 16 byte IV (initialization vector)</li>
<li>A checksum <li>A checksum
<li>Padding, if necessary</li> <li>Padding, if necessary</li>
<li>One or more { delivery instruction, I2NP message fragment} pairs</li> <li>One or more { delivery instruction, I2NP message fragment } pairs</li>
</ul> </ul>
<p>Tunnel IDs are 4 byte numbers used at each hop - participants know what
tunnel ID to listen for messages with and what tunnel ID they should be forwarded
on as to the next hop, and each hop chooses the tunnel ID which they receive messages
on. Tunnels themselves are short-lived (10 minutes).
Even if subsequent tunnels are built using the same sequence of
peers, each hop's tunnel ID will change.</p>
<p>To prevent adversaries from tagging the messages along the path by adjusting
the message size, all tunnel messages are a fixed 1024 bytes in size. To accommodate
larger I2NP messages as well as to support smaller ones more efficiently, the
gateway splits up the larger I2NP messages into fragments contained within each
tunnel message. The endpoint will attempt to rebuild the I2NP message from the
fragments for a short period of time, but will discard them as necessary.</p>
<p> <p>
Details are in the Details are in the
@ -96,7 +167,7 @@ Details are in the
<h3>2.2) <a name="tunnel.gateway">Gateway Processing</a></h3> <h4>Gateway Encryption</h3>
<p>After the preprocessing of messages into a padded payload, the gateway builds <p>After the preprocessing of messages into a padded payload, the gateway builds
a random 16 byte IV value, iteratively encrypting it and the tunnel message as a random 16 byte IV value, iteratively encrypting it and the tunnel message as
@ -111,7 +182,7 @@ data with the IV and layer keys for all hops in the tunnel. The result of the o
tunnel encryption is that when each peer encrypts it, the endpoint will recover tunnel encryption is that when each peer encrypts it, the endpoint will recover
the initial preprocessed data.</p> the initial preprocessed data.</p>
<h3>2.3) <a name="tunnel.participant">Participant Processing</a></h3> <h3><a name="tunnel.participant">Participant Processing</a></h3>
<p>When a peer receives a tunnel message, it checks that the message came from <p>When a peer receives a tunnel message, it checks that the message came from
the same previous hop as before (initialized when the first message comes through the same previous hop as before (initialized when the first message comes through
@ -134,7 +205,7 @@ false positive. The unique value fed into the Bloom filter is the XOR of the IV
and the first block so as to prevent nonsequential colluding peers in the tunnel and the first block so as to prevent nonsequential colluding peers in the tunnel
from tagging a message by resending it with the IV and first block switched.</p> from tagging a message by resending it with the IV and first block switched.</p>
<h3>2.4) <a name="tunnel.endpoint">Endpoint Processing</a></h3> <h3><a name="tunnel.endpoint">Endpoint Processing</a></h3>
<p>After receiving and validating a tunnel message at the last hop in the tunnel, <p>After receiving and validating a tunnel message at the last hop in the tunnel,
how the endpoint recovers the data encoded by the gateway depends upon whether how the endpoint recovers the data encoded by the gateway depends upon whether
@ -148,23 +219,6 @@ layer and IV keys of each step in reverse order.</p>
which it may then parse out into the included I2NP messages and forwards them as which it may then parse out into the included I2NP messages and forwards them as
requested in their delivery instructions.</p> requested in their delivery instructions.</p>
<p>These padding strategies can be used on a variety of levels, addressing the
exposure of message size information to different adversaries. After gathering
and reviewing some <a href="http://dev.i2p.net/~jrandom/messageSizes/">statistics</a>
from the 0.4 network, as well as exploring the anonymity tradeoffs, we're starting
with a fixed tunnel message size of 1024 bytes. Within this however, the fragmented
messages themselves are not padded by the tunnel at all (though for end to end
messages, they may be padded as part of the garlic wrapping).</p>
<h3>2.6) <a name="tunnel.fragmentation">Tunnel Fragmentation</a></h3>
<p>To prevent adversaries from tagging the messages along the path by adjusting
the message size, all tunnel messages are a fixed 1024 bytes in size. To accommodate
larger I2NP messages as well as to support smaller ones more efficiently, the
gateway splits up the larger I2NP messages into fragments contained within each
tunnel message. The endpoint will attempt to rebuild the I2NP message from the
fragments for a short period of time, but will discard them as necessary.</p>
<h2><a name="tunnel.building">Tunnel Building</a></h2> <h2><a name="tunnel.building">Tunnel Building</a></h2>
@ -177,7 +231,7 @@ reply. There are three important dimensions to keep in mind when producing
the tunnels: what peers are used (and where), how the requests are sent (and the tunnels: what peers are used (and where), how the requests are sent (and
replies received), and how they are maintained.</p> replies received), and how they are maintained.</p>
<h3>3.1) <a name="tunnel.peerselection">Peer Selection</a></h3> <h3><a name="tunnel.peerselection">Peer Selection</a></h3>
<p>Beyond the two types of tunnels - inbound and outbound - there are two styles <p>Beyond the two types of tunnels - inbound and outbound - there are two styles
of peer selection used for different tunnels - exploratory and client. of peer selection used for different tunnels - exploratory and client.
@ -240,7 +294,7 @@ within a single pool but not between different pools.
New keys are generated at each router restart. New keys are generated at each router restart.
<h3>3.2) <a name="tunnel.request">Request delivery</a></h3> <h3><a name="tunnel.request">Request delivery</a></h3>
<p> <p>
A multi-hop tunnel is built using a single build message which is repeatedly A multi-hop tunnel is built using a single build message which is repeatedly
@ -272,7 +326,7 @@ the router in question.
For more information on peer profiling, see the For more information on peer profiling, see the
<a href="how_peerselection.html">Peer Profiling and Selection page</a>. <a href="how_peerselection.html">Peer Profiling and Selection page</a>.
<h3>3.3) <a name="tunnel.pooling">Tunnel Pools</a></h3> <h3><a name="tunnel.pooling">Tunnel Pools</a></h3>
<p>To allow efficient operation, the router maintains a series of tunnel pools, <p>To allow efficient operation, the router maintains a series of tunnel pools,
each managing a group of tunnels used for a specific purpose with their own each managing a group of tunnels used for a specific purpose with their own
@ -327,4 +381,14 @@ automatically, how much should be configured as a per tunnel or per hop setting,
and how should the tunnel's creator (and in turn, user) control this operation? and how should the tunnel's creator (and in turn, user) control this operation?
All of this is left as unknown, to be worked out for a distant future release. All of this is left as unknown, to be worked out for a distant future release.
<h3>Padding</h3>
<p>The padding strategies can be used on a variety of levels, addressing the
exposure of message size information to different adversaries.
The current fixed tunnel message size is 1024 bytes. Within this however, the fragmented
messages themselves are not padded by the tunnel at all, though for end to end
messages, they may be padded as part of the garlic wrapping.</p>
{% endblock %} {% endblock %}