151 lines
11 KiB
HTML
151 lines
11 KiB
HTML
{% extends "global/layout.html" %}
|
|
{% block title %}A Gentle Introduction{% endblock %}
|
|
{% block content %}
|
|
|
|
<h2>A Gentle Introduction to How I2P Works</h2>
|
|
|
|
<p>I2P is a project to build, deploy, and maintain a network supporting 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 BitTorrent client ("I2PSnark"),
|
|
or a distributed data store. With the help of the <a href="{{ site_url('docs/applications/i2ptunnel') }}">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="{{ site_url('docs/how/threatmodel') }}">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 good anonymity, mixed in with sufficient cover
|
|
traffic provided by the activity of people who require less anonymity. This way, some users can avoid
|
|
detection by a very powerful adversary, while others will try to evade a weaker entity,
|
|
<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 reasons why we need a system to support
|
|
anonymous communication, and everyone has their own personal rationale. There are many
|
|
<a href="{{ site_url('docs/how/networkcomparisons') }}">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="{{ site_url('docs/how/tunnelrouting') }}">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 (TCP, UDP, etc), 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="{{ site_url('docs/how/networkdatabase') }}">network database</a> (using a modification of
|
|
the Kademlia algorithm) for distributing routing and contact information securely.</p>
|
|
|
|
<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/net.png') }}" alt="Network topology example" title="Network topology example" /></div>
|
|
|
|
|
|
<p>In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their
|
|
local router. They each have a pair of 2-hop inbound tunnels per destination (labeled 1, 2, 3, 4, 5 and 6),
|
|
and a small subset of each of those router's outbound tunnel pool is shown with 2-hop outbound tunnels.
|
|
For simplicity, Charlie's inbound tunnels and Dave's outbound tunnels are not shown, nor are the rest of
|
|
each router's outbound tunnel pool (typically stocked with a few tunnels at a time). When Alice and Bob
|
|
talk to each other, Alice sends a message out one of her (pink) outbound tunnels targeting one of Bob's
|
|
(green) inbound tunnels (tunnel 3 or 4). She knows to send to those tunnels on the correct router by querying the
|
|
network database, which is constantly updated as new leases are authorized and old ones expire.</p>
|
|
|
|
<p>If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of his
|
|
outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2). To make things easier, most
|
|
messages sent between Alice and Bob are <a href="{{ site_url('docs/how/garlicrouting') }}">garlic</a> wrapped, bundling the
|
|
sender's own current lease information so that the recipient can reply immediately without having to look
|
|
in the network database for the current data.</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="{{ site_url('docs/how/peerselection') }}">peer selection</a> page.</p>
|
|
|
|
<p>The network itself makes use of a significant number of <a href="{{ site_url('docs/how/cryptography') }}">cryptographic techniques and algorithms</a> -
|
|
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="{{ site_url('docs/how/elgamalaes') }}">ElGamal / AES+SessionTag</a>.</p>
|
|
|
|
<p>Content sent over I2P is encrypted through three layers 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 inter router transport layer encryption (e.g. the TCP transport
|
|
uses AES256 with ephemeral keys):</p>
|
|
<p>End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6;
|
|
end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a" to Bob's router "h" remains.
|
|
Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection
|
|
between the I2P router and the applications is not end-to-end encrypted!
|
|
A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the applications running atop of I2P.</p>
|
|
|
|
<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="End to end layered encryption" title="End to end layered encryption." /></div>
|
|
|
|
<p>The specific use of these algorithms are outlined <a href="{{ site_url('docs/how/cryptography') }}">elsewhere</a>.</p>
|
|
|
|
<p>The two main mechanisms for allowing people who need strong anonymity to 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="{{ site_url('docs/how/networkdatabase') }}">network database</a>'s algorithm, while end to end
|
|
messages should be <code>O(1)</code> (scale free), since messages go out K hops through the outbound
|
|
tunnel and another K hops through the inbound tunnel, with K no longer than 3.
|
|
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 written in earnest starting in August '03.
|
|
I2P is currently under development, following
|
|
the <a href="{{ site_url('volunteer/roadmap') }}">roadmap</a>.</p>
|
|
|
|
<h2>Who?</h2>
|
|
<p>We have a small <a href="{{ site_url('team') }}">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.5+), though some third party applications
|
|
are being written in Python and other languages. The code works on <a href="http://java.com/en/">Sun Java SE</a> and other Java Virtual Machines.
|
|
</p>
|
|
|
|
<h2>Where?</h2>
|
|
<p>Anyone interested should
|
|
join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de).
|
|
There are currently no scheduled development meetings, however
|
|
<a href="{{ url_for('meetings_index', lang=g.lang) }}">archives are available</a>.</p>
|
|
|
|
<p>The current source is available in <a href="{{ site_url('develop/monotone') }}">monotone</a>.</p>
|
|
|
|
<h2>Additional Information</h2>
|
|
<p>
|
|
See <a href="{{ site_url('docs/how') }}">the Index to Technical Documentation</a>
|
|
</p>
|
|
|
|
{% endblock %}
|