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

spec updates

Browse Source
This commit is contained in:
zzz
2016-01-10 22:18:00 +00:00
parent 8d2b8cca7f
commit 4aba81a5ac
2 changed files with 53 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
i2p2www/pages/site/docs/spec/i2np.html
View File

@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}I2NP Specification{% endblock %}
{% block lastupdated %}January 2015{% endblock %}
{% block accuratefor %}0.9.17{% endblock %}
{% block lastupdated %}January 2016{% endblock %}
{% block accuratefor %}0.9.24{% endblock %}
{% block content %}
<p>
The I2P Network Protocol (I2NP),
@ -177,6 +177,9 @@ some places in the protocol stack.
However, for compatibility with older versions, checksum generation is still required.
It is a topic for future research to determine points in the protocol stack
where the far-end router's version is known and checksum generation can be disabled.
</li><li>
The short expiration is unsigned and will wrap around on Feb. 7, 2106.
As of that date, an offset must be added to get the correct time.
</li></ul>
@ -585,8 +588,18 @@ Total length: Typical length is:
<td><a href="#msg_VariableTunnelBuildReply">VariableTunnelBuildReply</a></td>
<td align="right">24</td>
</tr>
<tr>
<td><i>Reserved for experimental messages</i></td>
<td align="right">224 - 254</td>
</tr>
<tr>
<td><i>Reserved for future expansion</i></td>
<td align="right">255</td>
</tr>
</table>
<h3 id="msg_DatabaseStore">DatabaseStore</h3>
<h4>Description</h4>
<p>
@ -1130,6 +1143,17 @@ data ::
+----+----+----+----+----+-//-+
{% endhighlight %}
<h4>Notes</h4>
<ul>
<li>
This message contains no routing information and will never be sent "unwrapped".
It is only used inside Garlic messages.
</ul>
<h4>Definition</h4>
{% highlight lang='dataspec' %}
length ::
@ -1171,6 +1195,10 @@ total size: 8*528 = 4224 bytes
See also the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a>.
<li>
The I2NP message ID for this message must be set according to the tunnel creation specification.
<li>
While this message is rarely seen in today's network, having been replaced by the VariableTunnelBuild message,
it may still be used for very long tunnels, and has not been deprecated.
Routers must implement.
</ul>
@ -1185,6 +1213,10 @@ Same format as `TunnelBuildMessage`, with `BuildResponseRecord`s
See also the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a>.
<li>
The I2NP message ID for this message must be set according to the tunnel creation specification.
<li>
While this message is rarely seen in today's network, having been replaced by the VariableTunnelBuildReply message,
it may still be used for very long tunnels, and has not been deprecated.
Routers must implement.
</ul>
<h3 id="msg_VariableTunnelBuild">VariableTunnelBuild</h3>
@ -1215,6 +1247,8 @@ total size: 1+$num*528
See also the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a>.
<li>
The I2NP message ID for this message must be set according to the tunnel creation specification.
<li>
Typical number of records in today's network is 5.
</ul>
<h3 id="msg_VariableTunnelBuildReply">VariableTunnelBuildReply</h3>
@ -1238,6 +1272,8 @@ Same format as `VariableTunnelBuildMessage`, with `BuildResponseRecord`s.
See also the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a>.
<li>
The I2NP message ID for this message must be set according to the tunnel creation specification.
<li>
Typical number of records in today's network is 5.
</ul>

22
i2p2www/pages/site/docs/spec/tunnel-creation.html
View File

@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}Tunnel Creation{% endblock %}
{% block lastupdated %}September 2014{% endblock %}
{% block accuratefor %}0.9.15{% endblock %}
{% block lastupdated %}January 2016{% endblock %}
{% block accuratefor %}0.9.24{% endblock %}
{% block content %}
This page documents the current tunnel build implementation.
@ -130,9 +130,19 @@ records contained within it for one starting with their own identity
hash (trimmed to 16 bytes). It then decrypts the ElGamal block from
that record and retrieves the protected cleartext. At that point,
they make sure the tunnel request is not a duplicate by feeding the
AES-256 reply key into a bloom filter.
Duplicates or invalid requests
are dropped.</p>
AES-256 reply key into a Bloom filter.
Duplicates or invalid requests are dropped.
Records that are not stamped with the current hour,
or the previous hour if shortly after the top of the hour,
must be dropped.
For example, take the hour in the timestamp, convert to a full time,
then if it's more than 65 minutes behind or 5 minutes ahead of the
current time, it is invalid.
The Bloom filter must have a duration of at least one hour
(plus a few minutes, to allow for clock skew),
so that duplicate records in the current hour that are not rejected
by checking the hour timestamp in the record, will be rejected by the filter.
</p>
<p>After deciding whether they will agree to participate in the tunnel
or not, they replace the record that had contained the request with
@ -332,8 +342,6 @@ we should do so.
<li>
Further analysis of possible tagging and timing attacks described in the above notes.
</li><li>
The Bloom filter rotation time should be evaluated.
</li><li>
Use only VTBM; do not select old peers that don't support it.
</li><li>
The Build Request Record does not specify a tunnel lifetime or expiration;