add todo_fr
This commit is contained in:
magma
@ -176,7 +176,7 @@
|
|||||||
|
|
||||||
<img src="/_static/images/sqbullet.png" /> <a href="meetings_fr.html">Rencontres i2p</a><br />
|
<img src="/_static/images/sqbullet.png" /> <a href="meetings_fr.html">Rencontres i2p</a><br />
|
||||||
<img src="/_static/images/sqbullet.png" /> <a href="roadmap_fr.html">Feuille de route</a><br />
|
<img src="/_static/images/sqbullet.png" /> <a href="roadmap_fr.html">Feuille de route</a><br />
|
||||||
<img src="/_static/images/sqbullet.png" /> <a href="todo.html">Les choses à faire</a><br />
|
<img src="/_static/images/sqbullet.png" /> <a href="todo.html_fr">Les choses à faire</a><br />
|
||||||
<br /><b><a href="intro.html">À propos d'i2p</a></b><br />
|
<br /><b><a href="intro.html">À propos d'i2p</a></b><br />
|
||||||
<img src="/_static/images/sqbullet.png" /> <a href="faq_fr.html">Foire aux questions</a><br />
|
<img src="/_static/images/sqbullet.png" /> <a href="faq_fr.html">Foire aux questions</a><br />
|
||||||
<img src="/_static/images/sqbullet.png" /> <a href="http://forum.i2p2.de/">I2P forums</a><br />
|
<img src="/_static/images/sqbullet.png" /> <a href="http://forum.i2p2.de/">I2P forums</a><br />
|
||||||
|
|||||||
345
www.i2p2/pages/todo_fr.html
Normal file
345
www.i2p2/pages/todo_fr.html
Normal file
@ -0,0 +1,345 @@
|
|||||||
|
{% extends "_layout.html" %}
|
||||||
|
{% block title %}To Do List{% endblock %}
|
||||||
|
{% block content %}
|
||||||
|
<h1>I2P Project Targets</h1>
|
||||||
|
<p>Below is a more detailed (yet still incomplete) discussion of the major areas
|
||||||
|
of future development on the core I2P network, spanning the plausibly planned
|
||||||
|
releases. This does not include stego transports, porting to wireless devices,
|
||||||
|
or tools to secure the local machine, nor does it include client applications
|
||||||
|
that will be essential in I2P's success. There are probably other things that
|
||||||
|
will come up, especially as I2P gets more peer review, but these are the main
|
||||||
|
'big things'. See also <a href="roadmap.html">the roadmap</a>. Want to help?
|
||||||
|
<a href="getinvolved.html">Get involved</a>! </p>
|
||||||
|
<br />
|
||||||
|
<h2>Core functionality <font size="-1"><a href="#core">[link]</a></font></h2>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<li><a href="#nat">NAT/Firewall bridging via 1-hop restricted routes</a></li>
|
||||||
|
<li><a href="#transport">High degree transport layer with UDP, NBIO, or NIO</a></li>
|
||||||
|
<li><a href="#netdb">NetworkDB and profile tuning and ejection policy for
|
||||||
|
large nets</a></li>
|
||||||
|
</ul>
|
||||||
|
<h2>Security / anonymity <font size="-1"><a href="#security">[link]</a></font></h2>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<li><a href="#tunnelId">Per-hop tunnel id & new permuted TunnelVerificationStructure
|
||||||
|
encryption</a></li>
|
||||||
|
<li><a href="#ordering">Strict ordering of participants within tunnels</a></li>
|
||||||
|
<li><a href="#tunnelLength">Randomly permuted tunnel lengths</a></li>
|
||||||
|
<li><a href="#fullRestrictedRoutes">Full blown n-hop restricted routes with
|
||||||
|
optional trusted links</a></li>
|
||||||
|
<li><a href="#hashcash">Hashcash for routerIdentity, destination, and tunnel
|
||||||
|
request</a></li>
|
||||||
|
<li><a href="#batching">Advanced tunnel operation (batching/mixing/throttling/padding)</a></li>
|
||||||
|
<li><a href="#stop">Stop & go mix w/ garlics & tunnels</a></li>
|
||||||
|
</ul>
|
||||||
|
<h2>Performance <font size="-1"><a href="performance.html">[link]</a></font></h2>
|
||||||
|
<h2 id="core">Core functionality</h2>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<li>
|
||||||
|
<h3 id="nat">NAT/Firewall bridging via 1-hop restricted routes</h3>
|
||||||
|
</li>
|
||||||
|
<b><i>Implemented in I2P 0.6.0.6</i></b>
|
||||||
|
<p>The functionality of allowing routers to fully participate within the network
|
||||||
|
while behind firewalls and NATs that they do not control requires some basic
|
||||||
|
restricted route operation (since those peers will not be able to receive
|
||||||
|
inbound connections). To do this successfully, you consider peers one of
|
||||||
|
two ways:</p>
|
||||||
|
</ul>
|
||||||
|
<ul>
|
||||||
|
<li><b>Peers who have reachable interfaces</b> - these peers do not need to
|
||||||
|
do anything special</li>
|
||||||
|
<li><b>Peers who do not have reachable interfaces</b> - these peers must build
|
||||||
|
a tunnel pointing at them where the gateway is one of the peers they have
|
||||||
|
established a connection with who has both a publicly reachable interface
|
||||||
|
and who has agreed to serve as their 'introducer'.</li>
|
||||||
|
</ul>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<p>To do this, peers who have no IP address simply connect to a few peers,
|
||||||
|
build a tunnel through them, and publish a reference to those tunnels within
|
||||||
|
their RouterInfo structure in the network database.</p>
|
||||||
|
<p>When someone wants to contact any particular router, they first must get
|
||||||
|
its RouterInfo from the network database, which will tell them whether they
|
||||||
|
can connect directly (e.g. the peer has a publicly reachable interface)
|
||||||
|
or whether they need to contact them indirectly. Direct connections occur
|
||||||
|
as normal, while indirect connections are done through one of the the published
|
||||||
|
tunnels.</p>
|
||||||
|
<p>When a router just wants to get a message or two to a specific hidden peer,
|
||||||
|
they can just use the indirect tunnel for sending the payload. However,
|
||||||
|
if the router wants to talk to the hidden peer often (for instance, as part
|
||||||
|
of a tunnel), they will send a garlic routed message through the indirect
|
||||||
|
tunnel to that hidden peer which unwraps to contain a message which should
|
||||||
|
be sent to the originating router. That hidden peer then establishes an
|
||||||
|
outbound connection to the originating router and from then on, those two
|
||||||
|
routers can talk to each other directly over that newly established direct
|
||||||
|
connection.</p>
|
||||||
|
<p>Of course, that only works if the originating peer can receive connections
|
||||||
|
(they aren't also hidden). However, if the originating peer is hidden, they
|
||||||
|
can simply direct the garlic routed message to come back to the originating
|
||||||
|
peer's inbound tunnel.</p>
|
||||||
|
<p>This is not meant to provide a way for a peer's IP address to be concealed,
|
||||||
|
merely as a way to let people behind firewalls and NATs fully operate within
|
||||||
|
the network. Concealing the peer's IP address adds a little more work, as
|
||||||
|
described <a href="#fullRestrictedRoutes">below.</a></p>
|
||||||
|
<p>With this technique, any router can participate as any part of a tunnel.
|
||||||
|
For efficiency purposes, a hidden peer would be a bad choice for an inbound
|
||||||
|
gateway, and within any given tunnel, two neighboring peers wouldn't want
|
||||||
|
to be hidden. But that is not technically necessary.</p>
|
||||||
|
</ul>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<li>
|
||||||
|
<h3 id="transport">High degree transport layer with UDP, NBIO, or NIO</h3>
|
||||||
|
<b><i>Both UDP and NIO have been Implemented in I2P</i></b>
|
||||||
|
<p>Standard TCP communication in Java generally requires blocking socket
|
||||||
|
calls, and to keep a blocked socket from hanging the entire system, those
|
||||||
|
blocking calls are done on their own threads. Our current TCP transport
|
||||||
|
is implemented in a naive fashion - for each peer we are talking to, we
|
||||||
|
have one thread reading and one thread writing. The reader thread simply
|
||||||
|
loops a bunch of read() calls, building I2NP messages and adding them
|
||||||
|
to our internal inbound message queue, and the writer thread pulls messages
|
||||||
|
off a per-connection outbound message queue and shoves the data through
|
||||||
|
write() calls.</p>
|
||||||
|
<p>We do this fairly efficiently, from a CPU perspective - at any time,
|
||||||
|
almost all of these threads are sitting idle, blocked waiting for something
|
||||||
|
to do. However, each thread consumes real resources (on older Linux kernels,
|
||||||
|
for instance, each thread would often be implemented as a fork()'ed process).
|
||||||
|
As the network grows, the number of peers each router will want to talk
|
||||||
|
with will increase (remember, I2P is fully connected, meaning that any
|
||||||
|
given peer should know how to get a message to any other peer, and restricted
|
||||||
|
route support will probably not significantly reduce the number of connections
|
||||||
|
necessary). This means that with a 100,000 router network, each router
|
||||||
|
will have up to 199,998 threads just to deal with the TCP connections!</p>
|
||||||
|
<p>Obviously, that just won't work. We need to use a transport layer that
|
||||||
|
can scale. In Java, we have two main camps:</p>
|
||||||
|
<h4>UDP</h4>
|
||||||
|
<b><i>Implemented in I2P 0.6 ("SSU") as documented <a href="udp.html">elsewhere</a></i></b>
|
||||||
|
<p>Sending and receiving UDP datagrams is a connectionless operation - if
|
||||||
|
we are communicating with 100,000 peers, we simply stick the UDP packets
|
||||||
|
in a queue and have a single thread pulling them off the queue and shoving
|
||||||
|
them out the pipe (and to receive, have a single thread pulling in any
|
||||||
|
UDP packets received and adding them to an inbound queue).</p>
|
||||||
|
<p>However, moving to UDP means losing the benefits of TCP's ordering, congestion
|
||||||
|
control, MTU discovery, etc. Implementing that code will take significant
|
||||||
|
work, however I2P doesn't need it to be as strong as TCP. Specifically,
|
||||||
|
a while ago I was taking some measurements in the simulator and on the
|
||||||
|
live net, and the vast majority of messages transferred would fit easily
|
||||||
|
within a single unfragmented UDP packet, and the largest of the messages
|
||||||
|
would fit within 20-30 packets. As mule pointed out, TCP adds a significant
|
||||||
|
overhead when dealing with so many small packets, as the ACKs are within
|
||||||
|
an order of magnitude in size. With UDP, we can optimize the transport
|
||||||
|
for both efficiency and resilience by taking into account I2P's particular
|
||||||
|
needs.</p>
|
||||||
|
<p>It will be a lot of work though.</p>
|
||||||
|
<h4>NIO or NBIO</h4>
|
||||||
|
<b><i>NIO Implemented in I2P 0.6.1.22 ("NTCP")</i></b>
|
||||||
|
<p>In Java 1.4, a set of "New I/O" packages was introduced, allowing Java
|
||||||
|
developers to take advantage of the operating system's nonblocking IO
|
||||||
|
capabilities - allowing you to maintain a large number of concurrent IO
|
||||||
|
operations without requiring a separate thread for each. There is much
|
||||||
|
promise with this approach, as we can scalable handle a large number of
|
||||||
|
concurrent connections and we don't have to write a mini-TCP stack with
|
||||||
|
UDP. However, the NIO packages have not proven themselves to be battle-ready,
|
||||||
|
as the Freenet developer's found. In addition, requiring NIO support would
|
||||||
|
mean we can't run on any of the open source JVMs like <a href="http://www.kaffe.org/">Kaffe</a>,
|
||||||
|
as <a href="http://www.classpath.org/">GNU/Classpath</a> has only limited
|
||||||
|
support for NIO. <i>(note: this may not be the case anymore, as there
|
||||||
|
has been some progress on Classpath's NIO, but it is an unknown quantity)</i></p>
|
||||||
|
<p>Another alternative along the same lines is the <a href="http://www.eecs.harvard.edu/~mdw/proj/java-nbio/">Non
|
||||||
|
Blocking I/O</a> package - essentially a cleanroom NIO implementation
|
||||||
|
(written before NIO was around). It works by using some native OS code
|
||||||
|
to do the nonblocking IO, passing off events through Java. It seems to
|
||||||
|
be working with Kaffe, though there doesn't seem to be much development
|
||||||
|
activity on it lately (likely due to 1.4's NIO deployment).</p>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<li>
|
||||||
|
<h3 id="netdb">NetworkDB and profile tuning and ejection policy for large
|
||||||
|
nets</h3>
|
||||||
|
<p>Within the current network database and profile management implementation,
|
||||||
|
we have taken the liberty of some practical shortcuts. For instance, we
|
||||||
|
don't have the code to drop peer references from the K-buckets, as we
|
||||||
|
don't have enough peers to even plausibly fill any of them, so instead,
|
||||||
|
we just keep the peers in whatever bucket is appropriate. Another example
|
||||||
|
deals with the peer profiles - the memory required to maintain each peer's
|
||||||
|
profile is small enough that we can keep thousands of full blown profiles
|
||||||
|
in memory without problems. While we have the capacity to use trimmed
|
||||||
|
down profiles (which we can maintain 100s of thousands in memory), we
|
||||||
|
don't have any code to deal with moving a profile from a "minimal profile"
|
||||||
|
to a "full profile", a "full profile" to a "minimal profile", or to simply
|
||||||
|
eject a profile altogether. It just wouldn't be practical to write that
|
||||||
|
code yet, since we aren't going to need it for a while.</p>
|
||||||
|
<p>That said, as the network grows we are going to want to keep these considerations
|
||||||
|
in mind. We will have some work to do, but we can put it off for later.</p>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
<h2 id="security">Security / anonymity</h2>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<li>
|
||||||
|
<h3 id="tunnelId">Per-hop tunnel id & new permuted TunnelVerificationStructure
|
||||||
|
encryption</h3>
|
||||||
|
<b><i>Addressed in I2P 0.5 as documented <a href="tunnel-alt.html">elsewhere</a></i></b>
|
||||||
|
<p>Right now, if Alice builds a four hop inbound tunnel starting at Elvis,
|
||||||
|
going to Dave, then to Charlie, then Bob, and finally Alice (A<--B<--C<--D<--E),
|
||||||
|
all five of them will know they are participating in tunnel "123", as
|
||||||
|
the messages are tagged as such. What we want to do is give each hop their
|
||||||
|
own unique tunnel hop ID - Charlie will receive messages on tunnel 234
|
||||||
|
and forward them to tunnel 876 on Bob. The intent is to prevent Bob or
|
||||||
|
Charlie from knowing that they are in Alice's tunnel, as if each hop in
|
||||||
|
the tunnel had the same tunnel ID, collusion attacks aren't much work.
|
||||||
|
</p>
|
||||||
|
<p>Adding a unique tunnel ID per hop isn't hard, but by itself, insufficient.
|
||||||
|
If Dave and Bob are under the control of the same attacker, they wouldn't
|
||||||
|
be able to tell they are in the same tunnel due to the tunnel ID, but
|
||||||
|
would be able to tell by the message bodies and verification structures
|
||||||
|
by simply comparing them. To prevent that, the tunnel must use layered
|
||||||
|
encryption along the path, both on the payload of the tunneled message
|
||||||
|
and on the verification structure (used to prevent simple tagging attacks).
|
||||||
|
This requires some simple modifications to the TunnelMessage, as well
|
||||||
|
as the inclusion of per-hop secret keys delivered during tunnel creation
|
||||||
|
and given to the tunnel's gateway. We must fix a maximum tunnel length
|
||||||
|
(e.g. 16 hops) and instruct the gateway to encrypt the message to each
|
||||||
|
of the 16 delivered secret keys, in reverse order, and to encrypt the
|
||||||
|
signature of the hash of the (encrypted) payload at each step. The gateway
|
||||||
|
then sends that 16-step encrypted message, along with a 16-step and 16-wide
|
||||||
|
encrypted mapping to the first hop, which then decrypts the mapping and
|
||||||
|
the payload with their secret key, looking in the 16-wide mapping for
|
||||||
|
the entry associated with their own hop (keyed by the per-hop tunnel ID)
|
||||||
|
and verifying the payload by checking it against the associated signed
|
||||||
|
hash.</p>
|
||||||
|
<p>The tunnel gateway does still have more information than the other peers
|
||||||
|
in the tunnel, and compromising both the gateway and a tunnel participant
|
||||||
|
would allow those peers to collude, exposing the fact that they are both
|
||||||
|
in the same tunnel. In addition, neighboring peers know that they are
|
||||||
|
in the same tunnel anyway, as they know who they send the message to (and
|
||||||
|
with IP-based transports without restricted routes, they know who they
|
||||||
|
got it from). However, the above two techniques significantly increase
|
||||||
|
the cost of gaining meaningful samples when dealing with longer tunnels.</p>
|
||||||
|
</li>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<li>
|
||||||
|
<h3 id="ordering">Strict ordering of participants within tunnels</h3>
|
||||||
|
<b><i>Implemented in release 0.6.2</i></b></li>
|
||||||
|
</ul>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<p>As Connelly <a href="http://dev.i2p/pipermail/i2p/2004-July/000335.html">proposed</a>
|
||||||
|
to deal with the <a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">predecessor
|
||||||
|
attack</a> <a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">(2008
|
||||||
|
update)</a>, keeping the order of peers within our tunnels consistent
|
||||||
|
(aka whenever Alice creates a tunnel with both Bob and Charlie in it,
|
||||||
|
Bob's next hop is always Charlie), we address the issue as Bob doesn't
|
||||||
|
get to substantially sample Alice's peer selection group. We may even
|
||||||
|
want to explicitly allow Bob to participate in Alice's tunnels in only
|
||||||
|
one way - receiving a message from Dave and sending it to Charlie - and
|
||||||
|
if any of those peers are not available to participate in the tunnel (due
|
||||||
|
to overload, network disconnection, etc), avoid asking Bob to participate
|
||||||
|
in any tunnels until they are back online.</p>
|
||||||
|
<p>More analysis is necessary for revising the tunnel creation - at the
|
||||||
|
moment, we simply select and order randomly within the peer's top tier
|
||||||
|
of peers (ones with fast + high capacity).</p>
|
||||||
|
<p>Adding a strict ordering to peers in a tunnel also improves the anonymity
|
||||||
|
of peers with 0-hop tunnels, as otherwise the fact that a peer's gateway
|
||||||
|
is always the same would be particularly damning. However, peers with
|
||||||
|
0-hop tunnels may want to periodically use a 1-hop tunnel to simulate
|
||||||
|
the failure of a normally reliable gateway peer (so every MTBF*(tunnel
|
||||||
|
duration) minutes, use a 1-hop tunnel).</p>
|
||||||
|
</ul>
|
||||||
|
<li>
|
||||||
|
<h3 id="tunnelLength">Randomly permuted tunnel lengths</h3>
|
||||||
|
<b><i>Addressed in I2P 0.5 as documented <a href="tunnel-alt.html">elsewhere</a></i></b></li>
|
||||||
|
</ul>
|
||||||
|
<ul class="targetlist">
|
||||||
|
<p>Without tunnel length permutation, if someone were to somehow detect that
|
||||||
|
a destination had a particular number of hops, it might be able to use that
|
||||||
|
information to identify the router the destination is located on, per the
|
||||||
|
predecessor attack. For instance, if everyone has 2-hop tunnels, if Bob
|
||||||
|
receives a tunnel message from Charlie and forwards it to Alice, Bob knows
|
||||||
|
Alice is the final router in the tunnel. If Bob were to identify what destination
|
||||||
|
that tunnel served (by means of colluding with the gateway and harvesting
|
||||||
|
the network database for all of the LeaseSets), he would know the router
|
||||||
|
on which that destination is located (and without restricted routes, that
|
||||||
|
would mean what IP address the destination is on).</p>
|
||||||
|
<p>It is to counter user behavior that tunnel lengths should be permuted,
|
||||||
|
using algorithms based on the length requested (for example, the 1/MTBF
|
||||||
|
length change for 0-hop tunnels outlined above).</p>
|
||||||
|
<li>
|
||||||
|
<h3 id="fullRestrictedRoutes">Full blown n-hop restricted routes with optional
|
||||||
|
trusted links</h3>
|
||||||
|
<p>The restricted route functionality described before was simply a functional
|
||||||
|
issue - how to let peers who would not otherwise be able to communicate
|
||||||
|
do so. However, the concept of allowing restricted routes includes additional
|
||||||
|
capabilities. For instance, if a router absolutely cannot risk communicating
|
||||||
|
directly with any untrusted peers, they can set up trusted links through
|
||||||
|
those peers, using them to both send and receive all of its messages.
|
||||||
|
Those hidden peers who want to be completely isolated would also refuse
|
||||||
|
to connect to peers who attempt to get them to (as demonstrated by the
|
||||||
|
garlic routing technique outlined before) - they can simply take the garlic
|
||||||
|
clove that has a request for delivery to a particular peer and tunnel
|
||||||
|
route that message out one of the hidden peer's trusted links with instructions
|
||||||
|
to forward it as requested.</p>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<h3 id="hashcash">Hashcash for routerIdentity, destination, and tunnel request</h3>
|
||||||
|
<p>Within the network, we will want some way to deter people from consuming
|
||||||
|
too many resources or from creating so many peers to mount a <a href="http://citeseer.ist.psu.edu/douceur02sybil.html">Sybil</a>
|
||||||
|
attack. Traditional techniques such as having a peer see who is requesting
|
||||||
|
a resource or running a peer aren't appropriate for use within I2P, as
|
||||||
|
doing so would compromise the anonymity of the system. Instead, we want
|
||||||
|
to make certain requests "expensive".</p>
|
||||||
|
<p><a href="http://www.hashcash.org/">Hashcash</a> is one technique that
|
||||||
|
we can use to anonymously increase the "cost" of doing certain activities,
|
||||||
|
such as creating a new router identity (done only once on installation),
|
||||||
|
creating a new destination (done only once when creating a service), or
|
||||||
|
requesting that a peer participate in a tunnel (done often, perhaps 2-300
|
||||||
|
times per hour). We don't know the "correct" cost of each type of certificate
|
||||||
|
yet, but with some research and experimentation, we could set a base level
|
||||||
|
that is sufficiently expensive while not an excessive burden for people
|
||||||
|
with few resources.</p>
|
||||||
|
<p>There are a few other algorithms that we can explore for making those
|
||||||
|
requests for resources "nonfree", and further research on that front is
|
||||||
|
appropriate.</p>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<h3 id="batching">Advanced tunnel operation (batching/mixing/throttling/padding)</h3>
|
||||||
|
<p>To powerful passive external observers as well as large colluding internal
|
||||||
|
observers, standard tunnel routing is vulnerable to traffic analysis attacks
|
||||||
|
- simply watching the size and frequency of messages being passed between
|
||||||
|
routers. To defend against these, we will want to essentially turn some
|
||||||
|
of the tunnels into its own mix cascade - delaying messages received at
|
||||||
|
the gateway and passing them in batches, reordering them as necessary,
|
||||||
|
and injecting dummy messages (indistinguishable from other "real" tunnel
|
||||||
|
messages by peers in the path). There has been a significant amount of
|
||||||
|
<a href="http://freehaven.net/doc/sync-batching/sync-batching.pdf">research</a>
|
||||||
|
on these algorithms that we can lean on prior to implementing the various
|
||||||
|
tunnel mixing strategies.</p>
|
||||||
|
<p>In addition to the anonymity aspects of more varied tunnel operation,
|
||||||
|
there is a functional dimension as well. Each peer only has a certain
|
||||||
|
amount of data they can route for the network, and to keep any particular
|
||||||
|
tunnel from consuming an unreasonable portion of that bandwidth, they
|
||||||
|
will want to include some throttles on the tunnel. For instance, a tunnel
|
||||||
|
may be configured to throttle itself after passing 600 messages (1 per
|
||||||
|
second), 2.4MB (4KBps), or exceeding some moving average (8KBps for the
|
||||||
|
last minute). Excess messages may be delayed or summarily dropped. With
|
||||||
|
this sort of throttling, peers can provide ATM-like QoS support for their
|
||||||
|
tunnels, refusing to agree to allocate more bandwidth than the peer has
|
||||||
|
available.</p>
|
||||||
|
<p>In addition, we may want to implement code to dynamically reroute tunnels
|
||||||
|
to avoid failed peers or to inject additional hops into the path. This
|
||||||
|
can be done by garlic routing a message to any particular peer in a tunnel
|
||||||
|
with instructions to redefine the next-hop in the tunnel.</p>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<h3 id="stop">Stop & go mix w/ garlics & tunnels</h3>
|
||||||
|
<p>Beyond the per-tunnel batching and mixing strategy, there are further
|
||||||
|
capabilities for protecting against powerful attackers, such as allowing
|
||||||
|
each step in a garlic routed path to define a delay or window in which
|
||||||
|
it should be forwarded on. This would enable protections against the long
|
||||||
|
term intersection attack, as a peer could send a message that looks perfectly
|
||||||
|
standard to most peers that pass it along, except at any peers where the
|
||||||
|
clove exposed includes delay instructions.</p>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
<h2 id="performance">Performance</h2>
|
||||||
|
<p>
|
||||||
|
Performance related improvements are listed on the
|
||||||
|
<a href="performance.html">Performance</a> page.
|
||||||
|
</p>
|
||||||
|
{% endblock %}
|
||||||
Reference in New Issue
Block a user