include blurb explaining tunnelIDs and replay prevention (thanks Connelly!)

router/doc/tunnel.html

-<code>$Id: tunnel.html,v 1.7 2005/01/14 22:53:13 jrandom Exp $</code>
+<code>$Id: tunnel.html,v 1.8 2005/01/15 01:43:35 jrandom Exp $</code>
 <pre>
 1) <a href="#tunnel.overview">Tunnel overview</a>
 2) <a href="#tunnel.operation">Tunnel operation</a>
@@ -91,6 +91,12 @@ Eventually, the message arrives at the endpoint where the messages
 bundled by the gateway are split out again and forwarded on as 
 requested.</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.  Tunnels themselves are short lived (10 minutes at the 
+moment), but depending upon the tunnel's purpose, and though subsequent tunnels 
+may be built using the same sequence of peers, each hop's tunnel ID will change.</p>
+
 <h3>2.1) <a name="tunnel.preprocessing">Message preprocessing</a></h3>
 
 <p>When the gateway wants to deliver data through the tunnel, it first
@@ -268,6 +274,14 @@ message is discarded.  Otherwise, the IV is updated by decrypting it, XORing tha
 with the IV_WHITENER, and replacing it with the first 16 bytes of its hash.  The 
 resulting message is then forwarded on to the next peer for processing.</p>
 
+<p>To prevent replay attacks at the tunnel level, each participant keeps track of
+the IVs received during the tunnel's lifetime, rejecting duplicates.  The memory 
+usage required should be minor, as each tunnel has only a very short lifespan (10m
+at the moment).  A constant 100KBps through a tunnel with full 32KB messages would
+give 1875 messages, requiring less than 30KB of memory.  Gateways and endpoints 
+handle replay by tracking the message IDs and expirations on the I2NP messages 
+contained in the tunnel.</p>
+
 <h3>2.4) <a name="tunnel.endpoint">Endpoint processing</a></h3>
 
 <p>When a message reaches the tunnel endpoint, they decrypts and verifies it like