Changes between Version 22 and Version 23 of petconpaper


Ignore:
Timestamp:
Mar 4, 2009 11:10:44 PM (10 years ago)
Author:
anonymous
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • petconpaper

    v22 v23  
    66PET-CON 2009.1
    77<br>
    8 DRAFT 2009-03-04 15:00 GMT
     8DRAFT 2009-03-04 21:00 GMT
    99<br>
    1010zzz@i2pmail.org
     
    1212<br>
    1313
     14<b>DO NOT EDIT HERE ANYMORE - zzz has copied over for LNI formatting</b>
     15
    1416<p><b>Abstract</b>
    1517<p>
     
    2325
    2426<p>
    25 I2P is a overlay network based on unidirectional tunnels routed between
    26 the I2P nodes. The routing method used - "garlic routing" - is similar to the onion routing used by
    27 Tor [Tor], transmitting data from peer to peer until the endpoint of tunnel is
    28 reached. In contrast to Tor, I2P provides primarily hidden services, with the addition
    29 of a few outproxies operated by private individuals.
    30 <p>
    31 The ancestor of the I2P project was IIP [IIP] - a specialiced IRC server with clients
    32 transmitting their data via a mix network. I2P was first started
    33 as a specialized, low-latency transport protocol for The Freenet Project but soon
    34 grew into a independent software project, driven by the author jrandom from
    35 2003 until end of 2007. Several other people contributed as well.
    36 After jrandom left  the project at the end of 2007, zzz and complication took over
    37 active programming. The codebase itself is public domain or licensed under GPL
    38 with exception, MIT or other free licenses [I2P]. Most code is written in JAVA and is therefore supported cross-platform.
    39 To maintain faster 1024-bit public-key encryption, some external libraries as the GMP (GNU MP
    40 Bignum Library) are interweaved within the java code.
    41 The codebase is under active development with 7 releases in the year 2008 and
    42 more than 100 development builds between those public releases.
    43 Beside the core router itself some bundled software (e.g. a bittorrent client
    44 based on snark, "I2Psnark") is maintained by zzz, complication, and others.
    45 
    46 <p>
    47 At the time of writing this paper approximately 830 peers are active in the I2P net (pic). This
    48 varies over time, as 50-100 new nodes (pic) joining the network every day and others
    49 leaving. Usually on weekend times the peak of 1000 active nodes are reached and
    50 in weekdays night the lower peak at 700 active routers generally occurs. This shows a
    51 quite stable base network on which the ~550 active destinations (pic) route traffic.
    52 I2P is oriented towards hidden services, all destinations inside the network
    53 are hosted upon those active peers. Only one HTTP outproxy (exit node in Tor terms) is
    54 publicly known to be running, in addition to an IRC gateway for I2P development discussion.
    55 In contrast to Tor, I2P is peer to peer traffic friendly while it distributes the
    56 encrypted traffic between all participating nodes.
    57 The current bandwith used by all peers is roughly 11 MByte/sec with peaks at 16
    58 MByte/sec (pic) and the peers builds ~40,000 tunnels (pic) producing this load.
    59 In the last 6 months the net grew from 400 up to 800 peers (pic), from 5 to 10 MByte/sec
    60 and from ~20,000 to ~40,000 tunnels, which shows the vital stats of the net
    61 doubled in half a year. We predict continued stable growth for the network.
     27I2P is a overlay network based on unidirectional tunnels routed between the I2P nodes. The routing method used - "garlic routing" - is similar to the onion routing used by Tor [Tor], transmitting data from peer to peer until the endpoint of tunnel is reached. In contrast to Tor, I2P provides primarily hidden services, with the addition of a few outproxies operated by private individuals.
     28<p>
     29The ancestor of the I2P project was IIP [IIP] - a specialiced IRC server with clients transmitting their data via a mix network. I2P was first started as a specialized, low-latency transport protocol for The Freenet Project but soon grew into a independent software project, driven by the author jrandom from  2003 until end of 2007. Several other people contributed as well. After jrandom left  the project at the end of 2007, zzz and complication took over active programming. The codebase itself is public domain or licensed under GPL with exception, MIT or other free licenses [I2P]. Most code is written in JAVA and is therefore supported cross-platform. To maintain faster 1024-bit public-key encryption, some external libraries as the GMP (GNU MP Bignum Library) are interweaved within the java code. The codebase is under active development with 7 releases in the year 2008 and more than 100 development builds between those public releases. Beside the core router itself some bundled software (e.g. a bittorrent client based on snark, "I2Psnark") is maintained by zzz, complication, and others.
     30
     31<p>
     32At the time of writing this paper approximately 830 peers are active in the I2P net (pic). This varies over time, as 50-100 new nodes (pic) joining the network every day and others leaving. Usually on weekend times the peak of 1000 active nodes are reached and in weekdays night the lower peak at 700 active routers generally occurs. This shows a quite stable base network on which the ~550 active destinations (pic) route traffic. I2P is oriented towards hidden services, all destinations inside the network are hosted upon those active peers. Only one HTTP outproxy (exit node in Tor terms) is publicly known to be running, in addition to an IRC gateway for I2P development discussion. In contrast to Tor, I2P is peer to peer traffic friendly while it distributes the encrypted traffic between all participating nodes.
     33The current bandwith used by all peers is roughly 11 MByte/sec with peaks at 16 MByte/sec (pic) and the peers builds ~40,000 tunnels (pic) producing this load. In the last 6 months the net grew from 400 up to 800 peers (pic), from 5 to 10 MByte/sec
     34and from ~20,000 to ~40,000 tunnels, which shows the vital stats of the net doubled in half a year. We predict continued stable growth for the network.
    6235<p>
    6336
     
    7245<li>- exploratory tunnels
    7346<p>
    74 The client tunnels transport all user-generated data using protocols such as HTTP, IRC,
    75 peer to peer data or any other client transmitting data throught I2P. These
    76 tunnels can be high bandwidth and can reach up to 200 kbyte/sec.
    77 <p>
    78 Exploratory tunnels are low bandwith tunnels used for managing the network.
    79 Beside tunnel tests and netdb queries these tunnels are used to build up the
    80 client tunnels. Especially the exploration of other peers is the main job of
    81 this tunnel class. This will be described further down.
    82 <p>
    83 Each service in I2P has a destination as a representation of the location to
    84 reach the service. Examples are servers like eepsites (the I2P internal webpages),
    85 monotone server, IRC server or audio streaming servers, and the clients have
    86 a destination as a return address, e.g. IRC clients, bittorrent clients, monotone
    87 clients or else. Servers have stable destinations while clients destination are
    88 created anew on every start.
    89 <p>
    90 Each destination has an associated set of tunnels to transport the data. The
    91 application and/or user can control the specifications of the tunnels:
     47The client tunnels transport all user-generated data using protocols such as HTTP, IRC, peer to peer data or any other client transmitting data throught I2P. These tunnels can be high bandwidth and can reach up to 200 kbyte/sec.
     48<p>
     49Exploratory tunnels are low bandwith tunnels used for managing the network. Beside tunnel tests and netdb queries these tunnels are used to build up the client tunnels. Especially the exploration of other peers is the main job of this tunnel class. This will be described further down.
     50<p>
     51Each service in I2P has a destination as a representation of the location to reach the service. Examples are servers like eepsites (the I2P internal webpages), monotone server, IRC server or audio streaming servers, and the clients have a destination as a return address, e.g. IRC clients, bittorrent clients, monotone clients or else. Servers have stable destinations while clients destination are created anew on every start.
     52<p>
     53Each destination has an associated set of tunnels to transport the data. The application and/or user can control the specifications of the tunnels:
    9254<li>- distance: 0-2 peers in between
    9355<li>- variance: a variance of 0-2 peers added/subtracted on random base
     
    9557<li>- backup: built 1-2 backup tunnels in case of original tunnels die unexpectedly
    9658<p>
    97 To provide anonymity of the destinations, the route from a client to server
    98 is divided into two tunnels: the outgoing tunnel, controlled by the client, and
    99 the incoming tunnel, controlled by the server.
    100 The connection between these two tunnels is direct, the endpoint (outbound gateway) of the outgoing
    101 tunnel connects direct to the inpoint (inbound gateway) of the incoming tunnel.
    102 This setup allows every participant to control its security and anonymity level
    103 for himself by setting the distance and variance for his tunnels.
    104 <p>
    105 Each client select the peers with which it builds his part of the tunnel by
    106 himself, based on the rating described further down.
    107 In this tunnel building process the strict ordering within a tunnel is obeyed,
    108 two or more I2P peers within the same subnet (/24,/16) cannot be used within the
    109 same tunnel, which restricts the predecessor attack.
    110 <p>
    111 To secure the tunnels  and the route from client to server further more, each
    112 tunnel in I2P has a fixed lifetime of 10 minutes and will be discarded after
    113 this time. A new tunnel will be created before the existing one will time out.
    114 Data will be sent on one or more of the tunnels
     59To provide anonymity of the destinations, the route from a client to server is divided into two tunnels: the outgoing tunnel, controlled by the client, and  the incoming tunnel, controlled by the server. The connection between these two tunnels is direct, the endpoint (outbound gateway) of the outgoing tunnel connects direct to the inpoint (inbound gateway) of the incoming tunnel. This setup allows every participant to control its security and anonymity level  for himself by setting the distance and variance for his tunnels.
     60<p>
     61Each client select the peers with which it builds his part of the tunnel by  himself, based on the rating described further down. In this tunnel building process the strict ordering within a tunnel is obeyed, two or more I2P peers within the same subnet (/24,/16) cannot be used within thesame tunnel, which restricts the predecessor attack.
     62<p>
     63To secure the tunnels  and the route from client to server further more, each tunnel in I2P has a fixed lifetime of 10 minutes and will be discarded after this time. A new tunnel will be created before the existing one will time out. Data will be sent on one or more of the tunnels
    11564associated with the specific destination.
    11665<p>
    117 Peers can reject or drop tunnel build requests sent by other peers for a number
    118 of reasons (overload, shutdown in progress, limit reached, out of sync).
    119 Even within the lifetime of a tunnel these can be discarded due to overload or
    120 unexpected shutdown of one of the peers in the tunnel. To prevent a breakage
    121 of the destination, each tunnel is tested on a periodic basis. This
    122 creates about 1 Kbyte/minute of traffic, which is very low bandwith.
     66Peers can reject or drop tunnel build requests sent by other peers for a number of reasons (overload, shutdown in progress, limit reached, out of sync). Even within the lifetime of a tunnel these can be discarded due to overload or unexpected shutdown of one of the peers in the tunnel. To prevent a breakage of the destination, each tunnel is tested on a periodic basis. This creates about 1 Kbyte/minute of traffic, which is very low bandwith.
    12367<p>
    12468The client tunnels on a peer are sorted into different classes:
     
    13377 <h2>NetDB Overview</h2>
    13478
    135 The NetDB is a collection of information stored on each peer. It containes for
    136 each peer the RouterInfo and for each known service the LeaseSet , which is the
    137 hidden service descriptor.LeaseSet will not be described here, for more info
    138 into this topic look into the i2p website (ref).
    139 the routerInfo is a small collection of all vital information describing a peer.
    140 E.g. the IP, port, peer ID, I2P stable version number, net ID version, and some
    141 statistical bandwith data are included. All of the these data are not trusted by
    142 the peer except for the K classification of bandwith.
    143 Each peer is set by default to 48KByte input and 24KByte output bandwith with
    144 90% share percantage (90% of maximum bandwith is allowed to be used up by
    145 participating tunnels). These peers will fit into the L class of bandwith.
    146 Each peer is sorted into a bandwith class based on the configured shared
    147 bandwith: These classes are named K,L,M,N,and O. Limits are <12 kbit/sec for K,
    148 12+ L, 32+ M, 64+ N,128+ kbit/sec O. This classification is just for information
    149 and except the K class not used for any routing information (peers of K class
    150 are not used at all for routing participating tunnels). Statistics shows only
    151 a small number of K class routers (96 % are class L-O) which indicates most
    152 peers are capable of routing tunnels.
    153 But if we trust these (user set) classification, serious anonymity issues and
    154 DOS implications (like the "low-ressource attacks") will rise up.
    155 This leads to the following implementation of peer profiling.
     79The NetDB is a collection of information stored on each peer. It containes for each peer the RouterInfo and for each known service the LeaseSet , which is the hidden service descriptor.LeaseSet will not be described here, for more info into this topic look into the i2p website (ref).
     80the routerInfo is a small collection of all vital information describing a peer. For example, the IP, port, peer ID, I2P stable version number, net ID version, and some statistical bandwith data are included. All of the these data are not trusted by
     81the peer except for the K classification of bandwith. Each peer is set by default to 48KByte input and 24KByte output bandwith with 90% share percantage (90% of maximum bandwith is allowed to be used up by participating tunnels). These peers will fit into the L class of bandwith.
     82Each peer is sorted into a bandwith class based on the configured shared bandwith: These classes are named K,L,M,N,and O. Limits are <12 kbit/sec for K,  12+ L, 32+ M, 64+ N,128+ kbit/sec O. This classification is just for information and except the K class not used for any routing information (peers of K class are not used at all for routing participating tunnels). Statistics shows only
     83a small number of K class routers (96 % are class L-O) which indicates most peers are capable of routing tunnels. But if we trust these (user set) classification, serious anonymity issues and DOS implications (like the "low-ressource attacks") will rise up.  This leads to the following implementation of peer profiling.
    15684 
    15785
     
    365293<li>[Tor] http://www.torproject.org/
    366294<li>[IIP] http://invisibleip.sourceforge.net/iip/ and http://en.wikipedia.org/wiki/Invisible_IRC_Project
    367 <li><i>Licenses http://www.i2p2.de/licenses.html
     295<li>Licenses http://www.i2p2.de/licenses.html
    368296<li>[Stats]Pics should be taken from stats.i2p
    369297