propagate from branch 'i2p.www' (head b16a6c7c7a1df52229bac767a4004e79ba81028d)

to branch 'i2p.www.revamp' (head 8acc895943066115be72a1b04e26e4cf21620e21)
This commit is contained in:
str4d
2013-07-31 08:17:26 +00:00
7 changed files with 136 additions and 44 deletions

View File

@ -96,8 +96,8 @@ user to root with "su" or by prefixing each command with "sudo").
</li>
<li>
{% trans %}Add the following entries to <code>/etc/apt/sources.list.d/i2p.list</code>{% endtrans %}<br />
<code>&nbsp;&nbsp;&nbsp; deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main <br />
&nbsp;&nbsp;&nbsp; deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main </code><br />
<code>&nbsp;&nbsp;&nbsp; deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main <br />
&nbsp;&nbsp;&nbsp; deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main </code><br />
</li>
<li>
{% trans %}Notify your package manager of the new PPA by entering{% endtrans %}<br />

View File

@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}Streaming Library{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}July 2013{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.6{% endblock %}
{% block accuratefor %}0.9.7{% endblock %}
{% block content %}
<h2>{% trans %}Overview{% endtrans %}</h2>
@ -134,10 +134,26 @@ Use the access list as a blacklist for incoming connections.
As of release {{ release }}.
{%- endtrans %}</td></tr>
<!--
<tr><td>i2p.streaming.alpha</td><td>0.125</td><td>
Ref. RFC 6298. Floating point value.
{% trans release='0.9.8' -%}
As of release {{ release }}.
{%- endtrans %}</td></tr>
-->
<tr><td>i2p.streaming.answerPings</td><td>true</td><td>{% trans -%}
Whether to respond to incoming pings
{%- endtrans %}</td></tr>
<!--
<tr><td>i2p.streaming.beta</td><td>0.25</td><td>
Ref. RFC 6298. Floating point value.
{% trans release='0.9.8' -%}
As of release {{ release }}.
{%- endtrans %}</td></tr>
-->
<tr><td>i2p.streaming.blacklist</td><td>null</td><td>{% trans -%}
Comma- or space-separated list of Base64 peer Hashes to be
blacklisted for incoming connections to ALL destinations in the context.
@ -198,12 +214,31 @@ The initial value of the resend delay field in the packet header, times 1000.
Not fully implemented; see below.
{%- endtrans %}</td></tr>
<tr><td>i2p.streaming.initialRTT</td><td>8000 </td><td>({% trans %}if no <a href="#sharing">sharing data</a> available{% endtrans %})</td></tr>
<tr><td>i2p.streaming.initialRTO</td><td>9000</td><td>{% trans -%}
Initial timeout
(if no <a href="#sharing">sharing data</a> available).
{%- endtrans %} {% trans release='0.9.8' -%}
As of release {{ release }}.
{%- endtrans %}</td></tr>
<tr><td>i2p.streaming.initialRTT</td><td>8000 </td><td>{% trans -%}
Initial round trip time estimate
(if no <a href="#sharing">sharing data</a> available).
Disabled as of release 0.9.8; uses actual RTT.
{%- endtrans %}</td></tr>
<tr><td>i2p.streaming.initialWindowSize</td><td>6</td><td>({% trans %}if no <a href="#sharing">sharing data</a> available{% endtrans %}) {% trans -%}
In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages.
{%- endtrans %}</td></tr>
<!--
<tr><td>i2p.streaming.kappa</td><td>4.0</td><td>
Ref. RFC 6298 "K". Floating point value.
{% trans release='0.9.8' -%}
As of release {{ release }}.
{%- endtrans %}</td></tr>
-->
<tr><td>i2p.streaming.maxConcurrentStreams</td><td>-1 </td><td>{% trans -%}
(0 or negative value means unlimited)
This is a total limit for incoming and outgoing combined.
@ -273,6 +308,27 @@ while in I2P, window sizes are in messages.
A higher number means slower growth.
{%- endtrans %}</td></tr>
<tr><td>i2p.streaming.tcbcache.rttDampening</td><td>0.75</td><td>{% trans -%}
Ref: RFC 2140. Floating point value.
May be set only via context properties, not connection options.
{%- endtrans %} {% trans release='0.9.8' -%}
As of release {{ release }}.
{%- endtrans %}</td></tr>
<tr><td>i2p.streaming.tcbcache.rttdevDampening</td><td>0.75</td><td>{% trans -%}
Ref: RFC 2140. Floating point value.
May be set only via context properties, not connection options.
{%- endtrans %} {% trans release='0.9.8' -%}
As of release {{ release }}.
{%- endtrans %}</td></tr>
<tr><td>i2p.streaming.tcbcache.wdwDampening</td><td>0.75</td><td>{% trans -%}
Ref: RFC 2140. Floating point value.
May be set only via context properties, not connection options.
{%- endtrans %} {% trans release='0.9.8' -%}
As of release {{ release }}.
{%- endtrans %}</td></tr>
<tr><td>i2p.streaming.writeTimeout</td><td>-1</td><td>{% trans -%}
How long to block on write/flush, in milliseconds. Negative means indefinitely.
{%- endtrans %}</td></tr>
@ -360,8 +416,8 @@ CLOSE packets may contain data as well.
<h3 id="sharing">{% trans %}Control Block Sharing{% endtrans %}</h3>
<p>{% trans -%}
The streaming lib supports "TCP" Control Block sharing.
This shares two important streaming lib parameters
(window size and round trip time)
This shares three important streaming lib parameters
(window size, round trip time, round trip time variance)
across connections to the same remote peer.
This is used for "temporal" sharing at connection open/close time,
not "ensemble" sharing during a connection (See
@ -370,7 +426,14 @@ There is a separate share per ConnectionManager (i.e. per local Destination)
so that there is no information leakage to other Destinations on the
same router.
The share data for a given peer expires after a few minutes.
{%- endtrans %}</p>
The following Control Block Sharing parameters can be set per router:
{%- endtrans %}
<ul>
<li>RTT_DAMPENING = 0.75</li>
<li>RTTDEV_DAMPENING = 0.75</li>
<li>WINDOW_DAMPENING = 0.75</li>
</ul>
</p>
<h3 id="other">{% trans %}Other Parameters{% endtrans %}</h3>
<p>{% trans -%}
@ -381,10 +444,12 @@ The following parameters are hardcoded, but may be of interest for analysis:
<li>MAX_RESEND_DELAY = 45*1000 (maximum RTO)
<li>MIN_WINDOW_SIZE = 1
<li>TREND_COUNT = 3
<li>RTT_DAMPENING = 0.875
<li>MIN_MESSAGE_SIZE = 512 (minimum MTU)
<li>INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
<li>INITIAL_TIMEOUT = 1.5 * initialRTT
<li>INITIAL_TIMEOUT (valid only before RTT is sampled) = 9000
<li>"alpha" ( RTT dampening factor as per RFC 6298 ) = 0.125</li>
<li>"beta" ( RTTDEV dampening factor as per RFC 6298 ) = 0.25</li>
<li>"K" ( RTDEV multiplier as per RFC 6298 ) = 4</li>
<li>PASSIVE_FLUSH_DELAY = 250
<li>Maximum RTT estimate: 60*1000
</ul>

View File

@ -381,6 +381,14 @@ certificate :: Certificate
total length: 387+ bytes
{% endhighlight %}
<h4>Notes</h4>
<ul><li>
The public key of the destination was used for the old i2cp-to-i2cp encryption
which was disabled in version 0.6, it is currently unused
except for the IV for LeaseSet encryption,
which is deprecated. The public key in the LeaseSet is used instead.
</li></ul>
<h4><a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/Destination.html">Javadoc</a></h4>
<h2 id="struct_Lease">Lease</h2>
@ -530,7 +538,7 @@ signature :: Signature
<ul>
<li>{% trans -%}
The public key of the destination was used for the old i2cp-to-i2cp encryption
which was disabled in version 0.6, it is currently unused?
which was disabled in version 0.6, it is currently unused.
{%- endtrans %}</li>
<li>{% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}

View File

@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}I2NP Specification{% endblock %}
{% block lastupdated %}June 2013{% endblock %}
{% block accuratefor %}0.9.6{% endblock %}
{% block lastupdated %}July 2013{% endblock %}
{% block accuratefor %}0.9.7{% endblock %}
{% block content %}
<h1>I2P Network Protocol (I2NP) Specification</h1>
<p>
@ -526,6 +526,12 @@ The key is the "real" hash of the RouterIdentity or Destination, NOT the routing
<h3 id="msg_DatabaseLookup">DatabaseLookup</h3>
<h4>Description</h4>
<p>
A request to look up an item in the network database.
The response is either a DatabaseStore or a DatabaseSearchReply.
</p>
<h4>Contents</h4>
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| SHA256 hash as the key to look up |
@ -729,7 +735,7 @@ from ::
</li><li>
The lookup key, peer hashes, and from hash are "real" hashes, NOT routing keys.
</li>
</ul>
@ -868,6 +874,12 @@ Expiration :: Date (8 bytes)
<h3 id="msg_TunnelData">TunnelData</h3>
<h4>Description</h4>
<p>
A message sent from a tunnel's gateway or participant to the next participant or endpoint.
The data is of fixed length, containing I2NP messages that are fragmented, batched, padded, and encrypted.
</p>
<h4>Contents</h4>
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| tunnnelID | data |
@ -900,6 +912,11 @@ data ::
<h3 id="msg_TunnelGateway">TunnelGateway</h3>
<h4>Description</h4>
<p>
Wraps another I2NP message to be sent into a tunnel at the tunnel's inbound gateway.
</p>
<h4>Contents</h4>
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+-//
| tunnelId | length | data...

View File

@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}SSU Protocol Specification{% endblock %}
{% block lastupdated %}June 2013{% endblock %}
{% block accuratefor %}0.9.6{% endblock %}
{% block lastupdated %}July 2013{% endblock %}
{% block accuratefor %}0.9.7{% endblock %}
{% block content %}
Note: IPv6 information is preliminary.
@ -154,18 +154,13 @@ bytes.</p>
<p>
All messages contain 0 or more bytes of padding.
Each message must be padded to a 16 byte boundary, as required by the <a href="{{ site_url('docs/how/cryptography') }}#AES">AES256 encryption layer</a>.
Currently, messages are not padded beyond the next 16 byte boundary.
The fixed-size tunnel messages of 1024 bytes (at a higher layer)
provide a significant amount of protection.
In the future, additional padding in the transport layer up to
a set of fixed packet sizes may be appropriate to further hide the data
fragmentation to external adversaries.
</p><p>
Through release 0.9.6, messages were only padded to the next 16 byte boundary,
Through release 0.9.7, messages were only padded to the next 16 byte boundary,
and messages not a multiple of 16 bytes could possibly be invalid.
As of release 0.9.7, messages may be padded to any length as long as the current MTU is honored.
Any extra 1-15 padding bytes beyond the last block of 16 bytes cannot be encrypted or decrypted and will be ignored.
However, the full length and all padding is included in the MAC calculation.
As of release 0.9.8, transmitted messages are not necessarily a multiple of 16 bytes.
The SessionConfirmed message is an exception, see below.
</p>
@ -392,7 +387,7 @@ bits 3-0: total identity fragments (F) 1-15</pre></li>
<td>sessionKey</td></tr>
</table>
<b>Fragment 0 through F-2</b>
<b>Fragment 0 through F-2 (if F &gt; 1):</b>
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
|info| cursize | |
@ -407,7 +402,7 @@ bits 3-0: total identity fragments (F) 1-15</pre></li>
+----+----+----+----+----+----+----+----+
{% endhighlight %}
<b>Fragment F-1:</b>
<b>Fragment F-1 (last or only fragment):</b>
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
|info| cursize | |
@ -422,6 +417,7 @@ bits 3-0: total identity fragments (F) 1-15</pre></li>
| arbitrary amount of uninterpreted |
| data, to 40 bytes prior to |
| end of the current packet |
| Packet length must be mult. of 16 |
+----+----+----+----+----+----+----+----+
| DSA signature |
+ +
@ -444,7 +440,9 @@ Typical size including header, in current implementation: 480 bytes
In the current implementation, the maximum fragment size is 512 bytes.
</li><li>
The typical <a href="{{ site_url('docs/spec/common-structures') }}#struct_RouterIdentity">Router Identity</a>
is 387 bytes, so no fragmentation is usually necessary.
is 387 bytes, so no fragmentation is ever necessary.
If new crypto extends the size of the RouterIdentity, the fragmentation scheme
must be tested carefully.
</li><li>
There is no mechanism for requesting or redelivering missing fragments.
</li><li>
@ -453,6 +451,10 @@ The total fragments field F must be set identically in all fragments.
See <a href="#keys">the Keys section above</a> for details on DSA signatures.
</li><li>
Signed-on time appears to be unused or unverified in the current implementation.
</li><li>
Since the signature is at the end, the padding in the last or only packet must pad the total packet to
a multiple of 16 bytes, or the signature will not get decrypted correctly.
This is different from all the other message types, where the padding is at the end.
</li></ul>

View File

@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}I2P Software Update Specification{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}May 2013{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.6{% endblock %}
{% block lastupdated %}{% trans %}July 2013{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.7{% endblock %}
{% block content %}
<h3>{% trans %}Overview{% endtrans %}</h3>
<p>{% trans -%}
@ -179,28 +179,28 @@ existing version checkers
<tr><td>
8 <td>unused
<tr><td>
9 <td>Version length (in bytes not chars, including padding)
9 <td>Signature type 0x00 = DSA-160, 0x01 = new algo
<tr><td>
10-11 <td>Signature length 40 (0x0028) = DSA-160
<tr><td>
12 <td>unused
<tr><td>
13 <td>Version length (in bytes not chars, including padding)
must be at least 16 (0x10) for compatibility
<tr><td>
10 <td>unused
14 <td>unused
<tr><td>
11 <td>Signer ID length (in bytes not chars)
15 <td>Signer ID length (in bytes not chars)
<tr><td>
12-19 <td>Compressed content length (not including header or sig)
<tr><td>
20 <td>unused
<tr><td>
21 <td>Compressed type 0x00 = zip
<tr><td>
22 <td>unused
<tr><td>
23 <td>Content type 0x00 = router w/o pack200, 0x01 = router w/ pack200, 0x02 = plugin
16-23 <td>Compressed content length (not including header or sig)
<tr><td>
24 <td>unused
<tr><td>
25 <td>Signature type 0x00 = DSA-160, 0x01 = new algo
25 <td>Compressed type 0x00 = zip
<tr><td>
26-27 <td>Signature length 40 (0x0028) = DSA-160
26 <td>unused
<tr><td>
27 <td>Content type 0x00 = router w/o pack200, 0x01 = router w/ pack200, 0x02 = plugin
<tr><td>
28-39 <td>unused
<tr><td>

View File

@ -64,8 +64,8 @@ Les étapes suivantes doivent être effectuées avec l'accès root (c.à d. en b
avec "su" ou en préfixant chaque commande avec "sudo").
<ol>
<li>Ajoutez les entrées suivantes à <code>/etc/apt/sources.list.d/i2p.list</code><br />
<code>&nbsp;&nbsp;&nbsp; deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main <br />
&nbsp;&nbsp;&nbsp; deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main </code><br />
<code>&nbsp;&nbsp;&nbsp; deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main <br />
&nbsp;&nbsp;&nbsp; deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main </code><br />
Ces deux lignes devraient fonctionner quelle que soit la version de Debian installée.</li>
<li>Ajouter la clé GPG de signature du dépôt avec la commande suivante:<br />
&nbsp;&nbsp;&nbsp;