From 6b6a9490f685682e83a7d8a31bec7c2dbdaca3e0 Mon Sep 17 00:00:00 2001
From: jrandom $Id: tunnel.html,v 1.7 2005/01/14 22:53:13 jrandom Exp $
+$Id: tunnel.html,v 1.8 2005/01/15 01:43:35 jrandom Exp $
1) Tunnel overview
2) Tunnel operation
@@ -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.
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.
+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.
+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.
+When a message reaches the tunnel endpoint, they decrypts and verifies it like