diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html index 1a0ca422..dedc4248 100644 --- a/i2p2www/pages/downloads/list.html +++ b/i2p2www/pages/downloads/list.html @@ -4,13 +4,13 @@

{{ _('Download I2P') }}

{{ _('Dependency') }}

-

{% trans java='https://www.java.com/en/download/index.jsp', +

{% trans java='http://java.com/download/', openjdk='http://openjdk.java.net/install/', icedtea='http://icedtea.classpath.org/wiki/Main_Page' %} Java Runtime 1.5 or higher. -(Oracle/Sun Java Version 6, -OpenJDK 6, or -IcedTea6 +(Oracle Java Version 6/7, +OpenJDK 6/7, or +IcedTea6/7 recommended)
Determine your installed Java version here @@ -140,8 +140,12 @@ or type java -version at your command prompt.

- {% trans monotoneurl=site_url('get-involved/guides/new-developers'), i2pversion=ver() -%} - Alternately, you can fetch the source from monotone. + {% trans monotoneurl=site_url('get-involved/guides/new-developers'), + gitrepo='http://git.repo.i2p/w/i2p.i2p.git', + github='https://github.com/i2p/i2p.i2p', + i2pversion=ver() -%} + Alternately, you can fetch the source from monotone + or via Git from git.repo.i2p or Github.
Run (tar xjvf i2psource_{{ i2pversion }}.tar.bz2 ; cd i2p-{{ i2pversion }} ; ant pkg) then either run the GUI installer or headless install as above. diff --git a/i2p2www/pages/site/docs/how/network-database.html b/i2p2www/pages/site/docs/how/network-database.html index cd4ddc81..c9c9dad6 100644 --- a/i2p2www/pages/site/docs/how/network-database.html +++ b/i2p2www/pages/site/docs/how/network-database.html @@ -309,7 +309,15 @@ The SHA256 hash of the key being looked up or stored is XOR-ed with the hash of the router in question to determine closeness. A modification to this algorithm is done to increase the costs of Sybil attacks. Instead of the SHA256 hash of the key being looked up of stored, the SHA256 hash is taken -of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd). +of the 32-byte binary key appended with the UTC date represented as an 8-byte ASCII string yyyyMMdd, i.e. SHA256(key + yyyyMMdd). +This is called the "routing key", and it changes every day at midnight UTC. +The daily transformation of the DHT is sometimes called "keyspace rotation", +although it isn't strictly a rotation. +{%- endtrans %}

+ +

{% trans -%} +Routing keys are never sent on-the-wire in any I2NP message, they are only used locally for +determination of distance. {%- endtrans %}

@@ -332,6 +340,28 @@ This allows an initial response, and later responses, to be sent to an appropria without requiring any LeaseSet lookups, or requiring the communicating Destinations to have published LeaseSets at all. {%- endtrans %}

+

Floodfill Selection

+

{% trans -%} +The DatabaseStoreMessage should be sent to the floodfill that is closest +to the current routing key for the RouterInfo or LeaseSet being stored. +Currently, the closest floodfill is found by a search in the local database. +Even if that floodfill is not actually closest, it will flood it "closer" by +sending it to multiple other floodfills. +This provides a high degree of fault-tolerance. +{%- endtrans %}

+ +

{% trans -%} +In traditional Kademlia, a peer would do a "find-closest" search before inserting +an item in the DHT to the closest target. As the verify operation will tend to +discover closer floodfills if they are present, a router will quickly improve +its knowledge of the DHT "neighborhood" for the RouterInfo and LeaseSets it regularly publishes. +While I2NP does not define a "find-closest" message, if it becomes necessary, +a router may simply do an iterative search for a key with the least significant bit flipped +(i.e. key ^ 0x01) until no closer peers are received in the DatabaseSearchReplyMessages. +This ensures that the true closest peer will be found even if a more-distant peer had +the netdb item. +{%- endtrans %}

+

{% trans %}RouterInfo Storage to Floodfills{% endtrans %}

{% trans i2np=site_url('docs/protocol/i2np') -%} @@ -372,12 +402,15 @@ This message is sent back to one of the client's inbound tunnels. After a floodfill router receives a DatabaseStoreMessage containing a valid RouterInfo or LeaseSet which is newer than that previously stored in its local NetDb, it "floods" it. -To flood a NetDb entry, it looks up the 7 floodfill routers closest to the key -of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.) +To flood a NetDb entry, it looks up several (currently 4) floodfill routers closest to the routing key +of the NetDb entry. (The routing key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.) +By flooding to those closest to the key, not closest to itself, the floodfill ensures that the storage +gets to the right place, even if the storing router did not have good knowledge of the +DHT "neighborhood" for the routing key. {%- endtrans %}

{% trans i2np=site_url('docs/protocol/i2np') -%} -It then directly connects to each of the 7 peers +The floodfill then directly connects to each of those peers and sends it a I2NP DatabaseStoreMessage with a zero Reply Token. The message is not end-to-end garlic encrypted, as this is a direct connection, so there are no intervening routers @@ -658,6 +691,19 @@ to the target key, or to each other.

{% trans -%} This attack becomes more difficult as the network size grows. +However, recent research demonstrates that the keyspace rotation is not particularly effective. +An attacker can precompute numerous router hashes in advance, +and only a few routers are sufficient to "eclipse" a portion +of the keyspace within a half hour after rotation. +{%- endtrans %}

+ +

{% trans -%} +One consequence of daily keyspace rotation is that the distributed network database +may become unreliable for a few minutes after the rotation -- +lookups will fail because the new "closest" router has not received a store yet. +The extent of the issue, and methods for mitigation +(for example netdb "handoffs" at midnight) +are a topic for further study. {%- endtrans %}

{% trans -%} diff --git a/i2p2www/pages/site/docs/protocol/i2np.html b/i2p2www/pages/site/docs/protocol/i2np.html index 02ea85b2..fadf69ae 100644 --- a/i2p2www/pages/site/docs/protocol/i2np.html +++ b/i2p2www/pages/site/docs/protocol/i2np.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}I2NP{% endblock %} -{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} -{% block accuratefor %}0.8{% endblock %} +{% block lastupdated %}{% trans %}June 2013{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.6{% endblock %} {% block content %}

{% trans %}I2P Network Protocol{% endtrans %} (I2NP)

{% trans -%} @@ -20,16 +20,11 @@ through multiple hops to the ultimate destination. Priority is only used locally at the origin, i.e. when queuing for outbound delivery. {%- endtrans %}

-

{% trans -%} -Both the NTCP and UDP transports implement priority transmission, -but in quite different manners. -UDP has complex code with queues for each priority, however it treats -messages with priorities 400-499, for example, the same. -(The priority queues are 100, 200, 300, 400, 500, and 1000) -These are global queues for all peers. -NTCP has a trivial linear search for the highest priority within -each buffer for a particular peer. -This is much less effective. +

{% trans outnetmessage='http://docs.i2p-projekt.de/javadoc/net/i2p/router/OutNetMessage.html' -%} +The priorities listed below may not be current and are subject to change. +See the OutNetMessage Javadocs +for the current priority settings. +Priority queueing implementation may vary. {%- endtrans %}

{% trans %}Message Format{% endtrans %}

@@ -104,13 +99,8 @@ which is wrapped in a DataMessage. DatabaseLookupMessage 2   -100/400 -{% trans -%} -400 normally; 100 if from HarvesterJob and sent directly; -400 for a router lookup -{%- endtrans %} - - +500 +{% trans %}May vary{% endtrans %} DatabaseSearchReplyMessage 3 @@ -126,9 +116,9 @@ three floodfill routers are returned. DatabaseStoreMessage 1 {% trans %}Varies{% endtrans %} -100/400 +460 {% trans -%} -Usually 100 (why?) +Priority may vary. Size is 898 bytes for a typical 2-lease leaseSet. RouterInfo structures are compressed, and size varies; however there is a continuing effort to reduce the amount of data published in a RouterInfo @@ -140,8 +130,10 @@ as we approach release 1.0. DataMessage 20 4 - 62080 -400 - +425 +{% trans -%} +Priority may vary on a per-destination basis +{%- endtrans %} @@ -167,8 +159,8 @@ but when unwrapped, given a priority of 100 by the forwarding router TunnelBuildMessage 21 4224 -300/500 -{% trans %}Usually 500 (why?){% endtrans %} +500 + @@ -203,7 +195,7 @@ TunnelGatewayMessage VariableTunnelBuildMessage 23 1057 - 4225 -300/500 +500 {% trans %}Shorter TunnelBuildMessage as of 0.7.12{% endtrans %} diff --git a/i2p2www/pages/site/docs/spec/i2np.html b/i2p2www/pages/site/docs/spec/i2np.html index 6b771248..7533d2a5 100644 --- a/i2p2www/pages/site/docs/spec/i2np.html +++ b/i2p2www/pages/site/docs/spec/i2np.html @@ -519,6 +519,8 @@ data:

Notes

@@ -622,28 +624,33 @@ excludedPeers :: reply_key :: 32 byte SessionKey - only included if encryptionFlag == 1 + only included if encryptionFlag == 1, only as of release 0.9.7 tags :: 1 byte Integer valid range: 1-32 (typically 1) the number of reply tags that follow - only included if encryptionFlag == 1 + only included if encryptionFlag == 1, only as of release 0.9.7 reply_tags :: one or more 32 byte SessionTags (typically one) - only included if encryptionFlag == 1 + only included if encryptionFlag == 1, only as of release 0.9.7 {% endhighlight %}

Notes

@@ -700,12 +707,11 @@ key :: num :: 1 byte Integer - number of peer hashes that follow + number of peer hashes that follow, 0-255 -peer_hash :: +peer_hash ($num entries) :: 32 bytes - SHA256 of the RouterInfo that the other router thinks are close to the key - $num entries + SHA256 of the RouterIdentity that the other router thinks is close to the key from :: 32 bytes @@ -713,9 +719,19 @@ from :: {% endhighlight %}

Notes

-

+