Changes between Version 11 and Version 12 of petconpaper

Feb 27, 2009 2:29:37 PM (10 years ago)



  • petconpaper

    v11 v12  
    1717Here we document the algorithms used in I2P's peer profiling and selection, discuss the strengths and weaknesses of the system, and describe opportunities for future work. We write this paper in the hope that it will be useful for guiding improvements in I2P and other anonymous networks with similar features.
    2021<h2>Overview of I2P</h2><ul> - echelon does this part
    80 </p>
     83<h2>Tunnel Overview</h2>
     85The tunnels used to transmit all data between the peers are divided into two
     87- client tunnels
     88- exploratory tunnels
     90The client tunnels transports all user generated data like IRC, webpages, code,
     91peer to peer data or any other client transmitting data throught I2P. These
     92tunnels are usual high bandwith and can reach up to 200 kbyte/sec.
     94Exploratory tunnels are low bandwith tunnels used for managing the network.
     95Beside tunnel tests and netdb queries these tunnels are used to build up the
     96client tunnels. Especially the exploration of other peers is the main job of
     97this tunnel class. This will be described further down.
     99Each service in I2P has a destination as a representation of the location to
     100reach the service. Examples are servers like eepsites (the I2P internal webpages),
     101monotone server, IRC server or audio streaming servers, and the clients have
     102a destination as a return address, e.g. IRC clients, bittorrent clients, monotone
     103clients or else. Servers got stable destinations while clients destination are
     104created new on every start.
     106Each destination have a associated set of tunnels to transport the data. The
     107application and/or user can control the specs of the tunnels:
     108- distance: 0-2 peers in between
     109- variance: a variance of 0-2 peers added/subtracted on random base
     110- quantity: up to three tunnels can be setup and data is distributed on them
     111- backup: built 1-2 backup tunnels in case of original tunnels die unexpected
     113To provide anonymity of the destinations, the route from a client to server
     114is devided into two tunnels: the outgoing tunnel, controlled by the client, and
     115the incoming tunnel, controlled by the server.
     116The connection between these two tunnels is direct, the endpoint of the outgoing
     117tunnel connects direct to the inpoint of the incoming tunnel.
     118This setup allows every participant to control its security and anonymity level
     119for himself by setting the distance and variance for his tunnels.
     121Each client select the peers with which it builds his part of the tunnel by
     122himself, based on the rating described further down.
     123In this tunnel building process the strict ordering within a tunnel is obeyed,
     124two or more I2P peers within the same subnet (/24,/16) cannot be used within the
     125same tunnel, which prevents the predecessor attack.
     127To secure the tunnels  and the route from client to server further more, each
     128tunnel in I2P has a fixed lifetime of 10 minutes and will be discarded after
     129this time. A new tunnel will be created before the existing one will timeout.
     130Until the old tunnel times out, data will be sent on all existant tunnels (
     131associated to the specific destination).
     133Peers can reject or drop tunnel build requests send by other peers due to a lot
     134of reasons (overload, shutdown in progress, limit reached, out of sync).
     135Even within lifetime of a tunnel these can be discarded due to overload or
     136unexpected shutdown of one of the peers in the tunnel. To prevent a breakage
     137of the destination, each tunnel is tested on a periodic base for funtion. This
     138creates more or less 1 kbyte/minute traffic, which is considered low bandwith.
     140The client tunnels on a peer are sorted into different classes:
     141- application tunnels: the tunnel starts or ends in this peer, binded to a
     142  server or client on the peer
     143- participating tunnels: this peer is a member in one of the in/outgoing tunnels
     144  and the participating tunnels reach in from a peer and is reached through to
     145  another peer.
     146  Three cases can be devided: endpoint of outgoing tunnel, inpoint of incoming
     147  tunnel, and pure participating tunnel
    81150<h2>Tunnel Overview</h2><ul> - echelon will do this part