-As briefly explained on the intro, in addition to sending -messages through tunnels (via tunnels), I2P uses a technique called -"garlic routing" - layered encryption of messages, passing through routers -selected by the original sender. This is similar to the way Mixmaster +Updated August 2010 for release 0.8 +
+ +Garlic Routing and "Garlic" Terminology
++The terms "garlic routing" and "garlic encryption" are often used rather loosely when referring to I2P's technology. +Here, we explain the history of the terms, the various meanings, and +the usage of "garlic" methods in I2P. +
+"Garlic routing" was first coined by +Michael J. Freedman +in Roger Dingledine's Free Haven +Master's thesis Section 8.1.1 (June 2000), as derived from +Onion Routing. +
+"Garlic" may have been used originally by I2P developers because I2P implements a form of +bundling as Freedman describes, or simply to emphasize general differences from Tor. +The specific reasoning may be lost to history. +Generally, when referring to I2P, the term "garlic" may mean one of three things: +
- +Layered Encryption +
- +Bundling multiple messages together +
- +ElGamal/AES Encryption +
Layered Encryption
++Onion routing is a technique for building paths, or tunnels, through a series of peers, +and then using that tunnel. +Messages are repeatedly encrypted by the originator, and then decrypted by each hop. +During the building phase, only the routing instructions for the next hop are exposed to each peer. +During the operating phase, messages are passed through the tunnel, and the +message and its routing instructions are only exposed to the endpoint of the tunnel. +
+This is similar to the way Mixmaster (see network comparisons) sends messages - taking a message, encrypting it to the recipient's public key, taking that encrypted message and encrypting it (along with instructions specifying the next hop), and then taking that resulting encrypted message and so on, until it has one layer of encryption -per hop along the path. The only significant difference between that technique -and I2P's garlic routing is that at each layer, any number of messages can be +per hop along the path. +
+In this sense, "garlic routing" as a general concept is identical to "onion routing". +As implemented in I2P, of course, there are several differences from the implementation in Tor; see below. +Even so, there are substantial similarities such that I2P benefits from a +large amount of academic research on onion routing, +Tor, and similar mixnets. +
+ + +Bundling Multiple Messages
++Michael Freedman defined "garlic routing" as an extension to onion routing, +in which multiple messages are bundled together. +He called each message a "bulb". +All the messages, each with its own delivery instructions, are exposed at the +endpoint. +This allows the efficient bundling of an onion routing "reply block" with the original message. +
+This concept is implemented in I2P, as described below. +Our term for garlic "bulbs" is "cloves". +Any number of messages can be contained, instead of just a single message. +This is a significant distinction from the onion routing implemented in Tor. +However, it is only one of many major architectural differences between I2P and Tor; +perhaps it is not, by itself, enough to justify a change in terminology. + +
+Another difference +from the method described by Freedman with I2P's bundling +is that the path is unidirectional - there is no "turning point" as seen in onion routing +or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible +and reliable delivery. +
+ + +ElGamal/AES Encryption
+In some cases, "garlic encryption" may simply mean +ElGamal/AES+SessionTag encryption +(without multiple layers). + + + +"Garlic" Methods in I2P
-In addition to the cloves, each unwrapped garlic message contains a sender -specified amount of padding data, allowing the sender to take active countermeasures -against traffic analysis. - -
Uses within I2P
- --I2P uses garlic routing in three places: -
-
-
- For building tunnels -
- For determining the success or failure of end to end message delivery (by wrapping an additional
- DeliveryStatusMessage in with the payload, where the clove containing the DeliveryStatusMessage
- has instructions forwarding it back through other routers and tunnels to the original sender)
-
+Now that we've defined various "garlic" terms, we can say that
+I2P uses garlic routing, bundling and encryption in three places:
+
-
+
- For building and routing through tunnels (layered encryption) +
- For determining the success or failure of end to end message delivery (bundling)
- For publishing some network database entries (dampening the probability of a successful traffic analysis attack) -
There are also significant ways that this technique can be used to improve the performance of the network, exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability. -
Encryption
+Tunnel Building and Routing
-The encryption of each layer in the garlic message uses the ElGamal/AES+SessionTag algorithm, -which avoids the cost of a full 2048bit ElGamal encryption for subsequent messages (using instead a random previously -specified SessionTag plus 256bit AES encryption). +In I2P, tunnels are unidirectional, and we require two tunnels +(one outbound and one inbound) for end-to-end communication in each direction. +Therefore, four tunnels are required for a single round-trip message and reply. +
+Tunnels are built, and then used, with layered encryption. +This is described on the +tunnel implementation page. +Tunnel building details are defined on +this page. +We use +ElGamal/AES+SessionTag for the encryption. +
+Tunnels are a general-purpose mechanism to transport all +I2NP messages, and +Garlic Messages are not used to build tunnels. +We do not bundle multiple +I2NP messages into a single +Garlic Message for unwrapping at the outbound tunnel endpoint; +the tunnel encryption is sufficient. +
+ + +End-to-End Message Bundling
++At the layer above tunnels, I2P delivers end-to-end messages between +Destinations. +Just as within a single tunnel, we use +ElGamal/AES+SessionTag for the encryption. +Each client message as delivered to the router through the +I2CP interface becomes a single +Garlic Clove +with its own +Delilvery Instructions, +inside a +Garlic Message. +Delivery Instructions may specify a Destination, Router, or Tunnel. +
+Generally, a Garlic Message will contain only one clove. +However, the router will periodically bundle two additional +cloves in the Garlic Message: + +
- +A +Delivery Status Message, +with +Delivery Instructions +specifying that it be sent back to the originating router as an acknowledgement. +This is similar to the "reply block" or "reply onion" +described in the references. +It is used for determining the success or failure of end to end message delivery. +The originating router may, upon failure to receive the Delivery Status Message +within the expected time period, modify the routing to the far-end Destination, +or take other actions. + +
- +A +Database Store Message, +containing a +LeaseSet +for the originating Destnation, with +Delivery Instructions +specifying the far-end destination's router. +By periodically bundling a LeaseSet, the router ensures that the far-end will be able +to maintain communications. +Otherwise the far-end would have to query a floodfill router for the network database entry, +and all LeaseSets would have to be published to the network database, as explained on the +network database page. +
+In the current implementation, the Delivery Status and Database Store Messages +are bundled when the local LeaseSet changes, when additional +Session Tags +are delivered, or if the messages have not been bundled in the previous minute. + +
+Obviously, the additional messages are currently bundled for specific purposes, +and not part of a general-purpose routing scheme. +
+ +Storage to the Floodfill Network Database
+ +As explained on the +network database page, +local +LeaseSets +are sent to floodfill routers in a +Database Store Message +wrapped in a +Garlic Message +so it is not visible to the tunnel's outbound gateway. + + + +Future Work
++The Garlic Message mechanism is very flexible and provides a structure for +implementing many types of mixnet delivery methods. +Together with the unused delay option in the +tunnel message Delivery Instructions, +a wide spectrum of batching, delay, mixing, and routing strategies are possible. +
+In particular, there is potential for much more flexibility at the outbound tunnel endpoint. +Messages could possibly be routed from there to one of several tunnels +(thus minimizing point-to-point connections), or multicast to several tunnels +for redundancy, or streaming audio and video. +
+Such experiments may conflict with the need to ensure security and anonymity, such +as limiting certain routing paths, restricting the types of I2NP messages that may +be forwarded along various paths, and enforcing certain message expiration times. +
+As a part of +ElGamal/AES encryption, +a garlic message contains a sender +specified amount of padding data, allowing the sender to take active countermeasures +against traffic analysis. +This is not currently used, beyond the requirement to pad to a multiple of 16 bytes. +
+Encryption of additional messages to and from the +floodfill routers. +
+ + +References
+- +The term garlic routing was first coined in Roger Dingledine's Free Haven +Master's thesis (June 2000), +see Section 8.1.1 authored by +Michael J. Freedman. +
- +Onion router publications +
- +Onion Routing on Wikipedia +
- +Garlic Routing on Wikipedia +
- +I2P Meeting 58 (2003) discussing the implementation of garlic routing +
- +Tor +
- +Free Haven publications +
- +Onion routing was first described in Hiding Routing Information +by David M. Goldschlag, Michael G. Reed, and Paul F. Syverson in 1996. +
-The term garlic routing was first coined by Michael Freedman in Roger Dingledine's Free Haven -Master's thesis (June 2000), which was derived from -Onion Routing. The main difference -from the method described by Freedman with I2P's garlic routing -is that the path is unidirectional - there is no "turning point" as seen in onion routing -or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible -and reliable delivery.{% endblock %} +{% endblock %} diff --git a/www.i2p2/pages/how_networkdatabase.html b/www.i2p2/pages/how_networkdatabase.html index 034e98dd..71b801d7 100644 --- a/www.i2p2/pages/how_networkdatabase.html +++ b/www.i2p2/pages/how_networkdatabase.html @@ -1,5 +1,5 @@ {% extends "_layout.html" %} -{% block title %}How the Network Database (netDb) Works{% endblock %} +{% block title %}The Network Database{% endblock %} {% block content %}
@@ -411,7 +411,7 @@
- Queries are sent throughmultiple routes simultaneously + Queries are sent through multiple routes simultaneously to reduce the chance of query failure.
@@ -482,7 +482,7 @@Destinations may be hosted on multiple routers simultaneously, by using the same - private and public keys (traditionally named eepPriv.dat files). + private and public keys (traditionally stored in eepPriv.dat files). As both instances will periodically publish their signed LeaseSets to the floodfill peers, the most recently published LeaseSet will be returned to a peer requesting a database lookup. As LeaseSets have (at most) a 10 minute lifetime, should a particular instance go down, @@ -566,7 +566,7 @@ metrics described above, this is a difficult scenario to handle. Tor's response can be much more nimble in the relay case, as the suspicious relays can be manually removed from the consensus. - Some possible responses in the I2P case, none of them satisfactory: + Some possible responses for the I2P network are listed below, however none of them is completely satisfactory:
- Compile a list of bad router hashes or IPs, and announce the list through various means
@@ -611,11 +611,11 @@ This attack becomes more difficult as the network size grows.
As a partial defense against this attack, the algorithm used to determine Kademlia "closeness" varies over time. - Rather than using the Hash of the key (i.e. H(k))to determine closeness, + Rather than using the Hash of the key (i.e. H(k)) to determine closeness, we use the Hash of the key appended with the current date string, i.e. H(k + YYYYMMDD). A function called the "routing key generator" does this, which transforms the original key into a "routing key". In other words, the entire netdb keyspace "rotates" every day at UTC midnight. - Any partial-keyspace attack would have to be regenerated every day, as + Any partial-keyspace attack would have to be regenerated every day, for after the rotation, the attacking routers would no longer be close to the target key, or to each other.
diff --git a/www.i2p2/pages/how_peerselection.html b/www.i2p2/pages/how_peerselection.html index 0a5870ce..16968718 100644 --- a/www.i2p2/pages/how_peerselection.html +++ b/www.i2p2/pages/how_peerselection.html @@ -90,7 +90,7 @@ send or receive on a single tunnel through the peer in a minute. For this estim performance in the previous minute. -Capacity
+Capacity
The capacity calculation simply goes through the profile and estimates how many tunnels the peer diff --git a/www.i2p2/pages/how_tunnelrouting.html b/www.i2p2/pages/how_tunnelrouting.html index f30185d4..fd720203 100644 --- a/www.i2p2/pages/how_tunnelrouting.html +++ b/www.i2p2/pages/how_tunnelrouting.html @@ -1,22 +1,35 @@ {% extends "_layout.html" %} -{% block title %}How Tunnel Routing Works{% endblock %} -{% block content %}Note: these documents have not yet been updated to include the changes made -in I2P 0.5 - the new -tunnel -routing and encryption algorithms, addressing several -issues (with the groundwork for addressing -others). +{% block title %}Tunnel Overview{% endblock %} +{% block content %} +
+Updated August 2010 for release 0.8 +
-As briefly explained in the intro, I2P builds virtual "tunnels" - +
Tunnel Overview
++This page contains an overview of I2P tunnel terminology and operation, with +links to more technical pages, details, and specifications. +
+As briefly explained in the introduction, I2P builds virtual "tunnels" - temporary and unidirectional paths through a sequence of routers. These -tunnels can be categorized as either inbound tunnels (where everything -given to it goes towards the creator of the tunnel) and outbound tunnels +tunnels are classified as either inbound tunnels (where everything +given to it goes towards the creator of the tunnel) or outbound tunnels (where the tunnel creator shoves messages away from them). When Alice wants to send a message to Bob, she will (typically) send it out one of her existing outbound tunnels with instructions for that tunnel's endpoint to forward it to the gateway router for one of Bob's current inbound tunnels, which in turn passes it to Bob.
+
++A: Outbound Gateway (Alice) +B: Outbound Participant +C: Outbound Endpoint +D: Inbound Gateway +E: Inbound Participant +F: Inbound Endpoint (Bob) +
+Tunnel vocabulary
-
@@ -32,77 +45,105 @@ tunnels, which in turn passes it to Bob.
- 0-hop tunnel - a tunnel where the gateway is also the endpoint
- 1-hop tunnel - a tunnel where the gateway talks directly to the endpoint -
- 2-(or more)-hop tunnel - a tunnel where there is at least one +
- 2-(or more)-hop tunnel - a tunnel where there is at least one intermediate tunnel participant. (the above diagram includes two 2-hop tunnels - one outbound from Alice, one inbound to Bob)
- - Tunnel lifetime - how long a particular tunnel is - supposed to be in operation for (each client specifies this when contacting - their router, and the router makes sure sufficient tunnels meeting that - criteria are built) +
- Tunnel ID - A 4 byte integer + different for each hop in a tunnel, and unique among all tunnels on a router. + Chosen randomly by the tunnel creator.
Tunnel information
-Routers performing the three roles (gateway, endpoint, participant) are given -different pieces of data to accomplish their tasks:
+Tunnel Build Information
+Routers performing the three roles (gateway, participant, endpoint) are given +different pieces of data in the initial +Tunnel Build Message +to accomplish their tasks:
- The tunnel gateway gets:
-
-
- tunnel signing key - a DSA private key for authenticating - messages sent down the tunnel -
- tunnel encryption key - an AES private key for encrypting - messages and instructions to the endpoint -
- tunnel id - 4 byte integer (each router can obviously only have - one tunnel with each tunnel id at any time) -
- next hop [optional] - what router is the next one in the path -
- configuration key - an AES private key used by the tunnel's - creator for updating the tunnel later on (if necessary) +
- tunnel encryption key - an AES private key for encrypting + messages and instructions to the next hop +
- tunnel IV key - an AES private key for double-encrypting + the IV to the next hop +
- reply key - an AES public key for encrypting + the reply to the tunnel build request +
- reply IV - the IV for encrypting + the reply to the tunnel build request +
- tunnel id - 4 byte integer (inbound gateways only) + +
- next hop - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint) +
- next tunnel id - The tunnel ID on the next hop +
+ - All intermediate tunnel participants get:
+
-
+
- tunnel encryption key - an AES private key for encrypting + messages and instructions to the next hop +
- tunnel IV key - an AES private key for double-encrypting + the IV to the next hop +
- reply key - an AES public key for encrypting + the reply to the tunnel build request +
- reply IV - the IV for encrypting + the reply to the tunnel build request +
- tunnel id - 4 byte integer + +
- next hop - what router is the next one in the path +
- next tunnel id - The tunnel ID on the next hop
- The tunnel endpoint gets:
-
-
- tunnel verification key - a DSA public key for authenticating - messages sent down the tunnel -
- tunnel encryption key - an AES private key for decrypting - messages and instructions sent by the gateway -
- tunnel id - 4 byte integer (each router can obviously only have - one tunnel with each tunnel id at any time) -
- configuration key - an AES private key used by the tunnel's - creator for updating the tunnel later on (if necessary) -
- - All tunnel participants get:
-
-
-
- tunnel verification key - a DSA public key for authenticating - messages sent down the tunnel -
- tunnel id - 4 byte integer (each router can obviously only have - one tunnel with each tunnel id at any time) -
- next hop [optional] - what router is the next one in the path -
- configuration key - an AES private key used by the tunnel's - creator for updating the tunnel later on (if necessary) +
- tunnel encryption key - an AES private key for encrypting + messages and instructions to the the endpoint (itself) +
- tunnel IV key - an AES private key for double-encrypting + the IV to the endpoint (itself) +
- reply key - an AES public key for encrypting + the reply to the tunnel build request (outbound endpoints only) +
- reply IV - the IV for encrypting + the reply to the tunnel build request (outbound endpoints only) +
- tunnel id - 4 byte integer (outbound endpoints only) + +
- reply router - the inbound gateway of the tunnel to send the reply through (outbound endpoints only) +
- reply tunnel id - The tunnel ID of the reply router (outbound endpoints only)
In addition, there are a series of options that the creator of a tunnel sends -when requesting a router to join a tunnel, such as the expiration date. In I2P -3.0, options specifying the pooling, mixing, and chaff generation settings will -be honored, and limits on the quantity and size of messages allowed during the -tunnel's lifetime will be implemented earlier (e.g. no more than 300 messages or -1MB per minute).
++Details are in the +tunnel creation specification. +
-Tunnel length
+Tunnel pooling
++Several tunnels for a particular purpose may be grouped into a "tunnel pool", +as described in the +tunnel specification. +This provides redundancy and additional bandwidth. +The pools used by the router itself are called "exploratory tunnels". +The pools used by applications are called "client tunnels". +
+ + + +Tunnel length
As mentioned above, each client requests that their router provide tunnels to -include at least a certain number of hops (plus other criteria that aren't -honored yet, such as bandwidth limits, etc). The decision as to how many routers +include at least a certain number of hops. +The decision as to how many routers to have in one's outbound and inbound tunnels has an important effect upon the latency, throughput, reliability, and anonymity provided by I2P - the more peers that messages have to go through, the longer it takes to get there and the more likely that one of those routers will fail prematurely. The less routers in a tunnel, the easier it is for an adversary to mount traffic analysis attacks and -pierce someone's anonymity.
+pierce someone's anonymity. +Tunnel lengths are specified by clients via +I2CP options. +The maximum number of hops in a tunnel is 7. + +0-hop tunnels
With no remote routers in a tunnel, the user has very basic plausible @@ -121,54 +162,92 @@ if the adversary ran a sufficient number of routers such that the single remote router in the tunnel is often one of those compromised ones, they would be able to mount the above statistical traffic analysis attack.
-2-hop (or more) tunnels
+2-hop tunnels
With two or more remote routers in a tunnel, the costs of mounting the traffic -analysis attack increases, since all remote routers would have to be compromised +analysis attack increases, since many remote routers would have to be compromised to mount it.
-The router will by default use 2-hop tunnels, at least in the main -distribution. Prior to the 0.2.5 release, all tunnels were 1-hop by default.
+3-hop (or more) tunnels
+To reduce the susceptibility to some attacks, +3 or more hops are recommended for the highest level of protection. +recent studies +also conclude that more than 3 hops does not provide additional protection. + + +Tunnel default lengths
+The router uses 2-hop tunnels by default for its exploratory tunnels. +Client tunnel defaults are set by the application, using +I2CP options. +Most applications use 2 or 3 hops as their default. +
+ -Tunnel pooling
-[explain tunnel pools, how we keep a free inbound pool, an outbound pool, and -a client inbound pool, and how the pools are refreshed every minute or so, using -the router's default settings]
Tunnel testing
All tunnels are periodically tested by their creator by sending a -DeliveryStatusMessage out the tunnel and bound for another inbound tunnel -(testing both tunnels at once). If either fails, both are marked as no longer -functional, and if they were used for a client's inbound tunnel, a new leaseSet -is created. Other techniques can be used to test tunnels later on, such as -garlic wrapping a number of tests into cloves, testing individual tunnel -participants separately (and using the tunnel configuration key to update the -next hop to work around failures), etc, but that is not implemented at the -moment. +DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel +(testing both tunnels at once). If either fails a number of consecutive tests, it is marked as no longer +functional. If it was used for a client's inbound tunnel, a new leaseSet +is created. +Tunnel test failures are also reflected in the +capacity rating in the peer profile.
+Tunnel creation
Tunnel creation is handled by garlic routing -a TunnelCreateMessage to a router, requesting that they participate in the +a Tunnel Build Message to a router, requesting that they participate in the tunnel (providing them with all of the appropriate information, as above, along with a certificate, which right now is a 'null' cert, but will support hashcash -or other non-free certificates when necessary). The message also includes a -SourceRouteReplyBlock, which allows the router to encrypt their -TunnelCreateStatusMessage into a SourceRouteReplyMessage, which is sent to -another router (specified in the SourceRouteReplyBlock), who then decrypts the -rest of the SourceRouteReplyBlock, reads out the delivery instructions contained -therein, and forwards the TunnelCreateStatusMessage accordingly. (the delivery -instructions can specify delivery to a specific router or can point at a tunnel) +or other non-free certificates when necessary). +That router forwards the message to the next hop in the tunnel. +Details are in the +tunnel creation specification.
-Issues/TODO
+ +Tunnel encryption
+Multi-layer encryption is handled by garlic encryption +of tunnel messages. +Details are in the +tunnel specification. +The IV of each hop is encrypted with a separate key as explained there. +
+ + +Future Work
+- +Other tunnel test techniques could be used, such as +garlic wrapping a number of tests into cloves, testing individual tunnel +participants separately, +etc. +
- +Move to 3-hop exploratory tunnels defaults. +
- +In a distant future release, +options specifying the pooling, mixing, and chaff generation settings may be implemented. +
- +In a distant future release, +limits on the quantity and size of messages allowed during the +tunnel's lifetime may be implemented (e.g. no more than 300 messages or +1MB per minute). +
See Also
-
-
- We will assign unique tunnel IDs for each router in the tunnel, rather - than having a single ID across the whole tunnel. this would make traffic - analysis even harder -
- Get rid of the sourceRouteBlock stuff -
- Should inbound tunnels that will be used by clients ever be used for - general messages (network database, etc), rather than being free for use until - its allocated? -
- I2P 3.0 tunnel mixing / pooling details -
- Tunnel throttling details -