A última atualização desta página foi em July 2011, e é a exata para a versão do roteador 0.8.7.

Sinopse

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 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.

Alice connecting through her outbound tunnel to Bob via his inbound tunnel

A: Outbound Gateway (Alice)
B: Outbound Participant
C: Ponto de saída
D: Ponto de entrada
E: Inbound Participant
F: Inbound Endpoint (Bob)

Tunnel vocabulary

  • Tunnel gateway - the first router in a tunnel. For inbound tunnels, this is the one mentioned in the LeaseSet published in the network database. For outbound tunnels, the gateway is the originating router. (e.g. both A and D above)
  • Tunnel endpoint - the last router in a tunnel. (e.g. both C and F above)
  • Tunnel participant - all routers in a tunnel except for the gateway or endpoint (e.g. both B and E above)
  • n-Hop tunnel - a tunnel with a specific number of inter-router jumps, e.g.:
    • 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 intermediate tunnel participant. (the above diagram includes two 2-hop tunnels - one outbound from Alice, one inbound to Bob)
  • 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 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 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 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)

Details are in the tunnel creation specification.

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. 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. Tunnel lengths are specified by clients via I2CP options. The maximum number of hops in a tunnel is 7.

túneis de 0-pulo

With no remote routers in a tunnel, the user has very basic plausible deniability (since no one knows for sure that the peer that sent them the message wasn't simply just forwarding it on as part of the tunnel). However, it would be fairly easy to mount a statistical analysis attack and notice that messages targeting a specific destination are always sent through a single gateway. Statistical analysis against outbound 0-hop tunnels are more complex, but could show similar information (though would be slightly harder to mount).

túneis de 1-pulo

With only one remote router in a tunnel, the user has both plausible deniability and basic anonymity, as long as they are not up against an internal adversary (as described on threat model). However, 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.

túnel de 2-pulos

Com dois ou mais roteadores remotos, o custo da montagem de ataque de análise de tráfego aumenta, uma vez que vários roteadores remotos devem ser comprometidos para montar isto.

túnel de 3-nós (ou mais)

Para reduzir a suscetibilidade a alguns ataques, 3 ou mais pulos são recomendados para o nível máximo de proteção. Estudos recentes também concluem que mais de 3 pulos não entrega proteção adiciona.

Tamanhos padrões de túnel

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.

Teste de túnel

All tunnels are periodically tested by their creator by sending a 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.

Criação de túnel

Tunnel creation is handled by garlic routing 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). That router forwards the message to the next hop in the tunnel. Details are in the tunnel creation specification.

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.

Trabalho futuro

  • 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).

Ver também