From d91c1d363babaf62f2f2f09d88772bf7436bf3c5 Mon Sep 17 00:00:00 2001
From: zzz <zzz@mail.i2p>
Date: Thu, 4 Sep 2014 13:25:12 +0000
Subject: [PATCH] I2CP version table Build message request time enforcement
---
i2p2www/pages/site/docs/spec/i2cp.html | 69 ++++++++++++++++++-
.../pages/site/docs/spec/tunnel-creation.html | 15 ++--
2 files changed, 73 insertions(+), 11 deletions(-)
diff --git a/i2p2www/pages/site/docs/spec/i2cp.html b/i2p2www/pages/site/docs/spec/i2cp.html
index 30a243555..7f6ce13be 100644
--- a/i2p2www/pages/site/docs/spec/i2cp.html
+++ b/i2p2www/pages/site/docs/spec/i2cp.html
@@ -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>
diff --git a/i2p2www/pages/site/docs/spec/tunnel-creation.html b/i2p2www/pages/site/docs/spec/tunnel-creation.html
index ad6e76f54..21c5afa3d 100644
--- a/i2p2www/pages/site/docs/spec/tunnel-creation.html
+++ b/i2p2www/pages/site/docs/spec/tunnel-creation.html
@@ -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.
--
GitLab