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.

27

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

29

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

32

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

33

The 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

34

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

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:

47

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

49

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

51

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

53

Each destination has an associated set of tunnels to transport the data. The application and/or user can control the specifications of the tunnels:

<li>- backup: built 1-2 backup tunnels in case of original tunnels die unexpectedly

96

58

<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

59

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

61

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

63

To 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

115

64

associated with the specific destination.

116

65

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

66

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

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.

79

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

80

the 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

81

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

82

Each 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

83

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