kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

cleaned up links and html

Browse Source
This commit is contained in:
jrandom
2004-07-19 16:00:26 +00:00
committed by zzz
parent d214851646
commit e6108f6715
5 changed files with 80 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
pages/how_garlicrouting.html
View File

@@ -1,9 +1,9 @@
<p>
As briefly explained on the <a href="iip-wiki?I2P/Overview">I2P/Overview</a>, in addition to sending
messages through tunnels (via <a href="iip-wiki?I2P/Tunnel">I2P/Tunnel</a>), I2P uses a technique called
As briefly explained on the <a href="how_intro.html">intro</a>, in addition to sending
messages through tunnels (via <a href="how_tunnelrouting.html">tunnels</a>), I2P uses a technique called
"garlic routing" - layered encryption of messages, passing through routers
selected by the original sender. This is similar to the way Mixmaster
(see <a href="iip-wiki?I2P/OtherEfforts">I2P/OtherEfforts</a>) sends messages - taking a message, encrypting it
(see <a href="how_networkcomparisons.html">network comparisons</a>) sends messages - taking a message, encrypting it
to the recipient's public key, taking that encrypted message and encrypting
it (along with instructions specifying the next hop), and then taking that
resulting encrypted message and so on, until it has one layer of encryption
@@ -12,7 +12,7 @@ and I2P's garlic routing is that at each layer, any number of messages can be
contained, instead of just a single message.
<p>
<img src="http://i2p.net/~jrandom/wiki/garlic.png">
<img src="http://dev.i2p.net/~jrandom/wiki/garlic.png">
<p>
In addition to the cloves, each unwrapped garlic message contains a sender
specified amount of padding data, allowing the sender to take active countermeasures
@@ -24,21 +24,22 @@ against traffic analysis.
I2P uses garlic routing in three places:
<UL>
<li> For building tunnels
<li> For determining the success or failure of end to end message delivery (by wrapping an additional DeliveryStatusMessage<a href="iip-wiki?action=edit&id=DeliveryStatusMessage">?</a> in with the payload, where the clove containing the DeliveryStatusMessage<a href="iip-wiki?action=edit&id=DeliveryStatusMessage">?</a> has instructions forwarding it back through other routers and tunnels to the original sender)
<li> For determining the success or failure of end to end message delivery (by wrapping an additional
DeliveryStatusMessage in with the payload, where the clove containing the DeliveryStatusMessage
has instructions forwarding it back through other routers and tunnels to the original sender)
<li> For publishing some network database entries (dampening the probability of a successful traffic analysis attack)
</UL>
<p>
There are also significant ways that this technique can be used to improve the performance of the network, exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability.
There are also significant ways that this technique can be used to improve the performance of the network,
exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability.
<p>
<H2>Encryption</H2>
<p>
The encryption of each layer in the garlic message uses the ElGamal<a href="iip-wiki?action=edit&id=ElGamal">?</a>/AES+SessionTag<a href="iip-wiki?action=edit&id=SessionTag">?</a> algorithm
(as outlined at <a href="iip-wiki?I2P/ElGamalAESSessionTag">I2P/ElGamalAESSessionTag</a>), which avoids the cost of a full 2048bit ElGamal<a href="iip-wiki?action=edit&id=ElGamal">?</a>
encryption for subsequent messages (using instead a random previously specified SessionTag<a href="iip-wiki?action=edit&id=SessionTag">?</a> plus
256bit AES encryption).
The encryption of each layer in the garlic message uses the <a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a> algorithm,
which avoids the cost of a full 2048bit ElGamal encryption for subsequent messages (using instead a random previously
specified SessionTag plus 256bit AES encryption).
<p>
<H2>References</H2>

45
pages/how_intro.html
View File

@@ -19,14 +19,14 @@ or even taken over to attempt more malicious attacks.</p>
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?PHPSESSID=a2cc81573922db94d0656146d3764863">I2PTunnel</a> application,
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="/book/view/41?PHPSESSID=a2cc81573922db94d0656146d3764863">threat model</a>, since there is no such thing as "true" anonymity, just
<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
@@ -36,46 +36,45 @@ corporations cannot identify her, as well as Will Whistleblower to publish sensi
others.</p>
<h2>Why?</h2>
<p>There are a multitude of fantastic <a href="/book/view/8?PHPSESSID=a2cc81573922db94d0656146d3764863">reasons</a> why we need a system to support
<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="/book/view/47?PHPSESSID=a2cc81573922db94d0656146d3764863">other efforts</a> working on finding ways to provide varying degrees of
<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 <a href="/book/view/42?PHPSESSID=a2cc81573922db94d0656146d3764863">Tunnel Routing</a>).
<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="/book/view/44?PHPSESSID=a2cc81573922db94d0656146d3764863">network database</a> (using a modification of
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. Additional topological information can be found
<a href="/book/page/wtf?PHPSESSID=a2cc81573922db94d0656146d3764863">here</a>.</p>
as published in the network database.</p>
<p><img src="http://i2p.net/~jrandom/wiki/topology.png" alt="The network topology" /></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="/book/view/42?PHPSESSID=a2cc81573922db94d0656146d3764863">tunnel routing</a>.
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://i2p.net/~jrandom/wiki/tunnelSending.png" alt="I2P Tunnel sending"></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="/book/view/43?PHPSESSID=a2cc81573922db94d0656146d3764863">garlic routing</a>. Inspired by a subsection for future works written by
<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
@@ -86,12 +85,12 @@ determine how many cloves are contained as well as how those cloves should be pr
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="/book/view/135?PHPSESSID=a2cc81573922db94d0656146d3764863">peer selection</a> pages</p>
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="/book/view/46?PHPSESSID=a2cc81573922db94d0656146d3764863">ElGamal / AES+SessionTag</a>.</p>
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
@@ -99,9 +98,9 @@ the recipient), tunnel encryption (all messages passing through a tunnel is encr
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://i2p.net/~jrandom/endToEndEncryption.png" alt="end to end layered encryption" /></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="/book/view/45?PHPSESSID=a2cc81573922db94d0656146d3764863">elsewhere</a></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
@@ -112,7 +111,7 @@ 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="/book/view/44?PHPSESSID=a2cc81573922db94d0656146d3764863">network database</a>'s algorithm, while end to end
<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>
@@ -122,26 +121,26 @@ tunnel and another K hops through the inbound tunnel - the size of the network (
<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?PHPSESSID=a2cc81573922db94d0656146d3764863">roadmap</a>.</p>
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?PHPSESSID=a2cc81573922db94d0656146d3764863">team</a> spread around several continents, working to advance different
<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 generally works on <a href="http://www.kaffe.org/">Kaffe</a>, and
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://invisiblenet.net/iip/">IIP</a>,
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="/node/view/49?PHPSESSID=a2cc81573922db94d0656146d3764863">archives available</a>.</p>
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>

44
pages/how_networkcomparisons.html
View File

@@ -25,15 +25,15 @@ anonymizing proxies, allowing people to tunnel out through the low latency
mix network. Morphmix includes some very interesting collusion detection
algorithms and Sybil defenses, while Tarzan makes use of the scarcity of IP
addresses to accomplishs the same. The two primary differences between
these systems and I2P are related to I2P's <a href="/book/view/41?PHPSESSID=42d2b0545f243f2537476db228ce1636">threat </B>model</B></a>
these systems and I2P are related to I2P's <a href="how_threatmodel.html">threat model</a>
and their out-proxy design (as opposed to providing both sender and receiver
anonymity). There is source code available to both systems, but we are not aware
of their use outside of academic environments.</p>
<p>
Stealing quite directly from the Tarzan paper, the following includes a quick
comparison of Tarzan, Crowds, Onion Routing (OR), and I2P</B>:</p>
comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:</p>
<img src="http://i2p.net/~jrandom/wiki/comparison.png">
<img src="http://dev.i2p.net/~jrandom/wiki/comparison.png">
<H2>TOR / Onion Routing</H2>
@@ -42,37 +42,35 @@ comparison of Tarzan, Crowds, Onion Routing (OR), and I2P</B>:</p>
<p>
TOR and Onion Routing are both anonymizing proxy networks, allowing people
to tunnel out through their low latency mix network. The two primary
differences between TOR / OnionRouting and I2P</B> are again related to differences
in the threat </B>model</B> and the out-proxy design (though TOR is working to provide
differences between TOR / OnionRouting and I2P are again related to differences
in the threat model and the out-proxy design (though TOR is working to provide
redevous points within the mix network, which will provide recipient anonymity).
In addition, these networks take the directory based approach - providing a
centralized point to manage the overall 'view' of the network, as well as gather
and report statistics, as opposed to I2P's</B> distributed
and report statistics, as opposed to I2P's distributed <a href="how_networkdatabase.html">network
database</a> and <a href="how_peerselection.html">peer selection</a>.</p>
<a href="/book/view/44?PHPSESSID=42d2b0545f243f2537476db228ce1636">network database</a> and <a href="/book/view/135?PHPSESSID=42d2b0545f243f2537476db228ce1636">peer selection</a>.</p>
<p>On the technical side, there are 5 main differences between TOR and I2P</B>:</p>
<p>On the technical side, there are 5 main differences between TOR and I2P:</p>
<ul>
<li>TOR is centrally managed (trusted directories, only some people fully participate
in the network with cover traffic) while I2P</B> is fully distributed. This has serious
in the network with cover traffic) while I2P is fully distributed. This has serious
anonymity implications for people using TOR that are not one of the TOR nodes,
since a powerful attacker could determine your identity, or coerce the maintainer
of TOR's directory server to include untrustworthy nodes.</li>
<li>TOR is circuit based (with reliable, ordered, bidirectional tunnels), while I2P</B>
<li>TOR is circuit based (with reliable, ordered, bidirectional tunnels), while I2P
is packet based (with unreliable, unordered, unidirectional tunnels). As with the
TCP/IP separation, I2P</B> optionally adds TCL-like functionality on top of the packet
TCP/IP separation, I2P optionally adds TCL-like functionality on top of the packet
based network by means of mihi's ministreaming library.</li>
<li>TOR is low latency, while I2P</B> is variable latency (both ASAP and stop+go). This will
allow I2P</B> to provide a higher level of anonymity by blending the anonymity set of
<li>TOR is low latency, while I2P is variable latency (both ASAP and stop+go). This will
allow I2P to provide a higher level of anonymity by blending the anonymity set of
different user bases together - for example, filesharing users and militants look
the same, though make use of different techniques to balance their own anonymity
and security needs)</li>
<li>TOR is IP addressed, relying on the security of the IP layer for authenticating
and securing the message delivery, while I2P</B> is cryptographically addressed.</li>
<li>TOR is written in C on *nix (windows port w/ cygwin?), while I2P</B> is written in
Java and tested on *nix, windows, and macs</li>
and securing the message delivery, while I2P is cryptographically addressed.</li>
<li>TOR is written in C while I2P is written in Java</li>
</ul>
<H2>Mixminion / Mixmaster</H2>
@@ -82,8 +80,8 @@ and report statistics, as opposed to I2P's</B> distributed
<p>
Mixminion and Mixmaster are networks to support anonymous email against a very
powerful adversary. I2P</B> aims to provide an adequate means to meet their threat
</B>model</B> as we reach I2P</B> 3.0 along side the needs of low latency users, providing
powerful adversary. I2P aims to provide an adequate means to meet their threat
model as we reach I2P 3.0 along side the needs of low latency users, providing
a significantly larger anonymity set. As with TOR and Onion Routing above,
both Mixminion and Mixmaster take the directory based approach as well.</p>
@@ -93,12 +91,12 @@ both Mixminion and Mixmaster take the directory based approach as well.</p>
<p>
Freenet is a fully distributed, peer to peer anonymous publishing network.
As such, generic anonymous communication over it requires the use of the global
blackboard model</B> - storing data somewhere that the recipient will then check
blackboard model - storing data somewhere that the recipient will then check
for a message. Freenet also does not support the concept of user defined delays -
it stores and fetches data as quickly as it can, rather than queueing up, pooling,
delaying, and mixing the data, leaving a hole with regards to long term intersection
attacks. In addition, there seem to be some performance issues that can arguably
be attributed to the global blackboard model</B> which will likely rule out interactive
be attributed to the global blackboard model which will likely rule out interactive
low latency communication.</p>
<H2>JAP</H2>
@@ -109,8 +107,8 @@ low latency communication.</p>
JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing web requests,
and as such it has a few centralized nodes (participants in the cascade) that blend
and mix requests from clients through the sequence of nodes (the cascade) before
proxying out onto the web. The scope, threat </B>model</B>, and security is substantially
different from I2P</B>, but for those who don't require significant anonymity but still
proxying out onto the web. The scope, threat model, and security is substantially
different from I2P, but for those who don't require significant anonymity but still
are not satisfied with an Anonymizer-like service, JAP is worth reviewing. One
caution to note is that anyone under the jurisdiction of the German courts may want
to take care, as the German Federal Bureau of Criminal Investigation (FBCI) has has

3
pages/how_networkdatabase.html
View File

@@ -1 +1,2 @@
[not yet written overview of the I2P network database, old content at http://wiki.invisiblenet.net/iip-wiki?NetworkDb]
(old version of this page lost... we need a rewrite. basic gist of it is we follow the
guidelines of Kademlia to manage a distributed routing table)

40
pages/how_tunnelrouting.html
View File

@@ -1,5 +1,5 @@
<p>
As briefly explained on the <a href="iip-wiki?I2P/Overview">I2P/Overview</a>, I2P builds virtual "tunnels" -
As briefly explained in the <a href="how_intro.html">intro</a>, I2P builds virtual "tunnels" -
temporary and unidirectional paths through a sequence of routers. These
tunnels can be categorized as either inbound tunnels (where everything
given to it goes towards the creator of the tunnel) and outbound tunnels
@@ -9,14 +9,16 @@ her existing outbound tunnels with instructions for that tunnel's endpoint
to forward it to the gateway router for one of Bob's current inbound
tunnels, which in turn passes it to Bob.
<p>
<img src="http://i2p.net/~jrandom/wiki/tunnelSending.png">
<img src="http://dev.i2p.net/~jrandom/wiki/tunnelSending.png">
<p>
<H2>Tunnel vocabulary</H2>
<p>
<UL>
<li> <b>Tunnel gateway</b> - the first router in a tunnel. For inbound tunnels, this is the one mentioned in the I2P/LeaseSet<a href="iip-wiki?action=edit&id=I2P/LeaseSet">?</a> published in the I2P/NetworkDb<a href="iip-wiki?action=edit&id=I2P/NetworkDb">?</a>. For outbound tunnels, the gateway is the originating router. (e.g. both A and D above)
<li> <b>Tunnel gateway</b> - the first router in a tunnel. For inbound tunnels, this is the one mentioned in the
LeaseSet published in the <a href="how_networkdatabase.html">network database</a>. For outbound tunnels, the
gateway is the originating router. (e.g. both A and D above)
</UL>
<p>
<UL>
@@ -34,13 +36,15 @@ tunnels, which in turn passes it to Bob.
<UL>
<li> <b>0-hop tunnel</b> - a tunnel where the gateway is also the endpoint
<li> <b>1-hop tunnel</b> - a tunnel where the gateway talks directly to the endpoint
<li> <b>2-(or more)-hop tunnel</b> - a tunnel where there is at least one tunnel participant. (the above diagram includes two 2-hop tunnels - one outbound from Alice, one inbound to Bob)
<li> <b>2-(or more)-hop tunnel</b> - a tunnel where there is at least one tunnel participant. (the above diagram includes two
2-hop tunnels - one outbound from Alice, one inbound to Bob)
</UL>
</UL>
<p>
<UL>
<li> <b>Tunnel lifetime</b> - how long a particular tunnel is supposed to be in operation for (each client specifies this when contacting their router, and the router makes sure sufficient tunnels meeting that criteria are built)
<li> <b>Tunnel lifetime</b> - how long a particular tunnel is supposed to be in operation for (each client specifies this
when contacting their router, and the router makes sure sufficient tunnels meeting that criteria are built)
</UL>
<p>
<H2>Tunnel information</H2>
@@ -113,7 +117,7 @@ tunnels are more complex, but could show similar information (though would be sl
<p>
With only one remote router in a tunnel, the user has both plausible deniability and basic anonymity, as long
as they are not up against an internal adversary (as described on <a href="iip-wiki?I2P/ThreatModel">I2P/ThreatModel</a>). However, if the adversary
as they are not up against an internal adversary (as described on <a href="how_threatmodel.html">threat model</a>). However, if the adversary
ran a sufficient number of routers such that the single remote router in the tunnel is often one of those
compromised ones, they would be able to mount the above statistical traffic analysis attack.
<p>
@@ -135,7 +139,7 @@ pools are refreshed every minute or so, using the router's default settings]
<H2>Tunnel testing</H2>
<p>
All tunnels are periodically tested by their creator by sending a DeliveryStatusMessage<a href="iip-wiki?action=edit&id=DeliveryStatusMessage">?</a> out the tunnel and bound
All tunnels are periodically tested by their creator by sending a DeliveryStatusMessage out the tunnel and bound
for another inbound tunnel (testing both tunnels at once). If either fails, both are marked as no longer functional,
and if they were used for a client's inbound tunnel, a new leaseSet is created. Other techniques can be used to test
tunnels later on, such as garlic wrapping a number of tests into cloves, testing individual tunnel participants
@@ -145,21 +149,23 @@ not implemented at the moment.
<H2>Tunnel creation</H2>
<p>
Tunnel creation is handled by garlic routing (see <a href="iip-wiki?I2P/GarlicRouting">I2P/GarlicRouting</a>) a TunnelCreateMessage<a href="iip-wiki?action=edit&id=TunnelCreateMessage">?</a> to a router,
Tunnel creation is handled by <a href="how_garlicrouting.html">garlic routing</a>) a TunnelCreateMessage to a router,
requesting that they participate in the tunnel (providing them with all of the appropriate information, as above,
along with a certificate, which right now is a 'null' cert, but will support hashcash or other non-free certificates
when necessary). The message also includes a SourceRouteReplyBlock<a href="iip-wiki?action=edit&id=SourceRouteReplyBlock">?</a>, which allows the router to encrypt their
TunnelCreateStatusMessage<a href="iip-wiki?action=edit&id=TunnelCreateStatusMessage">?</a> into a SourceRouteReplyMessage<a href="iip-wiki?action=edit&id=SourceRouteReplyMessage">?</a>, which is sent to another router (specified in the
SourceRouteReplyBlock<a href="iip-wiki?action=edit&id=SourceRouteReplyBlock">?</a>), who then decrypts the rest of the SourceRouteReplyBlock<a href="iip-wiki?action=edit&id=SourceRouteReplyBlock">?</a>, reads out the delivery instructions
contained therein, and forwards the TunnelCreateStatusMessage<a href="iip-wiki?action=edit&id=TunnelCreateStatusMessage">?</a> accordingly. (the delivery instructions can specify
when necessary). The message also includes a SourceRouteReplyBlock, which allows the router to encrypt their
TunnelCreateStatusMessage into a SourceRouteReplyMessage, which is sent to another router (specified in the
SourceRouteReplyBlock), who then decrypts the rest of the SourceRouteReplyBlock, reads out the delivery instructions
contained therein, and forwards the TunnelCreateStatusMessage accordingly. (the delivery instructions can specify
delivery to a specific router or can point at a tunnel)
<p>
<H2>Issues</H2>
<H2>Issues/todo</H2>
<p>
<UL>
<li> Should we assign unique tunnel ids for each router in the tunnel, rather than having a single id across the whole tunnel? this would make traffic analysis even harder
<li> Should inbound tunnels that will be used by clients ever be used for general messages (network database, etc), rather than being free for use until its allocated?
<li> I2P 3.0 tunnel mixing / pooling details
<li> Tunnel limiting details
<li> We will assign unique tunnel ids for each router in the tunnel, rather than having a single id across the whole tunnel. this would make traffic analysis even harder</li>
<li> Get rid of the sourceRouteBlock stuff</li>
<li> Should inbound tunnels that will be used by clients ever be used for general messages (network database, etc), rather than being free for use until its allocated?</li>
<li> I2P 3.0 tunnel mixing / pooling details</li>
<li> Tunnel throttling details
</ul>