propagate from branch 'i2p.www' (head b16a6c7c7a1df52229bac767a4004e79ba81028d)
to branch 'i2p.www.revamp' (head 8acc895943066115be72a1b04e26e4cf21620e21)
This commit is contained in:
@ -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> deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main <br />
|
||||
deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main </code><br />
|
||||
<code> deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main <br />
|
||||
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 />
|
||||
|
@ -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>
|
||||
|
@ -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') -%}
|
||||
|
@ -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...
|
||||
|
@ -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 > 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>
|
||||
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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> deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main <br />
|
||||
deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main </code><br />
|
||||
<code> deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main <br />
|
||||
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 />
|
||||
|
||||
|
Reference in New Issue
Block a user