tunnel edits
This commit is contained in:
@ -132,20 +132,36 @@ Cleartext:
|
||||
| reply_iv |
|
||||
+ +
|
||||
| |
|
||||
+----+----+----+----+----+----+----+----+----+
|
||||
|flag| request_time | send_message_id |
|
||||
+----+----+----+----+----+----+----+----+----+
|
||||
| padding...
|
||||
+----+----+----+--//
|
||||
+----+----+----+----+----+----+----+----+
|
||||
|flag| request_time | send_msg_id
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| |
|
||||
+----+ +
|
||||
| 29 bytes padding |
|
||||
+ +
|
||||
| |
|
||||
+ +----+----+
|
||||
| |
|
||||
+----+----+----+----+----+----+
|
||||
|
||||
encrypted:
|
||||
|
||||
ElGamal encrypted:
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| toPeer |
|
||||
+ +
|
||||
| |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| encrypted data ... |
|
||||
~ ~
|
||||
| |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
|
||||
|
||||
ElGamal and AES encrypted:
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| encrypted data ... |
|
||||
~ ~
|
||||
| |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
{% endfilter %}
|
||||
</pre>
|
||||
@ -190,12 +206,12 @@ send_message_id :: Integer
|
||||
|
||||
padding :: Data
|
||||
length -> 29 bytes
|
||||
|
||||
source -> random
|
||||
|
||||
total length: 222
|
||||
|
||||
encrypted:
|
||||
|
||||
ElGamal encrypted:
|
||||
|
||||
toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity
|
||||
length -> 16 bytes
|
||||
@ -205,6 +221,14 @@ encrypted_data :: ElGamal-2048 encrypted data (see notes)
|
||||
|
||||
total length: 528
|
||||
|
||||
|
||||
ElGamal and AES encrypted:
|
||||
|
||||
encrypted_data :: ElGamal and AES encrypted data
|
||||
length -> 528
|
||||
|
||||
total length: 528
|
||||
|
||||
{% endfilter %}
|
||||
</pre>
|
||||
|
||||
@ -226,7 +250,7 @@ The two padding bytes from the block (the zero bytes at locations 0 and 257) are
|
||||
unencrypted:
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| random data... |
|
||||
|
||||
~ ~
|
||||
| |
|
||||
+ +----+
|
||||
| |ret |
|
||||
@ -241,7 +265,7 @@ bytes 0-526: random data
|
||||
byte 527 : reply
|
||||
|
||||
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
|
||||
|
||||
|
||||
@ -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
|
||||
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
|
||||
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
|
||||
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>
|
||||
|
||||
<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.
|
||||
The current implementation uses a 5-record VTBM to build tunnels of 4 hops or less,
|
||||
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.
|
||||
<p>
|
||||
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 104-135: AES-256 tunnel IV key
|
||||
bytes 136-167: AES-256 reply key
|
||||
bytes 168-183: reply IV
|
||||
bytes 168-183: AES-256 reply IV
|
||||
byte 184: flags
|
||||
bytes 185-188: request time (in hours since the epoch)
|
||||
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 7: if set, allow messages from anyone
|
||||
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
|
||||
</pre>
|
||||
|
||||
Bit 7 indicates that the hop will be an inbound gateway (IBGW).
|
||||
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
|
||||
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
|
||||
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>
|
||||
|
||||
<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
|
||||
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
|
||||
encrypted</a> with the included reply key and IV (though each is
|
||||
encrypted separately, rather than chained across records).</p>
|
||||
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. Each is
|
||||
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>
|
||||
|
||||
@ -145,19 +173,23 @@ The padding is placed before the status byte:
|
||||
This is also described in the
|
||||
<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
|
||||
built and asymmetrically encrypted. Each record should then be
|
||||
decrypted with the reply keys and IVs of the hops earlier in the
|
||||
path. That decryption should be run in reverse order so that the
|
||||
<p>When building a new Tunnel Build Messaage, all of the Build Request Records must first be
|
||||
built and asymmetrically encrypted using
|
||||
<a href="how_cryptography.html#elgamal">ElGamal</a>.
|
||||
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
|
||||
right hop after their predecessor encrypts it.</p>
|
||||
|
||||
<p>The excess records not needed for individual requests are simply
|
||||
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
|
||||
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
|
||||
outbound tunnel is used.</p>
|
||||
|
||||
<h3 id="tunnelCreate.endpointHandling">Endpoint Handling</h3>
|
||||
<h3 id="tunnelCreate.endpointHandling">Tunnel Build Message Endpoint Handling</h3>
|
||||
|
||||
<p>
|
||||
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)
|
||||
and delivers it to the
|
||||
reply tunnel specified within the request record. That reply tunnel
|
||||
forwards the reply records down to the tunnel creator for
|
||||
processing, as below.</p>
|
||||
forwards the Tunnel Build Reply Message back to the tunnel creator,
|
||||
<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.
|
||||
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
|
||||
@ -196,10 +230,10 @@ inbound tunnel is used.</p>
|
||||
<p>
|
||||
For creation of an inbound tunnel,
|
||||
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>
|
||||
|
||||
<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
|
||||
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>
|
||||
<ul>
|
||||
<li>
|
||||
It appears that, 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
|
||||
tunnel of n-1 hops. This is to be researched and verified.
|
||||
In the current implementation, the originator leaves one record empty
|
||||
for itself. Thus a message of n records can only build a
|
||||
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,
|
||||
we should do so.
|
||||
<li>
|
||||
@ -279,7 +316,11 @@ Therefore the request time field is unused.
|
||||
This should be researched and possibly changed.
|
||||
<li>
|
||||
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 %}
|
||||
|
||||
@ -3,18 +3,18 @@
|
||||
{% block content %}
|
||||
|
||||
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
|
||||
tunnel of peers, using whatever means are available to pass the
|
||||
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
|
||||
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
|
||||
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
|
||||
in the tunnel, and provides each with the necessary configuration
|
||||
data. They may have any number of hops, but may be constrained with various
|
||||
proof-of-work requests to add on additional steps. It is the intent to make
|
||||
data. They may have any number of hops.
|
||||
It is the intent to make
|
||||
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
|
||||
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>
|
||||
|
||||
<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>.
|
||||
</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
|
||||
peers in the tunnel. First, the tunnel gateway accumulates a number
|
||||
of tunnel messages and preprocesses them into something for tunnel
|
||||
delivery. Next, that gateway encrypts that preprocessed data, then
|
||||
forwards it to the first hop. That peer, and subsequent tunnel
|
||||
<p>After a tunnel is built, <a href="i2np.html">I2NP messages</a> are processed and passed through it.
|
||||
Tunnel operation has four distinct processes, taken on by various
|
||||
peers in the tunnel. <ol><li>First, the tunnel gateway accumulates a number
|
||||
of I2NP messages and preprocesses them into tunnel messages for
|
||||
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
|
||||
a duplicate, then forward it on to the next peer.
|
||||
Eventually, the message arrives at the endpoint where the messages
|
||||
bundled by the gateway are split out again and forwarded on as
|
||||
requested.</p>
|
||||
</li><li>Eventually, the tunnel messages arrive at the endpoint where the I2NP messages
|
||||
originally bundled by the gateway are reassembled and forwarded on as
|
||||
requested.</li></ol></p>
|
||||
|
||||
<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>
|
||||
Intermediate tunnel participants do not know whether they are in an
|
||||
inbound or an outbound tunnel; they always "encrypt" for the next hop.
|
||||
Therefore, we take advantage of symmetric AES encryption
|
||||
to "decrypt" at the outbound tunnel gateway,
|
||||
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> </td>
|
||||
<td>Decrypt (using an encryption operation)</td>
|
||||
<td>Forward to next hop</td>
|
||||
</tr>
|
||||
|
||||
<tr><td>Outbound Endpoint</td>
|
||||
<td> </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> </td>
|
||||
<td>Encrypt</td>
|
||||
<td>Forward to next hop</td>
|
||||
</tr>
|
||||
|
||||
<tr><td>Inbound Endpoint (Creator)</td>
|
||||
<td> </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
|
||||
<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 checksum
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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,
|
||||
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
|
||||
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>
|
||||
|
||||
@ -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
|
||||
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
|
||||
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.
|
||||
|
||||
|
||||
<h3>3.2) <a name="tunnel.request">Request delivery</a></h3>
|
||||
<h3><a name="tunnel.request">Request delivery</a></h3>
|
||||
|
||||
<p>
|
||||
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
|
||||
<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,
|
||||
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?
|
||||
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 %}
|
||||
|
||||
Reference in New Issue
Block a user