I2P_Website/pages/how_intro.html

<p>I2P is an effort to build, deploy, and maintain a network to support secure and anonymous 
communication. People using I2P are in control of the tradeoffs between anonymity, reliability, 
bandwidth usage, and latency. There is no central point in the network on which pressure can be 
exerted to compromise the integrity, security, or anonymity of the system. The network supports 
dynamic reconfiguration in response to various attacks, and has been designed to make use of 
additional resources as they become available. Of course, all aspects of the network are open 
and freely available.</p>

<p>Unlike many other anonymizing networks, I2P doesn't try to provide anonymity by hiding the 
originator of some communication and not the recipient, or the other way around. I2P is designed 
to allow peers using I2P to communicate with each other anonymously – both sender and recipient 
are unidentifiable to each other as well as to third parties. For example, today there are both 
in-I2P web sites (allowing anonymous publishing / hosting) as well as HTTP proxies to the normal 
web (allowing anonymous web browsing). Having the ability to run servers within I2P is essential, 
as it is quite likely that any outbound proxies to the normal internet will be monitored, disabled, 
or even taken over to attempt more malicious attacks.</p>

<p>The network itself is message oriented - it is essentially a secure and anonymous IP layer, 
where messages are addressed to cryptographic keys (Destinations) and can be significantly larger 
than IP packets. Some example uses of the network include "eepsites" (webservers hosting normal web
applications within I2P), a <a href="http://bitconjurer.org/BitTorrent/">BitTorrent</a> port ("I2PSnark"), 
or a distributed data store.  With the help of mihi's <a href="i2ptunnel.html">I2PTunnel</a> application, 
we are able to stream traditional TCP/IP applications over I2P, such as SSH, irc, a squid proxy, and 
even streaming audio. Most people will not use I2P directly, or even need to know they're using it. 
Instead their view will be of one of the I2P enabled applications, or perhaps as a little controller 
app to turn on and off various proxies to enable the anonymizing functionality.</p>

<p>An essential part of designing, developing, and testing an anonymizing network is to define the 
<a href="how_threatmodel.html">threat model</a>, since there is no such thing as "true" anonymity, just 
increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to communicate 
in arbitrarily hostile environments by providing militant grade anonymity, mixed in with sufficient cover 
traffic provided by the activity of people who require less anonymity. This includes letting Joe Sixpack 
chat with his buddies without anyone listening in, Jane Filetrader to share files knowing that large 
corporations cannot identify her, as well as Will Whistleblower to publish sensitive documents - 
<i>all on the same network</i>, where each one's messages are essentially indistinguishable from the 
others.</p>

<h2>Why?</h2>
<p>There are a multitude of fantastic reasons why we need a system to support 
anonymous communication, and everyone has their own personal rationale. There have are many 
<a href="how_networkcomparisons.html">other efforts</a> working on finding ways to provide varying degrees of 
anonymity to people through the Internet, but we could not find any that met our needs or threat 
model.</p>

<h2>How?</h2>

<p>The network at a glance is made up of a set of nodes ("routers") with a number of unidirectional 
inbound and outbound virtual paths ("tunnels", as outlined on the <a href="how_tunnelrouting.html">tunnel routing</a> page). 
Each router is identified by a cryptographic RouterIdentity which is typically long lived. These routers 
communicate with each other through existing transport mechanisms (e.g. TCP, UDP, PHTTP), passing various 
messages.  Client applications have their own cryptographic identifier ("Destination") which enables it 
to send and receive messages. These clients can connect to any router and authorize the temporary 
allocation ("lease") of some tunnels that will be used for sending and receiving messages through the 
network.  I2P has its own internal <a href="how_networkdatabase.html">network database</a> (using a modification of 
the Kademlia algorithm) for distributing routing and contact information.</p>

<p>The following illustration is a simplistic view regarding how tunnels, routers, and destinations 
are associated, with a pair of inbound tunnels (pink lines) leading towards the router which the 
destination is connected to (little "a"), with a set of outbound tunnels (green lines) leading away 
from that router. The gateway for each of the inbound tunnels (big "A"s) are identified in the lease 
as published in the network database.</p>

<p><img src="http://dev.i2p.net/~jrandom/wiki/topology.png" alt="The network topology" /></p>

<p>Messages send from one Destination to another are (typically) sent through a pair of tunnels - first 
they go out one of the local router's outbound tunnels with instructions specifying that the outbound 
tunnel's end point forward the message to one of the target Destination's inbound tunnel gateways, 
which, on receiving the message, passes it down the tunnel to the recipient. Various mechanisms are 
used to secure these tunnel routed messages, as described <a href="how_tunnelrouting.html">tunnel routing</a>. 
In addition, they can be sent in parallel down multiple tunnels, with the last router discarding 
duplicates.</p>

<p><img src="http://dev.i2p.net/~jrandom/wiki/tunnelSending.png" alt="I2P Tunnel sending"></p>

<p>Some of the messages sent in the network (such as those used to manage tunnels, publish some Leases, 
and deliver long lived end to end messages) may be instead are sent via 
<a href="how_garlicrouting.html">garlic routing</a>. Inspired by a subsection for future works written by 
Michael Freedman within Roger Dingledine's freehaven 
<a href="http://www.freehaven.net/doc/freehaven10.ps">thesis</a>, and with some similarities to 
<a href="http://onion-router.net/">onion routing</a>.  I2P's garlic routing allows multiple messages 
("cloves") to be wrapped inside a single message ("garlic") so that only the intended recipient can 
determine how many cloves are contained as well as how those cloves should be processed.</p>

<p>To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and 
hence there are no directory servers keeping statistics regarding the performance and reliability of 
routers within the network. As such, each router must keep and maintain profiles of various routers 
and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability 
needs of the users, as described in the <a href="how_peerselection.html">peer selection</a> pages</p>

<p>The network itself makes use of a significant number of cryptographic techniques and altorithms - 
a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding, 
1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to 
station authentication, and <a href="how_elgamalaes.html">ElGamal / AES+SessionTag</a>.</p>

<p>Content sent over I2P is encrypted through three or four layers - end to end encryption (absolutely 
no routers get the plaintext, ever), garlic encryption (used to verify the delivery of the message to 
the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel 
gateway to the tunnel endpoint), and interrouter transport layer encryption (e.g. the TCP transport 
uses AES256 with ephemeral keys):</p>

<p><img src="http://dev.i2p.net/~jrandom/endToEndEncryption.png" alt="end to end layered encryption" /></p>

<p>The specific use of these algorithms are outlined <a href="how_cryptography.html">elsewhere</a></p>

<p>The two main mechanisms for allowing people who need militant grade anonymity use the network are 
explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling 
and mixing messages. These are currently planned for release 3.0, but garlic routed messages with no 
delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow people to set 
up and operate behind restricted routes (perhaps with trusted peers), as well as the deployment of more 
flexible and anonymous transports.</p>

<p>Some questions have been raised with regards to the scalability of I2P, and reasonably so. There 
will certainly be more analysis over time, but peer lookup and integration should be bounded by 
<code>O(log(N))</code> due to the <a href="how_networkdatabase.html">network database</a>'s algorithm, while end to end 
messages should be <code>O(log(1))</code> (scale free), since messages go out K hops through the outbound 
tunnel and another K hops through the inbound tunnel - the size of the network (N) bears no impact.</p>

<h2>When?</h2>
<p>I2P initially began in Feb 2003 as a proposed modification to 
<a href="http://freenetproject.org">freenet</a> to allow it to use alternate transports, such as 
<a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, then grew into its own as an 
'anonCommFramework' in April 2003, turning into I2P in July, with code being cut in earnest in August, 
reaching the 0.2 release in September and 0.3 in March.  I2P is currently moving forward according to 
the <a href="roadmap.html">roadmap</a>.</p>

<p>The network itself is not ready for general use, and should not be used by those who need anonymity 
until it has been met with sufficient peer review.</p>

<h2>Who?</h2>
<p>We have a small <a href="team.html">team</a> spread around several continents, working to advance different 
aspects of the project.  We are very open to other developers who want to get involved and anyone else 
who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled 
applications, or documentation. The entire system is open source - the router and most of the SDK are 
outright public domain with some BSD and Cryptix licensed code, while some applications like I2PTunnel 
and I2PSnark are GPL. Almost everything is written in Java (1.3+), though some third party applications 
are being written in Python. The code works on the current <a href="http://www.kaffe.org/">Kaffe</a>, and 
we are hoping to get it working on <a href="http://gcc.gnu.org/java/">GCJ</a> sooner rather than later.</p>

<h2>Where?</h2>
<p>Anyone interested should subscribe to the <a href="http://i2p.net/pipermail/i2p/">mailing list</a> and 
join us on the irc channel #i2p (hosted concurrently on <a href="http://invisiblechat.com/">IIP</a>,
irc.freenode.net, irc.duck.i2p, and irc.baffled.i2p). Weekly development meetings are held there every 
Tuesday at 9pm GMT with <a href="meetings.html">archives available</a>.</p>

<p>The current source is available through an anonymous CVS repository</p>
	<pre>
cvs -d :pserver:anoncvs@i2p.net/cvsroot co i2p</pre>
<p>with the password <code>anoncvs</code>. </p>