From f61d78acbeeff50640907215da5a931c5be1837d Mon Sep 17 00:00:00 2001 From: kytv Date: Wed, 17 Jul 2013 13:34:28 +0000 Subject: [PATCH 1/9] switch to precise for wheezy --- www.i2p2/pages/debian.html | 4 ++-- www.i2p2/pages/debian_fr.html | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/www.i2p2/pages/debian.html b/www.i2p2/pages/debian.html index 22c9fbca..966008e6 100644 --- a/www.i2p2/pages/debian.html +++ b/www.i2p2/pages/debian.html @@ -53,8 +53,8 @@ user to root with "su" or by prefixing each command with "sudo"). You'll have output like the following if the command was successful:
    
  • Add the following entries to /etc/apt/sources.list.d/i2p.list
    -     deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main
    -    deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main

    +     deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main
    +    deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main

  • Notify your package manager of the new PPA by entering
        apt-get update
    This command will retrieve the latest list of software from every diff --git a/www.i2p2/pages/debian_fr.html b/www.i2p2/pages/debian_fr.html index f38181c2..b2f8e993 100644 --- a/www.i2p2/pages/debian_fr.html +++ b/www.i2p2/pages/debian_fr.html @@ -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").
    1. Ajoutez les entrées suivantes à /etc/apt/sources.list.d/i2p.list
      -     deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main
      -    deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu raring main

      +     deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main
      +    deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main

      Ces deux lignes devraient fonctionner quelle que soit la version de Debian installée.
    2. Ajouter la clé GPG de signature du dépôt avec la commande suivante:
          From 5172b25febb274b33bc6ffad6d7a8f38150446f6 Mon Sep 17 00:00:00 2001 From: zab2 Date: Thu, 18 Jul 2013 14:22:55 +0000 Subject: [PATCH 2/9] Document streaming changes relevant to ticket #979 --- www.i2p2/pages/streaming.html | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/www.i2p2/pages/streaming.html b/www.i2p2/pages/streaming.html index fa8e3bf8..a7e4c408 100644 --- a/www.i2p2/pages/streaming.html +++ b/www.i2p2/pages/streaming.html @@ -398,8 +398,8 @@ CLOSE packets may contain data as well.

      Control Block Sharing

      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 @@ -408,6 +408,12 @@ 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. +The following Control Block Sharing parameters can be set per router: +

        +
      • RTT_DAMPENING = 0.75
      • +
      • RTTDEV_DAMPENING = 0.75
      • +
      • WINDOW_DAMPENING = 0.75
      • +

      Other Parameters

      @@ -417,13 +423,18 @@ The following parameters are hardcoded, but may be of interest for analysis:
    3. MAX_RESEND_DELAY = 45*1000 (maximum RTO)
    4. MIN_WINDOW_SIZE = 1
    5. TREND_COUNT = 3 -
    6. RTT_DAMPENING = 0.875
    7. MIN_MESSAGE_SIZE = 512 (minimum MTU)
    8. INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2) -
    9. INITIAL_TIMEOUT = 1.5 * initialRTT +
    10. INITIAL_TIMEOUT (valid only before RTT is sampled) = 12000
    11. PASSIVE_FLUSH_DELAY = 250
    12. Maximum RTT estimate: 60*1000 +The following parameters can be set per individual connection: +
        +
      • "alpha" ( RTT dampening factor as per RFC 6298 ) = 0.125
      • +
      • "beta" ( RTTDEV dampening factor as per RFC 6298 ) = 0.25
      • +
      • "K" ( RTDEV multiplier as per RFC 6298 ) = 4
      • +

      History

      From 25585b897b6caac8f8e25286cc1f5fb70385e130 Mon Sep 17 00:00:00 2001 From: zab2 Date: Thu, 18 Jul 2013 23:02:42 +0000 Subject: [PATCH 3/9] update docs for hard-coding of tcp consants --- www.i2p2/pages/streaming.html | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/www.i2p2/pages/streaming.html b/www.i2p2/pages/streaming.html index a7e4c408..a650d685 100644 --- a/www.i2p2/pages/streaming.html +++ b/www.i2p2/pages/streaming.html @@ -426,14 +426,11 @@ The following parameters are hardcoded, but may be of interest for analysis:
    13. MIN_MESSAGE_SIZE = 512 (minimum MTU)
    14. INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
    15. INITIAL_TIMEOUT (valid only before RTT is sampled) = 12000 -
    16. PASSIVE_FLUSH_DELAY = 250 -
    17. Maximum RTT estimate: 60*1000 - -The following parameters can be set per individual connection: -
      • "alpha" ( RTT dampening factor as per RFC 6298 ) = 0.125
      • "beta" ( RTTDEV dampening factor as per RFC 6298 ) = 0.25
      • "K" ( RTDEV multiplier as per RFC 6298 ) = 4
      • +
      • PASSIVE_FLUSH_DELAY = 250 +
      • Maximum RTT estimate: 60*1000

      From f7ca83297743617c7e48915c8e7288748b1d23a1 Mon Sep 17 00:00:00 2001 From: zzz Date: Fri, 19 Jul 2013 21:27:39 +0000 Subject: [PATCH 4/9] new streaming options --- www.i2p2/pages/streaming.html | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/www.i2p2/pages/streaming.html b/www.i2p2/pages/streaming.html index a650d685..987f9322 100644 --- a/www.i2p2/pages/streaming.html +++ b/www.i2p2/pages/streaming.html @@ -124,7 +124,11 @@ See the javadocs for details. i2cp.enableBlackListfalse Use the access list as a blacklist for incoming connections As of release 0.7.13. +i2p.streaming.alpha0.125 + Ref. RFC 6298. Floating point value. As of release 0.9.8. i2p.streaming.answerPingstrueWhether to respond to incoming pings +i2p.streaming.beta0.25 + Ref. RFC 6298. Floating point value. As of release 0.9.8. i2p.streaming.blacklistnullComma- or space-separated list of Base64 peer Hashes to be blacklisted for incoming connections to ALL destinations in the context. This option must be set in the context properties, NOT in the createManager() options argument. @@ -163,9 +167,18 @@ See the javadocs for details. The initial value of the resend delay field in the packet header, times 1000. Not fully implemented; see below. -i2p.streaming.initialRTT8000 (if no sharing data available) +i2p.streaming.initialRTO12000 + Initial timeout + (if no sharing data available). + As of release 0.9.8. +i2p.streaming.initialRTT8000 + Initial round trip time estimate + (if no sharing data available). + Disabled as of release 0.9.8; uses actual RTT. i2p.streaming.initialWindowSize6(if no sharing data available) In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages. +i2p.streaming.kappa4.0 + Ref. RFC 6298 "K". Floating point value. As of release 0.9.8. i2p.streaming.maxConcurrentStreams-1 (0 or negative value means unlimited) This is a total limit for incoming and outgoing combined. i2p.streaming.maxConnsPerMinute0 Incoming connection limit (per peer; 0 means disabled) @@ -198,6 +211,12 @@ See the javadocs for details. of 1/(factor). In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages. A higher number means slower growth. +i2p.streaming.tcbcache.rttDampening0.75 + Ref: RFC 2140. Floating point value. As of release 0.9.8. May be set only via context properties, not connection options. +i2p.streaming.tcbcache.rttdevDampening0.75 + Ref: RFC 2140. Floating point value. As of release 0.9.8. May be set only via context properties, not connection options. +i2p.streaming.tcbcache.wdwDampening0.75 + Ref: RFC 2140. Floating point value. As of release 0.9.8. May be set only via context properties, not connection options. i2p.streaming.writeTimeout-1 How long to block on write/flush, in milliseconds. Negative means indefinitely. From 99af28f31a3f6ae77b05137888ea29b3a5a4d264 Mon Sep 17 00:00:00 2001 From: zab2 Date: Tue, 23 Jul 2013 14:21:27 +0000 Subject: [PATCH 5/9] update streaming docs with new value of initial RTO --- www.i2p2/pages/streaming.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/www.i2p2/pages/streaming.html b/www.i2p2/pages/streaming.html index 987f9322..d725667f 100644 --- a/www.i2p2/pages/streaming.html +++ b/www.i2p2/pages/streaming.html @@ -167,7 +167,7 @@ See the javadocs for details. The initial value of the resend delay field in the packet header, times 1000. Not fully implemented; see below. -i2p.streaming.initialRTO12000 +i2p.streaming.initialRTO9000 Initial timeout (if no sharing data available). As of release 0.9.8. @@ -444,7 +444,7 @@ The following parameters are hardcoded, but may be of interest for analysis:
    18. TREND_COUNT = 3
    19. MIN_MESSAGE_SIZE = 512 (minimum MTU)
    20. INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2) -
    21. INITIAL_TIMEOUT (valid only before RTT is sampled) = 12000 +
    22. INITIAL_TIMEOUT (valid only before RTT is sampled) = 9000
    23. "alpha" ( RTT dampening factor as per RFC 6298 ) = 0.125
    24. "beta" ( RTTDEV dampening factor as per RFC 6298 ) = 0.25
    25. "K" ( RTDEV multiplier as per RFC 6298 ) = 4
    26. From b63cf4ca0f37b0a4d9e003ea11cf03084b752779 Mon Sep 17 00:00:00 2001 From: zzz Date: Wed, 24 Jul 2013 12:52:26 +0000 Subject: [PATCH 6/9] - Add descriptions to some I2NP messages - Comment out streaming options added in error (actually hardcoded) --- www.i2p2/pages/i2np_spec.html | 21 +++++++++++++++++++-- www.i2p2/pages/streaming.html | 8 +++++++- 2 files changed, 26 insertions(+), 3 deletions(-) diff --git a/www.i2p2/pages/i2np_spec.html b/www.i2p2/pages/i2np_spec.html index b77af16c..8af25f0a 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 June 2013, current as of router version 0.9.6 +Updated July 2013, current as of router version 0.9.7

      I2P Network Protocol (I2NP) Specification

      @@ -541,6 +541,12 @@ The key is the "real" hash of the RouterIdentity or Destination, NOT the routing

      DatabaseLookup

      +

      Description

      +

      + A request to look up an item in the network database. + The response is either a DatabaseStore or a DatabaseSearchReply. +

      +

      Contents

       {% filter escape %}
       +----+----+----+----+----+----+----+----+
      @@ -752,7 +758,7 @@ from:
       
    27. The lookup key, peer hashes, and from hash are "real" hashes, NOT routing keys.
    28. - + @@ -899,6 +905,12 @@ Expiration :: Date (8 bytes)

      TunnelData

      +

      Description

      +

      + 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. +

      +

      Contents

       {% filter escape %}
       +----+----+----+----+----+----+----+----+
      @@ -935,6 +947,11 @@ data:
       
       
       

      TunnelGateway

      +

      Description

      +

      + Wraps another I2NP message to be sent into a tunnel at the tunnel's inbound gateway. +

      +

      Contents

       {% filter escape %}
       +----+----+----+----+----+----+--\\----+
      diff --git a/www.i2p2/pages/streaming.html b/www.i2p2/pages/streaming.html
      index d725667f..e83eff99 100644
      --- a/www.i2p2/pages/streaming.html
      +++ b/www.i2p2/pages/streaming.html
      @@ -1,7 +1,7 @@
       {% extends "_layout.html" %}
       {% block title %}Streaming Library{% endblock %}
       {% block content %}
      -Updated July 2013, current as of router version 0.9.6
      +Updated July 2013, current as of router version 0.9.7
       

      Overview

      @@ -124,11 +124,15 @@ See the javadocs for details. i2cp.enableBlackListfalse Use the access list as a blacklist for incoming connections As of release 0.7.13. + i2p.streaming.answerPingstrueWhether to respond to incoming pings + i2p.streaming.blacklistnullComma- or space-separated list of Base64 peer Hashes to be blacklisted for incoming connections to ALL destinations in the context. This option must be set in the context properties, NOT in the createManager() options argument. @@ -177,8 +181,10 @@ See the javadocs for details. Disabled as of release 0.9.8; uses actual RTT. i2p.streaming.initialWindowSize6(if no sharing data available) In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages. + i2p.streaming.maxConcurrentStreams-1 (0 or negative value means unlimited) This is a total limit for incoming and outgoing combined. i2p.streaming.maxConnsPerMinute0 Incoming connection limit (per peer; 0 means disabled) From 3a876ba9304f26e23d4e9254ae17b4fe738dd23f Mon Sep 17 00:00:00 2001 From: zzz Date: Thu, 25 Jul 2013 19:04:23 +0000 Subject: [PATCH 7/9] UDP updates --- www.i2p2/pages/udp_spec.html | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/www.i2p2/pages/udp_spec.html b/www.i2p2/pages/udp_spec.html index 07b55272..75c35fd6 100644 --- a/www.i2p2/pages/udp_spec.html +++ b/www.i2p2/pages/udp_spec.html @@ -2,7 +2,7 @@ {% block title %}SSU Protocol Specification{% endblock %} {% block content %} -Updated June 2013 for release 0.9.6. IPv6 information is preliminary. +Updated July 2013 for release 0.9.7. IPv6 information is preliminary.

      See the SSU page for an overview of the SSU transport. @@ -152,18 +152,13 @@ bytes.

      All messages contain 0 or more bytes of padding. Each message must be padded to a 16 byte boundary, as required by the AES256 encryption layer. -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. -

      -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.

      @@ -391,7 +386,7 @@ bits 3-0: total identity fragments (F) 1-15
      - Fragment 0 through F-2
      + Fragment 0 through F-2 (if F > 1):
        +----+----+----+----+----+----+----+----+
        |info| cursize |                        |
        +----+----+----+                        |
      @@ -404,7 +399,7 @@ bits 3-0: total identity fragments (F) 1-15
      | data | +----+----+----+----+----+----+----+----+ - Fragment F-1: + Fragment F-1 (last or only fragment): +----+----+----+----+----+----+----+----+ |info| cursize | | +----+----+----+ | @@ -418,6 +413,7 @@ bits 3-0: total identity fragments (F) 1-15
      | arbitrary amount of uninterpreted | | data, to 40 bytes prior to | | end of the current packet | + | Packet length must be mult. of 16 | +----+----+----+----+----+----+----+----+ | DSA signature | + + @@ -440,7 +436,9 @@ Typical size including header, in current implementation: 480 bytes In the current implementation, the maximum fragment size is 512 bytes.
    29. The typical Router Identity -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.
    30. There is no mechanism for requesting or redelivering missing fragments.
    31. @@ -449,6 +447,10 @@ The total fragments field F must be set identically in all fragments. See the Keys section above for details on DSA signatures.
    32. Signed-on time appears to be unused or unverified in the current implementation. +
    33. +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.
    34. From 80791c8329726bc1f1f4661b8689967df53f536b Mon Sep 17 00:00:00 2001 From: zzz Date: Mon, 29 Jul 2013 13:48:29 +0000 Subject: [PATCH 8/9] su3 format update --- www.i2p2/pages/updates.html | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/www.i2p2/pages/updates.html b/www.i2p2/pages/updates.html index 815136f1..0b43b758 100644 --- a/www.i2p2/pages/updates.html +++ b/www.i2p2/pages/updates.html @@ -1,7 +1,7 @@ {% extends "_layout.html" %} {% block title %}I2P Software Update Specification{% endblock %} {% block content %} -Page last updated May 2013, current as of router version 0.9.6 +Page last updated July 2013, current as of router version 0.9.7

      Overview

      I2P uses a simple, yet secure, system for automated software update. @@ -145,28 +145,28 @@ Specification: 8 unused -9 Version length (in bytes not chars, including padding) +9 Signature type 0x00 = DSA-160, 0x01 = new algo + +10-11 Signature length 40 (0x0028) = DSA-160 + +12 unused + +13 Version length (in bytes not chars, including padding) must be at least 16 (0x10) for compatibility -10 unused +14 unused -11 Signer ID length (in bytes not chars) +15 Signer ID length (in bytes not chars) -12-19 Compressed content length (not including header or sig) - -20 unused - -21 Compressed type 0x00 = zip - -22 unused - -23 Content type 0x00 = router w/o pack200, 0x01 = router w/ pack200, 0x02 = plugin +16-23 Compressed content length (not including header or sig) 24 unused -25 Signature type 0x00 = DSA-160, 0x01 = new algo +25 Compressed type 0x00 = zip -26-27 Signature length 40 (0x0028) = DSA-160 +26 unused + +27 Content type 0x00 = router w/o pack200, 0x01 = router w/ pack200, 0x02 = plugin 28-39 unused From 5c2a99b62e49a11e62e6788c644e4c72e69a8d25 Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 30 Jul 2013 20:48:11 +0000 Subject: [PATCH 9/9] more info on dest pubkey --- www.i2p2/pages/common_structures_spec.html | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/www.i2p2/pages/common_structures_spec.html b/www.i2p2/pages/common_structures_spec.html index 6794119d..6e07d4a0 100644 --- a/www.i2p2/pages/common_structures_spec.html +++ b/www.i2p2/pages/common_structures_spec.html @@ -366,6 +366,14 @@ Total length: 387+ bytes {% endfilter %}

      +

      Notes

      +
      • +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. +
      +

      Javadoc

      Lease

      @@ -516,7 +524,7 @@ signature :: Signature

      Notes

      • 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.
      • The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption. It is currently generated anew at every router startup, it is not persistent.