This commit is contained in:
zzz
2010-08-26 14:10:37 +00:00
parent 40a886e09d
commit c8ca33bac1
6 changed files with 40 additions and 12 deletions

View File

@@ -4,7 +4,11 @@
Updated August 2010, current as of router version 0.8
<h1>Data types Specification</h1>
<p>
This document describes some data types common to all I2P protocols, like I2NP, I2CP, NTCP, etc.
This document describes some data types common to all I2P protocols, like
<a href="i2np.html">I2NP</a>,
<a href="i2cp.html">I2CP</a>,
<a href="udp.html">SSU</a>,
etc.
</p>
<h2 id="type_Integer">Integer</h2>
@@ -380,7 +384,7 @@ Total length: 387+ bytes
| end_date |
+----+----+----+----+----+----+----+----+
tunnel_gw :: RouterIdentity
tunnel_gw :: RouterIdentity of the tunnel gateway
length -> >= 387 bytes
tunnel_id :: TunnelId
@@ -391,6 +395,13 @@ end_date :: Date
{% endfilter %}
</pre>
<h4>Notes</h4>
<ul>
<li>
Could this be optimized to include the Hash of the Router Identity instead of the full Router Identtity?
</li></ul>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/Lease.html">Javadoc</a></h4>
<h2 id="struct_LeaseSet">LeaseSet</h2>
@@ -543,6 +554,15 @@ options :: Mapping
{% endfilter %}
</pre>
<h4>Notes</h4>
<ul>
<li>
Cost is typically 5 or 6 for SSU, and 10 or 11 for NTCP.
</li><li>
Expiration is currently unused, always null (all zeroes))
</li></ul>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterAddress.html">Javadoc</a></h4>
<h2 id="struct_RouterInfo">RouterInfo</h2>
@@ -640,4 +660,8 @@ The signature may be verified using the signing public key of the router_ident.
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterInfo.html">Javadoc</a></h4>
<h2 id="struct_DeliveryInstructions">Delivery Instructions</h2>
Defined in the <a href="tunnel_message_spec.html#delivery">Tunnel Message Specification</a>.
{% endblock %}

View File

@@ -277,6 +277,9 @@ Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange
using
<a href="#elgamal">the same shared prime and generator as specified above for ElGamal</a>,
followed by symmetric AES encryption as described above.
This provides
<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">perfect forward secrecy</a>
on the transport links.
</p>
<H3><a name="tcp">NTCP connections</a></H3>

View File

@@ -107,8 +107,8 @@ exploiting transport latency/throughput tradeoffs, and branching data through re
<h3>Tunnel Building and Routing</h3>
<p>
In I2P, tunnels are unidirectional, and we require two tunnels
(one outbound and one inbound) for end-to-end communication in each direction.
In I2P, tunnels are unidirectional. Each party builds two tunnels,
one for outbound and one for inbound traffic.
Therefore, four tunnels are required for a single round-trip message and reply.
</p><p>
Tunnels are built, and then used, with layered encryption.

View File

@@ -298,6 +298,10 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
</ul>
<h3 id="struct_DeliveryInstructions">Delivery Instructions</h3>
Defined in the <a href="tunnel_message_spec.html#delivery">Tunnel Message Specification</a>.
<h2 id="messages">Messages</h2>
<table border=1>
<tr>

View File

@@ -424,6 +424,9 @@ to create a limited number of message sizes.
</li><li>
Memory utilization (including that of the kernel) for NTCP should be compared to that for SSU.
</li><li>
Can the establishment messages be randomly padded somehow, to frustrate
identification of I2P traffic based on initial packet sizes?
</li><li>
Review and possibly disable 'check connection'
</li></ul>
</p>

View File

@@ -101,17 +101,11 @@ bandwidth, latency, and CPU usage.</p>
<h2>Full streaming protocol improvements</h2>
<ul>
<li>Some algorithms to share congestion and RTT information across streams
(per target destination? per source destination? for all of the local destinations?).</li>
<li>Further optimizations for interactive streams (most of the focus in the
current implementation is on bulk streams).</li>
<li>More explicit use of the new streaming lib's features in I2PTunnel and
the SAM bridge, reducing the per-tunnel overhead.</li>
<li>Perhaps re-enable the interactive stream profile (the
current implementation only uses the bulk stream profile).</li>
<li>Client level bandwidth limiting (in either or both directions on a stream,
or possibly shared across multiple streams). This would be in addition to
the router's overall bandwidth limiting, of course.</li>
<li>Various controls for destinations to throttle how many streams they accept
or create (we have some basic code, but largely disabled)<./li>
<li>Access control lists (only allowing streams to or from certain other known
destinations).</li>
<li>Web controls and monitoring the health of the various streams, as well