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

I2CP version table

Browse Source 
Build message request time enforcement
This commit is contained in:
zzz
2014-09-04 13:25:12 +00:00
parent 463051b98b
commit d91c1d363b
2 changed files with 73 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
i2p2www/pages/site/docs/spec/i2cp.html
View File

@@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}I2CP Specification{% endblock %}
{% block lastupdated %}June 2014{% endblock %}
{% block accuratefor %}0.9.13{% endblock %}
{% block lastupdated %}September 2014{% endblock %}
{% block accuratefor %}0.9.15{% endblock %}
{% block content %}
<h2>Overview</h2>
<p>
@@ -135,7 +135,70 @@ As of release 0.8.7, the two parties' protocol version strings are exchanged in
Going forward, clients may use this information to communicate correctly with old routers.
Clients and routers should not send messages that are unsupported by the other side,
as they generally disconnect the session upon reception of an unsupported message.
</p>
</p><p>
The exchanged version information is the "core" version or I2CP protocol version,
and is not necessarily the router version.
</p><p>
A basic summary of the I2CP protocol versions is as follows. For details, see below.
<table border=1>
<tr>
<th>Version</th>
<th>Required I2CP Features</th>
</tr><tr>
<td align="center">0.9.16</td>
<td align="left">Authentication, if enabled, is enforced before all other messages</td>
</td>
</tr><tr>
<td align="center">0.9.11</td>
<td align="left">Host Lookup and Host Reply messages supported<br>
Authentication mapping in Get Date message supported
</td>
</tr><tr>
<td align="center">0.9.7</td>
<td align="left">Request Variable Lease Set message supported</td>
</tr><tr>
<td align="center">0.9.5</td>
<td align="left">Additional Message Status codes defined</td>
</tr><tr>
<td align="center">0.9.4</td>
<td align="left">Send Message nonce=0 allowed<br>
Fast receive mode is the default
</td>
</tr><tr>
<td align="center">0.9.2</td>
<td align="left">Send Message Expires flag tag bits supported</td>
</tr><tr>
<td align="center">0.8.7</td>
<td align="left">Set Date version string included.<br>
If not present, the router is version 0.8.6 or older.
</td>
</tr><tr>
<td align="center">0.8.4</td>
<td align="left">Send Message Expires flag bits supported</td>
</tr><tr>
<td align="center">0.8.3</td>
<td align="left">Dest Lookup and Get Bandwidth messages supported in standard session<br>
Concurrent Dest Lookup messages supported
</td>
</tr><tr>
<td align="center">0.8.1</td>
<td align="left">i2cp.messageReliability=none supported</td>
</tr><tr>
<td align="center">0.7.2</td>
<td align="left">Get Bandwidth Limits and Bandwidth Limits messages supported</td>
</tr><tr>
<td align="center">0.7.1</td>
<td align="left">Send Message Expires message supported<br>
Reconfigure Session message supported
</td>
</tr><tr>
<td align="center">0.7</td>
<td align="left">Dest Lookup and Dest Reply messages supported</td>
</tr><tr>
<td align="center">0.6.5 or lower</td>
<td align="left">All messages and features not listed above</td>
</tr>
</table>
<h2 id="structures">Common structures</h2>

15
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 %}June 2013{% endblock %}
{% block accuratefor %}0.9.6{% endblock %}
{% block lastupdated %}September 2014{% endblock %}
{% block accuratefor %}0.9.15{% endblock %}
{% block content %}
This page documents the current tunnel build implementation.
@@ -63,7 +63,7 @@ Also specified in the
bytes 136-167: AES-256 reply key
bytes 168-183: AES-256 reply IV
byte 184: flags
bytes 185-188: request time (in hours since the epoch)
bytes 185-188: request time (in hours since the epoch, rounded down)
bytes 189-192: next message ID
bytes 193-221: uninterpreted / random padding</pre>
@@ -300,6 +300,10 @@ window would work (though doing that would require a high degree of
clock synchronization). Alternately, perhaps individual hops could
inject a random delay before forwarding on the request?</li>
<li>Are there any nonfatal methods of tagging the request?</li>
<li>
The timestamp with a one-hour resolution is used for replay prevention.
The constraint was not enforced until release 0.9.16.
</li>
</ul>
<h2 id="ref">References</h2>
@@ -326,11 +330,6 @@ This is to be researched and verified.
If it is possible to use the remaining record without compromising anonymity,
we should do so.
<li>
The usefulness of a timestamp with an hour resolution is questionable,
and the constraint is not currently enforced.
Therefore the request time field is unused.
This should be researched and possibly changed.
<li>
Further analysis of possible tagging and timing attacks described in the above notes.
</li><li>
The Bloom filter rotation time should be evaluated.