From 6e9003be28b6498d3ee19e95b5dc12f0be85c6ec Mon Sep 17 00:00:00 2001
From: zzz <zzz@mail.i2p>
Date: Mon, 25 Jun 2012 19:15:48 +0000
Subject: [PATCH] - Proposed new I2CP options for 0.9.2 - I2NP Garlic
clove/message clarifications
---
www.i2p2/pages/i2cp.html | 28 ++++++++++++++++++++++++++++
www.i2p2/pages/i2np_spec.html | 23 +++++++++++++++++++++--
2 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/www.i2p2/pages/i2cp.html b/www.i2p2/pages/i2cp.html
index 32694efc1..c12d5133b 100644
--- a/www.i2p2/pages/i2cp.html
+++ b/www.i2p2/pages/i2cp.html
@@ -79,6 +79,7 @@ The following options are traditionally passed to the router via
a <a href="i2cp_spec.html#type_SessionConfig">SessionConfig</a> contained in a <a href="i2cp_spec.html#msg_CreateSession">CreateSession Message</a> or a <a href="i2cp_spec.html#msg_ReconfigureSession">ReconfigureSession Message</a>.
<p>
<table border=1>
+<tr><th colspan="5">Router-side Options</th></tr>
<tr><th>Option <th>Recommended Arguments <th>Allowable Range<th>Default<th>Description
<tr><td>inbound.quantity <td>number from 1 to 3 <td>1 to 16<td>2<td>Number of tunnels in.
Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are not
@@ -116,6 +117,32 @@ a <a href="i2cp_spec.html#type_SessionConfig">SessionConfig</a> contained in a <
If the client is running in the same JVM as a router, this option is not required.
<tr><td>i2cp.password<td>string<td> <td> <td>For authorization, if required by the router (since 0.8.2).
If the client is running in the same JVM as a router, this option is not required.
+<tr><td>crypto.tagsToSend<td> <td>1-128<td>40<td>Number of ElGamal/AES Session Tags to send at a time (since 0.9.2).
+ For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower.
+<tr><td>crypto.lowTagThreshold<td> <td>1-128<td>30<td>Minimum number of ElGamal/AES Session Tags before we send more (since 0.9.2).
+ Recommended: approximately tagsToSend * 2/3
+<tr><td>shouldBundleReplyInfo<td>true, false<td> <td>true<td>Set to false to disable ever bundling a reply LeaseSet (since 0.9.2).
+ For clients that do not publish their LeaseSet, this option must be true
+ for any reply to be possible. "true" is also recommended for multihomed servers
+ with long connection times.
+
+ <p> Setting to "false" may save significant outbound bandwidth, especially if
+ the client is configured with a large number of inbound tunnels (Leases).
+ If replies are still required, this may shift the bandwidth burden to
+ the far-end client and the floodfill.
+ There are several cases where "false" is may be appropriate:
+ <ul><li>
+ Unidirectional communication, no reply required
+ <li>
+ LeaseSet is published and higher reply latency is acceptable
+ <li>
+ LeaseSet is published, client is a "server", all connections are inbound
+ so the connecting far-end destination obviously has the leaseset already.
+ Connections are either short, or it is acceptable for latency on a long-lived
+ connection to temporarily increase while the other end re-fetches the LeaseSet
+ after expiration.
+ HTTP servers may fit these requirements.
+ </li></ul>
<tr><td>inbound.*<td> <td> <td> <td>Any other options prefixed with "inbound." are stored
in the "unknown options" properties of the inbound tunnel pool's settings.
<tr><td>outbound.*<td> <td> <td> <td>Any other options prefixed with "outbound." are stored
@@ -134,6 +161,7 @@ and will be interpreted if passed to the I2PSession via the I2PClient.createSess
The streaming lib should also pass these options through to I2CP.
<p>
<table border=1>
+<tr><th colspan="6">Client-side Options</th></tr>
<tr><th>Option <th>As Of Release<th>Recommended Arguments <th>Allowable Range<th>Default<th>Description
<tr><td>i2cp.tcp.host <td> <td> <td> <td>127.0.0.1<td>Router hostname.
If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
diff --git a/www.i2p2/pages/i2np_spec.html b/www.i2p2/pages/i2np_spec.html
index c3e04f85d..9a1a87fbc 100644
--- a/www.i2p2/pages/i2np_spec.html
+++ b/www.i2p2/pages/i2np_spec.html
@@ -2,7 +2,7 @@
{% block title %}I2NP Specification{% endblock %}
{% block content %}
-Updated January 2012, current as of router version 0.8.12
+Updated June 2012, current as of router version 0.9
<h1>I2P Network Protocol (I2NP) Specification</h1>
<p>
@@ -366,10 +366,17 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
See also the <a href="how_garlicrouting.html">garlic routing specification</a>.
<li>
See also <a href="tunnel_message_spec.html#delivery">Delivery Instructions definition</a>
+<li>
+ Maximum length is a function of the total length of all the cloves and the
+ maximum length of the GarlicMessage.
<li>
In the future, the certificate could possibly be used for a HashCash to "pay" for the routing.
<li>
- The message is always a DataMessage?
+ The message can be any I2NP message (including a GarlicMessage, although that is not used in practice).
+ The messages used in practice are DataMessage, DeliveryStatusMessage, and DatabaseStoreMessage.
+<li>
+ The Clove ID is generally set to a random number on transmit and is checked for
+ duplicates on receive (same message ID space as top-level Message IDs)
</ul>
@@ -785,12 +792,24 @@ Expiration :: Date (8 bytes)
<ul>
<li>
When unencrypted, data contains one or more <a href="#struct_GarlicClove">Garlic Cloves</a>.
+<li>
+ The AES encrypted block is padded to a minimum of 128 bytes; with the 32-byte Session Tag
+ the minimum size of the encrypted message is 160 bytes; with the 4 length bytes
+ the minimum size of the Garlic Message is 164 bytes.
<li>
Actual max length is less than 64 KB; see the <a href="i2np.html">I2NP Overview</a>.
<li>
See also the <a href="how_elgamalaes.html">ElGamal/AES specification</a>.
<li>
See also the <a href="how_garlicrouting.html">garlic routing specification</a>.
+<li>
+ The 128 byte minimum size of the AES encrypted block is not currently configurable,
+ however the minimum size of a DataMessage in a GarlicClove in a GarlicMessage, with
+ overhead, is 128 bytes anyway. A configurable option to increase the minimum size
+ may be added in the future.
+<li>
+ The message ID is generally set to a random number on transmit and
+ appears to be ignored on receive.
<li>
In the future, the certificate could possibly be used for a HashCash to "pay" for the routing.
</ul>
--
GitLab