source: router/doc/tunnel.html @ 831d5ac

Last change on this file since 831d5ac was 831d5ac, checked in by zzz <zzz@…>, 16 years ago

not used

  • Property mode set to 100644
File size: 29.0 KB
Line 
1<b>Note: NOT used!  see tunnel-alt.html</b>
2
3<code>$Id: tunnel.html,v 1.10 2005/01/16 01:07:07 jrandom Exp $</code>
4<pre>
51) <a href="#tunnel.overview">Tunnel overview</a>
62) <a href="#tunnel.operation">Tunnel operation</a>
72.1) <a href="#tunnel.preprocessing">Message preprocessing</a>
82.2) <a href="#tunnel.gateway">Gateway processing</a>
92.3) <a href="#tunnel.participant">Participant processing</a>
102.4) <a href="#tunnel.endpoint">Endpoint processing</a>
112.5) <a href="#tunnel.padding">Padding</a>
122.6) <a href="#tunnel.fragmentation">Tunnel fragmentation</a>
132.7) <a href="#tunnel.alternatives">Alternatives</a>
142.7.1) <a href="#tunnel.nochecksum">Don't use a checksum block</a>
152.7.2) <a href="#tunnel.reroute">Adjust tunnel processing midstream</a>
162.7.3) <a href="#tunnel.bidirectional">Use bidirectional tunnels</a>
172.7.4) <a href="#tunnel.smallerhashes">Use smaller hashes</a>
183) <a href="#tunnel.building">Tunnel building</a>
193.1) <a href="#tunnel.peerselection">Peer selection</a>
203.1.1) <a href="#tunnel.selection.exploratory">Exploratory tunnel peer selection</a>
213.1.2) <a href="#tunnel.selection.client">Client tunnel peer selection</a>
223.2) <a href="#tunnel.request">Request delivery</a>
233.3) <a href="#tunnel.pooling">Pooling</a>
243.4) <a href="#tunnel.building.alternatives">Alternatives</a>
253.4.1) <a href="#tunnel.building.telescoping">Telescopic building</a>
263.4.2) <a href="#tunnel.building.nonexploratory">Non-exploratory tunnels for management</a>
274) <a href="#tunnel.throttling">Tunnel throttling</a>
285) <a href="#tunnel.mixing">Mixing/batching</a>
29</pre>
30
31<h2>1) <a name="tunnel.overview">Tunnel overview</a></h2>
32
33<p>Within I2P, messages are passed in one direction through a virtual
34tunnel of peers, using whatever means are available to pass the
35message on to the next hop.  Messages arrive at the tunnel's
36gateway, get bundled up for the path, and are forwarded on to the
37next hop in the tunnel, which processes and verifies the validity
38of the message and sends it on to the next hop, and so on, until
39it reaches the tunnel endpoint.  That endpoint takes the messages
40bundled up by the gateway and forwards them as instructed - either
41to another router, to another tunnel on another router, or locally.</p>
42
43<p>Tunnels all work the same, but can be segmented into two different
44groups - inbound tunnels and outbound tunnels.  The inbound tunnels
45have an untrusted gateway which passes messages down towards the
46tunnel creator, which serves as the tunnel endpoint.  For outbound
47tunnels, the tunnel creator serves as the gateway, passing messages
48out to the remote endpoint.</p>
49
50<p>The tunnel's creator selects exactly which peers will participate
51in the tunnel, and provides each with the necessary confiruration
52data.  They may vary in length from 0 hops (where the gateway
53is also the endpoint) to 8 hops (where there are 6 peers after
54the gateway and before the endpoint).  It is the intent to make
55it hard for either participants or third parties to determine
56the length of a tunnel, or even for colluding participants to
57determine whether they are a part of the same tunnel at all
58(barring the situation where colluding peers are next to each other
59in the tunnel).  Messages that have been corrupted are also dropped
60as soon as possible, reducing network load.</p>
61
62<p>Beyond their length, there are additional configurable parameters
63for each tunnel that can be used, such as a throttle on the size or
64frequency of messages delivered, how padding should be used, how
65long a tunnel should be in operation, whether to inject chaff
66messages, whether to use fragmentation, and what, if any, batching
67strategies should be employed.</p>
68
69<p>In practice, a series of tunnel pools are used for different
70purposes - each local client destination has its own set of inbound
71tunnels and outbound tunnels, configured to meet its anonymity and
72performance needs.  In addition, the router itself maintains a series
73of pools for participating in the network database and for managing
74the tunnels themselves.</p>
75
76<p>I2P is an inherently packet switched network, even with these
77tunnels, allowing it to take advantage of multiple tunnels running
78in parallel, increasing resiliance and balancing load.  Outside of
79the core I2P layer, there is an optional end to end streaming library
80available for client applications, exposing TCP-esque operation,
81including message reordering, retransmission, congestion control, etc.</p>
82
83<h2>2) <a name="tunnel.operation">Tunnel operation</a></h2>
84
85<p>Tunnel operation has four distinct processes, taken on by various
86peers in the tunnel.  First, the tunnel gateway accumulates a number
87of tunnel messages and preprocesses them into something for tunnel
88delivery.  Next, that gateway encrypts that preprocessed data, then
89forwards it to the first hop.  That peer, and subsequent tunnel
90participants, unwrap a layer of the encryption, verifying the
91integrity of the message, then forward it on to the next peer. 
92Eventually, the message arrives at the endpoint where the messages
93bundled by the gateway are split out again and forwarded on as
94requested.</p>
95
96<p>Tunnel IDs are 4 byte numbers used at each hop - participants know what
97tunnel ID to listen for messages with and what tunnel ID they should be forwarded
98on as to the next hop.  Tunnels themselves are short lived (10 minutes at the
99moment), but depending upon the tunnel's purpose, and though subsequent tunnels
100may be built using the same sequence of peers, each hop's tunnel ID will change.</p>
101
102<h3>2.1) <a name="tunnel.preprocessing">Message preprocessing</a></h3>
103
104<p>When the gateway wants to deliver data through the tunnel, it first
105gathers zero or more I2NP messages (no more than 32KB worth),
106selects how much padding will be used, and decides how each I2NP
107message should be handled by the tunnel endpoint, encoding that
108data into the raw tunnel payload:</p>
109<ul>
110<li>2 byte unsigned integer specifying the # of padding bytes</li>
111<li>that many random bytes</li>
112<li>a series of zero or more { instructions, message } pairs</li>
113</ul>
114
115<p>The instructions are encoded as follows:</p>
116<ul>
117<li>1 byte value:<pre>
118   bits 0-1: delivery type
119             (0x0 = LOCAL, 0x01 = TUNNEL, 0x02 = ROUTER)
120      bit 2: delay included?  (1 = true, 0 = false)
121      bit 3: fragmented?  (1 = true, 0 = false)
122      bit 4: extended options?  (1 = true, 0 = false)
123   bits 5-7: reserved</pre></li>
124<li>if the delivery type was TUNNEL, a 4 byte tunnel ID</li>
125<li>if the delivery type was TUNNEL or ROUTER, a 32 byte router hash</li>
126<li>if the delay included flag is true, a 1 byte value:<pre>
127      bit 0: type (0 = strict, 1 = randomized)
128   bits 1-7: delay exponent (2^value minutes)</pre></li>
129<li>if the fragmented flag is true, a 4 byte message ID, and a 1 byte value:<pre>
130   bits 0-6: fragment number
131      bit 7: is last?  (1 = true, 0 = false)</pre></li>
132<li>if the extended options flag is true:<pre>
133   = a 1 byte option size (in bytes)
134   = that many bytes</pre></li>
135<li>2 byte size of the I2NP message</li>
136</ul>
137
138<p>The I2NP message is encoded in its standard form, and the
139preprocessed payload must be padded to a multiple of 16 bytes.</p>
140
141<h3>2.2) <a name="tunnel.gateway">Gateway processing</a></h3>
142
143<p>After the preprocessing of messages into a padded payload, the gateway
144encrypts the payload with the eight keys, building a checksum block so
145that each peer can verify the integrity of the payload at any time, as
146well as an end to end verification block for the tunnel endpoint to
147verify the integrity of the checksum block.  The specific details follow.</p>
148
149<p>The encryption used is such that decryption
150merely requires running over the data with AES in CBC mode, calculating the
151SHA256 of a certain fixed portion of the message (bytes 16 through $size-144),
152and searching for the first 16 bytes of that hash in the checksum block.  There is a fixed number
153of hops defined (8 peers) so that we can verify the message
154without either leaking the position in the tunnel or having the message
155continually "shrink" as layers are peeled off.  For tunnels shorter than 8
156hops, the tunnel creator will take the place of the excess hops, decrypting
157with their keys (for outbound tunnels, this is done at the beginning, and for
158inbound tunnels, the end).</p>
159
160<p>The hard part in the encryption is building that entangled checksum block,
161which requires essentially finding out what the hash of the payload will look
162like at each step, randomly ordering those hashes, then building a matrix of
163what each of those randomly ordered hashes will look like at each step.  The
164gateway itself must pretend that it is one of the peers within the checksum
165block so that the first hop cannot tell that the previous hop was the gateway.
166To visualize this a bit:</p>
167
168<table border="1">
169 <tr><td colspan="2"></td>
170     <td><b>IV</b></td><td><b>Payload</b></td>
171     <td><b>eH[0]</b></td><td><b>eH[1]</b></td>
172     <td><b>eH[2]</b></td><td><b>eH[3]</b></td>
173     <td><b>eH[4]</b></td><td><b>eH[5]</b></td>
174     <td><b>eH[6]</b></td><td><b>eH[7]</b></td>
175     <td><b>V</b></td>
176 </tr>
177 <tr><td rowspan="2"><b>peer0</b><br /><font size="-2">key=K[0]</font></td><td><b>recv</b></td>
178     <td colspan="11"><hr /></td>
179 </tr>
180 <tr><td><b>send</b></td>
181     <td rowspan="2">IV[0]</td><td rowspan="2">P[0]</td>
182     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2">H(P[0])</td>
183     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td>
184     <td rowspan="2">V[0]</td>
185 </tr>
186 <tr><td rowspan="2"><b>peer1</b><br /><font size="-2">key=K[1]</font></td><td><b>recv</b></td>
187 </tr>
188 <tr><td><b>send</b></td>
189     <td rowspan="2">IV[1]</td><td rowspan="2">P[1]</td>
190     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td>
191     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2">H(P[1])</td><td rowspan="2"></td>
192     <td rowspan="2">V[1]</td>
193 </tr>
194 <tr><td rowspan="2"><b>peer2</b><br /><font size="-2">key=K[2]</font></td><td><b>recv</b></td>
195 </tr>
196 <tr><td><b>send</b></td>
197     <td rowspan="2">IV[2]</td><td rowspan="2">P[2]</td>
198     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td>
199     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2">H(P[2])</td>
200     <td rowspan="2">V[2]</td>
201 </tr>
202 <tr><td rowspan="2"><b>peer3</b><br /><font size="-2">key=K[3]</font></td><td><b>recv</b></td>
203 </tr>
204 <tr><td><b>send</b></td>
205     <td rowspan="2">IV[3]</td><td rowspan="2">P[3]</td>
206     <td rowspan="2">H(P[3])</td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td>
207     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td>
208     <td rowspan="2">V[3]</td>
209 </tr>
210 <tr><td rowspan="2"><b>peer4</b><br /><font size="-2">key=K[4]</font></td><td><b>recv</b></td>
211 </tr>
212 <tr><td><b>send</b></td>
213     <td rowspan="2">IV[4]</td><td rowspan="2">P[4]</td>
214     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2">H(P[4])</td><td rowspan="2"></td>
215     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td>
216     <td rowspan="2">V[4]</td>
217 </tr>
218 <tr><td rowspan="2"><b>peer5</b><br /><font size="-2">key=K[5]</font></td><td><b>recv</b></td>
219 </tr>
220 <tr><td><b>send</b></td>
221     <td rowspan="2">IV[5]</td><td rowspan="2">P[5]</td>
222     <td rowspan="2"></td><td rowspan="2">H(P[5])</td><td rowspan="2"></td><td rowspan="2"></td>
223     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td>
224     <td rowspan="2">V[5]</td>
225 </tr>
226 <tr><td rowspan="2"><b>peer6</b><br /><font size="-2">key=K[6]</font></td><td><b>recv</b></td>
227 </tr>
228 <tr><td><b>send</b></td>
229     <td rowspan="2">IV[6]</td><td rowspan="2">P[6]</td>
230     <td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td><td rowspan="2"></td>
231     <td rowspan="2"></td><td rowspan="2">H(P[6])</td><td rowspan="2"></td><td rowspan="2"></td>
232     <td rowspan="2">V[6]</td>
233 </tr>
234 <tr><td rowspan="2"><b>peer7</b><br /><font size="-2">key=K[7]</font></td><td><b>recv</b></td>
235 </tr>
236 <tr><td><b>send</b></td>
237     <td>IV[7]</td><td>P[7]</td>
238     <td></td><td></td><td></td><td></td><td>H(P[7])</td><td></td><td></td><td></td>
239     <td>V[7]</td>
240 </tr>
241</table>
242
243<p>In the above, P[7] is the same as the original data being passed through the
244tunnel (the preprocessed messages), and V[7] is the first 16 bytes of the SHA256 of eH[0-7] as seen on
245peer7 after decryption.  For
246cells in the matrix "higher up" than the hash, their value is derived by encrypting
247the cell below it with the key for the peer below it, using the end of the column
248to the left of it as the IV.  For cells in the matrix "lower down" than the hash,
249they're equal to the cell above them, decrypted by the current peer's key, using
250the end of the previous encrypted block on that row.</p>
251
252<p>With this randomized matrix of checksum blocks, each peer will be able to find
253the hash of the payload, or if it is not there, know that the message is corrupt.
254The entanglement by using CBC mode increases the difficulty in tagging the
255checksum blocks themselves, but it is still possible for that tagging to go
256briefly undetected if the columns after the tagged data have already been used
257to check the payload at a peer.  In any case, the tunnel endpoint (peer 7) knows
258for certain whether any of the checksum blocks have been tagged, as that would
259corrupt the verification block (V[7]).</p>
260
261<p>The IV[0] is a random 16 byte value, and IV[i] is the first 16 bytes of
262H(D(IV[i-1], K[i-1]) xor IV_WHITENER).  We don't use the same IV along the path, as that would
263allow trivial collusion, and we use the hash of the decrypted value to propogate
264the IV so as to hamper key leakage.  IV_WHITENER is a fixed 16 byte value.</p>
265
266<p>When the gateway wants to send the message, they export the right row for the
267peer who is the first hop (usually the peer1.recv row) and forward that entirely.</p>
268
269<h3>2.3) <a name="tunnel.participant">Participant processing</a></h3>
270
271<p>When a participant in a tunnel receives a message, they decrypt a layer with their
272tunnel key using AES256 in CBC mode with the first 16 bytes as the IV.  They then
273calculate the hash of what they see as the payload (bytes 16 through $size-144) and
274search for that first 16 bytes of that hash within the decrypted checksum block.  If no match is found, the
275message is discarded.  Otherwise, the IV is updated by decrypting it, XORing that value
276with the IV_WHITENER, and replacing it with the first 16 bytes of its hash.  The
277resulting message is then forwarded on to the next peer for processing.</p>
278
279<p>To prevent replay attacks at the tunnel level, each participant keeps track of
280the IVs received during the tunnel's lifetime, rejecting duplicates.  The memory
281usage required should be minor, as each tunnel has only a very short lifespan (10m
282at the moment).  A constant 100KBps through a tunnel with full 32KB messages would
283give 1875 messages, requiring less than 30KB of memory.  Gateways and endpoints
284handle replay by tracking the message IDs and expirations on the I2NP messages
285contained in the tunnel.</p>
286
287<h3>2.4) <a name="tunnel.endpoint">Endpoint processing</a></h3>
288
289<p>When a message reaches the tunnel endpoint, they decrypts and verifies it like
290a normal participant.  If the checksum block has a valid match, the endpoint then
291computes the hash of the checksum block itself (as seen after decryption) and compares
292that to the decrypted verification hash (the last 16 bytes).  If that verification
293hash does not match, the endpoint takes note of the tagging attempt by one of the
294tunnel participants and perhaps discards the message.</p>
295
296<p>At this point, the tunnel endpoint has the preprocessed data sent by the gateway,
297which it may then parse out into the included I2NP messages and forwards them as
298requested in their delivery instructions.</p>
299
300<h3>2.5) <a name="tunnel.padding">Padding</a></h3>
301
302<p>Several tunnel padding strategies are possible, each with their own merits:</p>
303
304<ul>
305<li>No padding</li>
306<li>Padding to a random size</li>
307<li>Padding to a fixed size</li>
308<li>Padding to the closest KB</li>
309<li>Padding to the closest exponential size (2^n bytes)</li>
310</ul>
311
312<p><i>Which to use?  no padding is most efficient, random padding is what
313we have now, fixed size would either be an extreme waste or force us to
314implement fragmentation.  Padding to the closest exponential size (ala freenet)
315seems promising.  Perhaps we should gather some stats on the net as to what size
316messages are, then see what costs and benefits would arise from different
317strategies?</i></p>
318
319<h3>2.6) <a name="tunnel.fragmentation">Tunnel fragmentation</a></h3>
320
321<p>For various padding and mixing schemes, it may be useful from an anonymity
322perspective to fragment a single I2NP message into multiple parts, each delivered
323seperately through different tunnel messages.  The endpoint may or may not
324support that fragmentation (discarding or hanging on to fragments as needed),
325and handling fragmentation will not immediately be implemented.</p>
326
327<h3>2.7) <a name="tunnel.alternatives">Alternatives</a></h3>
328
329<h4>2.7.1) <a name="tunnel.nochecksum">Don't use a checksum block</a></h4>
330
331<p>One alternative to the above process is to remove the checksum block
332completely and replace the verification hash with a plain hash of the payload.
333This would simplify processing at the tunnel gateway and save 144 bytes of
334bandwidth at each hop.  On the other hand, attackers within the tunnel could
335trivially adjust the message size to one which is easily traceable by
336colluding external observers in addition to later tunnel participants.  The
337corruption would also incur the waste of the entire bandwidth necessary to
338pass on the message.  Without the per-hop validation, it would also be possible
339to consume excess network resources by building extremely long tunnels, or by
340building loops into the tunnel.</p>
341
342<h4>2.7.2) <a name="tunnel.reroute">Adjust tunnel processing midstream</a></h4>
343
344<p>While the simple tunnel routing algorithm should be sufficient for most cases,
345there are three alternatives that can be explored:</p>
346<ul>
347<li>Delay a message within a tunnel at an arbitrary hop for either a specified
348amount of time or a randomized period.  This could be achieved by replacing the
349hash in the checksum block with e.g. the first 8 bytes of the hash, followed by
350some delay instructions.  Alternately, the instructions could tell the
351participant to actually interpret the raw payload as it is, and either discard
352the message or continue to forward it down the path (where it would be
353interpreted by the endpoint as a chaff message).  The later part of this would
354require the gateway to adjust its encryption algorithm to produce the cleartext
355payload on a different hop, but it shouldn't be much trouble.</li>
356<li>Allow routers participating in a tunnel to remix the message before
357forwarding it on - bouncing it through one of that peer's own outbound tunnels,
358bearing instructions for delivery to the next hop.  This could be used in either
359a controlled manner (with en-route instructions like the delays above) or
360probabalistically.</li>
361<li>Implement code for the tunnel creator to redefine a peer's "next hop" in
362the tunnel, allowing further dynamic redirection.</li>
363</ul>
364
365<h4>2.7.3) <a name="tunnel.bidirectional">Use bidirectional tunnels</a></h4>
366
367<p>The current strategy of using two seperate tunnels for inbound and outbound
368communication is not the only technique available, and it does have anonymity
369implications.  On the positive side, by using separate tunnels it lessens the
370traffic data exposed for analysis to participants in a tunnel - for instance,
371peers in an outbound tunnel from a web browser would only see the traffic of
372an HTTP GET, while the peers in an inbound tunnel would see the payload
373delivered along the tunnel.  With bidirectional tunnels, all participants would
374have access to the fact that e.g. 1KB was sent in one direction, then 100KB
375in the other.  On the negative side, using unidirectional tunnels means that
376there are two sets of peers which need to be profiled and accounted for, and
377additional care must be taken to address the increased speed of predecessor
378attacks.  The tunnel pooling and building process outlined below should
379minimize the worries of the predecessor attack, though if it were desired,
380it wouldn't be much trouble to build both the inbound and outbound tunnels
381along the same peers.</p>
382
383<h4>2.7.4) <a name="tunnel.smallerhashes">Use smaller blocksize</a></h4>
384
385<p>At the moment, our use of AES limits our block size to 16 bytes, which
386in turn provides the minimum size for each of the checksum block columns.
387If another algorithm was used with a smaller block size, or could otherwise
388allow the safe building of the checksum block with smaller portions of the
389hash, it might be worth exploring.  The 16 bytes used now at each hop should
390be more than sufficient.</p>
391
392<h2>3) <a name="tunnel.building">Tunnel building</a></h2>
393
394<p>When building a tunnel, the creator must send a request with the necessary
395configuration data to each of the hops, then wait for the potential participant
396to reply stating that they either agree or do not agree.  These tunnel request
397messages and their replies are garlic wrapped so that only the router who knows
398the key can decrypt it, and the path taken in both directions is tunnel routed
399as well.  There are three important dimensions to keep in mind when producing
400the tunnels: what peers are used (and where), how the requests are sent (and
401replies received), and how they are maintained.</p>
402
403<h3>3.1) <a name="tunnel.peerselection">Peer selection</a></h3>
404
405<p>Beyond the two types of tunnels - inbound and outbound - there are two styles
406of peer selection used for different tunnels - exploratory and client.
407Exploratory tunnels are used for both network database maintenance and tunnel
408maintenance, while client tunnels are used for end to end client messages.  </p>
409
410<h4>3.1.1) <a name="tunnel.selection.exploratory">Exploratory tunnel peer selection</a></h4>
411
412<p>Exploratory tunnels are built out of a random selection of peers from a subset
413of the network.  The particular subset varies on the local router and on what their
414tunnel routing needs are.  In general, the exploratory tunnels are built out of
415randomly selected peers who are in the peer's "not failing but active" profile
416category.  The secondary purpose of the tunnels, beyond merely tunnel routing,
417is to find underutilized high capacity peers so that they can be promoted for
418use in client tunnels.</p>
419
420<h4>3.1.2) <a name="tunnel.selection.client">Client tunnel peer selection</a></h4>
421
422<p>Client tunnels are built with a more stringent set of requirements - the local
423router will select peers out of its "fast and high capacity" profile category so
424that performance and reliability will meet the needs of the client application.
425However, there are several important details beyond that basic selection that
426should be adhered to, depending upon the client's anonymity needs.</p>
427 
428<p>For some clients who are worried about adversaries mounting a predecessor
429attack, the tunnel selection can keep the peers selected in a strict order -
430if A, B, and C are in a tunnel, the hop after A is always B, and the hop after
431B is always C.  A less strict ordering is also possible, assuring that while
432the hop after A may be B, B may never be before A.  Other configuration options
433include the ability for just the inbound tunnel gateways and outbound tunnel
434endpoints to be fixed, or rotated on an MTBF rate.</p>
435
436<h3>3.2) <a name="tunnel.request">Request delivery</a></h3>
437
438<p>As mentioned above, once the tunnel creator knows what peers should go into
439a tunnel and in what order, the creator builds a series of tunnel request
440messages, each containing the necessary information for that peer.  For instance,
441participating tunnels will be given the 4 byte tunnel ID on which they are to
442receive messages, the 4 byte tunnel ID on which they are to send out the messages,
443the 32 byte hash of the next hop's identity, and the 32 byte layer key used to
444remove a layer from the tunnel.  Of course, outbound tunnel endpoints are not
445given any "next hop" or "next tunnel ID" information.  Inbound tunnel gateways
446are however given the 8 layer keys in the order they should be encrypted (as
447described above).  To allow replies, the request contains a random session tag
448and a random session key with which the peer may garlic encrypt their decision,
449as well as the tunnel to which that garlic should be sent.  In addition to the
450above information, various client specific options may be included, such as
451what throttling to place on the tunnel, what padding or batch strategies to use,
452etc.</p>
453
454<p>After building all of the request messages, they are garlic wrapped for the
455target router and sent out an exploratory tunnel.  Upon receipt, that peer
456determines whether they can or will participate, creating a reply message and
457both garlic wrapping and tunnel routing the response with the supplied
458information.  Upon receipt of the reply at the tunnel creator, the tunnel is
459considered valid on that hop (if accepted).  Once all peers have accepted, the
460tunnel is active.</p>
461
462<h3>3.3) <a name="tunnel.pooling">Pooling</a></h3>
463
464<p>To allow efficient operation, the router maintains a series of tunnel pools,
465each managing a group of tunnels used for a specific purpose with their own
466configuration.  When a tunnel is needed for that purpose, the router selects one
467out of the appropriate pool at random.  Overall, there are two exploratory tunnel
468pools - one inbound and one outbound - each using the router's exploration
469defaults.  In addition, there is a pair of pools for each local destination -
470one inbound and one outbound tunnel.  Those pools use the configuration specified
471when the local destination connected to the router, or the router's defaults if
472not specified.</p>
473
474<p>Each pool has within its configuration a few key settings, defining how many
475tunnels to keep active, how many backup tunnels to maintain in case of failure,
476how frequently to test the tunnels, how long the tunnels should be, whether those
477lengths should be randomized, how often replacement tunnels should be built, as
478well as any of the other settings allowed when configuring individual tunnels.</p>
479
480<h3>3.4) <a name="tunnel.building.alternatives">Alternatives</a></h3>
481
482<h4>3.4.1) <a name="tunnel.building.telescoping">Telescopic building</a></h4>
483
484<p>One question that may arise regarding the use of the exploratory tunnels for
485sending and receiving tunnel creation messages is how that impacts the tunnel's
486vulnerability to predecessor attacks.  While the endpoints and gateways of
487those tunnels will be randomly distributed across the network (perhaps even
488including the tunnel creator in that set), another alternative is to use the
489tunnel pathways themselves to pass along the request and response, as is done
490in <a href="http://tor.eff.org/">TOR</a>.  This, however, may lead to leaks
491during tunnel creation, allowing peers to discover how many hops there are later
492on in the tunnel by monitoring the timing or packet count as the tunnel is
493built.  Techniques could be used to minimize this issue, such as using each of
494the hops as endpoints (per <a href="#tunnel.reroute">2.7.2</a>) for a random
495number of messages before continuing on to build the next hop.</p>
496
497<h4>3.4.2) <a name="tunnel.building.nonexploratory">Non-exploratory tunnels for management</a></h4>
498
499<p>A second alternative to the tunnel building process is to give the router
500an additional set of non-exploratory inbound and outbound pools, using those for
501the tunnel request and response.  Assuming the router has a well integrated view
502of the network, this should not be necessary, but if the router was partitioned
503in some way, using non-exploratory pools for tunnel management would reduce the
504leakage of information about what peers are in the router's partition.</p>
505
506<h2>4) <a name="tunnel.throttling">Tunnel throttling</a></h2>
507
508<p>Even though the tunnels within I2P bear a resemblence to a circuit switched
509network, everything within I2P is strictly message based - tunnels are merely
510accounting tricks to help organize the delivery of messages.  No assumptions are
511made regarding reliability or ordering of messages, and retransmissions are left
512to higher levels (e.g. I2P's client layer streaming library).  This allows I2P
513to take advantage of throttling techniques available to both packet switched and
514circuit switched networks.  For instance, each router may keep track of the
515moving average of how much data each tunnel is using, combine that with all of
516the averages used by other tunnels the router is participating in, and be able
517to accept or reject additional tunnel participation requests based on its
518capacity and utilization.  On the other hand, each router can simply drop
519messages that are beyond its capacity, exploiting the research used on the
520normal internet.</p>
521
522<h2>5) <a name="tunnel.mixing">Mixing/batching</a></h2>
523
524<p>What strategies should be used at the gateway and at each hop for delaying,
525reordering, rerouting, or padding messages?  To what extent should this be done
526automatically, how much should be configured as a per tunnel or per hop setting,
527and how should the tunnel's creator (and in turn, user) control this operation?
528All of this is left as unknown, to be worked out for
529<a href="http://www.i2p.net/roadmap#3.0">I2P 3.0</a></p>
Note: See TracBrowser for help on using the repository browser.