+ {{ title }}
+ +
+
@@ -36,9 +37,9 @@
Tech-intro AnwendungenEntwickeln
-
API+
API Lizenzen-
Trac
+ Trac
Syndie
Links
@@ -73,9 +74,9 @@
Introduzione Tecnica ApplicazioniSviluppo
-
API+
API Licenze-
Trac
+ Trac
Syndie
Links
@@ -107,11 +108,11 @@
Documentation
Hoe werkt het? Tech intro-
Applicaties+
Apps ontwikkelenDevelopment
-
API+
API Licenties-
Trac
+ Trac
Syndie
Links
@@ -149,9 +150,9 @@
技术内幕 程序开发开发
-
API+
API 许可证-
Trac
+ Trac
Syndie
链接
@@ -189,9 +190,9 @@
Intro technique Applications pour I2PDéveloppement
-
API+
API Licences-
Trac
+ Trac
Syndie
Liens
@@ -230,9 +231,9 @@
ПриложенияРазработка
-
API+
API Лицензии-
Багтрекер
+ Багтрекер
Syndie
Ссылки
@@ -244,6 +245,47 @@
Impressum
+{% elif lang == "cs" %} +
Vítejte v síti I2P
+
Stáhnout
+ + +
Novinky
+
Poznámky k vydání+ +
Projektové schůzky+
Plán rozvoje+
Seznam úkolů+ +
Co je I2P
+
FAQ+
Diskuzní fóra+
Projektové odměny+
Zapojte se+
Dotace!+ +
Tým I2P+
Síň slávy+ +
Dokumentace
+
Jak to funguje?+
Technický úvod+
Aplikace+ +
Vývoj
+
API+
Licence+
Trac
+
+Syndie
+
Odkazy
+
Kopie +
Kopie 2 +
Kopie 3 +
Bezpečné stránky +
Bezpečná kopie +
+
Tiráž
{% else %}
Welcome to I2P
@@ -268,11 +310,11 @@
Documentation
How does it work? Tech intro-
Applications+
App DevDevelopment
-
API+
API Licenses-
Trac
+ Trac
Syndie
Links
diff --git a/www.i2p2/pages/api_de.html b/www.i2p2/pages/api_de.html index e343319f..b1372dcc 100644 --- a/www.i2p2/pages/api_de.html +++ b/www.i2p2/pages/api_de.html @@ -6,8 +6,8 @@ Anwendungen nach Ideen über die 4 Grundprotokolle durchlesen, um eine Idee zum Schreiben einer Anwendung auf I2P zu bekommen:
- Core I2P API Javadoc
- (internal link)
+
- Core I2P API Javadoc + (internal link)
- BOB
- SAM und SAM V2
- ministreaming diff --git a/www.i2p2/pages/api_it.html b/www.i2p2/pages/api_it.html index 65e543ac..e1a5ba1e 100644 --- a/www.i2p2/pages/api_it.html +++ b/www.i2p2/pages/api_it.html @@ -5,8 +5,8 @@
- Core I2P API Javadoc - (Link Interni) +
- Core I2P API Javadoc + (Link Interni)
- BOB
- SAM, SAM V2 and SAM V3
- Ministreaming diff --git a/www.i2p2/pages/applications.html b/www.i2p2/pages/applications.html index 3036b8f0..ee2d431f 100644 --- a/www.i2p2/pages/applications.html +++ b/www.i2p2/pages/applications.html @@ -3,78 +3,93 @@ {% block content %}
- Why write I2P-specific code? +
- Important concepts +
- Development options +
- Start developing - a simple guide +
- + Creating a large amount of I2PTunnel instances consumes a non-trivial amount of resources, + which is problematic for distributed applications (a new tunnel is required for each peer). + +
- + General network protocols often send a lot of additional data that can be used to identify users. + Programming specifically for I2P allows the creation of a network protocol + that does not leak such information, keeping users anonymous and secure. + +
- + Network protocols designed for use on the regular internet can be inefficient + on I2P, which is a network with a much higher latency. + +
- I2P destinations are ugly and large - behind the scenes, they contain a 2048bit ElGamal +
-
+
+I2P destinations are ugly and large - behind the scenes, they contain a 2048bit ElGamal public key for encryption, a 1024bit DSA public key for signing, and a variable size -certificate (currently this is the null type, but may contain proof of work, blinded -data, or other information to increase the 'cost' of a destination in an effort to fight -Sybil).
There are existing ways to refer to these large and ugly destinations by short +certificate, which may contain proof of work or blinded data. +
++There are existing ways to refer to these large and ugly destinations by short and pretty names (e.g. "irc.duck.i2p"), but at the moment those techniques do not guarantee globally uniqueness (since they're stored locally at each person's machine as "hosts.txt") -and the current mechanism is not especially scalable nor secure (updates to one host file is +and the current mechanism is not especially scalable nor secure (updates to one host file are manually managed within Monotone, and as such, anyone with commit rights on the repository can change the destinations). There may be some secure, human readable, scalable, and globally unique, naming system some day, but applications shouldn't depend upon it being in place, since there are those who don't think such a beast is possible. Further information on the naming system is available. +
- Repliable datagrams +
- Raw datagrams +
- $I2P/lib/streaming.jar: the streaming library itself. +
- $I2P/lib/mstreaming.jar: the ministreaming library is used as the base for the streaming library. +
- $I2P/lib/i2p.jar: some standard I2P classes (like the Destination class) are very convenient when developing. +
Programmatori di applicazioni controllate prima di tutto la guida su come creare un applicazione per farsi un idea dei quattro protocolli base per creare un applicazione che funzioni su I2P:
-
-
Application Development Guide
-Why write I2P specific code?
+Contents
+-
+
Using mihi's I2PTunnel application, you can hook up -application instances and have them talk to each other over standard TCP -sockets. In plain client-server scenarios, this is an effective technique for -many simple protocols, but for distributed systems where each peer may contact -a number of other peers (instead of just a single server), or for systems that -expose TCP or IP information within the communication protocols themselves, -there are problems.
+Why write I2P-specific code?
-With I2PTunnel, you need to explicitly instantiate an I2PTunnel for each peer -you want to contact - if you are building a distributed instant messenger -application, that means you need to have each peer create an I2PTunnel 'client' -pointing at each peer it wants to contact, plus a single I2PTunnel 'server' to -receive other peer's connections. This process can of course be automated, but -there are nontrivial overheads involved in running more than just a few I2PTunnel -instances. In addition, with many protocols you will need to force everyone to -use the same set of ports for all peers - e.g. if you want to reliably run DCC -chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port -10003 is Charlie, and so on, since the protocol includes TCP/IP specific information -(host and port).
- -Applications that are designed to work with I2P can take advantage of its -built in data security and optional pseudonymous authentication. All data sent -over the network is transparently end to end encrypted (not even the routers -get the cleartext), and any application using the streaming or datagram -functionality has all of that data authenticated by the sending destination's -public key. As an aside, environments where anonymity instead of pseudonymity -is required are trivially accommodated by either using the I2CP directly, SAM RAW -sessions, or by simply creating a new sending destination whenever needed).
- -Another important thing to remember is that I2P is simply a communication -system - what data is sent and what is done with that data is outside of its scope. -Applications that are used on top of I2P should be carefully sanitized of any -insecure or identifying data or protocols (hostnames, port numbers, time zone, -character set, etc). This in and of itself is often a daunting task, as -analyzing the safety of a system that has had anonymity and security strapped on to -it is no small feat, giving significant incentive to learn from the experiences of -the traditional application base, but design the application and its communication -protocols with I2P's anonymity and security in mind.
- -There are also efficiency considerations to review when determining how to -interact on top of I2P. The streaming library and things built on top of it -operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP) -are strictly message based (like UDP or in some instances raw IP). The important -distinction is that with I2P, communication is operating over a long fat network - -each end to end message will have nontrivial latencies, but may contain payloads -of up to 32KB. An application that needs a simple request and response can get rid -of any state and drop the latency incurred by the startup and teardown handshakes -by using (best effort) datagrams without having to worry about MTU detection or -fragmentation of messages under 32KB. +
+ There are multiple ways to use applications in I2P. + Using I2PTunnel, + you can use regular applications without needing to program explicit I2P support. + This is very effective for client-server scenario's, + where you need to connect to a single website. + You can simply create a tunnel using I2PTunnel to connect to that website, as shown in Figure 1. +
++ If your application is distributed, it will require connections to a large amount of peers. + Using I2PTunnel, you will need to create a new tunnel for each peer you want to contact, + as shown in Figure 2. + This process can of course be automated, but running a lot of I2PTunnel instances creates a large amount of overhead. + In addition, with many protocols you will need to force everyone to + use the same set of ports for all peers - e.g. if you want to reliably run DCC + chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port + 10003 is Charlie, and so on, since the protocol includes TCP/IP specific information + (host and port). +
++ General network applications often send a lot of additional data that could be used to identify users. + Hostnames, port numbers, time zones, character sets, etc. are often sent without informing the user. + As such, designing the network protocol specifically with anonymity in mind + can avoid compromising user identities. +
++ There are also efficiency considerations to review when determining how to + interact on top of I2P. The streaming library and things built on top of it + operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP) + are strictly message based (like UDP or in some instances raw IP). The important + distinction is that with I2P, communication is operating over a long fat network - + each end to end message will have nontrivial latencies, but may contain payloads + of up to 32KB. An application that needs a simple request and response can get rid + of any state and drop the latency incurred by the startup and teardown handshakes + by using (best effort) datagrams without having to worry about MTU detection or + fragmentation of messages under 32KB. +
+
+ + Figure 1: Creating a server-client connection using I2PTunnel only requires creating a single tunnel. +
+
+ + Figure 2: Setting up connections for a peer-to-peer applications requires a very large amount of tunnels. +
+
+ In summary, a number of reasons to write I2P-specific code: +
-
+
-The ministreaming library itself uses a -functional but inefficient scheme for dealing with reliable and in order delivery -by requiring the equivalent of an ACK after each message which must traverse the -network end to end again (though there are plans for improving this with a more -efficient and robust algorithm). With ministreaming, an application -that uses one of the I2P message oriented protocols could in some situations get -substantially better performance. -However with the full streaming library now the standard interface, -it isn't clear if that is still the case. + Applications written in Java and accessible/runnable + using an HTML interface via the standard webapps/app.war + may be considered for inclusion in the i2p distribution.
--Applications written in Java and accessible/runnable -using an HTML interface via the standard webapps/app.war -may be considered for inclusion in the i2p distribution. -
- -Important ideas
+Important concepts
There are a few changes that require adjusting to when using I2P:
@@ -93,26 +108,30 @@ location of the end point signed as if there were universal deployment of DNSSEC to another (or with some special software, it can even operate on multiple routers at once). This is quite different from the TCP or UDP world where a single end point (port) must stay on a single host. -Anonymity and confidentiality
A useful thing to remember is that I2P has transparent end to end encryption -and authentication for all data passed over the network - if Bob sends Alice's destination, +and authentication for all data passed over the network - if Bob sends to Alice's destination, only Alice's destination can receive it, and if Bob is using the datagrams or streaming library, Alice knows for certain that Bob's destination is the one who sent the data.
@@ -132,7 +151,7 @@ UDP, applications don't need to worry about MTU detection and can simply fire of entire request or response, allowing them to transparently operate in I2P as a UDP-like application without having to write fragmentation, resends, etc. -Integration techniques
+Development options
There are several means of sending data over I2P, each with their own pros and cons. The streaming lib is the recommended interface, used by the majority of I2P applications. @@ -141,8 +160,7 @@ The streaming lib is the recommended interface, used by the majority of I2P appl
Streaming Lib
The full streaming library is now the standard -interface. Ministreaming and SAM are not recommended. -The streaming lib interface is similar to the ministreaming lib interface described below. +interface. It allows programming using TCP-like sockets, as explained in the Streaming development guide.
SAM, SAM V2, SAM V3
@@ -185,43 +203,280 @@ their own unique I2P destination and their own set of tunnels, keys, etc.Ministreaming
Not recommended
-For applications written in Java, the simplest way to go is to use the libraries that the SAM -bridge and I2PTunnel applications use. The streaming functionality is exposed in the 'ministreaming' -library, which is centered on the -I2PSocketManager, -the I2PSocket, and the -I2PServerSocket.
++It was possible to write I2P applications in Java using the ministreaming library. +However, the Streaming library has superceded this, and provides better functionality. +
Datagrams
Not recommended
-For applications that want to use repliable datagrams, they can be built with the -I2PDatagramMaker -and parsed on the receiving side by the -I2PDatagramDissector. -In turn, these are sent and received through an - -I2PSession.
- -Applications that want to use raw datagrams simply send directly through the I2PSession's -sendMessage(...) -method, receiving notification of available messages through the -I2PSessionListener and -then fetching those messages by calling -receiveMessage(...).
+The Datagram library allows sending UDP-like packets. +It's possible to use: +-
+
I2CP
-Not easy
+Not recommended
I2CP itself is a language independent protocol, but to implement an I2CP library in something other than Java there is a significant amount of code to be written (encryption routines, object marshalling, asynchronous message handling, etc). While someone could write an I2CP library in C or something else, it would most likely be more useful to use the C SAM library instead. -I2CP also needs documentation.
Web Applications
I2P comes with the Jetty webserver, and configuring to use the Apache server instead is straightforward. Any standard web app technology should work. +Start developing - a simple guide
+Developing using I2P requires a working I2P installation and a development environment of your own choice. +If you are using Java, you can start development with the streaming library or datagram library. +Using another programming language, SAM or BOB can be used. + +Developing with the streaming library
+ ++ Development using the streaming library requires the following libraries in your classpath: +
-
+
+ Network communication requires the usage of I2P network sockets. + To demonstrate this, we will create an application where a client can send text messages to a server, + who will print the messages and send them back to the client. In other words, the server will function as an echo. +
++ We will start by initializing the server application. This requires getting an I2PSocketManager + and creating an I2PServerSocket. + In addition, we will ask the I2PSocketManager for an I2PSession, so we can find out the Destination we use. +
+
+ package i2p.echoserver;
+
+ import net.i2p.client.I2PSession;
+ import net.i2p.client.streaming.I2PServerSocket;
+ import net.i2p.client.streaming.I2PSocketManager;
+ import net.i2p.client.streaming.I2PSocketManagerFactory;
+
+ public class Main {
+
+ public static void main(String[] args) {
+ //Initialize application
+ I2PSocketManager manager = I2PSocketManagerFactory.createManager();
+ I2PServerSocket serverSocket = manager.getServerSocket();
+ I2PSession session = manager.getSession();
+ System.out.println(session.getMyDestination().toBase64()); //Print the base64 string, the regular string would look like garbage.
+ //The additional main method code comes here...
+ }
+
+ }
+
+ +
+ Once we have an I2PServerSocket, we can create I2PSocket instances to accept connections from clients. + In this example, we will create a single I2PSocket instance, that can only handle one client at a time. + A real server would have to be able to handle multiple clients. + To do this, multiple I2PSocket instances would have to be created, each in separate threads. + Once we have created the I2PSocket instance, we read data, print it and send it back to the client. + The bold code is the new code we add. +
++ package i2p.echoserver; + ++
+ import java.io.IOException; + import java.io.InputStream; + import java.io.OutputStream; + import java.net.ConnectException; + import java.net.SocketTimeoutException; + import net.i2p.I2PException; + import net.i2p.client.streaming.I2PSocket; + import net.i2p.util.I2PThread; ++
+ import net.i2p.client.I2PSession;
+ import net.i2p.client.streaming.I2PServerSocket;
+ import net.i2p.client.streaming.I2PSocketManager;
+ import net.i2p.client.streaming.I2PSocketManagerFactory;
+
+ public class Main {
+
+ public static void main(String[] args) {
+ I2PSocketManager manager = I2PSocketManagerFactory.createManager();
+ I2PServerSocket serverSocket = manager.getServerSocket();
+ I2PSession session = manager.getSession();
+ System.out.println(session.getMyDestination().toBase64()); //Print the base64 string, the regular string would look like garbage.
+
+
+
+ //Create socket to handle clients
+ I2PThread t = new I2PThread(new ClientHandler(serverSocket));
+ t.setName("clienthandler1");
+ t.setDaemon(false);
+ t.start();
+ }
+
+ private static class ClientHandler implements Runnable {
+
+ public ClientHandler(I2PServerSocket socket) {
+ this.socket = socket;
+ }
+
+ public void run() {
+ while(true) {
+ try {
+ I2PSocket sock = this.socket.accept();
+ if(sock != null) {
+ BufferedReader br = new BufferedReader(new InputStreamReader(sock.getInputStream())); //Receive from clients
+ BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(sock.getOutputStream())); //Send to clients
+ String line = br.readLine();
+ if(line != null) {
+ System.out.println("Received from client: " + line);
+ bw.write(line);
+ bw.flush(); //Flush to make sure everything got sent
+ }
+ sock.close();
+ }
+ } catch (I2PException ex) {
+ System.out.println("General I2P exception!");
+ } catch (ConnectException ex) {
+ System.out.println("Error connecting!");
+ } catch (SocketTimeoutException ex) {
+ System.out.println("Timeout!");
+ } catch (IOException ex) {
+ System.out.println("General read/write-exception!");
+ }
+ }
+ }
+
+ private I2PServerSocket socket;
+
+ }
+
+ }
+
+ +
+ When you run the above server code, it should print something like this (but without the line endings, it should just be + one huge block of characters): +
+ y17s~L3H9q5xuIyyynyWahAuj6Jeg5VC~Klu9YPquQvD4vlgzmxn4yy~5Z0zVvKJiS2Lk + poPIcB3r9EbFYkz1mzzE3RYY~XFyPTaFQY8omDv49nltI2VCQ5cx7gAt~y4LdWqkyk3au + 6HdfYSLr45zxzWRGZnTXQay9HPuYcHysZHJP1lY28QsPz36DHr6IZ0vwMENQsnQ5rhq20 + jkB3iheYJeuO7MpL~1xrjgKzteirkCNHvXN8PjxNmxe-pj3QgOiow-R9rEYKyPAyGd2pe + qMD-J12CGfB6MlnmH5qPHGdZ13bUuebHiyZ1jqSprWL-SVIPcynAxD2Uu85ynxnx31Fth + nxFMk07vvggBrLM2Sw82pxNjKDbtO8reawe3cyksIXBBkuobOZdyOxp3NT~x6aLOxwkEq + BOF6kbxV7NPRPnivbNekd1E1GUq08ltDPVMO1pKJuGMsFyZC4Q~osZ8nI59ryouXgn97Q + 5ZDEO8-Iazx50~yUQTRgLMOTC5hqnAAAA ++ This is the base64-representation of the server Destination. The client will need this string to reach the server. + +
+ Now, we will create the client application. Again, a number of steps are required for initialization. + Again, we will need to start by getting an I2PSocketManager. + We won't use an I2PSession and an I2PServerSocket this time. + Instead, we will use the server Destination string to start our connection. + We will ask the user for the Destination string, and create an I2PSocket using this string. + Once we have an I2PSocket, we can start sending and receiving data to and from the server. +
+
+ package i2p.echoclient;
+
+ import java.io.BufferedReader;
+ import java.io.BufferedWriter;
+ import java.io.IOException;
+ import java.io.InputStreamReader;
+ import java.io.InterruptedIOException;
+ import java.io.OutputStream;
+ import java.io.OutputStreamWriter;
+ import java.net.ConnectException;
+ import java.net.NoRouteToHostException;
+ import java.util.logging.Level;
+ import java.util.logging.Logger;
+ import net.i2p.I2PException;
+ import net.i2p.client.streaming.I2PSocket;
+ import net.i2p.client.streaming.I2PSocketManager;
+ import net.i2p.client.streaming.I2PSocketManagerFactory;
+ import net.i2p.data.DataFormatException;
+ import net.i2p.data.Destination;
+
+ public class Main {
+
+ public static void main(String[] args) {
+ I2PSocketManager manager = I2PSocketManagerFactory.createManager();
+ System.out.println("Please enter a Destination:");
+ BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
+ String destinationString = null;
+ try {
+ destinationString = br.readLine();
+ } catch (IOException ex) {
+ System.out.println("Failed to get a Destination string.");
+ return;
+ }
+ Destination destination = null;
+ try {
+ destination = new Destination(destinationString);
+ } catch (DataFormatException ex) {
+ System.out.println("Destination string incorrectly formatted.");
+ return;
+ }
+ I2PSocket socket = null;
+ try {
+ socket = manager.connect(destination);
+ } catch (I2PException ex) {
+ System.out.println("General I2P exception occurred!");
+ } catch (ConnectException ex) {
+ System.out.println("Failed to connect!");
+ } catch (NoRouteToHostException ex) {
+ System.out.println("Couldn't find host!");
+ } catch (InterruptedIOException ex) {
+ System.out.println("Sending/receiving was interrupted!");
+ }
+ try {
+ //Write to server
+ BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
+ bw.write("Hello I2P!\n");
+ bw.flush(); //Flush to make sure everything got sent
+ //Read from server
+ BufferedReader br2 = new BufferedReader(new InputStreamReader(socket.getInputStream()));
+ String s = null;
+ while ((s = br2.readLine()) != null) {
+ System.out.println("Received from server: " + s);
+ }
+ socket.close();
+ } catch (IOException ex) {
+ System.out.println("Error occurred while sending/receiving!");
+ }
+ }
+
+ }
+
+ +
+ Finally, you can run both the server and the client application. + First, start the server application. It will print a Destination string (like shown above). + Next, start the client application. When it requests a Destination string, you can enter the string printed by the server. + The client will then send 'Hello I2P!' (along with a newline) to the server, who will print the message and send it back to the client. +
++ Congratulations, you have successfully communicated over I2P! +
+Existing Applications in Development
Contact us if you would like to help.-
diff --git a/www.i2p2/pages/common_structures_spec.html b/www.i2p2/pages/common_structures_spec.html
index 498fe775..4e8f6567 100644
--- a/www.i2p2/pages/common_structures_spec.html
+++ b/www.i2p2/pages/common_structures_spec.html
@@ -4,7 +4,11 @@
Updated August 2010, current as of router version 0.8
- +For Router Identities, the Certificate is always NULL, no others are currently implemented. +
- +For Garlic Cloves, the Certificate is always NULL, no others are currently implemented. +
- +For Garlic Messages, the Certificate is always NULL, no others are currently implemented. +
- +For Destinations, the Certificate may be non-NULL, +however non-NULL certs are not widely used, and any checking is left to the application-level. +
Data types Specification
- This document describes some data types common to all I2P protocols, like I2NP, I2CP, NTCP, etc. + This document describes some data types common to all I2P protocols, like + I2NP, + I2CP, + SSU, + etc.
Integer
@@ -54,26 +58,28 @@ Deprecated - unusedPublicKey
Description
- This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in the appropriate spec. + This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in + the cryptography specification.
Contents
256 bytes
-Javadoc
+Javadoc
PrivateKey
Description
- This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in the appropriate spec. + This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in + the cryptography specification.
Contents
256 bytes
-Javadoc
+Javadoc
SessionKey
Description
@@ -85,7 +91,7 @@ Deprecated - unused 32 bytes -Javadoc
+Javadoc
SigningPublicKey
Description
@@ -97,7 +103,7 @@ Deprecated - unused 128 bytes -Javadoc
+Javadoc
SigningPrivateKey
Description
@@ -109,7 +115,7 @@ Deprecated - unused 20 bytes -Javadoc
+Javadoc
Signature
Description
@@ -121,7 +127,7 @@ Deprecated - unused 40 bytes -Javadoc
+Javadoc
Hash
Description
@@ -133,7 +139,7 @@ Deprecated - unused 32 bytes -Javadoc
+Javadoc
Session Tag
Description
@@ -145,19 +151,19 @@ Deprecated - unused 32 bytes -Javadoc
+Javadoc
TunnelId
Description
- Defines an identifier that is unique within a particular set of routers for a tunnel. + Defines an identifier that is unique to each router in a tunnel.
Contents
4 byte Integer
-Javadoc
+Javadoc
Certificate
Description
@@ -191,7 +197,20 @@ payload :: data {% endfilter %} -Javadoc
+Notes
+-
+
Javadoc
Mapping
@@ -239,7 +258,7 @@ For example, UTF-8 strings in a RouterInfo options mapping in a I2NP Database Store Message will be corrupted.Javadoc
+Javadoc
@@ -292,7 +311,7 @@ Total length: 387+ bytesNotes
The certificate for a RouterIdentity is currently unused and is always NULL. -Javadoc
+Javadoc
Destination
Description
@@ -338,7 +357,7 @@ Total length: 387+ bytes {% endfilter %} -Javadoc
+Javadoc
Lease
Description
@@ -365,7 +384,7 @@ Total length: 387+ bytes | end_date | +----+----+----+----+----+----+----+----+ -tunnel_gw :: RouterIdentity +tunnel_gw :: RouterIdentity of the tunnel gateway length -> >= 387 bytes tunnel_id :: TunnelId @@ -376,7 +395,14 @@ end_date :: Date {% endfilter %} -Javadoc
+Notes
+-
+
- +Could this be optimized to include the Hash of the Router Identity instead of the full Router Identtity? +
Javadoc
LeaseSet
Description
@@ -456,7 +482,7 @@ end_date :: Date +----+----+----+----+----+----+----+----+ destination :: Destination - length -> >= 397 bytes + length -> >= 387 bytes encryption_key :: PublicKey length -> 256 bytes @@ -466,6 +492,7 @@ signing_key :: SigningPublicKey num :: Integer length -> 1 byte + value: 0 <= num <= 6 leases :: [Lease] length -> >= $num*399 bytes @@ -482,7 +509,7 @@ The signature may be verified using the signing public key of the destination. The signing_key is currently unused. It was intended for LeaseSet revocation, which is unimplemented. -Javadoc
+Javadoc
@@ -527,7 +554,16 @@ options :: Mapping {% endfilter %} -Javadoc
+Notes
+-
+
- +Cost is typically 5 or 6 for SSU, and 10 or 11 for NTCP. +
- +Expiration is currently unused, always null (all zeroes)) +
Javadoc
RouterInfo
Description
@@ -622,6 +658,10 @@ This is currently unused. It was intended for a form of restricted routes, whichThe signature may be verified using the signing public key of the router_ident. -
Javadoc
+Javadoc
+ + +Delivery Instructions
+Defined in the Tunnel Message Specification. {% endblock %} diff --git a/www.i2p2/pages/datagrams.html b/www.i2p2/pages/datagrams.html index 726095ea..396c6776 100644 --- a/www.i2p2/pages/datagrams.html +++ b/www.i2p2/pages/datagrams.html @@ -21,7 +21,7 @@ either protocol may be carried by either transport.Application Guide
Applications written in Java may use the -datagram API, +datagram API, while applications in other languages can use SAM's datagram support. There is also limited support in i2ptunnel in the SOCKS proxy, @@ -66,11 +66,26 @@ indicate datagram type.
The protocols and ports may be set in I2CP's -I2PSession API, +I2PSession API, as implemented in -I2PSessionMuxedImpl. +I2PSessionMuxedImpl.
+Data Integrity
+Data integrity is assured by the gzip CRC-32 checksum implemented in +the I2CP layer. +There is no checksum field in the datagram protocol. + +Packet Encapsulation
+Each datagram is sent through I2P as a single message (or as an individual clove in a +Garlic Message). +Message encapsulation is implemented in the underlying +I2CP, +I2NP, and +tunnel messagelayers. +There is no packet delimiter mechanism or length field in the datagram protocol. + +Specification
Non-Repliable Datagrams
diff --git a/www.i2p2/pages/download_cs.html b/www.i2p2/pages/download_cs.html new file mode 100644 index 00000000..e7b49c91 --- /dev/null +++ b/www.i2p2/pages/download_cs.html @@ -0,0 +1,106 @@ +{% extends "_layout_cs.html" %} +{% block title %}Stáhnout{% endblock %} +{% block content %} +Stáhnout I2P
+Požadavky pro instalaci
+Sun Java 1.5 nebo novější (doporučená verze Sun Java 1.6), nebo ekvivalentní JRE. ++Svou aktuální nainstalovanou verzi Javy si můžete ověřit na této stránce +nebo z příkazové řádky pomocí příkazu java -version +
Nová instalace
+-
+
- Grafický instalační program:
+ i2pinstall_0.8.exe + (SHA256 +d14ef28ffff7ef95e5627d7bbeac8f5aad57c82b89d2071383787f2124152ca9 + sig)
+ Pod Windows: stáhněte soubor a spusťte ho. Pod ostatními operačními systémy soubor spustíte + z příkazové řádky příkazemjava -jar i2pinstall_0.8.exe+
+ - Instalace z příkazové řádky:
+ Stáhněte si grafický instalační program (viz výše) a spusťte ho příkazemjava -jar i2pinstall_0.8.exe -console
+ Tato instalace funguje pod operačními systémy Windows, Linux a Mac. +
+ - Instalace ze zdrojového kódu:
+ i2psource_0.8.tar.bz2 + (SHA256 +a179fc478279383af3420c84699a014a40f9cb0da87ab2a2d2b890639345b999 + sig)
+ Alternativně lze zdrojový kód stáhnout z repozitáře monotone.
+ Spusťte sestavení programu příkazem(tar xjvf i2psource_0.8.tar.bz2 ; cd i2p-0.8 ; ant pkg)a potom + spusťte grafický instalační program nebo instalaci z příkazové řádky (viz výše).
+
Po dokončení instalace
+ +Windows: Klikněte na ikonu "Start I2P". Otevře se nové okno s +ovládacím panelem, +které obsahuje další pokyny.
+ +Unix a kompatibilní systémy: I2P lze spustit jako službu skriptem "i2prouter". +Naleznete ho ve složce, kde jste nainstalovali I2P. Stav služby lze zjistit příkazem +"sh i2prouter status". Službu lze ovládat pomocí argumentů "start", "stop" a "restart". +Po jejím spuštění je k dispozici ovládací panel. + +OpenSolaris a další systémy, pro které není podporován wrapper (i2psvc) mohou proces +spustit pomocí příkazu "sh runplain.sh" +
+ +Při první instalaci prosím nezapomeňte nastavit NAT/firewall. Je-li to možné, +otevřete Internetové porty I2P popsané zde. Pokud jste úspěšně +otevřeli TCP port pro příchozí spojení, nastavte jej i na +konfigurační stránce. +
+ +Na konfigurační stránce +také prosím nastavte povolenou přenosovou kapacitu. Počáteční nastavení +96 kB/s pro příchozí a 40 kB/s pro odchozí data je poměrně pomalé. +
+ +Aktualizace z předchozích verzí:
++K dispozici je buď automatická nebo manuální aktualizace. +
+Provozujete-li verzi 0.7.5 nebo novější, váš router by měl detekovat novou verzi. +Klikněte na odkaz 'Download Update' (Stáhnout aktualizaci) v ovládacím panelu, když se zobrazí. +
+Zvláštní případy +
-
+
- Vzhledem k závadě ve verzi 0.7.6 můžete za jistých podmínek obdržet chybové hlášení +"downloaded version is not greater than current version" (stažená verze není novější než +aktuální verze). V takovém případě použijte manuální aktualizaci popsanou níže. + +
- Provozujete-li verzi 0.7.4 nebo starší, přečtěte si prosím +poznámky k verzi 0.7.5, které popisují jak nastavit router +pro automatickou detekci nových verzí. + +
- Provozujete-li verzi 0.6.1.30 nebo starší, přečtěte si prosím +tyto instrukce jak nastavit router pro automatickou detekci +nových verzí. + +
Aktualizace z předchozích verzí (manuální postup):
+-
+
- Stáhněte si i2pupdate_0.8.zip + (SHA256 +57c6dd9dab15dc52613e35ba538842de948ad5f230d17f693cdcc86fa056f97c + sig) a uložte jej do + instalační složky I2P. Přejmenujte tento soubor na i2pupdate.zip. + (Alternativně si můžete stáhnout zdrojový kód jak je popsáno výše a spustit + "ant updater", výsledný soubor i2pupdate.zip pak nakopírovat do instalační složky + I2P.) Tento soubor nerozbalujte. +
- Klikněte na tlačítko "Graceful restart" (hladký restart) na stránce + konfigurace služby I2P. +
- Dejte si šálek kávy a vraťte se za 11 minut. +
Soubor je podepsán uživatelem zzz, +jehož klíč je k dispozici zde. +
+ +{% endblock %} diff --git a/www.i2p2/pages/faq.html b/www.i2p2/pages/faq.html index 2de4108d..476f5727 100644 --- a/www.i2p2/pages/faq.html +++ b/www.i2p2/pages/faq.html @@ -42,7 +42,7 @@Here are some places, pick one or more.
-
-
- trac.i2p2.i2p ticket +
- trac.i2p2.de ticket
- forum.i2p
- paste.i2p2.i2p and follow up on IRC #i2p
- Discuss with the developers on IRC #i2p
diff --git a/www.i2p2/pages/faq_de.html b/www.i2p2/pages/faq_de.html
index 69324f49..96189159 100644
--- a/www.i2p2/pages/faq_de.html
+++ b/www.i2p2/pages/faq_de.html
@@ -7,7 +7,7 @@
Hier sind ein paar Stellen, wähle einen oder mehrere
-
-
- trac.i2p2.i2p Ticket +
- trac.i2p2.de Ticket
- forum.i2p
- paste.i2p2.i2p und melde den Link im IRC Kanal #i2p
- Diskussion mit den Entwicklern im IRC Kanal #i2p
diff --git a/www.i2p2/pages/faq_fr.html b/www.i2p2/pages/faq_fr.html
index 3a05649d..1b0caec2 100644
--- a/www.i2p2/pages/faq_fr.html
+++ b/www.i2p2/pages/faq_fr.html
@@ -8,7 +8,7 @@
Voici les endroits ou vous pouvez le faire, utilisez en un ou plus :
-
-
- trac.i2p2.i2p ticket +
- trac.i2p2.de ticket
- forum.i2p
- paste.i2p2.i2p et suivez le sur IRC #i2p
- Discutez avec les développeurs d'I2P sur IRC #i2p
diff --git a/www.i2p2/pages/faq_zh.html b/www.i2p2/pages/faq_zh.html
index 356c3d93..377a3eb9 100644
--- a/www.i2p2/pages/faq_zh.html
+++ b/www.i2p2/pages/faq_zh.html
@@ -42,7 +42,7 @@
我想我发现了软件的一个错误，到哪报告？(链接)
以下这些地方都可以，您可以任选其一。
-
-
- trac.i2p2.i2p申报故障 +
- trac.i2p2.de申报故障
- 论坛 forum.i2p
- 将日志贴到公共剪切板 paste.i2p2.i2p 然后来 IRC #i2p
- 到IRC的#i2p房间向开发组反馈问题 diff --git a/www.i2p2/pages/getinvolved.html b/www.i2p2/pages/getinvolved.html index fffcb2c8..ab9cebf4 100644 --- a/www.i2p2/pages/getinvolved.html +++ b/www.i2p2/pages/getinvolved.html @@ -16,7 +16,7 @@ Fix up the Wikipedia article about I2P in your language. Tell your friends.
- Testing - Run the latest builds from monotone -and report results on #i2p or as bugs on Trac. +and report results on #i2p or as bugs on Trac.
- Documentation - Help fix the parts of the website that are outdated or incomplete. Translate pages into other languages. @@ -33,7 +33,7 @@ Write or port applications for I2P! There's some guidelines and a list of ideas on the applications page.
- Coding -
There's plenty to do if you know Java or are ready to learn.
-Check for open tickets on Trac
+Check for open tickets on Trac
or the TODO list on zzz.i2p for
some ideas on where to start.
See the new developer's guide for details.
diff --git a/www.i2p2/pages/getinvolved_de.html b/www.i2p2/pages/getinvolved_de.html
index 088777e8..ef9707aa 100644
--- a/www.i2p2/pages/getinvolved_de.html
+++ b/www.i2p2/pages/getinvolved_de.html
@@ -13,7 +13,7 @@ dich einzubringen! Hier ist eine Liste die dir beim Start hilft:
- Testen - Benutze die letzten Versionen aus dem Monotone Archive -und berichte Ergebnisse in #i2p oder Fehler und Bugs auf Trac. +und berichte Ergebnisse in #i2p oder Fehler und Bugs auf Trac.
- Dokumentation - Hilf mit beim aktualisieren und erstellen der fehlenden Dokumente auf der Webseite, übersetze die Webseite in andere Sprachen! @@ -30,7 +30,7 @@ Schreibe oder portiere eine Anwendung für I2P! Es gibt ein paar Richtlienen und eine Liste von Ideen auf der Anwendungsseite.
- Coding - Es gibt viel zu tun falls Du Java kannst oder bereit bist, Java zu lernen. -Kontrolliere Trac nach offenen Tickets oder +Kontrolliere Trac nach offenen Tickets oder die TODO Liste auf zzz.i2p für einige Ideen zum Start. Schaue zur Anleitung für neue Entwickler Seite für Details.
- Analysen -
diff --git a/www.i2p2/pages/getinvolved_ru.html b/www.i2p2/pages/getinvolved_ru.html
index 140e3829..e1348408 100644
--- a/www.i2p2/pages/getinvolved_ru.html
+++ b/www.i2p2/pages/getinvolved_ru.html
@@ -14,7 +14,7 @@
- Расскажите о нас! — Расскажите знакомым про I2P, дайте ссылку на проект в форумном обсуждении или в комментариях к статье, прорекламируйте в своём блоге. Создайте/обновите статью об I2P в Википедии на Вашем языке. -
- Тестирование — Обновляйтесь до текущего билда из monotone-репозитория и сообщайте обо всех обнаруженных ошибках на канале #i2p или в багтрекере. +
- Тестирование — Обновляйтесь до текущего билда из monotone-репозитория и сообщайте обо всех обнаруженных ошибках на канале #i2p или в багтрекере.
- Документация — Исправьте устаревший текст, дополните незавершенные инструкции, добавьте перевод на свой язык. @@ -26,7 +26,7 @@
- Приложения — Создавайте новые I2P-программы или переделайте уже существующие под работу через I2P-сеть. Несколько методических рекомендаций и список нереализованных задумок можно посмотреть на странице Application Development Guide. -
- Разработка — Если Вы Java-программист, то перед Вами широкий фронт работ. Для начала проверьте багтрекер на наличие открытых тикетов или загляните в TODO-список на форуме zzz.i2p. Подробнее смотрите на странице New Developer's Guide +
- Разработка — Если Вы Java-программист, то перед Вами широкий фронт работ. Для начала проверьте багтрекер на наличие открытых тикетов или загляните в TODO-список на форуме zzz.i2p. Подробнее смотрите на странице New Developer's Guide
- Поиск уязвимостей — Проанализируйте или протестируйте код на слабые места. Требуют внимания как уязвимости, касающиеся анонимности (см. описание на странице I2P's Threat Model), так и DoS-уязвимости, и прочие потенциальные угрозы.
diff --git a/www.i2p2/pages/glossary.html b/www.i2p2/pages/glossary.html
new file mode 100644
index 00000000..57866852
--- /dev/null
+++ b/www.i2p2/pages/glossary.html
@@ -0,0 +1,11 @@
+{% extends "_layout.html" %}
+{% block title %}Glossary{% endblock %}
+{% block content %}
+This page lists often-used terminology when discussing I2P and cryptography.
+
+
+{% endblock %} diff --git a/www.i2p2/pages/halloffame.html b/www.i2p2/pages/halloffame.html index fbbe54e8..7f2cb7fe 100644 --- a/www.i2p2/pages/halloffame.html +++ b/www.i2p2/pages/halloffame.html @@ -13,11 +13,6 @@+ +I2P +Invisible Internet Project: a project meant to provide an anonymity layer, so user can communicate anonymously using a range of applications. +Welterde 8 €/mo, since January, 2008 - i2p2.de eche|on 32 €/mo since January, 2008 - i2p-projekt.de and domains
-This fee went direct to the i2p.net hoster as it has it run out. -Because of the special situation arisen early 2008 -we decided to let it run til money was out. -From begin of Feb 2009 on we got a new fund setup.
Big thanks go to the following people who have donated to I2P!
Current monthly subscriptions:
@@ -58,7 +53,7 @@ From begin of Feb 2009 on we got a new fund setup.Jan, 2010 anonymous 500 € General fund Jan, 2010 bernerbaer 50 € General fund Jan, 2010 anonymous 15 € General fund Apr, 2009-Jan, 2010 neutron 20 $euro;/month outproxy fund Apr, 2009-Jan, 2010 neutron 20 €/month outproxy fund Jan, 2010 anonymous $20 USD General fund Jan, 2010 anonymous 6.80 € General fund Jan, 2010 anonymous 10 € General fund Mar, 2009 [anonymous] 50 € General fund Feb, 2009 [anonymous] 30 € General fund Feb, 2009 DVT 20 € General fund Oct, 2008 eche|on 500.0 € Datastorage bounty Mar, 2007 zzz $200 USD General fund Nov, 2006-Dec, 2007 [anonymous] $10 USD/month general fund Dec, 2006 bar New mac testing machine Dec, 2006 [anonymous] $200 USD General fund Jan, 2006 [anonymous] $40 USD I2P general fund Jan, 2006 [anonymous] $50 USD I2P general fund Jan, 2006 [anonymous] $20 USD I2P general fund Dec, 2005 [anonymous] $10 USD I2P general fund Dec, 2005 [anonymous] $10 USD I2P general fund Nov, 2005-Dec, 2007 [anonymous] $10 USD/month general fund Jan, 2005-Dec, 2007 [anonymous] $10 USD/month general fund Jan, 2005-Jun, 2005 Martin Stares $60 USD I2P general fund Jan, 2005 Nico Zimmerman $2 USD I2P general fund Nov, 2004-Dec, 2007 jnymo $10 USD/month general fund Dec, 2004, May, 2005 Elliot Turner $350 USD I2P general fund Dec, 2004 [anonymous] $5 USD I2P general fund The I2P Project is committed to maintaining accurate, current documentation. If you find any inaccuracies in the documents linked below, please -enter a ticket identifying the problem. +enter a ticket identifying the problem.
Index to Technical Documentation
@@ -23,7 +23,7 @@ If you find any inaccuracies in the documents linked below, please- Technical Introduction
- A Less-Technical Introduction -
- Threat model +
- Threat model and analysis
- Comparisons to other anonymous networks
- Protocol stack chart
- Streaming Library
- -Streaming Javadoc +Streaming Javadoc
- Datagrams
- -Datagram Javadoc +Datagram Javadoc
Client-to-Router Interface API and Protocol
@@ -76,13 +76,13 @@ Traditionally used only by Java applications and higher-level APIs.- I2CP I2P Control Protocol / API overview
- -I2CP Specification +I2CP Specification
- -I2CP API Javadoc +I2CP API Javadoc
- Common data structures specification
- -Data Structures Javadoc +Data Structures Javadoc
End-to-End Encryption
@@ -107,21 +107,21 @@ I2P is a message-oriented router. The messages sent between routers are defined - I2NP Specification
- -I2NP Javadoc +I2NP Javadoc
- Common data structures specification
- -Data Structures Javadoc +Data Structures Javadoc
Tunnels
Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.- Peer profiling and selection -
- Tunnel routing -
- Garlic routing +
- Tunnel routing overview +
- Garlic routing and "garlic" terminology
- Tunnel building and encryption -
- ElGamal/AES+SessionTag for build request encryption +
- ElGamal/AES for build request encryption
- ElGamal and AES cryptography details
- Tunnel building specification
- Low-level tunnel message specification @@ -130,7 +130,7 @@ Selecting peers, requesting tunnels through those peers, and encrypting and rout
- -Transport layer overview +Transport layer overview
- NTCP TCP-based transport overview
- @@ -142,16 +142,20 @@ The protocols for direct (point-to-point) router to router communication.
- SSU transport encryption
- -Transport Javadoc +Transport Javadoc
- -NTCP Javadoc +NTCP Javadoc
- -SSU Javadoc +SSU Javadoc
- +Native BigInteger Library +
- Time synchronization and NTP +
- +Performance
Transport Layer
The protocols for direct (point-to-point) router to router communication.Other Router Topics
Developer's Guides
@@ -161,6 +165,10 @@ Time synchronization and NTP New Translator's Guide - Monotone Guide +
- +Javadocs +
- +To Do List
ElGamal is used for asymmetric encryption. +ElGamal is used in several places in I2P: +
- +To encrypt router-to-router Tunnel Build Messages +
- +For end-to-end (destination-to-destination) encryption as a part of ElGamal/AES+SessionTag +
- +For encryption of some netDb stores and queries sent to floodfill routers +as a part of ElGamal/AES+SessionTag +(destination-to-router or router-to-router). +
We use common primes for 2048 ElGamal encryption and decryption, as given by IETF RFC-3526. We currently only use ElGamal to encrypt the IV and session key in a single block, followed by the -AES encrypted payload using that key and IV. Specifically, the unencrypted ElGamal -block is formatted (in network byte order): +AES encrypted payload using that key and IV.
+The unencrypted ElGamal contains: +
- |_______1_______2_______3_______4_______5_______6_______7_______8 - |nonzero|H(data) - | - | - | - | | data ... | + +----+----+----+----+----+----+----+----+ + |nonz| H(data) | + +----+ + + | | + + + + | | + + + + | | + + +----+----+----+----+----+----+----+ + | | data... + +----+----+----+--//
The H(data) is the SHA256 of the data that is encrypted in the ElGamal block, and is preceded by a random nonzero byte. The data encrypted in the block -can be up to 222 bytes long. See -the ElGamal code. +may be up to 222 bytes long. +As the encrypted data may contain a substantial number of zeros if the +cleartext is smaller than 222 bytes, it is recommended that higher layers pad +the cleartext to 222 bytes with random data. +Total length: typically 255 bytes. +
+The encrypted ElGamal contains: +
-ElGamal is never used on its own in I2P, but instead always as part of -ElGamal/AES+SessionTag. +
+ +----+----+----+----+----+----+----+----+ + | zero padding... | | + +----+----+----+--// ----+ + + | | + + + + | ElG encrypted part 1 | + ~ ~ + | | + + +----+----+----+----+----+----+----+ + | | zero padding... | | + +----+----+----+----+--// ----+ + + | | + + + + | ElG encrypted part 2 | + ~ ~ + | | + + +----+----+----+----+----+----+ + | + + +----+----+ + +
+Each encrypted part is prepended with zeros to a size of exactly 257 bytes. +Total length: 514 bytes. +In typical usage, higher layers pad the cleartext data to 222 bytes, +resulting in an unencrypted block of 255 bytes. +This is encoded as two 256-byte encrypted parts, +and there is a single byte of zero padding before each part at this layer. ++See +the ElGamal code.
The shared prime is the @@ -98,8 +151,19 @@ It may be quite difficult to make any change backward-compatible.
AES
-AES is used for symmetric encryption. -
+AES is used for symmetric encryption, in several cases: +
- +For transport encryption after DH key exchange +
- +For end-to-end (destination-to-destination) encryption as a part of ElGamal/AES+SessionTag +
- +For encryption of some netDb stores and queries sent to floodfill routers +as a part of ElGamal/AES+SessionTag +(destination-to-router or router-to-router). +
- +For encryption of periodic tunnel test messages sent from the router to itself, through its own tunnels. +
We use 256 bit AES in CBC mode. The padding used is specified in IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02)). In this case, padding exists of pseudorandomly generated octets to match 16 byte blocks. @@ -119,12 +183,36 @@ Two situations are possible: 2. For situations where we know the size of the data to be sent, we AES encrypt the following:
- |_______1_______2_______3_______4_______5_______6_______7_______8 - |H(data) - | - | - | | - | size of data (in bytes) | data ... | rand ... | + +----+----+----+----+----+----+----+----+ + | H(data) | + + + + | | + + + + | | + + + + | | + +----+----+----+----+----+----+----+----+ + | size | data ... | + +----+----+ + + | | + ~ ~ + | | + + + + | | + + +----//---+----+ + | | | + +----+----+----//---+----+ + + | Padding to 16 bytes | + +----+----+----+----+----+----+----+----+ + +H(data): 32-byte SHA-256 Hash of the data + +size: 2-byte Integer, number of data bytes to follow + +data: payload + +padding: random data, to a multiple of 16 bytes +
After the data comes an application specified number of randomly generated padding bytes. @@ -266,11 +354,15 @@ It may be quite difficult to make any change backward-compatible.
Transports
-At the lowest -level, inter-router communication is protected by the transport layer security. +At the lowest protocol layer, +point-to-point inter-router communication is protected by the transport layer security. Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange using -the same shared prime and generator as specified above for ElGamal. +the same shared prime and generator as specified above for ElGamal, +followed by symmetric AES encryption as described above. +This provides +perfect forward secrecy +on the transport links.
NTCP connections
@@ -280,8 +372,8 @@ NTCP connections are negotiated with a 2048 Diffie-Hellman implementation, using the router's identity to proceed with a station to station agreement, followed by some encrypted protocol specific fields, with all subsequent data encrypted with AES (as above). -A possible enhancement is to use session tags like we do with -ElGamalAES+SessionTag to avoid the 2048 bit DH negotiation. +The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) forward secrecy', while ElGamalAES+SessionTag does not. +In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed:
@@ -305,7 +397,7 @@ checking. See the SSU specification for details. -
References
+References
-
NIST 800-57
diff --git a/www.i2p2/pages/how_cryptography_de.html b/www.i2p2/pages/how_cryptography_de.html
index 684f6257..ba8f49a4 100644
--- a/www.i2p2/pages/how_cryptography_de.html
+++ b/www.i2p2/pages/how_cryptography_de.html
@@ -38,7 +38,7 @@ Die H(Daten) ist der SHA256 Wert der Daten, die in dem ElGamal Block
verschlüsselt sind. Vor den H(Daten) steht ein zufälliges Byte, das
nicht Null ist. Die Daten im Block können bis zu 222 Bytes lang sein.
Die Spezifikation ist
-[im Quelltext].
+[im Quelltext].
ElGamal wird in I2P nie alleine genutzt, es ist immer ein Teil von ElGamal/AES+SessionTag. @@ -59,14 +59,14 @@ Wir benutzen 256bit AES im CBC Modus mit dem PKCS#5 Padding für 16 Byte Blo (welches bedeuted, das jeder Block mit der Anzahl der aufgefüllten Bytes als Daten aufgefüllt wird). Zur Spezifikation schaue in den - [CBC Quelltext] + [CBC Quelltext] und für die Crytix AES -[Implementation hier] +[Implementation hier]
In Situationen, in denen wir AES Daten streamen, nutzen wir die selben Algorhytmen, wie sie in -[AESOutputStream] und -[AESInputStream] +[AESOutputStream] und +[AESInputStream] implementiert sind.
Für Situationen, in denen die Gröse der zu sendenden Daten bekannt ist, @@ -83,14 +83,14 @@ Ende der zufälligen Daten ist AES verschlüsselt (256bit CBC mit PKCS#5
Dieser Code ist in den safeEncrypt und safeDecrypt Methoden der -[AESEngine] +[AESEngine] implementiert.
DSA
Signaturen werden mit 1024bit DSA erzeugt und verifiziert, wie es in der -[DSAEngine] +[DSAEngine] implementiert ist.
Die DSA Konstanten
@@ -143,7 +143,7 @@ implementiert ist.Hashes in I2P sind bekannte, alte SHA256 wie es im -[SHA256Generator] +[SHA256Generator] implementiert ist.
TCP Verbindungen
@@ -170,11 +170,11 @@ RouterInfo Struktur nutzen (die die ElGamal und DSA Schlüssel enthält)Die grundlegenden TCP Verbindungsalgorhythmen sind in der establishConnection() Funktion implementiert (die wiederrum exchangeKey() und identifyStationToStation()) in -[TCPConnection] +[TCPConnection] aufruft).
Dieses wird erweitert durch die -[RestrictiveTCPConnection] +[RestrictiveTCPConnection] Funktion, die die establishConnection() Methode aktualisiert um die Protokoll Version, die Uhrzeit und die öffentlich erreichbare IP Adresse des Knotens verifizieren zu können. (Da wir noch keine diff --git a/www.i2p2/pages/how_de.html b/www.i2p2/pages/how_de.html index 8dcf7782..726d105c 100644 --- a/www.i2p2/pages/how_de.html +++ b/www.i2p2/pages/how_de.html @@ -14,7 +14,7 @@ Die Schnittstelle zwischen Anwendungen und dem Router trägt den Namen I2CP
Das I2P-Projekt ist um eine vollständige und aktuelle Dokumentation bemüht. Wer in einer der unten verlinkten Seiten Ungenauigkeiten oder Unstimmigkeiten findet, -möge diese bitte hier melden. +möge diese bitte hier melden.
Inhaltsverzeichnis
@@ -66,11 +66,11 @@ Die Java-Schnittstelle und die Kommunikationsprotokolle zur zuverlässigen (- Datenströme (Streaming) (englisch)
- -Java-Dokumentation zur Streaming-Bibliothek (englisch) +Java-Dokumentation zur Streaming-Bibliothek (englisch)
- Datenpakete (Datagrams) (englisch)
- -Java-Dokumentation zur Datagram-Bibliothek (englisch) +Java-Dokumentation zur Datagram-Bibliothek (englisch)
Routerschnittstelle und zugehöriges Protokoll
@@ -78,13 +78,13 @@ Die unmittelbare Schnittstelle zum Router. Die Java-Programmierschnittstelle und- I2CP (I2P Control Protocol) Beschreibung des Protokolls und der Schnittstelle (englisch)
- -Technische Beschreibung I2CP +Technische Beschreibung I2CP (englisch)
- -Java-Dokumentation zu I2CP (englisch) +Java-Dokumentation zu I2CP (englisch)
- Techn. Beschreibung Datenstrukturen (englisch)
- -Java-Dokumentation zu den Datenstrukturen (englisch) +Java-Dokumentation zu den Datenstrukturen (englisch)
Durchgehende Verschlüsselung
@@ -109,11 +109,11 @@ I2P-Router sind nachrichtenbasiert. Der Versand von Nachrichten zwischen Routern - Technische Beschreibung I2NP (englisch)
- -Java-Dokumentation zu I2NP (englisch) +Java-Dokumentation zu I2NP (englisch)
- Techn. Beschreibung Datenstrukturen (englisch)
- -Java-Dokumentation zu den Datenstrukturen (englisch) +Java-Dokumentation zu den Datenstrukturen (englisch)
Tunnel
@@ -143,11 +143,11 @@ Protokolle zur direkten Kommunikation zwischen zwei Routern. Verschlüsselung des NTCP-Transports (englisch) - Verschlüsselung des SSU-Transports (englisch)
- -Java-Dokumentation zur Transportschicht (englisch) +Java-Dokumentation zur Transportschicht (englisch)
- -Java-Dokumentation zu NTCP (englisch) +Java-Dokumentation zu NTCP (englisch)
- -Java-Dokumentation zu SSU (englisch) +Java-Dokumentation zu SSU (englisch)
Sonstiges zum Thema Router
diff --git a/www.i2p2/pages/how_elgamalaes.html b/www.i2p2/pages/how_elgamalaes.html index 1e68a98d..b6ff47df 100644 --- a/www.i2p2/pages/how_elgamalaes.html +++ b/www.i2p2/pages/how_elgamalaes.html @@ -1,80 +1,329 @@ {% extends "_layout.html" %} -{% block title %}How ElGamal and AES Encryption Work{% endblock %} -{% block content %}-Within I2P, various messages are encrypted, but we don't want anyone to know -to whom or from whom it is bound, so we can't just toss a "to" or "from" address. -In addition, messages are not delivered in order (or reliably), so we can't simply -ElGamal encrypt the first message and AES the subsequent messages. The alternative -of ElGamal encrypting each individual message is daunting in light of the message -frequency desired. Instead, we take each message and evaluate whether it fits into -the three possible conditions:
+{% block title %}ElGamal/AES + SessionTag Encryption{% endblock %} +{% block content %} +Updated August 2010, current as of router version 0.8 +Overview
++ElGamal/AES+SessionTags is used for end-to-end encryption. +
+As an unreliable, unordered, message based system, I2P uses a simple combination + of asymmetric and symmetric encryption algorithms to provide data confidentiality + and integrity to garlic messages. As a whole, the combination is referred + to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe + the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces.
+The first time a router wants to encrypt a garlic message to another router, + they encrypt the keying material for an AES256 session key with ElGamal and + append the AES256/CBC encrypted payload after that encrypted ElGamal block. + In addition to the encrypted payload, the AES encrypted section contains the + payload length, the SHA256 hash of the unencrypted payload, as well as a number + of "session tags" - random 32 byte nonces. The next time the sender wants + to encrypt a garlic message to another router, rather than ElGamal encrypt + a new session key they simply pick one of the previously delivered session + tags and AES encrypt the payload like before, using the session key used with + that session tag, prepended with the session tag itself. When a router receives + a garlic encrypted message, they check the first 32 bytes to see if it matches + an available session tag - if it does, they simply AES decrypt the message, + but if it does not, they ElGamal decrypt the first block.
+Each session tag can be used only once so as to prevent internal adversaries + from unnecessarily correlating different messages as being between the same + routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses + when and how many tags to deliver, prestocking the recipient with enough tags + to cover a volley of messages. Garlic messages may detect the successful tag + delivery by bundling a small additional message as a clove (a "delivery status + message") - when the garlic message arrives at the intended recipient and + is decrypted successfully, this small delivery status message is one of the + cloves exposed and has instructions for the recipient to send the clove back + to the original sender (through an inbound tunnel, of course). When the original + sender receives this delivery status message, they know that the session tags + bundled in the garlic message were successfully delivered.
+Session tags themselves have a short lifetime, after which they are + discarded if not used. In addition, the quantity stored for each key is limited, + as are the number of keys themselves - if too many arrive, either new or old + messages may be dropped. The sender keeps track whether messages using session + tags are getting through, and if there isn't sufficient communication it may + drop the ones previously assumed to be properly delivered, reverting back + to the full expensive ElGamal encryption. + A session will continue to exist until all its tags are exhausted or expire. +
+Sessions are unidirectional. Tags are delivered from Alice to Bob, +and Alice then uses the tags, one by one, in subsequent messages to Bob. +
+Sessions may be established between Destinations, between Routers, or +between a Router and a Destination. +Each Router and Destination maintains its own Session Key Manager to +keep track of Session Keys and Session Tags. +Separate Session Key Managers prevents correlation of multiple Destinations +to each other or a Router by adversaries. +
+ + + +Message Reception
++Each message received has one of two +the two possible conditions:
-
-
-
- its ElGamal encrypted to us -
- its AES encrypted to us -
- its not encrypted to us +
- It is part of an existing session and contains a Session Tag and an AES encrypted block +
- It is for a new session and contains both ElGamal and AES encrypted blocks
New Session Message Specification
-If its ElGamal encrypted to us, the message is considered a new session, and -is encrypted per encryptNewSession(...) in -[ElGamalAESEngine] -as follows -
- -An initial ElGamal block, encrypted as before:
- +An ElGamal Message contains two parts, an encrypted ElGamal block +and an encrypted AES block. ++The encrypted message contains:
- |_______1_______2_______3_______4_______5_______6_______7_______8 - | 32 byte session key - | - | - | | - | 32 byte pre-IV (first 16 bytes of H(pre-IV) == IV) - | - | - | | - | (158 bytes of random data) - | ... - | | + +----+----+----+----+----+----+----+----+ + | | + + + + | ElGamal Encrypted Block | + ~ ~ + | | + + +----+----+----+----+----+----+ + | | | + +----+----+ + + | | + + + + | AES Encrypted Block | + ~ ~ + | | + + +----+----+----+----+----+----+ + | + + +----+----+ +
- -Followed by the following, AES encrypted as before, -using the session key and IV from the header:
- + +ElGamal Block
++The encrypted ElGamal Block is always 514 bytes long. +The encrypted AES Block length is variable but is always a multiple of 16 bytes. +
+The unencrypted ElGamal data is 222 bytes long, containing:
- |_______1_______2_______3_______4_______5_______6_______7_______8 - | # session tags| that many sessionTags (32 byte random numbers) - | ... - | | size of the payload (bytes) | H(payload) - | - | - | - | | flag |payload - | ... - | | - | random bytes leaving the total AES block (size % 16 == 0) | + +----+----+----+----+----+----+----+----+ + | | + + + + | Session Key | + + + + | | + + + + | | + +----+----+----+----+----+----+----+----+ + | | + + + + | Pre-IV | + + + + | | + + + + | | + +----+----+----+----+----+----+----+----+ + + + + | | + + + + | 158 bytes random padding | + ~ ~ + | | + + +----+----+ + | | + +----+----+----+----+----+----+ +
+The 32-byte +Session Key +is the identifier for the session. +The 32-byte Pre-IV will be used to generate the IV for the AES block that follows; +the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV. ++The 222 byte payload is encrypted +using ElGamal +and the encrypted block is 514 bytes long. +
+ +AES Block
+The unencrypted data in the AES block contains the following: +
+ +----+----+----+----+----+----+----+----+ + |tag count| | + +----+----+ + + | | + + + + | Session Tags | + ~ ~ + | | + + + + | | + + +----+----+----+----+----+----+ + | | payload size | | + +----+----+----+----+----+----+ + + | | + + + + | Payload Hash | + + + + | | + + +----+----+ + | |flag| | + +----+----+----+----+----+----+----+ + + | | + + + + | New Session Key (opt.) | + + + + | | + + +----+ + | | | + +----+----+----+----+----+----+----+ + + | | + + + + | Payload | + ~ ~ + | | + + +----//---+----+ + | | | + +----+----+----//---+----+ + + | Padding to 16 bytes | + +----+----+----+----+----+----+----+----+ + +tag count: 2-byte Integer, 0-200 + +Session Tags: That many 32-byte Session Tags + +payload size: 4-byte Integer + +Payload Hash: The 32-byte SHA256 SHA256 Hash of the payload + +flag: A one-byte value. Normally == 0. If == 0x01, a Session Key follows + +New Session Key: A 32-byte Session Key, + to replace the old key, and is only present if preceding flag is 0x01 + +Payload: the data + +Padding: Random data to a multiple of 16 bytes for the total length. + May contain more than the minimum required padding. + +Minimum length: 48 bytes
-If the flag is 0x01, it is followed by a new session key, replacing -the old one.
++The data is then AES Encrypted, +using the session key and IV (calculated from the pre-IV) from the ElGamal section.
+ +Notes
+-
+
- + Actual max payload length, and max block length, is less than 64 KB; see theI2NP Overview. +
- +New Session Key is currently unused and is never present. +
Existing Session Message Specification
The session tags delivered successfully are remembered for a -brief period (30 minutes currently) until they are used (and discarded). -They are used by packaging in a message that is not preceded by an -ElGamal block. Instead, it is encrypted per encryptExistingSession(...) in -[ElGamalAESEngine] -as follows -
+brief period (15 minutes currently) until they are used or discarded. +A tag is used by packaging one in an Existing Session Message that +contains only an AES encrypted block, and + is not preceded by an +ElGamal block. +- |_______1_______2_______3_______4_______5_______6_______7_______8 - | session tag (32 byte random number previously delivered and - | not yet expired or used). the session tag also serves as - | the pre-IV (the first 16 bytes of H(sessionTag) == IV) - | | -
+ +----+----+----+----+----+----+----+----+ + | | + + + + | Session Tag | + + + + | | + + + + | | + +----+----+----+----+----+----+----+----+ + | | + + + + | AES Encrypted Block | + ~ ~ + | | + + + + | | + +----+----+----+----+----+----+----+----+ + +Session Tag: A 32-byte Session Tag + previously delivered in an AES block + +AES Encrypyted Block: As specified above. + + +The session tag also serves as +the pre-IV. The IV is the first 16 bytes of the SHA-256 Hash of the sessionTag. ++To decode a message from an existing session, a router looks up the Session Tag to find an +associated Session Key. If the Session Tag is found, the AES block is decrypted using the associated Session Key. +If the tag is not found, the message is assumed to be a New Session Message. +
+ + + +Future Work
++There are many possible areas to tune the Session Key Manager's algorithms; +some may interact with the streaming library behavior, or have significant +impact on overal performance. +
- +Delivery of too many tags at one time may impose substantial overhead for brief streaming connections +or datagrams, and increase the chance of message loss. +We currently deliver 40 tags at a time (1280 bytes). +32 (1024 bytes) may be better for tunnel fragmentation. +
- +A few tags could be delivered in each of several messages, or lots of tags all at once. +
- +It is also important to study and tune +the low-tag thresholds at which more tags are sent. +
- +The number of tags delivered could depend on message size, keeping in mind +the eventual padding to 1KB at the tunnel message layer. +
- +Clients could send an estimate of session lifetime to the router, as an advisory +on the number of tags required. +
- +Delivery of too few tags causes the router to fall back to an expensive ElGamal encryption. +
- +The router may assume delivery of Session Tags, or await acknowledgement before using them; +there are tradeoffs for each strategy. +
- +For very brief messages, almost the full 222 bytes of the pre-IV and padding fields in the ElGamal block +could be used for the entire message, instead of establishing a session. +
- +Evaluate padding strategy; currently we pad to a minimum of 128 bytes. +Would be better to add a few tags to small messages than pad. +
- +Perhaps things could be more efficient if the Session Tag system was bidirectional, +so tags delivered in the 'forward' path could be used in the 'reverse' path, +thus avoiding ElGamal in the initial response. +The router currently plays some tricks like this when sending +tunnel test messages to itself. +
- +Change from Session Tags to +a synchronized PRNG. +
- +Several of these ideas may require a new I2NP message type, or +set a flag in the +Delivery Instructions, +or set a magic number in the first few bytes of the Session Key field +and accept a small risk of the random Session Key matching the magic number. +
Followed by the AES encrypted block above (2 byte # session tags, -that many session tags, sizeof(payload), H(payload), flag, payload, -random padding).
{% endblock %} diff --git a/www.i2p2/pages/how_elgamalaes_de.html b/www.i2p2/pages/how_elgamalaes_de.html index 40d42629..03b75210 100644 --- a/www.i2p2/pages/how_elgamalaes_de.html +++ b/www.i2p2/pages/how_elgamalaes_de.html @@ -22,7 +22,7 @@ testen, ob diese in eine der drei Möglichkeiten passt: Falls es für uns ElGamal verschlüsselt ist, wird die Nachricht als neue Session behandelt und wird verschlüsselt mittels encryptNewSession(....) in der -[ElGamalAESEngine] +[ElGamalAESEngine] wie folgend -Ein initialer ElGamal Block, verschlüsselt wie zuvor:
@@ -67,7 +67,7 @@ ersetzt. Zeit (zur Zeit 30 Minuten) gespeichert bis sie gebraucht (und weggeworfen) werden. Sie werden für das Einpacken einer Nachricht ohne vorhergehnden ElGamal Block genutzt. Dabei wird es mit encryptExistingSession(...) in der -[ElGamalAESEngine] +[ElGamalAESEngine] wie folgend verschlüsselt -diff --git a/www.i2p2/pages/how_garlicrouting.html b/www.i2p2/pages/how_garlicrouting.html index a1929350..6fba2314 100644 --- a/www.i2p2/pages/how_garlicrouting.html +++ b/www.i2p2/pages/how_garlicrouting.html @@ -1,53 +1,261 @@ {% extends "_layout.html" %} -{% block title %}How Garlic Routing Works{% endblock %} +{% block title %}Garlic Routing{% endblock %} {% block content %}-As briefly explained on the intro, in addition to sending -messages through tunnels (via tunnels), I2P uses a technique called -"garlic routing" - layered encryption of messages, passing through routers -selected by the original sender. This is similar to the way Mixmaster +Updated August 2010 for release 0.8 +
+ +Garlic Routing and "Garlic" Terminology
++The terms "garlic routing" and "garlic encryption" are often used rather loosely when referring to I2P's technology. +Here, we explain the history of the terms, the various meanings, and +the usage of "garlic" methods in I2P. +
+"Garlic routing" was first coined by +Michael J. Freedman +in Roger Dingledine's Free Haven +Master's thesis Section 8.1.1 (June 2000), as derived from +Onion Routing. +
+"Garlic" may have been used originally by I2P developers because I2P implements a form of +bundling as Freedman describes, or simply to emphasize general differences from Tor. +The specific reasoning may be lost to history. +Generally, when referring to I2P, the term "garlic" may mean one of three things: +
- +Layered Encryption +
- +Bundling multiple messages together +
- +ElGamal/AES Encryption +
Layered Encryption
++Onion routing is a technique for building paths, or tunnels, through a series of peers, +and then using that tunnel. +Messages are repeatedly encrypted by the originator, and then decrypted by each hop. +During the building phase, only the routing instructions for the next hop are exposed to each peer. +During the operating phase, messages are passed through the tunnel, and the +message and its routing instructions are only exposed to the endpoint of the tunnel. +
+This is similar to the way Mixmaster (see network comparisons) sends messages - taking a message, encrypting it to the recipient's public key, taking that encrypted message and encrypting it (along with instructions specifying the next hop), and then taking that resulting encrypted message and so on, until it has one layer of encryption -per hop along the path. The only significant difference between that technique -and I2P's garlic routing is that at each layer, any number of messages can be +per hop along the path. +
+In this sense, "garlic routing" as a general concept is identical to "onion routing". +As implemented in I2P, of course, there are several differences from the implementation in Tor; see below. +Even so, there are substantial similarities such that I2P benefits from a +large amount of academic research on onion routing, +Tor, and similar mixnets. +
+ + +Bundling Multiple Messages
++Michael Freedman defined "garlic routing" as an extension to onion routing, +in which multiple messages are bundled together. +He called each message a "bulb". +All the messages, each with its own delivery instructions, are exposed at the +endpoint. +This allows the efficient bundling of an onion routing "reply block" with the original message. +
+This concept is implemented in I2P, as described below. +Our term for garlic "bulbs" is "cloves". +Any number of messages can be contained, instead of just a single message. +This is a significant distinction from the onion routing implemented in Tor. +However, it is only one of many major architectural differences between I2P and Tor; +perhaps it is not, by itself, enough to justify a change in terminology. + +
+Another difference +from the method described by Freedman +is that the path is unidirectional - there is no "turning point" as seen in onion routing +or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible +and reliable delivery. +
+ + +ElGamal/AES Encryption
+In some cases, "garlic encryption" may simply mean +ElGamal/AES+SessionTag encryption +(without multiple layers). + + + +"Garlic" Methods in I2P
-In addition to the cloves, each unwrapped garlic message contains a sender -specified amount of padding data, allowing the sender to take active countermeasures -against traffic analysis. - -
Uses within I2P
- --I2P uses garlic routing in three places: -
-
-
- For building tunnels -
- For determining the success or failure of end to end message delivery (by wrapping an additional
- DeliveryStatusMessage in with the payload, where the clove containing the DeliveryStatusMessage
- has instructions forwarding it back through other routers and tunnels to the original sender)
-
+Now that we've defined various "garlic" terms, we can say that
+I2P uses garlic routing, bundling and encryption in three places:
+
-
+
- For building and routing through tunnels (layered encryption) +
- For determining the success or failure of end to end message delivery (bundling)
- For publishing some network database entries (dampening the probability of a successful traffic analysis attack) -
There are also significant ways that this technique can be used to improve the performance of the network, exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability. -
Encryption
+Tunnel Building and Routing
-The encryption of each layer in the garlic message uses the ElGamal/AES+SessionTag algorithm, -which avoids the cost of a full 2048bit ElGamal encryption for subsequent messages (using instead a random previously -specified SessionTag plus 256bit AES encryption). +In I2P, tunnels are unidirectional. Each party builds two tunnels, +one for outbound and one for inbound traffic. +Therefore, four tunnels are required for a single round-trip message and reply. +
+Tunnels are built, and then used, with layered encryption. +This is described on the +tunnel implementation page. +Tunnel building details are defined on +this page. +We use +ElGamal/AES+SessionTag for the encryption. +
+Tunnels are a general-purpose mechanism to transport all +I2NP messages, and +Garlic Messages are not used to build tunnels. +We do not bundle multiple +I2NP messages into a single +Garlic Message for unwrapping at the outbound tunnel endpoint; +the tunnel encryption is sufficient. +
+ + +End-to-End Message Bundling
++At the layer above tunnels, I2P delivers end-to-end messages between +Destinations. +Just as within a single tunnel, we use +ElGamal/AES+SessionTag for the encryption. +Each client message as delivered to the router through the +I2CP interface becomes a single +Garlic Clove +with its own +Delivery Instructions, +inside a +Garlic Message. +Delivery Instructions may specify a Destination, Router, or Tunnel. +
+Generally, a Garlic Message will contain only one clove. +However, the router will periodically bundle two additional +cloves in the Garlic Message: +
+ + +
+- +A +Delivery Status Message, +with +Delivery Instructions +specifying that it be sent back to the originating router as an acknowledgment. +This is similar to the "reply block" or "reply onion" +described in the references. +It is used for determining the success or failure of end to end message delivery. +The originating router may, upon failure to receive the Delivery Status Message +within the expected time period, modify the routing to the far-end Destination, +or take other actions. + +
- +A +Database Store Message, +containing a +LeaseSet +for the originating Destination, with +Delivery Instructions +specifying the far-end destination's router. +By periodically bundling a LeaseSet, the router ensures that the far-end will be able +to maintain communications. +Otherwise the far-end would have to query a floodfill router for the network database entry, +and all LeaseSets would have to be published to the network database, as explained on the +network database page. +
+In the current implementation, the Delivery Status and Database Store Messages +are bundled when the local LeaseSet changes, when additional +Session Tags +are delivered, or if the messages have not been bundled in the previous minute. + +
+Obviously, the additional messages are currently bundled for specific purposes, +and not part of a general-purpose routing scheme. +
+ +Storage to the Floodfill Network Database
+ +As explained on the +network database page, +local +LeaseSets +are sent to floodfill routers in a +Database Store Message +wrapped in a +Garlic Message +so it is not visible to the tunnel's outbound gateway. + + + +Future Work
++The Garlic Message mechanism is very flexible and provides a structure for +implementing many types of mixnet delivery methods. +Together with the unused delay option in the +tunnel message Delivery Instructions, +a wide spectrum of batching, delay, mixing, and routing strategies are possible. +
+In particular, there is potential for much more flexibility at the outbound tunnel endpoint. +Messages could possibly be routed from there to one of several tunnels +(thus minimizing point-to-point connections), or multicast to several tunnels +for redundancy, or streaming audio and video. +
+Such experiments may conflict with the need to ensure security and anonymity, such +as limiting certain routing paths, restricting the types of I2NP messages that may +be forwarded along various paths, and enforcing certain message expiration times. +
+As a part of +ElGamal/AES encryption, +a garlic message contains a sender +specified amount of padding data, allowing the sender to take active countermeasures +against traffic analysis. +This is not currently used, beyond the requirement to pad to a multiple of 16 bytes. +
+Encryption of additional messages to and from the +floodfill routers. +
+ + +References
+- +The term garlic routing was first coined in Roger Dingledine's Free Haven +Master's thesis (June 2000), +see Section 8.1.1 authored by +Michael J. Freedman. +
- +Onion router publications +
- +Onion Routing on Wikipedia +
- +Garlic Routing on Wikipedia +
- +I2P Meeting 58 (2003) discussing the implementation of garlic routing +
- +Tor +
- +Free Haven publications +
- +Onion routing was first described in Hiding Routing Information +by David M. Goldschlag, Michael G. Reed, and Paul F. Syverson in 1996. +
-The term garlic routing was first coined by Michael Freedman in Roger Dingledine's Free Haven -Master's thesis (June 2000), which was derived from -Onion Routing. The main difference -from the method described by Freedman with I2P's garlic routing -is that the path is unidirectional - there is no "turning point" as seen in onion routing -or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible -and reliable delivery.{% endblock %} +{% endblock %} diff --git a/www.i2p2/pages/how_networkcomparisons.html b/www.i2p2/pages/how_networkcomparisons.html index 8f81cda7..ff88cdf7 100644 --- a/www.i2p2/pages/how_networkcomparisons.html +++ b/www.i2p2/pages/how_networkcomparisons.html @@ -169,6 +169,17 @@ these systems and I2P are related to I2P's threat mode and their out-proxy design (as opposed to providing both sender and receiver anonymity). There is source code available to both systems, but we are not aware of their use outside of academic environments.
+ +Mixminion / Mixmaster
[Mixminion] diff --git a/www.i2p2/pages/how_networkdatabase.html b/www.i2p2/pages/how_networkdatabase.html index 034e98dd..61f2d6ca 100644 --- a/www.i2p2/pages/how_networkdatabase.html +++ b/www.i2p2/pages/how_networkdatabase.html @@ -1,5 +1,5 @@ {% extends "_layout.html" %} -{% block title %}How the Network Database (netDb) Works{% endblock %} +{% block title %}The Network Database{% endblock %} {% block content %}@@ -28,8 +28,8 @@
When an I2P router wants to contact another router, they need to know some key pieces of data - all of which are bundled up and signed by the router into - a structure called the "RouterInfo", which is distributed under the key derived - from the SHA256 of the router's identity. The structure itself contains: + a structure called the "RouterInfo", which is distributed with the SHA256 of the router's identity + as the key. The structure itself contains:
- The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA signing key, and a certificate) @@ -95,7 +95,7 @@ RouterInfo specification
- There is no expiration during the first hour of uptime, as the persistent stored data may be old. +
- There is no expiration during the first hour of uptime, as the persistent stored data may be old. +
- There is no expiration if there are 25 or less RouterInfos.
- As the number of local RouterInfos grows, the expiration time shrinks, in an attempt to maintain - a reasonable number RouterInfos. + a reasonable number RouterInfos. The expiration time with less than 120 routers is 72 hours, + while expiration time with 300 routers is around 30 hours.
- RouterInfos containing SSU introducers expire in about an hour, as - the introducer list expires in about that time -
- Floodfills use a short expiration time for all local RouterInfos, as valid RouterInfos will - be frequently republished to them + the introducer list expires in about that time. +
- Floodfills use a short expiration time (1 hour) for all local RouterInfos, as valid RouterInfos will + be frequently republished to them.
- The tunnel gateway router (by specifying its identity) +
- The tunnel ID on that router to send messages with (a 4 byte number) +
- When that tunnel will expire. +
- The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA signing key and a certificate) +
- Additional encryption public key: used for end-to-end encryption of garlic messages +
- Additional signing public key: intended for LeaseSet revocation, but is currently unused. +
- Signature of all the LeaseSet data, to make sure the Destination published the LeaseSet. +
- Compile a list of bad router hashes or IPs, and announce the list through various means
@@ -611,11 +621,11 @@ This attack becomes more difficult as the network size grows.
As a partial defense against this attack, the algorithm used to determine Kademlia "closeness" varies over time. - Rather than using the Hash of the key (i.e. H(k))to determine closeness, + Rather than using the Hash of the key (i.e. H(k)) to determine closeness, we use the Hash of the key appended with the current date string, i.e. H(k + YYYYMMDD). A function called the "routing key generator" does this, which transforms the original key into a "routing key". In other words, the entire netdb keyspace "rotates" every day at UTC midnight. - Any partial-keyspace attack would have to be regenerated every day, as + Any partial-keyspace attack would have to be regenerated every day, for after the rotation, the attacking routers would no longer be close to the target key, or to each other.
@@ -679,7 +689,7 @@ This attack becomes more difficult as the network size grows. In other words, the Kademlia lookup is not iterative. This means the query capture attack described in Hashing it out in Public - much less likely, until iterative lookups are implemented. + is much less likely, until iterative lookups are implemented.DHT-Based Relay Selection
diff --git a/www.i2p2/pages/how_peerselection.html b/www.i2p2/pages/how_peerselection.html index 0a5870ce..de322589 100644 --- a/www.i2p2/pages/how_peerselection.html +++ b/www.i2p2/pages/how_peerselection.html @@ -62,7 +62,7 @@ about how long it takes for them to reply to a network database query, how often their tunnels fail, and how many new peers they are able to introduce us to, as well as simple data points such as when we last heard from them or when the last communication error occurred. The specific data points gathered -can be found in the code +can be found in the code@@ -90,7 +90,7 @@ send or receive on a single tunnel through the peer in a minute. For this estim performance in the previous minute.
-Capacity
+Capacity
The capacity calculation simply goes through the profile and estimates how many tunnels the peer @@ -125,7 +125,7 @@ groups - fast, high capacity, and standard.
- I2P is a free route mixnet - the message creator explicitly defines the path that messages will be sent out (the outbound tunnel), and the message recipient explicitly defines the path that messages will be received on (the - inbound tunnel). However, any of these hops along the path may inject an - arbitrary number of hops before forwarding the message to the next peer (though - the current implementation does not). -
- I2P is variable latency - each application (destination) determines its - own tradeoff of latency, throughput, bandwidth, and anonymity by configuring - the number of hops in their tunnels, the number of tunnels to keep in parallel, - and how frequently to rotate tunnels. In addition, there are plans to implement - nontrivial delays and batching strategies - whose existence is only known to the particular hop or tunnel gateway that - receives the message, allowing a mostly low latency mixnet to provide cover - traffic for higher latency communication (e.g. email). -
- I2P has no entry and exit points - all peers fully participate in the + inbound tunnel). + +
- I2P has no official entry and exit points - all peers fully participate in the mix, and there are no network layer in- or out-proxies (however, at the - application layer, a few outbound HTTP proxies exist at the moment) -
- I2P is fully distributed - there are no central controls or peers who - take on uneven responsibilities (beyond load balancing due to resource constraints). + application layer, a few proxies do exist) +
- I2P is fully distributed - there are no central controls or authorities. One could modify some routers to operate mix cascades (building tunnels and giving out the keys necessary to control the forwarding at the tunnel endpoint) or directory based profiling and selection, all without breaking compatibility with the rest of the network, but doing so is of course not necessary (and may even harm one's anonymity).
- Brute force attacks
- Timing attacks @@ -67,9 +103,11 @@ this list to include new attacks as they are identified.
- Partitioning attacks
- Predecessor attacks
- Harvesting attacks +
- Identification Through Traffic Analysis
- Sybil attacks
- Cryptographic attacks
- Floodfill attacks +
- Other Network Database attacks
- Attacks on centralized resources
- Development attacks
- Implementation attacks @@ -99,7 +137,17 @@ would want to make appropriate countermeasures, such as not communicating with unknown destinations, not publishing one's current leaseSet in the network database, actively rerouting the associated tunnels 'mid stream', throttling the inbound tunnels themselves, and/or using restricted routes with trusted links -to secure the local connection. +to secure the local connection. +
- +strict ordering of peers +
- +peer profiling and selection from a small group that changes slowly +
- +Limits on the number of tunnels routed through a single peer +
- +Prevention of peers from the same /16 IP range from being members of a single tunnel +
- +We do not use low-bandwidth "guard nodes" +
- +We use tunnel pools comprised of several tunnels, and traffic can shift from tunnel to tunnel. +
- +Tunnels are not long-lived; new tunnels are built every 10 minutes. +
- +Tunnel lengths are configurable. +While 3-hop tunnels are recommended for full protection, several applications and +services use 2-hop tunnels by default. +
- Greedy user attack: The most plausible attack against I2P will simply
- be people trying to consume significantly more resources than they are
- willing to contribute. The defense against this is twofold:
-
-
- First, for people who do not need very strong anonymity, simply set the tunnel length - to 0 hops (1 hop until strict ordering and - permuted lengths is implemented). This will - provide optimal throughput while still providing a degree of anonymity via - plausible deniability. In addition, it will not consume significant network - resources. -
- Second, for people who do need stronger anonymity, educate them so they - understand that without routing other people's traffic, their own anonymity - is weakened, so that if they want to consume significant network resources - while still being anonymous, they need to provide significant network - resources.
- Greedy user attack: This is simply
+ people trying to consume significantly more resources than they are
+ willing to contribute. The defense against this is:
-
+
- Set defaults so that most users provide resources to the network. + In I2P, users route traffic by default. In sharp distinction to + other networks, + over 95% of I2P users relay traffic for others. + +
- Provide easy configuration options so that users may increase their + contribution (share percentage) to the network. Display easy-to-understand + metrics such as "share ratio" so that users may see what they are contributing. +
+ Maintain a strong community with blogs, forums, IRC, and other means of communication. + - Starvation attack: A hostile user may attempt to harm the network by
creating a significant number of peers in the network who are not identified as
being under control of the same entity (as with Sybil). These nodes then
@@ -176,10 +266,9 @@ each with different costs and consequences:
-
I2P addresses these issues by maintaining profiles on the
peers, attempting to identify underperforming ones and simply ignoring
them, or using them rarely.
- In the process of fixing several problems and bugs with peer reachability
- in the 0.6.1.32 and 0.6.1.33 releases, we have significantly enhanced the
- ability to recognize and avoid troublesome peers. These efforts will
- continue in the 0.6.2.x release cycle.
+ We have significantly enhanced the
+ ability to recognize and avoid troublesome peers; however there are still
+ significant efforts required in this area.
- Flooding attack: A hostile user may attempt to flood the network,
a peer, a destination, or a tunnel. Network and peer flooding is possible,
@@ -202,20 +291,17 @@ each with different costs and consequences:
-
engineering practices and potentially requiring nontrivial certificates
(e.g. HashCash) to be attached to these expensive requests should mitigate
the issue, though there may be room for an attacker to exploit various
- bugs in the implementation.
+ bugs in the implementation.
- Floodfill DOS attack: A hostile user may attempt to harm the network by becoming a floodfill router. The current defenses against unreliable, intermittent, or malicious floodfill routers are poor. - To fix problems with floodfill peer selection - in the 0.6.1.32 and earlier releases, significantly enhancements in the - ability to recognize and avoid troublesome floodfill peers - were included in release 0.6.1.33. - However, there is much more to do. A floodfill router may provide bad or no response to lookups, and it may also interfere with inter-floodfill communication. - A brief summary of the issues is - listed on zzz.i2p. - These efforts will continue in the 0.6.2.x release cycle. + Some defenses and + peer profiling are implemented, + however there is much more to do. + For more information see the + network database page.
- +Network growth will make it more difficult to obtain a given proportion of the network +
- +Floodfill routers implement query limits as DOS protection +
- +"Hidden mode", which prevents a router from publishing its information to the netDb, +(but also prevents it from relaying data) is not widely used now but could be. +
- +Random port selection +
- +Point-to-Point Encryption of all traffic +
- +DH key exchange with no protocol bytes or other unencrypted constant fields +
- +Simultaneous use of both +TCP and +UDP transports. +UDP may be much harder for some Deep Packet Inspection (DPI) equipment to track. +
- +Padding at the transport layer to random lengths, especially during the connection handshake +
- +Study of packet size distribution signatures, and additional padding as necessary +
- +Development of additional transport methods that mimic SSL or other common protocols +
- +Review of padding strategies at higher layers to see how they affect packet sizes at the transport layer +
- +Review of methods implemented by various state-level firewalls to block Tor +
- +Working directly with DPI and obfuscation experts +
- +Maintaining backward compatibility +
- +The classic HashCash problem - +selecting HashCash values that are meaningful proofs of work on high-end machines, +while still being feasible on low-end machines such as mobile devices. +
- RouterInfo Javadoc + RouterInfo Javadoc
RouterInfo Expiration
@@ -106,13 +106,15 @@ In the current implementation, there are the following general policies:-
-
RouterInfo Persistent Storage
@@ -126,20 +128,25 @@The second piece of data distributed in the netDb is a "LeaseSet" - documenting - a group of tunnel entry points (leases) for a particular client destination. - Each of these leases specify the tunnel's gateway router (with the hash of its - identity), the tunnel ID on that router to send messages (a 4 byte number), and - when that tunnel will expire. The LeaseSet itself is stored in the netDb under + a group of tunnel entry points (leases) for a particular client destination. + Each of these leases specify the following information: +
-
+
- In addition to these leases, the LeaseSet includes the destination - itself (namely, the destination's 2048bit ElGamal encryption key, 1024bit DSA - signing key, and certificate) and an additional signing and - encryption public keys. The additional encryption public key is used for end-to-end encryption of - garlic messages. - The additional signing public key was intended for LeaseSet revocation but is currently unused. + In addition to these leases, the LeaseSet includes: +
-
+
@@ -148,9 +155,9 @@ LeaseSet specification
- Lease Javadoc + Lease Javadoc
@@ -159,6 +166,8 @@ A LeaseSet for a destination used only for outgoing connections is unpublished. It is never sent for publication to a floodfill router. "Client" tunnels, such as those for web browsing and IRC clients, are unpublished. + Servers will still be able to send messages back to those unpublished destinations, + because of I2NP storage messages. @@ -168,7 +177,7 @@ A LeaseSet may be revoked by publishing a new LeaseSet with zero leases. Revocations must be signed by the additional signing key in the LeaseSet. Revocations are not fully implemented, and it is unclear if they have any practical use. - This is the only planned use for the that signing key, so it is currently unused. + This is the only planned use for that signing key, so it is currently unused.
- LeaseSet Javadoc + LeaseSet JavadocEncrypted LeaseSets
@@ -210,14 +219,14 @@Floodfill
- The floodfill netDb is simple distributed storage mechanism. - The storage algorithm is simple- send the data to the closest peer that has advertised itself + The floodfill netDb is a simple distributed storage mechanism. + The storage algorithm is simple: send the data to the closest peer that has advertised itself as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them for the entry to be sent, verifying its proper insertion / distribution. If the verification peer doesn't reply, or they don't have the entry, the sender repeats the process. When the peer in the floodfill netDb receives a netDb - store from a peer not in the floodfill netDb, they send it to all of the peers - in the floodfill netDb. + store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers. + The peers selected are the ones closest (according to the XOR-metric) to a specific key.
Determining who is part of the floodfill netDb is trivial - it is exposed in each @@ -272,17 +281,18 @@ A floodfill router's only services that are in addition to those of non-floodfill routers are in accepting netDb stores and responding to netDb queries. Since they are generally high-bandwidth, they are more likely to participate in a high number of tunnels - (i.e. be a "relay" for others), but this not directly related to their distributed database services. + (i.e. be a "relay" for others), but this is not directly related to their distributed database services.
-Kademlia Closeness Metric
+Kademlia Closeness Metric
The netDb uses a simple Kademlia-style XOR metric to determine closeness. - 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 - (there is an additional daily keyspace rotation to increase the costs of Sybil attacks, - as explained below). + 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).
@@ -300,7 +310,7 @@ -LeaseSet Storage to Peers
+LeaseSet Storage to Peers
I2NP DatabaseStoreMessages containing the local LeaseSet are periodically exchanged with peers by bundling them in a garlic message along with normal traffic from the related Destination. @@ -354,7 +364,7 @@ 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) + of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.)
It then directly connects to each of the 7 peers @@ -373,7 +383,7 @@ The replies are specified to return via one of the router's inbound exploratory tunnels.
- Lookups are generally sent to the two "good" floodfill routers closest to the requested key, in parallel. + Lookups are generally sent to the two "good" (the connection doesn't fail) floodfill routers closest to the requested key, in parallel.
If the key is found locally by the floodfill router, it responds with a @@ -411,7 +421,7 @@
- Queries are sent throughmultiple routes simultaneously + Queries are sent through multiple routes simultaneously to reduce the chance of query failure.
@@ -482,7 +492,7 @@Destinations may be hosted on multiple routers simultaneously, by using the same - private and public keys (traditionally named eepPriv.dat files). + private and public keys (traditionally stored in eepPriv.dat files). As both instances will periodically publish their signed LeaseSets to the floodfill peers, the most recently published LeaseSet will be returned to a peer requesting a database lookup. As LeaseSets have (at most) a 10 minute lifetime, should a particular instance go down, @@ -566,7 +576,7 @@ metrics described above, this is a difficult scenario to handle. Tor's response can be much more nimble in the relay case, as the suspicious relays can be manually removed from the consensus. - Some possible responses in the I2P case, none of them satisfactory: + Some possible responses for the I2P network are listed below, however none of them is completely satisfactory:
Group size limits
diff --git a/www.i2p2/pages/how_peerselection_de.html b/www.i2p2/pages/how_peerselection_de.html index d4955b9a..b1abebda 100644 --- a/www.i2p2/pages/how_peerselection_de.html +++ b/www.i2p2/pages/how_peerselection_de.html @@ -23,7 +23,7 @@ mitteilen können. Auch einfachere Daten sind enthalten, wie etwa der Zeitpunkt des letzten Kontaktes oder wann der letzte Fehler in der Kommunikation war. Die einzelnen gesammelten Datenpunkte können im Monotone abgelesen werden (Link folgt). -Momentan gibt es keine "Löschstrategie, um sich der Profile der Knoten @@ -55,7 +55,7 @@ Netzwerk integriert ist und ob er nicht funktioniert.
Die Berechnung der Geschwindigkeit (wie im Quellkode implementiert) +here) --!> wird einfach mit den Profilen durchgeführt und schätzt, wie viele Daten wir durch einen einzigen Tunnel durch diesen Knoten in einer Minute senden oder empfangen können. Dafür werden einfach die Werte der @@ -77,7 +77,7 @@ dem derzeitigem Netzwerk zu bestätigen.
Kapazität/h3>
die Berechnung der Kapazität +here) --!> bearbeitet die Profile und schätzt wie viele von uns angefragte Tunnel der Knoten in der nächsten Stunde akzeptiert. Dafür betrachtet die Methode, wieviele Tunnel der Knoten in letzter Zeit akzeptiert hat, wie @@ -104,7 +104,7 @@ zur Effektivität im aktuellem Netzwerk.
Die Berechnung der Integration +here) --!> ist nur für die Netzwerkdatenbank notwendig (und, falls eingebaut, zum Erkennen und reparieren von Netzwerk`splits`). Zur Zeit wird es für nichts benutzt, da der Kode zum Erkennen der Splits in gut verbundenen Netzwerken @@ -131,7 +131,7 @@ Schwachstelle im derzeitigem Floodfillsystem behoben.
Die Berechung zum Versagen diff --git a/www.i2p2/pages/how_threatmodel.html b/www.i2p2/pages/how_threatmodel.html index 5acdc071..91600512 100644 --- a/www.i2p2/pages/how_threatmodel.html +++ b/www.i2p2/pages/how_threatmodel.html @@ -1,15 +1,18 @@ {% extends "_layout.html" %} {% block title %}I2P's Threat Model{% endblock %} -{% block content %}
What do we mean by "anonymous"?
+{% block content %} -Your level of anonymity can be described as how hard it is for someone -to find out information you don't want them to know - who you are, where +Updated August 2010, current as of router version 0.8 +
What do we mean by "anonymous"?
+ +Your level of anonymity can be described as "how hard it is for someone +to find out information you don't want them to know?" - who you are, where you are located, who you communicate with, or even when you communicate. "Perfect" anonymity is not a useful concept here - software will not make you indistinguishable from people that don't use computers or who are not on -the Internet. Instead, I2P is working to provide sufficient anonymity to meet the -real needs of whomever we can - from Joe Sixpack browsing porn to Tommy Trader -sharing files to Irene Insurgent organizing an upcoming action.
+the Internet. Instead, we are working to provide sufficient anonymity to meet the +real needs of whomever we can - from those simply browsing websites, to those exchanging +data, to those fearful of discovery by powerful organizations or states.The question of whether I2P provides sufficient anonymity for your particular needs is a hard one, but this page will hopefully assist in @@ -17,47 +20,80 @@ answering that question by exploring how I2P operates under various attacks so that you may decide whether it meets your needs.
We welcome further research and analysis on I2P's resistance to the threats described below. -Both review of existing literature (much of it focused on Tor) and original +More review of existing literature (much of it focused on Tor) and original work focused on I2P is needed.
-Mix summary
+Network Topology Summary
I2P builds off the ideas of many other systems, but a few key points should be kept in mind when reviewing related literature:
+ We have documented plans to implement + nontrivial delays and batching strategies + whose existence is only known to the particular hop or tunnel gateway that + receives the message, allowing a mostly low latency mixnet to provide cover + traffic for higher latency communication (e.g. email). + However we are aware that significant delays are required to provide meaningful + protection, and that implementation of such delays will be a significant challenge. + It is not clear at this time whether we will actually implement these delay features. +
+ In theory, routers along the message path may inject an + arbitrary number of hops before forwarding the message to the next peer, though + the current implementation does not. +
-Attacks
-Taking from the attacks and analyzes put forth in the + +
The Threat Model (Attacks)
++I2P design started in 2003, not long after the advent of +[Onion Routing], +[Freenet], and +[Tor]. +Our design benefits substantially from the research published around that time. +I2P uses several onion routing techniques, so we continue to benefit +from the significant academic interest in Tor. +
+Taking from the attacks and analysis put forth in the anonymity literature (largely Traffic Analysis: Protocols, Attacks, Design Issues and Open Problems), the following briefly describes a wide variety -of attacks as well as many of I2Ps defenses. We will update -this list to include new attacks as they are identified.
+of attacks as well as many of I2Ps defenses. We update +this list to include new attacks as they are identified. ++Included are some attacks that may be unique to I2P. +We do not have good answers for all these attacks, however +we continue to do research and improve our defenses. +
+In addition, many of these attacks are significantly easier than +they should be, due to the modest size of the current network. +While we are aware of some limitations that need to be addressed, +I2P is designed to support hundreds of thousands, or millions, of +participants. +As we continue to spread the word and grow the network, +these attacks will become much harder. +
+The +network comparisons and +"garlic" terminology pages may also be helpful +to review. +
+Index
+As a partial defense against routers trying to route all the network's traffic, +routers contain limits as to how many tunnels can be routed through a single peer. +As the network grows, these limits are subject to further adjustment. +Other mechanisms for peer rating, selection and avoidance +are discussed on the +peer selection page. +
+ +Timing attacks
@@ -120,10 +168,12 @@ automatic replies though - the streaming library does (with the SYN+ACK) as does message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).Without protocol scrubbing or higher latency, global active adversaries can -gain substantial information. As such, people concerned with these attacks should -increase the latency (per nontrivial delays or +gain substantial information. As such, people concerned with these attacks could +increase the latency (using nontrivial delays or batching strategies), include protocol scrubbing, or -other advanced tunnel routing techniques.
+other advanced tunnel routing techniques, +but these are unimplemented in I2P. +References: Low-Resource Routing Attacks Against Anonymous Systems @@ -139,31 +189,71 @@ peers that are online when a message successfully goes through. The cost of this attack is significant as the network grows, but may be feasible in some scenarios.
-I2P does not attempt to address this for low latency communication, -but does for peers who can afford delays (per nontrivial +
+In summary, if an attacker is at both ends of your tunnel at the same time, +he may be successful. +I2P does not have a full defense to this for low latency communication. +This is an inherent weakness of low-latency onion routing. +Tor provides a similar disclaimer. +
+Partial defenses implemented in I2P: +
+In the future, it could +for peers who can afford significant delays (per nontrivial delays and batching strategies). In addition, this is only relevant for destinations that other people know about - a private group whose destination is only known to trusted peers does not have to worry, as an adversary can't "ping" them to mount the attack.
+Reference: +One Cell Enough +
+ + +Denial of service attacks
There are a whole slew of denial of service attacks available against I2P, each with different costs and consequences:
-
-
+Also discussed on the + network database page (bootstrap attack). +
Predecessor attacks
@@ -275,14 +365,21 @@ target is located.I2P avoids this in four ways: first, the peers selected to participate in tunnels are not randomly sampled throughout the network - they are derived from the peer selection algorithm which breaks them -into tiers. Second, with strict ordering of peers +into tiers. Second, with strict ordering of peers in a tunnel, the fact that a peer shows up more frequently does not mean they're -the source. Third, with permuted tunnel length +the source. Third, with permuted tunnel length +(not enabled by default) even 0 hop tunnels can provide plausible deniability as the occasional variation of the gateway will look like normal tunnels. Fourth, with -restricted routes, only the peer with +restricted routes (unimplemented), only the peer with a restricted connection to the target will ever contact the target, while -attackers will merely run into that gateway.
+attackers will merely run into that gateway. ++The current +tunnel build method +was specifically designed to combat the predecessor attack. +See also the intersection attack. +
References: http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf @@ -290,21 +387,83 @@ which is an update to the 2004 predecessor attack paper http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf.
-Harvesting attacks
-The harvesting attack can be used for legal attacks and to help mounting +
Harvesting attacks
++"Harvesting" means compiling a list of users running I2P. +It can be used for legal attacks and to help other attacks by simply running a peer, seeing who it connects to, and -harvesting whatever references to other peers it can find. I2P itself is -built to optimize this attack, since there is the distributed network database -containing just this information. However, this by itself isn't a problem, -since there are ways to track down who is participating in the network with -essentially all public systems - I2P just makes it easier to do (and, in -turn, gains the ability to combat partitioning and provide well bounded -discovery time). With basic and -comprehensive restricted routes, +harvesting whatever references to other peers it can find. +
+I2P itself is not designed with effective defenses against +this attack, since there is the distributed network database +containing just this information. +The following factors make the attack somewhat harder in practice: +
+In the future, routers could use GeoIP to identify if they are in a particular +country where identification as an I2P node would be risky. +In that case, the router could automatically enable hidden mode, or +enact other restricted route methods. +
+ + + +Identification Through Traffic Analysis
++By inspecting the traffic into and out of a router, a malicious ISP +or state-level firewall could identify that a computer is running I2P. +As discussed above, I2P is not specifically designed +to hide that a computer is running I2P. However, several design decisions made +in the design of the +transport layer and protocols +make it somewhat difficult to identify I2P traffic: +
+Reference: +Breaking and Improving Protocol Obfuscation +
+ +Sybil attacks
@@ -322,28 +481,93 @@ IIP used identity. We currently have not implemented any particular technique to address Sybil, but do include placeholder certificates in the router's and destination's data structures which can contain a HashCash certificate of -appropriate value when necessary (or some other certificate proving scarcity). +appropriate value when necessary (or some other certificate proving scarcity). ++Requiring HashCash Certificates in various places has two major problems: +
+Various limitations on the number of routers in a given IP range restrict +the vulnerability to attackers that don't have the ability to put machines +in several IP blocks. +However, this is not a meaningful defense against a powerful adversary. +
+See the + network database page +for more Sybil discussion. +
+ +Cryptographic attacks
-We are still assuming the security of the cryptographic primitives explained -elsewhere. That includes the immediate detection of +We use strong cryptography with long keys, and +we assume the security of the industry-standard cryptographic primitives used in I2P, as documented +on the low-level cryptography page. +Security features +include the immediate detection of altered messages along the path, the inability to decrypt messages not addressed to you, -and defense against man-in-the-middle attacks. The network protocol and data structures +and defense against man-in-the-middle attacks. +The key sizes chosen in 2003 were quite conservative at the time, and are still longer than +those used in other anonymity networks. +We don't think the current key lengths are our biggest weakness, +especially for traditional, non-state-level adversaries; +bugs and the small size of the network are much more worrisome. +Of course, all cryptographic algorithms eventually become obsolete due to +the advent of faster processors, cryptographic research, and advancements in +methods such as rainbow tables, clusters of video game hardware, etc. +Unfortunately, I2P was not designed with easy mechanisms to lengthen keys or change +shared secret values while maintaining backward compatibility. +
+Upgrading the various data structures and protocols to support longer keys +will have to be tackled eventually, and this will be a +major undertaking, just as it will be for +others. +Hopefully, through careful planning, we can minimize the disruption, and +implement mechanisms to make it easier for future transitions. +
+In the future, +several I2P protocols and data structures support securely padding messages to arbitrary sizes, so messages could be made constant size or garlic messages could be modified randomly so that some cloves appear to contain more subcloves than they actually do. At the moment, however, garlic, tunnel, and end to end messages include simple random padding.
+ +Floodfill Anonymity attacks
In addition to the floodfill DOS attacks described above, floodfill routers are uniquely positioned -to learn about network participants, due to their centralized role +to learn about network participants, due to their role in the netDb, and the high frequency of communication with those participants. -The specific potential threats and corresponding defenses are a topic for further research. -
+This is somewhat mitigated because floodfill routers only manage a portion
+of the total keyspace, and the keyspace rotates daily, as explained.
+on the
+ network database page.
+The specific mechanisms by which routers communicate with floodfills have been
+ carefully designed.
+However, these threats should be studied further.
+The specific potential threats and corresponding defenses are a topic for future research.
+
+
+
+ - The new website is mirrored and uses DNS round-robin for external public access. +
- The website is mirrored and uses DNS round-robin for external public access.
- Routers now support multiple external reseed locations, however more reseed hosts may be needed, and the handling of unreliable or malicious reseed hosts may need improvement. @@ -365,7 +589,7 @@ not the operation of the network itself.
- Routers now better handle multiple unreliable floodfill peers. Malicious floodfills needs more study.
- The code is now stored in a distributed source control system. -
- Routers still rely on a single news host, update for this is TBD. +
- Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host. A malicious news host could feed a huge file, need to limit the size.
- Naming system services, including addressbook subscription providers, add-host services,
and jump services, could be malicious. Substantial protections for subscriptions were implemented
@@ -385,9 +609,9 @@ These attacks aren't directly on the network, but instead go after its developme
by either introducing legal hurdles on anyone contributing to the development
of the software, or by using whatever means are available to get the developers to
subvert the software. Traditional technical measures cannot defeat these attacks, and
-if someone threatened the lives of a developer's loved ones (or even just issuing a
-court order along with a gag order, under threat of prison), everyone should expect that
-the code would be modified.
+if someone threatened the life or livelihood of a developer (or even just issuing a
+court order along with a gag order, under threat of prison), we would have a big problem.
+
However, two techniques help defend against these attacks: @@ -407,22 +631,42 @@ However, two techniques help defend against these attacks: discussion forums (forum.i2p), and the software distribution sites, all available within I2P.
- Outbound connections (bids) -
- Inbound NTCP -
- Inbound SSU -
- Peer selection for inbound and outbound tunnels -
- Other-end inbound gateway -
- Netdb stores / shitlisting -
- Floodfill stores -
- Floodfill queries -
- Inter-floodfill flooding -
- SSU peer tests -
- SSU address determination -
- 0-hop tunnel - a tunnel where the gateway is also the endpoint
- 1-hop tunnel - a tunnel where the gateway talks directly to the endpoint -
- 2-(or more)-hop tunnel - a tunnel where there is at least one +
- 2-(or more)-hop tunnel - a tunnel where there is at least one intermediate tunnel participant. (the above diagram includes two 2-hop tunnels - one outbound from Alice, one inbound to Bob)
Other Network Database attacks
++ A hostile user may attempt to harm the network by + creating one or more floodfill routers and crafting them to offer + bad, slow, or no responses. + Several scenarios are discussed on the + network database page. +
+ +Central Resource Attacks
@@ -355,7 +579,7 @@ most of which are now distributed. Attacks on externally-reachable resources mainly affect the ability of new users to find us, not the operation of the network itself.
-
-
Implementation attacks
+Implementation attacks (bugs)
Try as we might, most nontrivial applications include errors in the design or implementation, and I2P is no exception. There may be bugs that could be exploited to attack the anonymity or security of the communication running over I2P in unexpected ways. To help withstand attacks against the design or protocols in use, we publish -all designs and documentation in the open and asking for any and all criticism with -the hope that many eyes will improve the system. In addition, the code is being +all designs and documentation and solicit review and criticism with +the hope that many eyes will improve the system. +We do not believe in +security through obscurity. +
+In addition, the code is being treated the same way, with little aversion towards reworking or throwing out something that isn't meeting the needs of the software system (including ease of modification). Documentation for the design and implementation of the network and the software components are an essential part of security, as without them it is unlikely that developers would be willing to spend the time to learn the software -enough to identify shortcomings and bugs.
+enough to identify shortcomings and bugs. ++Our software is likely, in particular, to contain bugs related to denial of service +through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues in the router console, +and other vulnerabilities to non-standard inputs via the various protocols. +
+I2P is still a small network with a small development community and almost no +interest from academic or research groups. +Therefore we lack the analysis that +other anonymity networks +may have received. We continue to recruit people to +get involved and help. +
+ +Other Defenses
@@ -437,23 +681,6 @@ blocking by only a subset of peers would tend to segment the network, exacerbate reachability problems, and decrease overall reliability. Therefore we would want to agree on a particular blocklist and enable it by default. --Any blocking within i2p would have to be implemented at the following -places in the code to be fully effective. -Different places address the various possible malicious behaviors. -
-
-
Blocklists are only a part (perhaps a small part) of an array of defenses @@ -467,15 +694,16 @@ If a blocklist is hosted at a central location with automatic updates the network is vulnerable to a central resource attack. Automatic subscription to a list gives the list provider the power to shut -the i2p network down. Completely. So we probably won't be doing that. -Inclusion in i2pupdate files perhaps? Signed or unsigned? -In-I2P subscription? +the i2p network down. Completely.
-Initial test results -show that the common splist.txt blocklist is overly broad for our use - at the least -we don't want to block Tor users that are in splist. -Level1 + bogon + (maybe) level2 is more reasonable? -But we don't want to block potential anonymity researchers at .edu locations. +Currently, a default blocklist is distributed with our software, +listing only the IPs of past DOS sources. +There +is no automatic update mechanism. +Should a particular IP range implement serious attacks on the I2P network, +we would have to ask people to update their blocklist manually through +out-of-band mechanisms such as forums, blogs, etc. +
{% endblock %} diff --git a/www.i2p2/pages/how_tunnelrouting.html b/www.i2p2/pages/how_tunnelrouting.html index f30185d4..46dedeaf 100644 --- a/www.i2p2/pages/how_tunnelrouting.html +++ b/www.i2p2/pages/how_tunnelrouting.html @@ -1,22 +1,35 @@ {% extends "_layout.html" %} -{% block title %}How Tunnel Routing Works{% endblock %} -{% block content %}Note: these documents have not yet been updated to include the changes made -in I2P 0.5 - the new -tunnel -routing and encryption algorithms, addressing several -issues (with the groundwork for addressing -others). +{% block title %}Tunnel Overview{% endblock %} +{% block content %} ++Updated August 2010 for release 0.8 +
-As briefly explained in the intro, I2P builds virtual "tunnels" - +
Tunnel Overview
++This page contains an overview of I2P tunnel terminology and operation, with +links to more technical pages, details, and specifications. +
+As briefly explained in the introduction, I2P builds virtual "tunnels" - temporary and unidirectional paths through a sequence of routers. These -tunnels can be categorized as either inbound tunnels (where everything -given to it goes towards the creator of the tunnel) and outbound tunnels +tunnels are classified as either inbound tunnels (where everything +given to it goes towards the creator of the tunnel) or outbound tunnels (where the tunnel creator shoves messages away from them). When Alice wants to send a message to Bob, she will (typically) send it out one of her existing outbound tunnels with instructions for that tunnel's endpoint to forward it to the gateway router for one of Bob's current inbound tunnels, which in turn passes it to Bob.
+
++A: Outbound Gateway (Alice) +B: Outbound Participant +C: Outbound Endpoint +D: Inbound Gateway +E: Inbound Participant +F: Inbound Endpoint (Bob) +
+Tunnel vocabulary
-
@@ -32,77 +45,105 @@ tunnels, which in turn passes it to Bob.
- - Tunnel lifetime - how long a particular tunnel is - supposed to be in operation for (each client specifies this when contacting - their router, and the router makes sure sufficient tunnels meeting that - criteria are built) +
- Tunnel ID - A 4 byte integer + different for each hop in a tunnel, and unique among all tunnels on a router. + Chosen randomly by the tunnel creator.
Tunnel information
-Routers performing the three roles (gateway, endpoint, participant) are given -different pieces of data to accomplish their tasks:
+Tunnel Build Information
+Routers performing the three roles (gateway, participant, endpoint) are given +different pieces of data in the initial +Tunnel Build Message +to accomplish their tasks:
- The tunnel gateway gets:
-
-
- tunnel signing key - a DSA private key for authenticating - messages sent down the tunnel -
- tunnel encryption key - an AES private key for encrypting - messages and instructions to the endpoint -
- tunnel id - 4 byte integer (each router can obviously only have - one tunnel with each tunnel id at any time) -
- next hop [optional] - what router is the next one in the path -
- configuration key - an AES private key used by the tunnel's - creator for updating the tunnel later on (if necessary) +
- tunnel encryption key - an AES private key for encrypting + messages and instructions to the next hop +
- tunnel IV key - an AES private key for double-encrypting + the IV to the next hop +
- reply key - an AES public key for encrypting + the reply to the tunnel build request +
- reply IV - the IV for encrypting + the reply to the tunnel build request +
- tunnel id - 4 byte integer (inbound gateways only) + +
- next hop - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint) +
- next tunnel id - The tunnel ID on the next hop +
+ - All intermediate tunnel participants get:
+
-
+
- tunnel encryption key - an AES private key for encrypting + messages and instructions to the next hop +
- tunnel IV key - an AES private key for double-encrypting + the IV to the next hop +
- reply key - an AES public key for encrypting + the reply to the tunnel build request +
- reply IV - the IV for encrypting + the reply to the tunnel build request +
- tunnel id - 4 byte integer + +
- next hop - what router is the next one in the path +
- next tunnel id - The tunnel ID on the next hop
- The tunnel endpoint gets:
-
-
- tunnel verification key - a DSA public key for authenticating - messages sent down the tunnel -
- tunnel encryption key - an AES private key for decrypting - messages and instructions sent by the gateway -
- tunnel id - 4 byte integer (each router can obviously only have - one tunnel with each tunnel id at any time) -
- configuration key - an AES private key used by the tunnel's - creator for updating the tunnel later on (if necessary) -
- - All tunnel participants get:
-
-
-
- tunnel verification key - a DSA public key for authenticating - messages sent down the tunnel -
- tunnel id - 4 byte integer (each router can obviously only have - one tunnel with each tunnel id at any time) -
- next hop [optional] - what router is the next one in the path -
- configuration key - an AES private key used by the tunnel's - creator for updating the tunnel later on (if necessary) +
- tunnel encryption key - an AES private key for encrypting + messages and instructions to the the endpoint (itself) +
- tunnel IV key - an AES private key for double-encrypting + the IV to the endpoint (itself) +
- reply key - an AES public key for encrypting + the reply to the tunnel build request (outbound endpoints only) +
- reply IV - the IV for encrypting + the reply to the tunnel build request (outbound endpoints only) +
- tunnel id - 4 byte integer (outbound endpoints only) + +
- reply router - the inbound gateway of the tunnel to send the reply through (outbound endpoints only) +
- reply tunnel id - The tunnel ID of the reply router (outbound endpoints only)
In addition, there are a series of options that the creator of a tunnel sends -when requesting a router to join a tunnel, such as the expiration date. In I2P -3.0, options specifying the pooling, mixing, and chaff generation settings will -be honored, and limits on the quantity and size of messages allowed during the -tunnel's lifetime will be implemented earlier (e.g. no more than 300 messages or -1MB per minute).
++Details are in the +tunnel creation specification. +
-Tunnel length
+Tunnel pooling
++Several tunnels for a particular purpose may be grouped into a "tunnel pool", +as described in the +tunnel specification. +This provides redundancy and additional bandwidth. +The pools used by the router itself are called "exploratory tunnels". +The pools used by applications are called "client tunnels". +
+ + + +Tunnel length
As mentioned above, each client requests that their router provide tunnels to -include at least a certain number of hops (plus other criteria that aren't -honored yet, such as bandwidth limits, etc). The decision as to how many routers +include at least a certain number of hops. +The decision as to how many routers to have in one's outbound and inbound tunnels has an important effect upon the latency, throughput, reliability, and anonymity provided by I2P - the more peers that messages have to go through, the longer it takes to get there and the more likely that one of those routers will fail prematurely. The less routers in a tunnel, the easier it is for an adversary to mount traffic analysis attacks and -pierce someone's anonymity.
+pierce someone's anonymity. +Tunnel lengths are specified by clients via +I2CP options. +The maximum number of hops in a tunnel is 7. + +0-hop tunnels
With no remote routers in a tunnel, the user has very basic plausible @@ -121,54 +162,92 @@ if the adversary ran a sufficient number of routers such that the single remote router in the tunnel is often one of those compromised ones, they would be able to mount the above statistical traffic analysis attack.
-2-hop (or more) tunnels
+2-hop tunnels
With two or more remote routers in a tunnel, the costs of mounting the traffic -analysis attack increases, since all remote routers would have to be compromised +analysis attack increases, since many remote routers would have to be compromised to mount it.
-The router will by default use 2-hop tunnels, at least in the main -distribution. Prior to the 0.2.5 release, all tunnels were 1-hop by default.
+3-hop (or more) tunnels
+To reduce the susceptibility to some attacks, +3 or more hops are recommended for the highest level of protection. +recent studies +also conclude that more than 3 hops does not provide additional protection. -Tunnel pooling
-[explain tunnel pools, how we keep a free inbound pool, an outbound pool, and -a client inbound pool, and how the pools are refreshed every minute or so, using -the router's default settings]
-Tunnel testing
-All tunnels are periodically tested by their creator by sending a -DeliveryStatusMessage out the tunnel and bound for another inbound tunnel -(testing both tunnels at once). If either fails, both are marked as no longer -functional, and if they were used for a client's inbound tunnel, a new leaseSet -is created. Other techniques can be used to test tunnels later on, such as -garlic wrapping a number of tests into cloves, testing individual tunnel -participants separately (and using the tunnel configuration key to update the -next hop to work around failures), etc, but that is not implemented at the -moment. +
Tunnel default lengths
+The router uses 2-hop tunnels by default for its exploratory tunnels. +Client tunnel defaults are set by the application, using +I2CP options. +Most applications use 2 or 3 hops as their default.
+ + +Tunnel testing
+All tunnels are periodically tested by their creator by sending a +DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel +(testing both tunnels at once). If either fails a number of consecutive tests, it is marked as no longer +functional. If it was used for a client's inbound tunnel, a new leaseSet +is created. +Tunnel test failures are also reflected in the +capacity rating in the peer profile. +
+ +Tunnel creation
Tunnel creation is handled by garlic routing -a TunnelCreateMessage to a router, requesting that they participate in the +a Tunnel Build Message to a router, requesting that they participate in the tunnel (providing them with all of the appropriate information, as above, along with a certificate, which right now is a 'null' cert, but will support hashcash -or other non-free certificates when necessary). The message also includes a -SourceRouteReplyBlock, which allows the router to encrypt their -TunnelCreateStatusMessage into a SourceRouteReplyMessage, which is sent to -another router (specified in the SourceRouteReplyBlock), who then decrypts the -rest of the SourceRouteReplyBlock, reads out the delivery instructions contained -therein, and forwards the TunnelCreateStatusMessage accordingly. (the delivery -instructions can specify delivery to a specific router or can point at a tunnel) +or other non-free certificates when necessary). +That router forwards the message to the next hop in the tunnel. +Details are in the +tunnel creation specification.
-Issues/TODO
+ +Tunnel encryption
+Multi-layer encryption is handled by garlic encryption +of tunnel messages. +Details are in the +tunnel specification. +The IV of each hop is encrypted with a separate key as explained there. +
+ + +Future Work
+- +Other tunnel test techniques could be used, such as +garlic wrapping a number of tests into cloves, testing individual tunnel +participants separately, +etc. +
- +Move to 3-hop exploratory tunnels defaults. +
- +In a distant future release, +options specifying the pooling, mixing, and chaff generation settings may be implemented. +
- +In a distant future release, +limits on the quantity and size of messages allowed during the +tunnel's lifetime may be implemented (e.g. no more than 300 messages or +1MB per minute). +
See Also
-
-
- We will assign unique tunnel IDs for each router in the tunnel, rather - than having a single ID across the whole tunnel. this would make traffic - analysis even harder -
- Get rid of the sourceRouteBlock stuff -
- Should inbound tunnels that will be used by clients ever be used for - general messages (network database, etc), rather than being free for use until - its allocated? -
- I2P 3.0 tunnel mixing / pooling details -
- Tunnel throttling details -
The I2P Client Protocol (I2CP) exposes a strong separation of concerns between the router and any client that wishes to communicate over the network. It enables secure and asynchronous messaging by sending and receiving messages over a @@ -8,24 +10,29 @@ single TCP socket, yet never exposing any private keys and authenticating itself to the router only through signatures. With I2CP, a client application tells the router who they are (their "destination"), what anonymity, reliability, and latency tradeoffs to make, and where to send messages. In turn the router uses -I2CP to tell the client when any messages have arrived, to request authorization -for some tunnels to be used, and, if necessary, to notify the client that the -router is under attack and unable to operate safely.
+I2CP to tell the client when any messages have arrived, and to request authorization +for some tunnels to be used. + -As the I2CP requires all client libraries to provide an implementation of the -end to end encryption (including ElGamal/AES+SessionTag), -the protocol itself isn't likely to be adopted for normal client applications -(except for those implemented in Java that can use the existing I2P -Client SDK). +
+The protocol itself has only been implemented in Java, to provide the +Client SDK. This SDK is exposed in the i2p.jar package, which implements the client-side of I2CP. Clients should never need to access the router.jar package, which contains the router itself and the router-side of I2CP.
++While implementing the client side of I2CP in a non-Java language is certainly feasible, +a non-Java client would also have to implement the +streaming library for TCP-style connections. +Together, implementing I2CP and the streaming library would be a sizable task. +
+Applications can take advantage of the base I2CP plus the streaming and datagram libraries -by using the Simple Anonymous Messaging or BOB protocols, +by using the Simple Anonymous Messaging or BOB protocols, which do not require clients to deal with any sort of cryptography. Also, clients may access the network by one of several proxies - HTTP, CONNECT, and SOCKS 4/4a/5. @@ -33,21 +40,13 @@ Alternatively, Java clients may access those libraries in ministreaming.jar and So there are several options for both Java and non-Java applications.
-I2CP end-to-end encryption was disabled in I2P release 0.6, -leaving in place the end-to-end garlic encryption. -However, client libraries must still implement public/private key signing -for LeaseSets, and key management. -
- -While the I2CP has been quite stable since its inception in -August of 2003, there have been several messages added. -Here is the -I2CP Protocol Specification Version 0.9 -(PDF) dated August 28, 2003. -That document also references the -Common Data Structures Specification Version 0.9. -There have been several changes to the protocol since that time, -and many of the messages in those documents were never implemented. +
Client-side end-to-end encryption (encrypting the data over the I2CP connection) +was disabled in I2P release 0.6, +leaving in place the ElGamal/AES end-to-end encryption +which is implemented in the router. +The only cryptography that client libraries must still implement is +DSA public/private key signing +for LeaseSets and Session Configurations, and management of those keys.
In a standard I2P installation, port 7654 is used by java clients to communicate @@ -56,113 +55,26 @@ By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, set the router advanced configuration option i2cp.tcp.bindAllInterfaces=true and restart.
-I2CP Definition
+I2CP Protocol Specification
-Note - The following information is extracted from the current code base, -however it may be incomplete and/or inaccurate. Check the code to be sure. -Rather than completely document the messages here, we refer you to the -old protocol and data specifications linked above, together with the actual code. -
-R->C is Router to Client; -C->R is Client to Router -
-
| Message | Direction | Type - |
|---|---|---|
| -BandwidthLimitsMessage (new in release 0.7.2) - | R->C - | 23 - |
| -CreateLeaseSetMessage - | C->R - | 4 - |
| -CreateSessionMessage - | C->R - | 1 - |
| -DestLookupMessage (new in release 0.7) - | C->R - | 34 - |
| -DestReplyMessage (new in release 0.7) - | R->C - | 35 - |
| -DestroySessionMessage - | C->R - | 3 - |
| -DisconnectMessage - | R->C - | 30 - |
| -GetBandwidthLimitsMessage (new in release 0.7.2) - | C->R - | 8 - |
| -GetDateMessage - | C->R - | 32 - |
| -MessagePayloadMessage - | R->C - | 31 - |
| -MessageStatusMessage - | R->C - | 22 - |
| -ReceiveMessageBeginMessage - | R->C - | 6 - |
| -ReceiveMessageEndMessage - | C->R - | 7 - |
| -ReconfigureSessionMessage (new in release 0.7.1) - | C->R - | 2 - |
| -ReportAbuseMessage - | R->C - | 29 - |
| -RequestLeaseSetMessage - | R->C - | 21 - |
| -SendMessageExpiresMessage (new in release 0.7.1) - | C->R - | 36 - |
| -SendMessageMessage - | C->R - | 5 - |
| -SessionStatusMessage - | R->C - | 20 - |
| -SetDateMessage - | R->C - | 33 - |
I2CP Initialization
When a client connects to the router, it first sends a single protocol version byte (0x2A). -Then it sends a GetDateMessage and waits for the SetDateMessage response. -Next, it sends a CreateSessionMessage containing the session configuration. -It next awaits a RequestLeaseSetMessage from the router, indicating that inbound tunnels +Then it sends a GetDate Message and waits for the SetDate Message response. +Next, it sends a CreateSession Message containing the session configuration. +It next awaits a RequestLeaseSet Message from the router, indicating that inbound tunnels have been built, and responds with a CreateLeaseSetMessage containing the signed LeaseSet. The client may now initiate or receive connections from other I2P destinations.
I2CP Options
The following options are traditionally passed to the router via -a SessionConfig contained in a CreateSessionMessage or a ReconfigureSessionMessage. +a SessionConfig contained in a CreateSession Message or a ReconfigureSession Message.
| Option | Recommended Arguments | Allowable Range | Default | Description @@ -194,6 +106,7 @@ a SessionConfig contained in a CreateSessionMessage or a ReconfigureSessionMessa |
|---|---|---|---|---|
| i2cp.dontPublishLeaseSet | true, false | false | Should generally be set to true for clients and false for servers | |
| i2cp.messageReliability | BestEffort, Guaranteed | BestEffort | Guaranteed is disabled + | |
| explicitPeers | null | Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only |
Note: Large quantity, length, or variance settings may cause significant performance or reliability problems. @@ -225,7 +138,7 @@ Note: All arguments, including numbers, are strings. True/false values are case- Anything other than case-insensitive "true" is interpreted as false. All option names are case-sensitive. -
I2CP Data Format and Multiplexing
+I2CP Payload Data Format and Multiplexing
The end-to-end messages handled by I2CP (i.e. the data sent by the client in a SendMessageMessage and received by the client in a MessagePayloadMessage) is gzipped with a standard 10-byte gzip @@ -249,5 +162,53 @@ turns the gzip effort setting to 0, which may save a little CPU.
+Data integrity is verified with the standard gzip CRC-32 as +specified by RFC 1952. +
+ + +Future Work
+- +There is an in-JVM version of I2CP that uses a Java pipe instead of real sockets. +However, it still does message serialization and deserialization. +It should be refactored to pass the Message objects directly. +
- +The protocol is highly inefficient, with three I2CP messages for every outgoing message, +and four I2CP messages for every incoming message. +Perhaps the acknowledgments and queueing could be eliminated, especially for the in-JVM version. +This would eliminate a lot of data structures and memory for holding +unacknowledged messages. +
- +Implement i2cp.messageReliablity=none to disable the two Message Status Message responses +to a Send Message Message. +Make it the default? At least via the streaming lib. +
- +The API does not support Dest Lookups or Get Bandwidth Limits Messages in a standard session, +only in a simple session. +This should be fixed. +
- +The API does not support parallel Dest Lookups or Get Bandwidth Limits Messages in a session. +This should be fixed. +
- +Implement I2CP and the streaming library in another programming language. +
- +Is the initial Get Date / Set Date handshake required? +
- +There is currently no authorization mechanism. +This would be required on the socket version only, not in the in-JVM version. +
- +Private Keys are included in the Create Lease Set message, +are they really required? Revocation is unimplemented. +
- +Some improvements may be able to use messages previously defined but not implemented. +For reference, here is the +I2CP Protocol Specification Version 0.9 +(PDF) dated August 28, 2003. +That document also references the +Common Data Structures Specification Version 0.9. +
I2P Control Protocol (I2CP) Specification
+Overview
++This page specified the I2P Control Protocol (I2CP), +which is the interface between clients and the router. +Java clients will use the I2CP client API, which implements this protocol. +Non-Java clients will most likely use a higher-layer protocol +such as SAM or BOB. +More information is on the I2CP Overview page. +
+ + + +Sessions
++The protocol was designed to handle multiple "sessions", each with a 2-byte session ID, +over a single TCP connection. +This does not appear to be fully implemented. +Do not attempt to use multiple sessions on a single I2CP connection. +
+ ++It also appears that there are some provisions for a single client to talk to multiple +routers over separate connections. This is also untested, +and probably not useful. +
+ ++It does not appear that there is currently a way for a session to be +maintained after a disconnect, or to be +recovered on a different +I2CP connection. +
+ + + + +Example Message Sequences
+Standard Session Establish
+
+{% filter escape %}
+ Client Router
+
+ ---------------------> Protocol Byte (0x2a)
+ ---------------------> Get Date Message
+ Set Date Message <---------------------
+ ---------------------> Create Session Message
+ Session Status Message <---------------------
+Request LeaseSet Message <---------------------
+ ---------------------> Create LeaseSet Message
+{% endfilter %}
+
+
+
+Get Bandwidth Limits (Simple Session)
+
+{% filter escape %}
+ Client Router
+
+ ---------------------> Protocol Byte (0x2a)
+ ---------------------> Get Bandwidth Limits Message
+Bandwidth Limits Message <---------------------
+{% endfilter %}
+
+
+
+
+Destination Lookup (Simple Session)
+
+{% filter escape %}
+ Client Router
+
+ ---------------------> Protocol Byte (0x2a)
+ ---------------------> Dest Lookup Message
+ Dest Reply Message <---------------------
+{% endfilter %}
+
+
+
+
+Outgoing Message
+(existing session)
+
+{% filter escape %}
+ Client Router
+
+ ---------------------> Send Message Message
+ Message Status Message <---------------------
+ (accepted)
+ Message Status Message <---------------------
+ (succeeded)
+{% endfilter %}
+
+
+
+
+
+Incoming Message
+(existing session)
+
+{% filter escape %}
+ Client Router
+
+ Message Status Message <---------------------
+ (available)
+ ---------------------> Receive Message Begin Message
+ Message Payload Message <---------------------
+ ---------------------> Receive Message End Message
+{% endfilter %}
+
+
+
+
+
+Common structures
+ + + +I2CP message header
+Description
++ Common header to all I2CP messages, containing the message length and message type. +
+Contents
+- + 4 byte Integer specifying the length of the message body +
- + 1 byte Integer specifying the message type. +
- + The I2CP message body, 0 or more bytes +
Notes
++Actual message length limit is about 64 KB. +
+ + + + +Message ID
+Description
++Uniquely identifies a message waiting on a particular router at a +point in time. +
+Contents
+- +4 byte Integer +
Notes
++Message IDs are unique within a session only; they are not globally unique. +
+ + + + +Payload
+Description
++This structure is the content of a message being delivered from one +Destination to another. +
+Contents
+- +4 byte Integer length +
- +That many bytes +
Notes
++The payload is in a gzip format as specified on the +I2CP Overview page. +
+ + + + +Session Config
+Description
++Defines the configuration options for a particular client session. +
+Contents
+- +Destination +
- +Mapping of options +
- +Creation Date +
- +DSA Signature of the previous 3 fields, signed by the +Signing Private Key +
Notes
++The options are specified on the +I2CP Overview page. +
+ + + + + +Session ID
+Description
++Uniquely identifies a session on a particular router at a point in +time. +
+Contents
+- +2 byte Integer +
Notes
++
+ + + + +Messages
+Message Types
+| Message | Direction | Type + |
|---|---|---|
| + +BandwidthLimitsMessage + + + | R->C + | 23 + |
| + +CreateLeaseSetMessage + + | C->R + | 4 + |
| + +CreateSessionMessage + + | C->R + | 1 + |
| + +DestLookupMessage + + | C->R + | 34 + |
| + +DestReplyMessage + + | R->C + | 35 + |
| + +DestroySessionMessage + + | C->R + | 3 + |
| + +DisconnectMessage + + | bidir. + | 30 + |
| + +GetBandwidthLimitsMessage + + | C->R + | 8 + |
| + +GetDateMessage + + | C->R + | 32 + |
| + +MessagePayloadMessage + + | R->C + | 31 + |
| + +MessageStatusMessage + + | R->C + | 22 + |
| + +ReceiveMessageBeginMessage + + | C->R + | 6 + |
| + +ReceiveMessageEndMessage + + | C->R + | 7 + |
| + +ReconfigureSessionMessage + + | C->R + | 2 + |
| + +ReportAbuseMessage + + | bidir. + | 29 + |
| + +RequestLeaseSetMessage + + | R->C + | 21 + |
| + +SendMessageMessage + + | C->R + | 5 + |
| + +SendMessageExpiresMessage + + | C->R + | 36 + |
| + +SessionStatusMessage + + | R->C + | 20 + |
| + +SetDateMessage + + | R->C + | 33 + |
Bandwidth Limits
+Description
++Tell the client what the bandwidth limits are. +Sent from Router to Client in response to a Get Bandwidth Limits Message. +
+Contents
+- +4 byte Integer +Client inbound limit (KBps) +
- +4 byte Integer +Client outbound limit (KBps) +
- +4 byte Integer +Router inbound limit (KBps) +
- +4 byte Integer +Router inbound burst limit (KBps) +
- +4 byte Integer +Router outbound limit (KBps) +
- +4 byte Integer +Router outbound burst limit (KBps) +
- +4 byte Integer +Router burst time (seconds) +
- +Nine 4-byte Integers +undefined +
Notes
++Currently, the client limits are the only values set, +and are actually the router limits. All the values labeled as router limits are always 0. +As of release 0.7.2. +
+ + + +Create Lease Set
+Description
++This message is sent in response to a RequestLeaseSetMessage and contains all +of the Lease structures that should be published to the I2NP Network Database. +Sent from Client to Router. +
+Contents
+- +Session ID +
- +Signing Private Key +
- +Private Key +
- +LeaseSet +
Notes
++The SigningPrivateKey matches the SigningPublicKey from within the +LeaseSet, as does the PrivateKey with the PublicKey. The Signing keys are +necessary to allow the router to revoke the LeaseSet if the client goes offline, +and the normal keys are necessary for decrypting garlic routed messages. The +LeaseSet granted may include Lease structures for tunnels pointing at another +router if the client is actively connected to multiple routers with Leases granted +to each. +Really? +Revocation is unimplemented. +Connection to multiple routers is untested. +
+ + + +Create Session
+Description
++This message is sent from a client to initiate a session, where a session is defined +as a single Destination's connection to the network, to which all messages for +that Destination will be delivered and from which all messages that +Destination sends to any other Destination will be sent through. +Sent from Client to Router. +The router responds with a Session Status Message. +
+Contents
+ + +Notes
++The second message sent by the client after sending the Get Date Message and receiving the Set Date Message response. +If the Date in the Session Config is too far from the router's current time, the session will be rejected. +If there is already a session on the router for this Destination, the session will be rejected. +
+ + + +Dest Lookup
+Description
++ +Sent from Client to Router. +The router responds with a Dest Reply Message. +
+Contents
+- +SHA-256 Hash +
Notes
++Only one Dest Lookup may be outstanding at a time. +Currently supported only by client sessions set up with I2PSimpleSession. +These limitations should be fixed. +As of release 0.7. +
+ + + +Dest Reply
+Description
++Sent from Router to Client in response to a Dest Lookup Message. +
+Contents
+- +Destination (optional) +
Notes
++If the Destination is not present, the lookup failed. +As of release 0.7. +In the future, +we should return the Hash instead of nothing if the lookup failed, +so we can have multiple lookups outstanding and correlate the replies. +
+ + + +Destroy Session
+Description
++This message is sent from a client to destroy a session. +Sent from Client to Router. +The router responds with a Session Status Message. +
+Contents
+- +Session ID +
Notes
++The router at this point should release all resources related to the session. +
+ + + +Disconnect
+Description
++Tell the other party that there are problems and the current connection is about to +be destroyed. This does not necessarily end a session. +Sent either from router to client or from client to router. +
+Contents
+- +Reason String +
Notes
++Only implemented in the router-to-client direction. +Disconnecting probably does end a session, in practice. +
+ + + +Get Bandwidth Limits
+Description
++Request that the router state what its current bandwidth limits are. +Sent from Client to Router. +The router responds with a Bandwidth Limits Message. +
+Contents
+None + +Notes
++Currently supported only by client sessions set up with I2PSimpleSession. +These limitations should be fixed. +As of release 0.7.2. +
+ + + +Get Date
+Description
++Sent from Client to Router. +The router responds with a Set Date Message. +
+Contents
+None + +Notes
++Generally the first message sent by the client after sending the protocol version byte. +
+ + + +Message Payload
+Description
++Deliver the payload of a message to the client. +Sent from Router to Client. +The client responds with a Receive Message End Message. +
+Contents
+- +Session ID +
- +Message ID +
- +Payload +
Notes
++
+ + + +Message Status
+Description
++Notify the client of the delivery status of an incoming or outgoing message. +Sent from Router to Client. +If this message indicates that an incoming message is available, +the client responds with a Receive Message Begin Message. +For an outgoing message, this is a response to a +Send Message Message or +Send Message Expires Message. +
+Contents
+- +Session ID +
- +Message ID +
- +1 byte Integer status +
- +4 byte Integer size +
- +4 byte Integer nonce +
Notes
++The known status values are 0 for message is available, 1 for accepted, 2 for best +effort succeeded, 3 for best effort failed, 4 for guaranteed succeeded, 5 for +guaranteed failed. The size Integer specifies the size of the available +message and is only relevant for status = 0. +Even though guaranteed is unimplemented, (best effort is the only service), the current +router implementation uses the guaranteed status codes, not the best effort codes. +
++When status = 1 (accepted), the nonce matches the nonce in the +Send Message Message, and the included Message ID +will be used for subsequent success or failure notification. +Otherwise, the nonce may be ignored. +
+ + + +Receive Message Begin
+Description
++Request the router to deliver a message that it was previously notified of. +Sent from Client to Router. +The router responds with a Message Payload Message. +
+Contents
+- +Session ID +
- +Message ID +
Notes
++The ReceiveMessageBeginMessage is sent as a response to a +MessageStatusMessage stating that a new message is available for pickup. If the +message id specified in the ReceiveMessageBeginMessage is invalid or +incorrect, the router may simply not reply, or it may send back a +DisconnectMessage. +
+ + + + +Receive Message End
+Description
++Tell the router that delivery of a message was completed successfully and that +the router can discard the message. +Sent from Client to Router. +
+Contents
+- +Session ID +
- +Message ID +
Notes
++The ReceiveMessageBeginMessage is sent after a MessagePayloadMessage fully +delivers a message's payload. +
+ + + + +Reconfigure Session
+Description
++ +Sent from Client to Router to update the session configuration. +The router responds with a Session Status Message. +
+Contents
+- +Session ID +
- +Session Config +
Notes
++As of release 0.7.1. +
+ + + + +Report Abuse
+Description
++Tell the other party (client or router) that they are under attack, potentially with reference to a +particular messageId. If the router is under attack, the client may decide to +migrate to another router, and if a client is under attack, the router may rebuild +its routers or shitlist some of the peers that sent it messages delivering the attack. +Sent either from router to client or from client to router. +
+Contents
+- +Session ID +
- +1 byte Integer abuse severity +(0 is minimally abusive, 255 being extremely abusive) +
- +Reason String +
- +Message ID +
Notes
++Unused. +Not fully implemented. Both router and client can generate Report Abuse Messages, +but neither has a handler for the message when received. +
+ + + + +Request LeaseSet
+Description
++Request that a client authorize the inclusion of a particular set of inbound tunnels. +Sent from Router to Client. +The client responds with a Create LeaseSet Message. +
+Contents
+- +Session ID +
- +1 byte Integer number of tunnels +
-
+ That many pairs of:
+
- + Router Identity +
- + Tunnel ID +
- +End Date +
Notes
++
+ + + + + +Send Message
+Description
++This is how a client sends a message (the payload) to the Destination. +The router will use a default expiration. +Sent from Client to Router. +The router responds with a Message Status Message. +
+Contents
+- +Session ID +
- +Destination +
- +Payload +
- +4 byte Integer nonce +
Notes
++As soon as the SendMessageMessage arrives fully intact, the router should return +a MessageStatusMessage stating that it has been accepted for delivery. +That message will contain the same nonce sent here. +Later on, +based on the delivery guarantees of the session configuration, the router may +additionally send back another MessageStatusMessage updating the status. +
+ + + + +Send Message Expires
+Description
++Sent from Client to Router. Same as Send Message Message, except includes an expiration. +
+Contents
+- +Session ID +
- +Destination +
- +Payload +
- +4 byte Integer nonce +
- +Expiration Date +
Notes
++As of release 0.7.1. +
+ + + + +Session Status
+Description
++Instruct the client as to the status of its session. +Sent from Router to Client. +
+Contents
+- +Session ID +
- +1 byte Integer status +
Notes
++Status values include 0 for destroyed, 1 for created, 2 for updated, and +3 for invalid session. +If created, the Session ID is the identifier to be used for the rest of the session. +
+ + + +Set Date
+Description
++The current date and time. +Sent from Router to Client as a part of the initial handshake. +
+Contents
+- +Date +
Notes
++This is generally the first message sent by the router. +
+ + + + + + + +{% endblock %} diff --git a/www.i2p2/pages/i2np.html b/www.i2p2/pages/i2np.html index 61cccecd..fd65e5ce 100644 --- a/www.i2p2/pages/i2np.html +++ b/www.i2p2/pages/i2np.html @@ -27,11 +27,6 @@ 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. --It isn't clear whether the current priority scheme is generally effective, -and whether the priorities for various messages should be adjusted further. -This is a topic for further research, analysis and testing. -
Message Format
@@ -178,4 +173,10 @@ Others listed in See also the Common Data Structure Specification page. +
Future Work
++It isn't clear whether the current priority scheme is generally effective, +and whether the priorities for various messages should be adjusted further. +This is a topic for further research, analysis and testing. + {% endblock %} diff --git a/www.i2p2/pages/i2np_spec.html b/www.i2p2/pages/i2np_spec.html index 9c104272..e966eed3 100644 --- a/www.i2p2/pages/i2np_spec.html +++ b/www.i2p2/pages/i2np_spec.html @@ -42,12 +42,12 @@ common transports supported. type :: Integer length -> 1 byte - purpose -> identifies the message type(see table below) + purpose -> identifies the message type (see table below) msg-id :: Integer length -> 4 bytes - purpose -> uniquely identifies this message(for some time at least) + purpose -> uniquely identifies this message (for some time at least) expiration :: Date 8 bytes @@ -132,20 +132,36 @@ Cleartext: | reply_iv | + + | | -+----+----+----+----+----+----+----+----+----+ -|flag| request_time | send_message_id | -+----+----+----+----+----+----+----+----+----+ -| padding... -+----+----+----+--// ++----+----+----+----+----+----+----+----+ +|flag| request_time | send_msg_id ++----+----+----+----+----+----+----+----+ + | | ++----+ + +| 29 bytes padding | ++ + +| | ++ +----+----+ +| | ++----+----+----+----+----+----+ -encrypted: + +ElGamal encrypted: +----+----+----+----+----+----+----+----+ | toPeer | + + | | +----+----+----+----+----+----+----+----+ | encrypted data ... | +~ ~ +| | ++----+----+----+----+----+----+----+----+ + +ElGamal and AES encrypted: ++----+----+----+----+----+----+----+----+ +| encrypted data ... | +~ ~ +| | +----+----+----+----+----+----+----+----+ {% endfilter %} @@ -190,27 +206,41 @@ send_message_id :: Integer padding :: Data length -> 29 bytes - source -> random total length: 222 -encrypted: -toPeer :: Hash +ElGamal encrypted: + +toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity length -> 16 bytes -encrypted_data :: ElGamal-2048 encrypted data +encrypted_data :: ElGamal-2048 encrypted data (see notes) length -> 512 total length: 528 + +ElGamal and AES encrypted: + +encrypted_data :: ElGamal and AES encrypted data + length -> 528 + +total length: 528 + {% endfilter %}
Notes
-+
- +In the 512-byte encrypted record, +the ElGamal data contains bytes 1-256 and 258-513 of the +514-byte ElGamal encrypted block. +The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed. +
- See also the tunnel creation specification. +
Delivery Instructions
+Defined in the Tunnel Message Specification. + +Messages
+
+
+| + + + + |
+I2P je anonymizační síť, která nabízí jednoduchou aplikační vrstvu pro bezpečnou komunikaci +s utajením totožnosti. Všechna přenášená data jsou několikanásobně zašifrována. Celá síť je +distribuovaná a dynamická a žádná strana není považována za důvěryhodnou. +
+Existuje celá řada aplikací, které mohou komunikovat přes I2P síť, +včetně e-mailu, P2P, IRC chatu a dalších. +
+I2P síť roste rychle. V roce 2009 bylo uvolněno devět nových verzí a objem přenášených dat +vzrostl pětinásobně: +
+
++Projekt I2P vzniknul v roce 2003, aby podpořil snahy těch, kteří se pokouší budovat svobodnější +společnost poskytováním necenzurovatelného, anonymního a bezpečného komunikačního systému. I2P +je výzkumným projektem, jehož výsledkem je plně distribuovaná, autonomní, škálovatelná, anonymní, +odolná a bezpečná síť s nízkým zpožděním. Cílem je úspěšný provoz v nepřátelském prostředí, a to +i v případě napadení organizací se značnými finančními a politickými prostředky. Všechny prvky +sítě jsou k dispozici ve formě otevřeného zdrojového kódu a zcela zdarma. Obojí by mělo uživatelům +sítě dodat jistoty v tom, že software dělá to, co tvrdí. Také to všem umožňuje přispívat a kód +vylepšovat, a odrážet tak agresivní pokusy o potlačení svobody projevu. +
+Anonymita není booleovská hodnota, zapnuto/vypnuto - nesnažíme se něco učinit "dokonale anonymním". +Namísto toho pracujeme na tom, aby útoky na anonymitu byly čím dál tím nákladnější. I2P je mixující +sítí s nízkým zpožděním (low latency mix network) a anonymita, kterou takový systém poskytuje má +svá omezení. Aplikace, které skrze tuto síť komunikují, jako jsou +Syndie, I2P mail a I2PSnark, však poskytují další funkčnost +a ochranu. +
+Síť I2P není dokončená. Zatím se na ni nelze spoléhat pro "zaručenou" anonymitu. Síť je dosud +poměrně malá a postrádá zevrubné akademické posouzení. Není odolná proti útokům s neomezenými +prostředky, a díky inherentním omezením mixujících sítí s nízkým zpožděním asi nikdy nebude. +
+Síť I2P přenáší data prostřednictvím ostatních rovnocenných uzlů (peers), jak ukazuje následující +obrázek. Všechna data jsou šifrována po celou dobu přenosu. Více informací o tom, jak síť funguje +naleznete v úvodu. +
+
+However, to have changes included in a release, developers -must be trusted by the release managers (currently Complication and zzz). +must be trusted by the release manager (currently zzz). In addition, they must explicitly agree with the above terms to be trusted. That means that they must send one of the release managers a signed message affirming that:
-
diff --git a/www.i2p2/pages/licenses_de.html b/www.i2p2/pages/licenses_de.html
index 3dc67b92..0a1e3938 100644
--- a/www.i2p2/pages/licenses_de.html
+++ b/www.i2p2/pages/licenses_de.html
@@ -262,7 +262,7 @@ Siehe auf die Monotone Seite für Details.
- Present: duck, eche|on, Mathiasdm, Moru (later on), superuser, whitenoise, zzz +
-
+ Website content progress:
+
+ The website overhaul has taken 7 weeks so far. Progress is not fast enough. We need more people to join in! +
+
+ -
+ Website backend progress:
+
+ No report yet, welterde could not attend the meeting. +
+
+ -
+ Location for development discussion:
+
+ Most people agree that IRC is not an ideal location to post long-winded development discussions, it's too volatile, not backed up and not everyone can read it. All developers are advised to post their discussions (or a writeup) to another medium, like zzz.i2p, mailing lists or forum.i2p. + Opinions on the alternatives are a bit more divided. zzz.i2p is currently the location for most discussions, but a number of people also like the idea of a mailing list. No decision has been made on which alternative would be best suited. +
+
+ -
+ Task appointing and disagreements:
+
+ Currently, people appoint themselves to a task by editing the team.html page (this requires monotone access, so there is at least a level of trust implied before being allowed to appoint yourself). + However, what happens if people disagree? +
++ The discussion pointed out that when disagreeing, a discussion should be held (for example on zzz.i2p). If that doesn't resolve the issue, a vote is a possibility, or the Project Manager (zzz) or repository maintainers (welterde, eche|on) can make a decision. +
+
+ -
+ Status updates:
+
+ Status updates will be started next weekend. They will mostly consist of a 'what work did you do last week?' and 'what work will you do next week?'. +
+
+ -
+ Development conferences:
+
+ Nothing big was mentioned. +
+
+ -
+ Promoting the usage of the bittorrent protocol inside I2P: pros and cons:
+
+ Filesharing in general and bittorrent more specifically can be either good or bad for I2P. + On one hand, they could give I2P a bad reputation. On the other hand, they could boost I2P popularity. + What to do? +
++ Filesharing on I2P will not be promoted specifically. Instead, general usability should be looked at and improved. + If people decide to use filesharing on I2P (or any other service, like e-mail or browsing), it should become easier as a result of improving the usability. +
+
+ - Meeting 208 - September 8, 2010
- Meeting 207 - February 10, 2009
- Meeting 206 - April 10, 2007
- Meeting 205 - April 3, 2007 diff --git a/www.i2p2/pages/ministreaming.html b/www.i2p2/pages/ministreaming.html index 38d60bfc..01a155ab 100644 --- a/www.i2p2/pages/ministreaming.html +++ b/www.i2p2/pages/ministreaming.html @@ -9,7 +9,7 @@ Ministreaming is deprecated and is incompatible with today's applications. The following documentation is old. Also note that streaming extends ministreaming in the same Java package (net.i2p.client.streaming), so the current -API documentation +API documentation contains both. Obsolete ministreaming classes and methods are clearly marked as deprecated in the Javadocs. @@ -38,7 +38,7 @@ messages sent (or include any application level ACK or SACK), so it must wait on average twice the time it takes to send a message before sending another.
- Names are converted to lower case on import +
- Names are converted to lower case on import.
- Names are checked for conflict with existing names in the existing userhosts.txt and hosts.txt -(but not privatehosts.txt) -after conversion to lower case -
- Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case -
- Must not start with '.' or '-' -
- Must end with '.i2p' -
- 67 characters maximum, including the '.i2p' -
- Must not contain '..' -
- Must not contain '.-' or '-.' (as of 0.6.1.33) -
- Must not contain '--' except in 'xn--' for IDN +(but not privatehosts.txt) after conversion to lower case. +
- Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case. +
- Must not start with '.' or '-'. +
- Must end with '.i2p'. +
- 67 characters maximum, including the '.i2p'. +
- Must not contain '..'. +
- Must not contain '.-' or '-.' (as of 0.6.1.33). +
- Must not contain '--' except in 'xn--' for IDN.
- Base 32 hostnames (*.b32.i2p) are not allowed. -
- Certain hostnames reserved for project use are not allowed. -
- Keys are checked for base64 validity +
- Certain hostnames reserved for project use are not allowed + (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.proxy.i2p). +
- Keys are checked for base64 validity.
- Keys are checked for conflict with existing keys in hosts.txt (but not privatehosts.txt). -
- Maximum key length 516 bytes -
- Maximum key length 616 bytes +
- Minimum key length 516 bytes. +
- Maximum key length 616 bytes (to account for certs up to 100 bytes).
- Limit on number of 'subdomains' -
- Authorization for 'subdomains' through various methods -
- Hashcash or signed certificates -
- Editorial review of host names and/or content -
- Categorization of hosts by content -
- Reservation or rejection of certain host names -
- Restrictions on number of names registered in a given time period -
- Delays between registration and publication -
- Requirement that the host be up for verification -
- Expiration and/or revocation -
- IDN spoof rejection +
- A limit on number of 'subdomains'. +
- Authorization for 'subdomains' through various methods. +
- Hashcash or signed certificates. +
- Editorial review of host names and/or content. +
- Categorization of hosts by content. +
- Reservation or rejection of certain host names. +
- Restrictions on the number of names registered in a given time period. +
- Delays between registration and publication. +
- Requirement that the host be up for verification. +
- Expiration and/or revocation. +
- IDN spoof rejection.
- Install monotone
- Skim over the monotone tutorial -
- Enable the i2ptunnel client tunnel on port 8998 pointing to mtn.i2p2.i2p (if you are having nonce issues, see ticket #64 for a workaround) +
- Enable the i2ptunnel client tunnel on port 8998 pointing to mtn.i2p2.i2p (if you are having nonce issues, see ticket #64 for a workaround)
- mtn -d i2p.mtn db init
- mtn -d i2p.mtn pull 127.0.0.1:8998 i2p.i2p
- mtn -d i2p.mtn co --branch=i2p.i2p @@ -59,7 +59,7 @@ see the application development guide.
- See zzz's TODO lists, this website's TODO list or -Trac +Trac for ideas.
-
diff --git a/www.i2p2/pages/newdevelopers_de.html b/www.i2p2/pages/newdevelopers_de.html
index 33c17324..001fd016 100644
--- a/www.i2p2/pages/newdevelopers_de.html
+++ b/www.i2p2/pages/newdevelopers_de.html
@@ -54,7 +54,7 @@ schaue dir die Anleitung zum Entwickeln von Anwendunge
- Siehe nach in der zzz Aufgabenliste, Aufgabenliste dieser Webseite oder -Trac +Trac für Ideen.
- diff --git a/www.i2p2/pages/newdevelopers_it.html b/www.i2p2/pages/newdevelopers_it.html index 4e31d652..cfddd71f 100644 --- a/www.i2p2/pages/newdevelopers_it.html +++ b/www.i2p2/pages/newdevelopers_it.html @@ -53,7 +53,7 @@ leggete laguida su come creare nuove applicazioni.
- Guardate zzz's TODO lists, TODO list di questo sito o -Trac +Trac per idee.
- diff --git a/www.i2p2/pages/ntcp.html b/www.i2p2/pages/ntcp.html index 3552589c..54008d93 100644 --- a/www.i2p2/pages/ntcp.html +++ b/www.i2p2/pages/ntcp.html @@ -34,16 +34,18 @@ because it uses the underlying Java TCP transport for reliable delivery.
Standard Message Format
After establishment, - the NTCP transport sends individual I2NP messages AES/256/CBC encrypted with - a simple checksum. The unencrypted message is encoded as follows: + the NTCP transport sends individual I2NP messages, with a simple checksum. + The unencrypted message is encoded as follows:
* +-------+-------+--//--+---//----+-------+-------+-------+-------+ * | sizeof(data) | data | padding | Adler checksum of sz+data+pad | * +-------+-------+--//--+---//----+-------+-------+-------+-------+
- That message is then encrypted with the DH/2048 negotiated session key - (station to station authenticated per the EstablishState class) using the - last 16 bytes of the previous encrypted message as the IV. + The data is then AES/256/CBC encrypted. The session key for the encryption + is negotiated during establishment (using Diffie-Hellman 2048 bit). + The establishment between two routers is implemented in the EstablishState class + and detailed below. + The IV for AES/256/CBC encryption is the last 16 bytes of the previous encrypted message.@@ -90,7 +92,7 @@ Then, DSA signatures of the critical data are exchanged to confirm the connectio
Legend: - X, Y: 256 byte DH keys + X, Y: 256 byte DH public keys H(): 32 byte SHA256 Hash E(data, session key, IV): AES256 Encrypt S(): 40 byte DSA Signature @@ -102,10 +104,28 @@ Then, DSA signatures of the critical data are exchanged to confirm the connectioDH Key Exchange
The initial 2048-bit DH key exchange -uses the same shared prime and generator as that used for I2P's +uses the same shared prime (p) and generator (g) as that used for I2P's ElGamal encryption.
++The DH key exchange consists of a number of steps, displayed below. +The mapping between these steps and the messages sent between I2P routers, +is marked in bold. +
-
+
- Alice generates a secret 226-bit integer x. + She then calculates X = g^x mod p. + +
- Alice sends X to Bob (Message 1). +
- Bob generates a secret 226-bit integer y. + He then calculates Y = g^y mod p. +
- Bob sends Y to Alice.(Message 2) +
- Alice can now compute sessionKey = Y^x mod p. +
- Bob can now compute sessionKey = X^y mod p. +
- Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod p. +
Message 1 (Session Request)
This is the DH request. @@ -184,7 +204,7 @@ Unencrypted Contents: Y: 256 byte Y from Diffie Hellman - HXY: SHA256 Hash(X concatentated with Y) + HXY: SHA256 Hash(X concatenated with Y) (32 bytes) tsB: 4 byte timestamp (seconds since the epoch) @@ -404,6 +424,9 @@ to create a limited number of message sizes.- Memory utilization (including that of the kernel) for NTCP should be compared to that for SSU.
- +Can the establishment messages be randomly padded somehow, to frustrate +identification of I2P traffic based on initial packet sizes? +
- Review and possibly disable 'check connection'
- Perhaps re-enable the interactive stream profile (the + current implementation only uses the bulk stream profile). +
- Client level bandwidth limiting (in either or both directions on a stream, + or possibly shared across multiple streams). This would be in addition to + the router's overall bandwidth limiting, of course. +
- Access control lists (only allowing streams to or from certain other known + destinations). +
- Web controls and monitoring the health of the various streams, as well + as the ability to explicitly close or throttle them. +
- - download .xpi2p -
- - verify sud sig against stored keys, or else: - - extract, get pubkey from properties, then verify, then store key -
- - verify zip integrity -
- - extract plugin.config file -
- - verify min/max/version/etc -
- - check that webapps don't duplicate those in $I2P -
- - stop existing plugin -
- - verify install dir doesn't exist if update=false, or ask -
- - verify install dir does exist if update=true, or ask -
- - unzip into appDir/plugins/name/ -
- - add to plugins.config +
- The .xpi2p file is downloaded. +
- The .sud signature is verified against stored keys. + If there is no matching key, the .sud is extracted, the key is loaded from the properties, then verified and stored. +
- Verify the integrity of the zip file. +
- Extract the plugin.config file. +
- Verify the I2P version, to make sure the plugin will work. +
- Check that webapps don't duplicate the existing $I2P applications. +
- Stop the existing plugin (if present). +
- Verify that the install directory does not exist yet if update=false, or ask to overwrite. +
- Verify that the install directory does exist if update=false, or ask to create. +
- Unzip the plugin in to appDir/plugins/name/ +
- Add the plugin to plugins.config
- - check clients.config, load and start each item (add configured jars to classpath) -
- - check console/webapp and console/webapp.config, load and start (add configured jars to classpath) -
- - add console/locale/foo.jar to translate classpath if present -
- - add console/theme to theme search path if present -
- - add summary bar link +
- Check clients.config, and load and start each item (add the configured jars to the classpath). +
- Check console/webapp and console/webapp.config. Load and start required items (add the configured jars to the classpath). +
- Add console/locale/foo.jar to the translation classpath if present. +
- Add console/theme to the theme search path if present. +
- Add the summary bar link.
- - Plugins should not attempt to write anywhere in $I2P as it may be readonly, and that isn't good policy anyway + Plugins should not attempt to write anywhere in $I2P as it may be readonly, and that isn't good policy anyway.
- Plugins may write to $CONFIG but keeping files in $PLUGIN only is recommended. All files in $PLUGIN will be deleted at uninstall. @@ -352,9 +336,9 @@ If the user may want to save data after uninstallation, the uninstallargs hook could ask.
- - $CWD may be anywhere; do not assume it is in a particular place, do not attempt to read or write files relative to $CWD + $CWD may be anywhere; do not assume it is in a particular place, do not attempt to read or write files relative to $CWD.
- - Java programs should find out where they are with the directory getters in I2PAppContext + Java programs should find out where they are with the directory getters in I2PAppContext.
- Plugin directory is I2PAppContext.getGlobalContext().getAppDir().getAbsolutePath() + "/plugins/" + appname, or put a $PLUGIN argument in the args line in clients.config. @@ -363,7 +347,7 @@ context API in i2p.jar.
- See Howto for info on generating signing keys and generating/verifying keys and sud files
- - All config files must be UTF-8 + All config files must be UTF-8.
- To run in a separate JVM, use ShellCommand with java -cp foo:bar:baz my.main.class arg1 arg2 arg3. Of course, it will be a lot harder to stop the plugin then... @@ -392,9 +376,9 @@ access to router classes.
- Since each version must be higher than the one before, you could enhance your build script to add a build number to the end of the version. -This helps for testing. Most of zzz's plugins have that feature, check build.xml for an example. +This helps for testing. Most of zzz's plugins have that feature, check build.xml for an example.
- -Plugins must never call System.exit() +Plugins must never call System.exit().
-
Please respect licenses by meeting license requirements for any software you bundle.
diff --git a/www.i2p2/pages/plugins.html b/www.i2p2/pages/plugins.html
index fbd1d9a0..04467698 100644
--- a/www.i2p2/pages/plugins.html
+++ b/www.i2p2/pages/plugins.html
@@ -86,7 +86,7 @@ Plugins are a great way to learn more about I2P or easily add some feature.
Getting Started
To create a plugin from an existing binary package you will need to get makeplugin.sh from -the i2p.scripts branch in monotone. +the i2p.scripts branch in monotone.Known Issues
@@ -98,23 +98,23 @@ Updates of a plugin with included jars (not wars) won't be recognized if the plu it requires class loader trickery to flush the class cache; a full router restart is required. - -Automatic updates (and check-for-updates) unimplemented. +Automatic updates (and check-for-updates) are currently unimplemented.
- -Stop button displayed even if there is nothing to stop. +The stop button is displayed even if there is nothing to stop.
- Plugins running in a separate JVM create a logs/ directory in $CWD.
- -No initial keys except for jrandom and zzz (using same keys as for router update), +No initial keys are present, except for jrandom and zzz (using the same keys as for router update), so the first key seen for a signer is automatically accepted - there is no signing key authority.
- When deleting a plugin, the directory is not always deleted, especially on Windows.
- Installing a plugin requiring Java 1.6 on a Java 1.5 machine will result in a "plugin is corrupt" -message if pack200 is used. +message if pack200 compression of the plugin file is used.
- Theme and translation plugins are untested.
- -Disabling autostart doesn't always work +Disabling autostart doesn't always work.
-
+ Internet Layer:
+
+ IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery. +
+ -
+ Transport Layer:
+
+ TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet. +
+ UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet. +
+ -
+ I2P Transport Layer: provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection.
+ Two protocols are implemented to provide these capabilities. NTCP builds on top of TCP, while SSU uses UDP.
+
+ NTCP: NIO-based TCP +
+ SSU: Secure Semi-reliable UDP +
+ -
+ I2P Tunnel Layer: provide full encrypted tunnel connections.
+
+ Tunnel messages: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery. + The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key), + so it will be forwarded. +
+ I2NP messages: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages. +
+ -
+ I2P Garlic Layer: provide encrypted and anonymous end-to-end I2P message delivery.
+
+ I2NP messages: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous. +
+ -
+ I2P Client Layer: allow any client to use I2P functionality, without requiring the direct use of the router API.
+
+ I2CP: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket. +
+ -
+ I2P End-to-end Transport Layer: allow TCP- or UDP-like functionality on top of I2P.
+
+ Streaming Library: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P. +
+ Datagram Library: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P. +
+ -
+ I2P Application Interface Layer: additional (optional) libraries allowing easier implementations on top of I2P.
+
+ I2PTunnel +
+ SAM/SAMv2/SAMv3(*), + BOB +
+ -
+ I2P Application Proxy Layer: proxy systems.
+
+ HTTP Client/Server, IRC Client, SOCKS, Streamr +
+ - Streaming/datagram applications: i2psnark, Syndie, i2phex... +
- SAM/BOB applications: IMule, i2p-bt, i2prufus, Robert... +
- Other I2P applications: Syndie, EepGet, plugins... +
- Regular applications: Jetty, Apache, Monotone, CVS, browsers, e-mail... +
- MIN_RESEND_DELAY = 2*1000 -
- MAX_RESEND_DELAY = 45*1000 -
- i2p.streaming.connectTimeout = 5*60*1000 -
- i2p.streaming.initialReceiveWindow = 1 -
- i2p.streaming.initialWindowSize = 12 -
- MIN_WINDOW_SIZE = 1 -
- i2p.streaming.maxWindowSize = 128 // as of release 0.6.3 (was 64) -
- TREND_COUNT = 3 -
- i2p.streaming.maxResends = 8 -
- RTT_DAMPENING = 0.875 // as of release 0.6.5 (was 0.9) -
- i2p.streaming.profile = 1 (bulk) (2=interactive not supported) -
- MIN_MESSAGE_SIZE = 512 // as of release 0.6.5 -
- i2p.streaming.maxMessageSize = 1730 // as of release 0.6.5 (was 960) -
- INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2) -
- i2p.streaming.initialRTT = 10*1000 -
- INITIAL_TIMEOUT = 1.5 * initialRTT -
- i2p.streaming.initialResendDelay = 1000 -
- i2p.streaming.initialAckDelay = 2000 -
- i2p.streaming.inactivityTimeout = 90*1000 -
- i2p.streaming.inactivityAction = 2 (send) (0=noop, 1=disconnect) -
- i2p.streaming.congestionAvoidanceGrowthRateFactor = 1 -
- i2p.streaming.slowStartGrowthRateFactor = 1 -
- PASSIVE_FLUSH_DELAY = 250 // as of release 0.6.5 (was 500) -
- i2p.streaming.answerPings = true // new option as of release 0.7.7 -
- i2p.streaming.maxConcurrentStreams = -1 // 0 or negative value means unlimited -
- i2p.streaming.maxConnsPerMinute = 0 // per peer; 0 means disabled; as of release 0.7.14 -
- i2p.streaming.maxConnsPerHour = 0 // per peer; 0 means disabled; as of release 0.7.14 -
- i2p.streaming.maxConnsPerDay = 0 // per peer; 0 means disabled; as of release 0.7.14 -
- i2p.streaming.maxTotalConnsPerMinute = 0 // all peers; 0 means disabled; as of release 0.7.14 -
- i2p.streaming.maxTotalConnsPerHour = 0 // all peers; 0 means disabled; as of release 0.7.14 -
- i2p.streaming.maxTotalConnsPerDay = 0 // all peers; 0 means disabled; as of release 0.7.14 -
-Dennoch muss der Releasemanager (derzeit Complication und zzz) dem Entwickler +Dennoch muss der Releasemanager (derzeit zzz) dem Entwickler vertrauen, wenn dieser Änderungen in ein Release einbringen möchte. Zusätzlich muss ein Entwickler den oberen Bestimmungen explizit zustimmen um vertrauenswürdig zu sein. diff --git a/www.i2p2/pages/meeting208.html b/www.i2p2/pages/meeting208.html new file mode 100644 index 00000000..18448cd8 --- /dev/null +++ b/www.i2p2/pages/meeting208.html @@ -0,0 +1,334 @@ +{% extends "_layout.html" %} +{% block title %}I2P Development Meeting 208{% endblock %} +{% block content %}
I2P dev meeting, September 8, 2010
+Quick recap
+-
+
Full IRC Log
+
+{% filter escape %}
+22:02 <@Mathiasdm> okay
+22:02 <@Mathiasdm> meeting time
+22:03 <@Mathiasdm> 0) Hello
+22:03 <@Mathiasdm> 1) Website content progress
+22:03 <@Mathiasdm> 2) Website backend progress
+22:03 <@Mathiasdm> 3) Location for dev discussion
+22:03 <@Mathiasdm> 4) Task appointing + handling of disagreements
+22:03 <@Mathiasdm> 5) Status updates
+22:03 <@Mathiasdm> 6) Upcoming dev conferences
+22:03 <@Mathiasdm> okay
+22:03 <@Mathiasdm> 0) Hello
+22:04 <@Mathiasdm> Welcome to the 208th dev meeting! (shamelessly stolen from badger :p)
+22:04 * Mathiasdm pokes everyone
+22:04 < eche|on> *poke*
+22:04 * Mathiasdm pokes zzz, thanks for the op
+22:06 <@Mathiasdm> hm, more poking needed to wake everyone up? zzz badger dr|z3d dream duck eche|on hottuna postman sponge superuser ReturningNovice (sorry :))
+22:06 < eche|on> *POKE*
+22:06 <@Mathiasdm> sorry, eche|on :p saw your poke
+22:08 < duck> moin
+22:08 <@Mathiasdm> moin duck
+22:09 < hawk> * Mathiasd1 pokes welterde
+22:11 <@Mathiasdm> okay, waiting a bit longer then, since there's only 3 of us so far
+22:11 <@Mathiasdm> anyone who wants to join in, just poke back
+22:11 < whitenoise> *poke*
+22:11 <@zzz> ack
+22:12 <@Mathiasdm> aha, lead dev, good :)
+22:13 <@Mathiasdm> and just to be sure as many people as possible can join in, waiting 2 more minutes and then starting
+22:14 <@Mathiasdm> 1 more minute now
+22:14 < superuser> mooin
+22:15 <@Mathiasdm> right on time, superuser ;)
+22:15 <@Mathiasdm> hi all
+22:15 < superuser> ;-)
+22:15 < superuser> hi Mathiasdm
+22:15 < superuser> and all
+22:15 <@Mathiasdm> 1) Website content progress
+22:15 <@Mathiasdm> as we probably all know, I2P development is currently halted due to the specs overhaul
+22:16 * Mathiasdm hands the hot potato to zzz, so he can talk about the specs overhaul progress
+22:16 < eche|on> right
+22:17 <@zzz> it's been 7 weeks, progress is slow. I'm working on i2cp right now, I've spent several hours on it already
+22:17 <@zzz> need other ppl to chip in both on what they've promised to do, and on the stuff that is unclaimed
+22:17 <@zzz> eot
+22:18 <@Mathiasdm> okay
+22:18 * Mathiasdm will get started again tomorrow, now dev environment is set up again
+22:18 <@Mathiasdm> others having something to say about it, go ahead :)
+22:19 <@Mathiasdm> guess not
+22:19 <@Mathiasdm> hm
+22:19 <@Mathiasdm> 2) Website backend progress
+22:19 < eche|on> I think is is great form the peoples doing it.
+22:19 <@Mathiasdm> oh
+22:19 <@Mathiasdm> sorry :)
+22:21 <@Mathiasdm> we're skipping 2) for now, unless welt comes in
+22:21 <@Mathiasdm> 3) Location for dev discussion
+22:22 <@Mathiasdm> this is related to http://zzz.i2p/topics/719
+22:22 <@Mathiasdm> I quote:
+22:22 <@Mathiasdm> "* Post developer discussions on zzz.i2p. What I mean is: IRC is a highly 'volatile' medium, where not everyone is online all the time, and not everyone logs. It's a great medium for a short discussion, but do consider posting a short write-up on zzz.i2p, so others can join in on the discussion."
+22:22 < eche|on> dev discussion is a hard topic. IRC is nice, but not reliant neither an archive
+22:22 <@Mathiasdm> yes, agreed
+22:23 <@Mathiasdm> but there are many things to chose from
+22:23 <@Mathiasdm> zzz.i2p, forum.i2p, mailing list
+22:23 <@Mathiasdm> well, okay, 3 things :p
+22:23 < eche|on> I would suggest some central point of archive
+22:23 < eche|on> with a backup.
+22:24 <@Mathiasdm> yes
+22:24 <@Mathiasdm> but setting up distributed storage for this sounds like a hard thing :p
+22:24 <@Mathiasdm> though mailing list is doable, I guess
+22:25 <@Mathiasdm> mailing list is 'kinda distributed'
+22:25 < eche|on> :-)
+22:25 < superuser> isn't the website itself already distributed?
+22:25 <@Mathiasdm> anyone else, ideas?
+22:25 < eche|on> a mailinglist is a good solution, to
+22:26 < superuser> could also go there
+22:26 <@Mathiasdm> yes, but that doesn't include the forum, superuser
+22:26 < eche|on> rightm website is in monotone
+22:26 <@Mathiasdm> true
+22:26 < superuser> no, I don't mean the forum, but website itself
+22:26 < superuser> aren't old dev meetings available there somewhere too?
+22:26 <@Mathiasdm> but it's hard to discuss when you have to check your discussions into monotone :p
+22:27 < superuser> true
+22:27 <@Mathiasdm> perhaps with the new backend welt is working on, it'll be more doable
+22:27 < superuser> would only be of interest for archiving, not for keeping discussing
+22:28 <@Mathiasdm> for a temporary way, I would propose: if you keep a big discussion on IRC, post a few notes on _a_ persistent medium
+22:29 <@Mathiasdm> be it zzz.i2p, mailing list or forum
+22:29 <@Mathiasdm> I know, that's a bit vague
+22:29 < eche|on> I vote mailinglist ++
+22:29 <@Mathiasdm> hm, welt, are mailinglist instructions on the website somewhere?
+22:29 < superuser> you mean welt's nntp service?
+22:29 <@Mathiasdm> mailing list sounds good to me too, eche|on, but I wonder if it will work to get everyone to use it?
+22:29 < eche|on> currently no ml available
+22:29 <@Mathiasdm> yes, superuser
+22:29 <@Mathiasdm> er
+22:29 <@Mathiasdm> or what was it
+22:29 <@Mathiasdm> I think so
+22:30 <@Mathiasdm> eche|on: welt set a few ml's up this summer
+22:30 < eche|on> nntp is news server
+22:30 <@Mathiasdm> but not widely used yet
+22:30 <@Mathiasdm> yes, indeed, but there's a mailing list now too
+22:30 <@Mathiasdm> but I don't have the location here
+22:30 <@Mathiasdm> zzz, duck: opinions?
+22:31 < superuser> I have no mailing list info so far, just seen welt's and Mathiasdm's and ReturningNovice's posts on news server
+22:32 <@zzz> I'm not a big fan of an ML but I'll use it if ppl want. welt's seems to be a big secret atm
+22:33 < duck> I think zzz.i2p is fine
+22:33 <@Mathiasdm> imho anything not-irc would be useful (I like IRC, as said before, but too much dev discussions are unfolloweable)
+22:33 < eche|on> zzz.i2p is fine, but: irc discussions needs to be copied intoi AND somehow a kind of backup would be nice
+22:34 <@Mathiasdm> hm, maybe I can set s omething up like
+22:34 <@Mathiasdm> er
+22:34 <@Mathiasdm> what was it called
+22:34 <@Mathiasdm> 2 or 3 years ago
+22:34 <@Mathiasdm> trevorreznik.i2p?
+22:36 <@Mathiasdm> how about: we keep using zzz.i2p, and we start using a mailing list, and try to make sure IRC discussions don't stay IRC-only?
+22:36 < duck> all major design stuff is already on zzz.i2p
+22:36 < eche|on> better: try keep using zzz.i2p and copy IRC into it.
+22:36 < duck> I dont see your problem
+22:37 < superuser> what if zzz one disappearsÃ
+22:37 < superuser> s/Ã/?
+22:37 < duck> dev/design
+22:37 <@Mathiasdm> for example, everything sponge posts (just an example, sponge :p) about seedless and bob is often irc-only discussion
+22:38 < duck> I dont think a mailinglist will result into sponge documenting his protocol and api
+22:38 < duck> but sure, give it a try
+22:39 <@Mathiasdm> nooo, that's not what I meant, duck
+22:39 <@Mathiasdm> as said, I don't care if it's on zzz.i2p or on mailing list
+22:39 <@Mathiasdm> I just don't want it to be IRC-only, those discussions
+22:39 <@Mathiasdm> but yes, you have a good point too
+22:39 <@Mathiasdm> that some things will perhaps stay irc-only
+22:39 < duck> then go talk to sponge
+22:39 <@Mathiasdm> it was an example
+22:40 < duck> (which you might be doing through this meeting ofc)
+22:40 < duck> ok, understood
+22:40 <@Mathiasdm> :)
+22:41 <@Mathiasdm> okay, I guess if everyone just tries to post things on zzz.i2p (or mailing list -- but we'll wait for welt :p), that's settled
+22:42 <@Mathiasdm> for now, at least
+22:42 <@Mathiasdm> anyone have anything to add on this?
+22:44 <@Mathiasdm> okay
+22:44 <@Mathiasdm> next
+22:44 <@Mathiasdm> 4) Task appointing + handling of disagreements
+22:45 -!- Moru [kvirc@irc2p] has joined #i2p-dev
+22:45 <@Mathiasdm> currently, tasks (displayed on http://www.i2p2.de/team.html ) are appointed/chosen by people simply changing the webpage
+22:45 < hawk> Title: Team - I2P (at www.i2p2.de)
+22:45 <@Mathiasdm> so if you want to do a task, you just do it, and you add yourself to the webpage
+22:45 <@Mathiasdm> which is good, I guess :)
+22:46 < eche|on> if someone disagree: discussion in IRC/zzz.i2p
+22:46 <@Mathiasdm> yes, disagreeing is the point
+22:46 < eche|on> but people need checkin-rights to change, means: need som etrust from existant devs
+22:46 <@Mathiasdm> there was disagreement this summer, and we didn't really handle that
+22:46 <@Mathiasdm> true, eche|on
+22:47 <@Mathiasdm> how do we resolve a discussio if the people disagreeing can't come to agreement?
+22:47 <@Mathiasdm> vote or something?
+22:47 <@Mathiasdm> that's what I was wondering about
+22:48 <@Mathiasdm> suggestions?
+22:48 < eche|on> last line of defense was noted once
+22:48 < eche|on> which was zzz
+22:48 <@Mathiasdm> last line of defense?
+22:48 <@Mathiasdm> ah
+22:49 < whitenoise> what about a third better solution?
+22:49 < duck> if all else fails; resort to zzz
+22:49 < eche|on> but voting is a nice idea, but I think a solution will be found ahead
+22:49 <@Mathiasdm> if the third solution is definitely better, the two parties will choose that one ;)
+22:50 <@Mathiasdm> hm, okay
+22:50 <@Mathiasdm> just out of curiosity, zzz, you agree to being 'the last line of defense'? :)
+22:50 <@Mathiasdm> it sounds okay to me, but do you want that yourself?
+22:51 <@zzz> not particularly. my rule is whoever is actually doing something is in charge. ppl that do nothing but talk and piss other ppl off are not.
+22:52 <@zzz> there's plenty of work to go around.
+22:53 <@Mathiasdm> okay :) sounds good
+22:53 <@Mathiasdm> anyone have additional comments? if not, next item
+22:53 < superuser> generally "the one who does it is in charge" sounds good
+22:53 < superuser> but what if two parties actually do
+22:53 < superuser> and still go in opposite directions?
+22:54 < superuser> I guess in that case a voting mechanism would not be too uncool
+22:54 <@Mathiasdm> true
+22:54 <@zzz> if it's code I can pick. I'm definitely not the last line of defense for the website. welt and echelon are.
+22:55 <@Mathiasdm> well, if discussion happens and a solution cannot be found, there can be a vote or someone (zzz, welt?) can pick
+22:55 <@zzz> they would pick a winner by pulling privs from the loser.
+22:56 <@Mathiasdm> *only if it's a nasty discussion, I would hope ;) friendly disagreements shouldn't result in losing privs :p
+22:57 < eche|on> right
+22:58 <@Mathiasdm> okay then
+22:58 <@Mathiasdm> next point
+22:58 <@Mathiasdm> if that's okay
+22:58 <@Mathiasdm> 5) Status updates
+22:58 < eche|on> ok
+22:59 <@Mathiasdm> I will start 'collecting' status updates this weekend, I think
+22:59 <@Mathiasdm> I was going to do so last week, but caught up in work
+22:59 < eche|on> great. go ahead.
+22:59 <@Mathiasdm> basically, simply 'what did you do last week?' and 'what are your plans for next week?'
+23:00 <@Mathiasdm> and I'll post them a bit summarized on the website
+23:00 <@Mathiasdm> suggestions are always welcome :)
+23:00 <@Mathiasdm> okay, final point (added only a bit before starting the meeting)
+23:00 <@Mathiasdm> 6) Upcoming dev conferences
+23:01 <@Mathiasdm> -who's going to 27c3?
+23:01 <@Mathiasdm> -who's going to brucon?
+23:01 <@Mathiasdm> -any others?
+23:02 <@Mathiasdm> I will certainly attend brucon, and most likely 27c3 for a day (and will stay in berlin for a few days)
+23:02 < whitenoise> Mathiasdm, I added 1 more point 10 min. before the beginning.
+23:02 <@Mathiasdm> oh? sorry, didn't see
+23:03 <@Mathiasdm> okay, will do that in a minute, whitenoise
+23:03 < whitenoise> ok
+23:03 < whitenoise> thanks
+23:03 <@Mathiasdm> nobody remarks on dev conferences?
+23:04 <@Mathiasdm> then: 7) Promoting the usage of the bittorrent protocol inside I2P: pros and cons
+23:04 * Mathiasdm hands hot potato to whitenoise
+23:04 < whitenoise> Ok, so we discussed this a little bit with duck
+23:05 < whitenoise> While it's a good way for cover traffic and network growth, it may lead to the notoriety of I2P as a illegal file-sharing network
+23:05 < eche|on> I decided to not attend to 27c3
+23:06 <@Mathiasdm> ah, too bad, eche|on
+23:06 <@Mathiasdm> true, whitenoise
+23:06 < whitenoise> On the other hand...
+23:06 < superuser> I think, bt should not be empahsized more than other services, but i2p be promoted as general use network
+23:07 < superuser> oh, he had not yet finished...
+23:07 <@Mathiasdm> he might be lagging, give him a bit :)
+23:08 < whitenoise> if we don't promote this protocol, in some not very near future, if the business model for selling digital media is not changed, the pressure on torrent users will be higher, so they will start looking for ways to hide
+23:08 < whitenoise> which can lead to my first point (notoriety) anyway
+23:08 < whitenoise> but it's doubtful, of course
+23:08 < Moru> Hello! Excuse me for butting here... sad but true, promote it as filesharing and you will have loads more users and plenty of developers joining. Mabe even get funded by those that wants to use a safe filesharing platform.
+23:09 <@Mathiasdm> simply promoting it would not do that, imho
+23:09 <@Mathiasdm> and whitenoise, you are right about notoriety
+23:09 <@Mathiasdm> but are we promoting it?
+23:10 < whitenoise> Imo, right now we don't
+23:10 <@Mathiasdm> and bittorrent in itself is not causing the notoriety, file sharing is (imho important distinction, but perhaps not in this discussion)
+23:10 <@Mathiasdm> (and hi, Moru)
+23:11 < whitenoise> Well, bittorrent is the most used way, that's why I talk about it
+23:11 < whitenoise> of course, it may be emule or anything else
+23:11 <@Mathiasdm> how would you see promoting it?
+23:12 < whitenoise> For example, current simple users have some difficulties setting everything up
+23:12 < whitenoise> We could make info about bittorrent more conspicuous
+23:13 <@Mathiasdm> hm, yes
+23:13 < whitenoise> description more simple
+23:13 < whitenoise> and so on.
+23:13 <@Mathiasdm> but that's (imho) more a general I2P problem
+23:13 < whitenoise> maybe improve i2psnark a little
+23:13 <@Mathiasdm> I2P could become a lot more conspicuous :p
+23:13 < whitenoise> yes
+23:14 < whitenoise> but doing it (as well as advertising it on twitter, for example) will surely attract some users
+23:14 <@Mathiasdm> yes
+23:14 <@Mathiasdm> well, I agree, and I hope we will more towards making everything clearer (better usability and such) in the near future
+23:14 < whitenoise> so, the question is, I guess, what we should do and what we shouldn't
+23:15 < whitenoise> improve description but don't advertise as a filesharing network, maybe?
+23:15 <@Mathiasdm> what we should do (once development of 0.9 starts) is imho take a look at the 'pain points' of usability
+23:15 < eche|on> laready got some ideas of those
+23:17 <@Mathiasdm> yes, I2P description would help; console overhaul (perhaps? I don't know) would help
+23:17 <@Mathiasdm> eche|on: didn't we have a .pdf with usability remarks from a conference you went?
+23:17 < eche|on> hm
+23:18 <@zzz> i have it
+23:18 < eche|on> need to look for it, but we had some issues over all.
+23:18 <@Mathiasdm> have a link, zzz?
+23:19 <@Mathiasdm> okay, we could focus on it a bit after the website specs?
+23:20 <@zzz> http://zzz.i2p/files/petcon-usability-long.pdf
+23:20 <@Mathiasdm> thx
+23:20 < eche|on> thats a nice idea
+23:21 <@Mathiasdm> okay then
+23:21 <@Mathiasdm> other remarks or ideas, whitenoise?
+23:21 < whitenoise> hm...
+23:22 <@Mathiasdm> you are of course always free to start working on website usability improvements too
+23:22 < eche|on> just wait for some mails with contact data to pay out some money ;-)
+23:23 < whitenoise> well, I guess we decided to improve usability in general without any accent on bittorrent, right?
+23:23 < whitenoise> :-)
+23:23 <@Mathiasdm> that looks like it, yes, whitenoise
+23:23 <@Mathiasdm> I will mail you my bank account, eche|on, just send me the money ;)
+23:23 <@Mathiasdm> okay then
+23:23 <@Mathiasdm> 8) cookies for everyone who attended
+23:24 < eche|on> *g*
+23:24 <@Mathiasdm> ===Meeting over===
+23:24 <@Mathiasdm> thanks all :)
+23:24 < eche|on> COOKIES!
+23:25 <@Mathiasdm> don't eat all of them
+23:25 * Mathiasdm pokes eche|on
+{% endfilter %}
+{# TODO: pygments #}
+
+-
+
Even with those issues, the ministreaming library performs quite well in many -situations, and its API +situations, and its API is both quite simple and capable of remaining unchanged as different streaming implementations are introduced. The library is deployed in its own ministreaming.jar. diff --git a/www.i2p2/pages/naming.html b/www.i2p2/pages/naming.html index 4b510ce3..f4e70c03 100644 --- a/www.i2p2/pages/naming.html +++ b/www.i2p2/pages/naming.html @@ -145,23 +145,23 @@ to other routers.
Naming rules:
-
-
Any name received via subscription that passes all the checks is added to the local hosts.txt. @@ -223,17 +223,17 @@ It is recommended that host add services impose, at a minimum, the restrictions Host add services may impose additional restrictions on hostnames and keys, for example:
-
-
Jump Services
diff --git a/www.i2p2/pages/newdevelopers.html b/www.i2p2/pages/newdevelopers.html index 68868e2e..6315d2ef 100644 --- a/www.i2p2/pages/newdevelopers.html +++ b/www.i2p2/pages/newdevelopers.html @@ -24,7 +24,7 @@ get the monotone source repository installed - short instructions:Notable performance improvements have been made using the techniques below. +There is more to do, see the Performance page +for current issues and thoughts.
+ +Native math [implemented]
+When I last profiled the I2P code, the vast majority of time was spent within +one function: java.math.BigInteger's +modPow. +Rather than try to tune this method, we'll call out to +GNU MP - an insanely fast math library +(with tuned assembler for many architectures). (Editor: see +NativeBigInteger for faster public key cryptography)
+ugha and duck are working on the C/JNI glue code, and the existing java code +is already deployed with hooks for that whenever its ready. Preliminary results +look fantastic - running the router with the native GMP modPow is providing over +a 800% speedup in encryption performance, and the load was cut in half. This +was just on one user's machine, and things are nowhere near ready for packaging +and deployment, yet.
+ +Garlic wrapping a "reply" LeaseSet [implemented but needs tuning]
+This algorithm tweak will only be relevant for applications that want their +peers to reply to them (though that includes everything that uses I2PTunnel or +mihi's ministreaming lib):
+Previously, when Alice sent Bob a message, when Bob replied he had to do a +lookup in the network database - sending out a few requests to get Alice's +current LeaseSet. If he already has Alice's current LeaseSet, he can instead +just send his reply immediately - this is (part of) why it typically takes a +little longer talking to someone the first time you connect, but subsequent +communication is faster. Currently - for all clients - we wrap +the sender's current LeaseSet in the garlic that is delivered to the recipient, +so that when they go to reply, they'll always have the LeaseSet locally +stored - completely removing any need for a network database lookup on replies. +This trades off a large portion of the sender's bandwidth for that faster reply. +If we didn't do this very often, +overall network bandwidth usage would decrease, since the recipient doesn't +have to do the network database lookup.
++For unpublished LeaseSets such as "shared clients", this is the only way to +get the LeaseSet to Bob. Unfortunately this bundling every time adds +almost 100% overhead to a high-bandwidth connection, and much more to +a connection with smaller messages. +
+Changes scheduled for release 0.6.2 will bundle the LeaseSet only when +necessary, at the beginning of a connection or when the LeaseSet changes. +This will substantially reduce the total overhead of I2P messaging. +
+ +More efficient TCP rejection [implemented]
+At the moment, all TCP connections do all of their peer validation after +going through the full (expensive) Diffie-Hellman handshaking to negotiate a +private session key. This means that if someone's clock is really wrong, or +their NAT/firewall/etc is improperly configured (or they're just running an +incompatible version of the router), they're going to consistently (though not +constantly, thanks to the shitlist) cause a futile expensive cryptographic +operation on all the peers they know about. While we will want to keep some +verification/validation within the encryption boundary, we'll want to update the +protocol to do some of it first, so that we can reject them cleanly +without wasting much CPU or other resources.
+ +Adjust the tunnel testing [implemented]
+Rather than going with the fairly random scheme we have now, we should use a +more context aware algorithm for testing tunnels. e.g. if we already know its +passing valid data correctly, there's no need to test it, while if we haven't +seen any data through it recently, perhaps its worthwhile to throw some data its +way. This will reduce the tunnel contention due to excess messages, as well as +improve the speed at which we detect - and address - failing tunnels.
+ +Persistent Tunnel / Lease Selection
+Outbound tunnel selection implemented in 0.6.1.30, inbound lease selection +implemented in release 0.6.2.
+Selecting tunnels and leases at random for every message creates a large +incidence of out-of-order delivery, which prevents the streaming lib from +increasing its window size as much as it could. By persisting with the +same selections for a given connection, the transfer rate is much faster. +
+ +Compress some data structures [implemented]
+The I2NP messages and the data they contain is already defined in a fairly +compact structure, though one attribute of the RouterInfo structure is not - +"options" is a plain ASCII name = value mapping. Right now, we're filling it +with those published statistics - around 3300 bytes per peer. Trivial to +implement GZip compression would nearly cut that to 1/3 its size, and when you +consider how often RouterInfo structures are passed across the network, that's +significant savings - every time a router asks another router for a networkDb +entry that the peer doesn't have, it sends back 3-10 RouterInfo of them.
+ +Update the ministreaming protocol
[replaced by full streaming protocol] +Currently mihi's ministreaming library has a fairly simple stream negotiation +protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then +Alice and Bob send each other some data, until one of them sends the other a +CLOSE message. For long lasting connections (to an IRC server, for instance), +that overhead is negligible, but for simple one-off request/response situations +(an HTTP request/reply, for instance), that's more than twice as many messages as +necessary. If, however, Alice piggybacked her first payload in with the SYN +message, and Bob piggybacked his first reply with the ACK - and perhaps also +included the CLOSE flag - transient streams such as HTTP requests could be +reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.
+ +Implement full streaming protocol
[implemented] +The ministreaming protocol takes advantage of a poor design decision in the +I2P client protocol (I2CP) - the exposure of "mode=GUARANTEED", allowing what +would otherwise be an unreliable, best-effort, message based protocol to be used +for reliable, blocking operation (under the covers, its still all unreliable and +message based, with the router providing delivery guarantees by garlic wrapping +an "ACK" message in with the payload, so once the data gets to the target, the +ACK message is forwarded back to us [through tunnels, of course]).
+As I've +said, having +I2PTunnel (and the ministreaming lib) go this route was the best thing that +could be done, but more efficient mechanisms are available. When we rip out the +"mode=GUARANTEED" functionality, we're essentially leaving ourselves with an +I2CP that looks like an anonymous IP layer, and as such, we'll be able to +implement the streaming library to take advantage of the design experiences of +the TCP layer - selective ACKs, congestion detection, nagle, etc.
+{% endblock %} diff --git a/www.i2p2/pages/performance.html b/www.i2p2/pages/performance.html index 9a541e4c..c104206e 100644 --- a/www.i2p2/pages/performance.html +++ b/www.i2p2/pages/performance.html @@ -1,6 +1,8 @@ {% extends "_layout.html" %} {% block title %}Performance{% endblock %} {% block content %} +Updated August 2010, current as of router version 0.8 +Probably one of the most frequent things people ask is "how fast is I2P?", and no one seems to like the answer - "it depends". After trying out I2P, the next thing they ask is "will it get faster?", and the answer to that is a most @@ -11,50 +13,8 @@ related, and others still are protocol related. However, all of those dimensions affect the latency, throughput, and perceived performance of the network, as they reduce contention for scarce resources. This list is of course not comprehensive, but it does cover the major ones that are seen.
- -Native math [implemented]
-When I last profiled the I2P code, the vast majority of time was spent within -one function: java.math.BigInteger's -modPow. -Rather than try to tune this method, we'll call out to -GNU MP - an insanely fast math library -(with tuned assembler for many architectures). (Editor: see -NativeBigInteger for faster public key cryptography)
-ugha and duck are working on the C/JNI glue code, and the existing java code -is already deployed with hooks for that whenever its ready. Preliminary results -look fantastic - running the router with the native GMP modPow is providing over -a 800% speedup in encryption performance, and the load was cut in half. This -was just on one user's machine, and things are nowhere near ready for packaging -and deployment, yet.
- -Garlic wrapping a "reply" LeaseSet [implemented but needs tuning]
-This algorithm tweak will only be relevant for applications that want their -peers to reply to them (though that includes everything that uses I2PTunnel or -mihi's ministreaming lib):
-Previously, when Alice sent Bob a message, when Bob replied he had to do a -lookup in the network database - sending out a few requests to get Alice's -current LeaseSet. If he already has Alice's current LeaseSet, he can instead -just send his reply immediately - this is (part of) why it typically takes a -little longer talking to someone the first time you connect, but subsequent -communication is faster. Currently - for all clients - we wrap -the sender's current LeaseSet in the garlic that is delivered to the recipient, -so that when they go to reply, they'll always have the LeaseSet locally -stored - completely removing any need for a network database lookup on replies. -This trades off a large portion of the sender's bandwidth for that faster reply. -If we didn't do this very often, -overall network bandwidth usage would decrease, since the recipient doesn't -have to do the network database lookup.
--For unpublished LeaseSets such as "shared clients", this is the only way to -get the LeaseSet to Bob. Unfortunately this bundling every time adds -almost 100% overhead to a high-bandwidth connection, and much more to -a connection with smaller messages. -
-Changes scheduled for release 0.6.2 will bundle the LeaseSet only when -necessary, at the beginning of a connection or when the LeaseSet changes. -This will substantially reduce the total overhead of I2P messaging. -
- +For past performance improvements see the +Performance History.
Better peer profiling and selection
Probably one of the most important parts of getting faster performance will @@ -75,7 +35,7 @@ gave us a reference to someone we had never heard of). We can also do some tuning on what we actually send - how many peers we bounce back (or even if we bounce back a reply), as well as how many concurrent searches we perform.
-Longer SessionTag lifetime
+Session Tag Tuning and Improvements
The way the ElGamal/AES+SessionTag algorithm works is by managing a set of random one-time-use 32 byte arrays, and expiring them if they aren't used quickly enough. If we expire them too soon, we're @@ -86,6 +46,33 @@ tags, even more encryption failures may occur prior to detection). With some more active detection and feedback driven algorithms, we can safely and more efficiently tune the lifetime of the tags, replacing the ElGamal encryption with a trivial AES operation.
++Additional ideas for improving Session Tag delivery are described on the +ElGamal/AES+SessionTag page. +
+ + +Migrate sessionTag to synchronized PRNG
+Right now, our ElGamal/AES+SessionTag +algorithm works by tagging each encrypted message with a unique random +32 byte nonce (a "session tag"), identifying that message as being encrypted +with the associated AES session's key. This prevents peers from distinguishing +messages that are part of the same session, since each message has a completely +new random tag. To accomplish this, every few messages bundle a whole +new set of session tags within the encrypted message itself, transparently +delivering a way to identify future messages. We then have to keep track +of what messages are successfully delivered so that we know what tags +we may use.
+This works fine and is fairly robust, however it is inefficient in terms +of bandwidth usage, as it requires the delivery of these tags ahead of +time (and not all tags may be necessary, or some may be wasted, due to +their expiration). On average though, predelivering the session tag costs +32 bytes per message (the size of a tag). As Taral suggested though, that +size can be avoided by replacing the delivery of the tags with a synchronized +PRNG - when a new session is established (through an ElGamal encrypted +block), both sides seed a PRNG for use and generate the session tags on +demand (with the recipient precalculating the next few possible values +to handle out of order delivery).
Longer lasting tunnels
The current default tunnel duration of 10 minutes is fairly arbitrary, though @@ -96,13 +83,12 @@ network and CPU load (due to expensive tunnel creation messages).
This appears to be an easy fix for high load on the big-bandwidth routers, but we should not resort to it until we've tuned the tunnel building algorithms further. -However, the 10 minute tunnel lifetime is hardcoded in a few places, -so the code needs to be cleaned up before we could change the duration. +However, the 10 minute tunnel lifetime is hardcoded in quite a few places, +so substantial effort would be required to change the duration. +Also, it would be difficult to maintain backward compatibility with such a change.
-A new tunnel build algorithm was introduced in release 0.6.1.32 and it has greatly -reduced the number of tunnel builds. Together with better detection of -unreachable peers and other peer selection strategies implemented in release 0.6.1.33, -the situation is much improved, and there are no current plans to extend tunnel lifetime. +Currently, since the network average tunnel build success rate is fairly high, +there are no current plans to extend tunnel lifetime.
@@ -119,62 +105,20 @@ doesn't pass our test within 60 seconds "dead"? as tunable parameters to allow for more appropriate tradeoffs between bandwidth, latency, and CPU usage. -More efficient TCP rejection [implemented]
-At the moment, all TCP connections do all of their peer validation after -going through the full (expensive) Diffie-Hellman handshaking to negotiate a -private session key. This means that if someone's clock is really wrong, or -their NAT/firewall/etc is improperly configured (or they're just running an -incompatible version of the router), they're going to consistently (though not -constantly, thanks to the shitlist) cause a futile expensive cryptographic -operation on all the peers they know about. While we will want to keep some -verification/validation within the encryption boundary, we'll want to update the -protocol to do some of it first, so that we can reject them cleanly -without wasting much CPU or other resources.
- -Adjust the tunnel testing [implemented]
-Rather than going with the fairly random scheme we have now, we should use a -more context aware algorithm for testing tunnels. e.g. if we already know its -passing valid data correctly, there's no need to test it, while if we haven't -seen any data through it recently, perhaps its worthwhile to throw some data its -way. This will reduce the tunnel contention due to excess messages, as well as -improve the speed at which we detect - and address - failing tunnels.
- -Compress some data structures [implemented]
-The I2NP messages and the data they contain is already defined in a fairly -compact structure, though one attribute of the RouterInfo structure is not - -"options" is a plain ASCII name = value mapping. Right now, we're filling it -with those published statistics - around 3300 bytes per peer. Trivial to -implement GZip compression would nearly cut that to 1/3 its size, and when you -consider how often RouterInfo structures are passed across the network, that's -significant savings - every time a router asks another router for a networkDb -entry that the peer doesn't have, it sends back 3-10 RouterInfo of them.
- -Update the ministreaming protocol
[replaced by full streaming protocol] -Currently mihi's ministreaming library has a fairly simple stream negotiation -protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then -Alice and Bob send each other some data, until one of them sends the other a -CLOSE message. For long lasting connections (to an IRC server, for instance), -that overhead is negligible, but for simple one-off request/response situations -(an HTTP request/reply, for instance), that's more than twice as many messages as -necessary. If, however, Alice piggybacked her first payload in with the SYN -message, and Bob piggybacked his first reply with the ACK - and perhaps also -included the CLOSE flag - transient streams such as HTTP requests could be -reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.
- -Implement full streaming protocol
[implemented] -The ministreaming protocol takes advantage of a poor design decision in the -I2P client protocol (I2CP) - the exposure of "mode=GUARANTEED", allowing what -would otherwise be an unreliable, best-effort, message based protocol to be used -for reliable, blocking operation (under the covers, its still all unreliable and -message based, with the router providing delivery guarantees by garlic wrapping -an "ACK" message in with the payload, so once the data gets to the target, the -ACK message is forwarded back to us [through tunnels, of course]).
-As I've -said, having -I2PTunnel (and the ministreaming lib) go this route was the best thing that -could be done, but more efficient mechanisms are available. When we rip out the -"mode=GUARANTEED" functionality, we're essentially leaving ourselves with an -I2CP that looks like an anonymous IP layer, and as such, we'll be able to -implement the streaming library to take advantage of the design experiences of -the TCP layer - selective ACKs, congestion detection, nagle, etc.
+Full streaming protocol improvements
+-
+
+Additional ideas for improving the streaming library are described on the +streaming library page. +
{% endblock %} diff --git a/www.i2p2/pages/plugin_spec.html b/www.i2p2/pages/plugin_spec.html index a3645698..a24bfdca 100644 --- a/www.i2p2/pages/plugin_spec.html +++ b/www.i2p2/pages/plugin_spec.html @@ -205,52 +205,36 @@ foo.xpi2p is a sud file containing the following: -Plugin installer tasks -
+Plugin installer tasks
+This lists what happens when a plugin is installed by I2P.-
-
Plugin starter tasks
- - Check plugins.config for which to start. - For each one: +This lists what happens when plugins are started. +First, plugins.config is checked to see which plugins need to be started. +For each plugin:-
-
@@ -342,7 +326,7 @@ Pack200 unpacking is supported on routers 0.7.11-5 or higher, which is essential support plugins at all.
Here is the protocol stack for I2P. -See also theIndex to Technical Documentation. +See also the Index to Technical Documentation. Updated August 2010, current for router version 0.8.
-
| Standard Apps - | Jetty, Apache, Monotone, CVS, browsers - |
+ +Each of the layers in the stack provides extra capabilities. +The capabilities are listed below, starting at the bottom of the protocol stack. +
|
| Other I2P Apps - | Syndie, EepGet, plugins - |
+ +The following layers are strictly speaking no longer part of the I2P Protocol stack, they are not part of the core 'I2P router' functionality. +However, each of these layers adds additional functionality, to allow applications simple and convenient I2P usage. +
+Finally, what could be considered the 'I2P application layer', is a large number of applications on top of I2P. +We can order this based on the I2P stack layer they use. +
|
| SAM/BOB Apps - | - | IMule, i2p-bt, i2prufus, Robert
+
+
+
+ + Figure 1: The layers in the I2P Network stack. + - |
| Proxy Apps - | HTTP Client/Server, IRC Client, SOCKS - | Streamr - - |
| Interface Apps - | I2PTunnel - | SAM -/ -SAMv2 -/ -SAMv3 -(*), BOB - - |
| Java Apps - | i2psnark, Syndie, i2phex - | - - |
| End-to-End Transport - | Streaming Lib - | Datagrams - - |
| Client Protocol - | I2CP - - | |
| Network Protocol - | I2NP - - | |
| Garlic Encryption - | ElGamal/AES+SessionTag - - | |
| Tunnel Messages - | Tunnel Messages - - | |
| Tunnel Message Encryption - | AES256/CBC - - | |
| Transports - | NTCP - | SSU - - |
| Transport Encryption - | AES256/CBC - - | |
| - | Java NIO TCP - | UDP - - |
| OS - | TCP - - | |
* Note: SAM/SAMv2 can use both the streaming lib and datagrams. +
{% endblock %} diff --git a/www.i2p2/pages/streaming.html b/www.i2p2/pages/streaming.html index f15768ff..5ebdc51c 100644 --- a/www.i2p2/pages/streaming.html +++ b/www.i2p2/pages/streaming.html @@ -1,6 +1,7 @@ {% extends "_layout.html" %} -{% block title %}Streaming Lib{% endblock %} +{% block title %}Streaming Library{% endblock %} {% block content %} +Updated August 2010, current as of router version 0.8Overview
@@ -9,10 +10,12 @@ as it is not a core router function. In practice, however, it provides a vital function for almost all existing I2P applications, by providing a TCP-like streams over I2P, and allowing existing apps to be easily ported to I2P. +The other end-to-end transport library for client communication is the +datagram library.
The streaming library is a layer on top of the core -I2CP that allows reliable, in order, and authenticated streams +I2CP API that allows reliable, in-order, and authenticated streams of messages to operate across an unreliable, unordered, and unauthenticated message layer. Just like the TCP to IP relationship, this streaming functionality has a whole series of tradeoffs and optimizations available, but @@ -20,23 +23,9 @@ rather than embed that functionality into the base I2P code, it has been factore off into its own library both to keep the TCP-esque complexities separate and to allow alternative optimized implementations.
-History
-The streaming library has grown organically for I2P - first mihi implemented the -"mini streaming library" as part of I2PTunnel, which was limited to a window -size of 1 message (requiring an ACK before sending the next one), and then it was -refactored out into a generic streaming interface (mirroring TCP sockets) and the -full streaming implementation was deployed with a sliding window protocol and -optimizations to take into account the high bandwidth x delay product. Individual -streams may adjust the maximum packet size and other options. The default -message size is selected to fit precisely in two 1K I2NP tunnel messages, -and is a reasonable tradeoff between the bandwidth costs of -retransmitting lost messages and the latency of multiple messages. -
- --In addition, in consideration of the relatively high cost of subsequent messages, -the streaming library's protocol for scheduling and delivering messages has been optimized to +In consideration of the relatively high cost of messages, +the streaming library's protocol for scheduling and delivering those messages has been optimized to allow individual messages passed to contain as much information as is available. For instance, a small HTTP transaction proxied through the streaming library can be completed in a single round trip - the first messages bundle a SYN, FIN, and @@ -48,20 +37,51 @@ immediately.
-On the whole, however, the streaming library bears much resemblance to an +The streaming library bears much resemblance to an abstraction of TCP, with its sliding windows, congestion control algorithms (both slow start and congestion avoidance), and general packet behavior (ACK, SYN, FIN, RST, rto calculation, etc).
- -Usage
-The standard interface to the streaming lib is for the application to set up -a I2PSocketManagerFactory from the ministreaming lib. -Only I2PSocketManagerFactory is used here - everything else is from the full streaming lib -(I2PSocketManagerFull, not I2PSocketManagerImpl, and I2PSocketFull, not I2PSocketImpl). -The remainder of the ministreaming lib is not normally used - don't be confused. +The streaming library is +a robust library +which is optimized for operation over I2P. +It has a one-phase setup, and +it contains a full windowing implementation. +
+ + + + +API
+ ++The streaming library API provides a standard socket paradigm to Java applications. +The lower-level +I2CP +API is completely hidden, except that applications may pass +I2CP parameters through the streaming library, +to be interpreted by I2CP. +
+ ++The standard interface to the streaming lib is for the application to use the +I2PSocketManagerFactory +to create an +I2PSocketManager. +The application then asks the socket manager for an +I2PSession, +which will cause a connection to the router via +I2CP. +The application can then setup connections with an +I2PSocket +or receive connections with an +I2PServerSocket. +
++Here are the +full streaming library Javadocs.
@@ -69,218 +89,376 @@ For a good example of usage, see the i2psnark code.
-Advantages
-The streaming lib has many advantages over the ministreaming library written by mihi as a part of his -I2PTunnel application. -The streaming library is -a more robust streaming library -which is further optimized for operation over I2P. The two main issues with -the ministreaming library are its use of the traditional TCP two phase -establishment protocol and the current fixed window size of 1. -The streaming lib fixes both of these issues - it has a one-phase setup, and -it contains a full windowing implementation. -
- +Options and Defaults
-Significant tuning of the streaming lib parameters, -greatly increasing outbound performance, was implemented in 0.6.1.28. -Subsequent releases include additional tuning and bug fixes. - -
Default Parameters
-The current default values are listed below. -Lower case values are streaming lib parameters that can changed on a +The options and current default values are listed below. +Options are case-sensitive and may be set for the whole router, for a particular client, or for an individual socket on a per-connection basis. -These values are tuned for HTTP performance over typical I2P conditions. Other applications such +Many values are tuned for HTTP performance over typical I2P conditions. Other applications such as peer-to-peer services are strongly encouraged to modify as necessary, by setting the options and passing them via the call to -I2PSocketManagerFactory.createManager(_i2cpHost, _i2cpPort, opts). +I2PSocketManagerFactory.createManager(_i2cpHost, _i2cpPort, opts). Time values are in ms. --
-
-The streaming lib uses standard slow-start (exponential window growth) and congestion avoidance (linear window growth) -phases. However, before the 0.6.1.33 release, window growth was substantially slower than optimal; -these issues were fixed in release 0.6.1.33. +Note that higher-layer APIs, such as +SAM, +BOB, and +I2PTunnel, +may override these defaults with their own defaults. +Also note that many options only apply to servers listening for incoming connections.
+ +| Option | Default | Notes | +
|---|---|---|
| i2cp.accessList | null | Comma- or space-separated list of Base64 peer Hashes used for either access list or blacklist + |
| i2cp.enableAccessList | false + | Use the access list as a whitelist for incoming connections + |
| i2cp.enableBlackList | false + | Use the access list as a blacklist for incoming connections + |
| i2p.streaming.answerPings | true | Whether to respond to incoming pings + |
| i2p.streaming.congestionAvoidanceGrowthRateFactor | 1 + | + When we're in congestion avoidance, we grow the window size at the rate + of 1/(windowSize*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.connectDelay | -1 + | + How long to wait after instantiating a new con + before actually attempting to connect. If this is + <= 0, connect immediately with no initial data. If greater than 0, wait + until the output stream is flushed, the buffer fills, + or that many milliseconds pass, and include any initial data with the SYN. + |
| i2p.streaming.connectTimeout | 5*60*1000 | 5 minutes! + |
| i2p.streaming.inactivityAction | 2 (send) | (0=noop, 1=disconnect) + What to do on an inactivity timeout - do nothing, disconnect, or send a duplicate ack. + |
| i2p.streaming.inactivityTimeout | 90*1000 + | |
| i2p.streaming.initialAckDelay | 2000 + | |
| i2p.streaming.initialResendDelay | 1000 + | + The initial value of the resend delay field in the packet header, times 1000. + Not fully implemented; see below. + |
| i2p.streaming.initialRTT | 8000 | (if no sharing data available) + |
| i2p.streaming.initialWindowSize | 6 | (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.maxConnsPerMinute | 0 | Incoming connection limit (per peer; 0 means disabled) + |
| i2p.streaming.maxConnsPerHour | 0 | (per peer; 0 means disabled) + |
| i2p.streaming.maxConnsPerDay | 0 | (per peer; 0 means disabled) + |
| i2p.streaming.maxMessageSize | 1730 | The MTU in bytes. + |
| i2p.streaming.maxResends | 8 + | + Maximum number of retransmissions before failure. + |
| i2p.streaming.maxTotalConnsPerMinute | 0 | Incoming connection limit (all peers; 0 means disabled) + |
| i2p.streaming.maxTotalConnsPerHour | 0 | (all peers; 0 means disabled) + Use with caution as exceeding this will disable a server for a long time. + |
| i2p.streaming.maxTotalConnsPerDay | 0 | (all peers; 0 means disabled) + Use with caution as exceeding this will disable a server for a long time. + |
| i2p.streaming.maxWindowSize | 128 + | |
| i2p.streaming.profile | 1 (bulk) | (2=interactive not supported) + This doesn't currently do anything, but setting it to a value other than 1 will cause an error. + |
| i2p.streaming.slowStartGrowthRateFactor | 1 + | + When we're in slow start, we grow the window size at the rate + 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. + |
Protocol Specification
+Packet Format
++The format of a single packet in the streaming protocol is: +
+ ++----+----+----+----+----+----+----+----+ +| send Stream ID | rcv Stream ID | ++----+----+----+----+----+----+----+----+ +| sequence Num | ack Through | ++----+----+----+----+----+----+----+----+ +| nc | NACKs ... ++----+----+----+----+----+----+----+----+ + | rd | flags | opt size| opt data ++----+----+----+----+----+----+----+----+ + ... | ++----+----+----+----+----+----+----+----+ +| payload ... ++----+----+----+----// + + ++ +
| Field | Length | Contents + |
|---|---|---|
| sendStreamId | 4 byte Integer | Random number selected by the connection recipient +and constant for the life of the connection. +0 in the SYN message sent by the originator, and in subsequent messages, until a SYN reply is received, +containint the peer's stream ID. + + |
| receiveStreamId | 4 byte Integer | Random number selected by the connection originator +and constant for the life of the connection. May be 0 if unknown, for example in a RESET packet. + + |
| sequenceNum | 4 byte Integer | +The sequence for this message, starting at 0 in the SYN message, +and incremented by 1 in each message except for plain ACKs and retransmissions. +If the sequenceNum is 0 and the SYN flag is not set, this is a plain ACK +packet that should not be ACKed. + + |
| ackThrough | 4 byte Integer | +The highest packet sequence number that was received +on the receiveStreamId. This field is ignored on the initial +connection packet (where receiveStreamId is the unknown id) or +if the NO_ACK flag set. +All packets up to and including this sequence number are ACKed, +EXCEPT for those listed in NACKs below. + + |
| NACK count | 1 byte Integer | +The number of 4-byte NACKs in the next field + + |
| NACKs | n * 4 byte Integers | +Sequence numbers less than ackThrough that are not yet received. +Two NACKs of a packet is a request for a 'fast retransmit' of that packet. + + |
| resendDelay | 1 byte Integer | +How long is the creator of this packet going to wait before +resending this packet (if it hasn't yet been ACKed). The +value is seconds since the packet was created. +Currently ignored on receive. + + |
| flags | 2 byte value | +See below. + + |
| option size | 2 byte Integer | +The number of bytes in the next field + + |
| option data | 0 or more bytes | +As specified by the flags. See below. + + |
| payload | remaining packet size | + |
Flags and Option Data Fields
+The flags field above specifies some metadata about the packet, and in +turn may require certain additional data to be included. The flags are +as follows. Any data structures specified must be added to the options area +in the given order.
++Bit order: 15....0 (15 is MSB) +
+| Bit | Flag | Option Data | Function + |
|---|---|---|---|
| 0 | SYNCHRONIZE | -- | +Similar to TCP SYN. Set in the intial packet and in the first response. + |
| 1 | CLOSE | -- | +Similar to TCP FIN. If the response to a SYNCHRONIZE fits in a single message, the response +will contain both SYNCHRONIZE and CLOSE. + |
| 2 | RESET | -- | +Abnormal close. + |
| 3 | SIGNATURE_INCLUDED | 40 byte DSA Signature + | +Currently sent only with SYNCHRONIZE and CLOSE, where it is required. +The signature uses the Destination's DSA signing keys +to sign the entire header and payload with the 40-byte space in the option data field +for the signature being set to all zeroes. + |
| 4 | SIGNATURE_REQUESTED | -- | +Unused. Requests every packet in the other direction to have SIGNATURE_INCLUDED + |
| 5 | FROM_INCLUDED | 387+ byte Destination + | +Currently sent only with SYNCHRONIZE, where it is required. + |
| 6 | DELAY_REQUESTED | 2 byte Integer | +Optional delay. +How many milliseconds the sender of this packet wants the recipient +to wait before sending any more data. +A value greater than 60000 indicates choking. + |
| 7 | MAX_PACKET_SIZE_INCLUDED | 2 byte Integer | +Currently sent with SYNCHRONIZE or with a retransmission; +could be optimized to only send with a SYN. + |
| 8 | PROFILE_INTERACTIVE | -- | +Unused or ignored; the interactive profile is unimplemented. + |
| 9 | ECHO | -- | +Unused except by ping programs + |
| 10 | NO_ACK | -- | +This flag simply tells the recipient to ignore the ackThrough field in the header. +Currently unused, the ackThrough field is always valid. + |
| 11-15 | unused | + |
Implementation Details
+ +Setup
++The initiator sends a packet with the SYNCHRONIZE flag set. This packet may contain the initial data as well. +The peer replies with a packet with the SYNCHRONIZE flag set. This packet may contain the initial response data as well. +
++The initiator may send additional data packets, up to the initial window size, before receiving the SYNCHRONIZE response. +These packets will also have the send Stream ID field set to 0. +Recipients must buffer packets received on unknown streams for a short period of time, as they may +arrive out of order, in advance of the SYNCHRONIZE packet. +
+ +MTU Selection and Negotiation
The maximum message size (also called the MTU / MRU) is negotiated to the lower value supported by the two peers. As tunnel messages are padded to 1KB, a poor MTU selection will lead to a large amount of overhead. -The MTU is chosen to fit precisely in an integral number of 1K I2NP tunnel messages, +The MTU is specified by the option i2p.streaming.maxMessageSize. +The current default MTU of 1730 was chosen to fit precisely into two 1K I2NP tunnel messages, including overhead for the typical case. +
+The first message in a connection includes a 387 byte (typical) Destination added by the streaming layer, -and usually a 898 byte (typical) LeaseSet bundled in the Garlic message. -Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not realistic. +and usually a 898 byte (typical) LeaseSet, and Session keys, bundled in the Garlic message by the router. +(The LeaseSet and Session Keys will not be bundled if an ElGamal Session was previously established). +Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not always attainable. However, the selection of the MTU, together with careful implementation of fragmentation and batching strategies in the tunnel gateway processor, are important factors in network bandwidth, latency, reliability, and efficiency, especially for long-lived connections.
--The interaction of the routing algorithms with the streaming lib strongly affects performance. -In particular, random distribution of messages to multiple tunnels in a pool -leads to a high degree of out-of-order delivery which results in smaller window -sizes than would otherwise be the case. -In release 0.6.1.30, the routing of messages to the outbound tunnels was made -consistent, with pushback when a tunnel was backlogged. -This had a significant positive impact on bandwidths. -The pushback code was reverted in release 0.6.1.31 due to anonymity concerns. -Consistent message routing to inbound tunnels -was implemented in release 0.6.1.32. -
+Data Integrity
+Data integrity is assured by the gzip CRC-32 checksum implemented in +the I2CP layer. +There is no checksum field in the streaming protocol. + +Packet Encapsulation
+Each packet is sent through I2P as a single message (or as an individual clove in a +Garlic Message). +Message encapsulation is implemented in the underlying +I2CP, +I2NP, and +tunnel messagelayers. +There is no packet delimiter mechanism or payload length field in the streaming protocol. + + +Windowing
-Another area for research is the interaction of the streaming lib with the -NTCP and SSU transport layers. -See the NTCP page for a discussion. +The streaming lib uses standard slow-start (exponential window growth) and congestion avoidance (linear window growth) +phases, with exponential backoff. +Windowing and acknowledgements use packet count, not byte count.
-Packet Format
+Close
-Here is the format of a single packet transferred as part of a streaming connection. -
| Field | Length | Contents - |
|---|---|---|
| sendStreamId | 4 byte value | Random number selected by the connection recipient -and constant for the life of the connection. -0 in the SYN message sent by the originator. - |
| receiveStreamId | 4 byte value | Random number selected by the connection originator -and constant for the life of the connection. - - |
| sequenceNum | 4 byte unsigned integer | -The sequence for this message, starting at 0 in the SYN message, -and incremented by 1 in each message except for plain ACKs and retransmissions. -If the sequenceNum is 0 and the SYN is not set, this is a plain ACK -packet that should not be ACKed. - - |
| ackThrough | 4 byte unsigned integer | -The highest packet sequence number that was received -on the receiveStreamId. This field is ignored on the initial -connection packet (where receiveStreamId is the unknown id) or -if FLAG_NO_ACK is set. -All packets up to and including this sequence number are ACKed, -EXCEPT for those listed in NACKs below. - - |
| number of NACKs | 1 byte unsigned integer | - - |
| that many NACKs | n * 4 byte unsigned integers | -Sequence numbers less than ackThrough that are not yet received. -Two NACKs of a packet is a request for a 'fast retransmit' of that packet. - - |
| resendDelay | 1 byte unsigned integer | -How long is the creator of this packet going to wait before -resending this packet (if it hasn't yet been ACKed). The -value is seconds since the packet was created. -Ignored on receive. Broken on send before release 0.7.8 (the sender did not divide by 1000, -and the default is 1000 ms, so the included value was 1000 & 0xff = 0xe8 = 232 seconds. - - |
| flags | 2 byte value | -See below. - - |
| option data size | 2 byte unsigned integer | -See below. - - |
| option data specified by those flags | 0 or more bytes | -See below. - - |
| payload | remaining packet size | - |
The flags field above specifies some metadata about the packet, and in -turn may require certain additional data to be included. The flags are -as follows (with any data structures specified added to the options area -in the given order):
-| Bit Number | Flag | Option Data | Function - |
|---|---|---|---|
| 0 | FLAG_SYNCHRONIZE | no option data | -Similar to TCP SYN. - |
| 1 | FLAG_CLOSE | no option data | -Similar to TCP FIN. If the response to a SYN fits in a single message, the response -will contain both FLAG_SYNCHRONIZE and FLAG_CLOSE. - |
| 2 | FLAG_RESET | no option data | -Abnormal close. - |
| 3 | FLAG_SIGNATURE_INCLUDED | 40 bytes | net.i2p.data.Signature -Typically sent only with FLAG_SYNCHRONIZE and FLAG_CLOSE, where it is required. -If the signature is included, it uses the Destination's DSA key -to sign the entire header and payload with the space in the options -for the signature being set to all zeroes. - |
| 4 | FLAG_SIGNATURE_REQUESTED | no option data | -Unused. Requests every packet in the other direction to have FLAG_SIGNATURE_INCLUDED - |
| 5 | FLAG_FROM_INCLUDED | typ. 387 bytes | net.i2p.data.Destination -Typically sent only with FLAG_SYNCHRONIZE. - |
| 6 | FLAG_DELAY_REQUESTED | 2 byte integer | -Optional delay. -How many milliseconds the sender of this packet wants the recipient -to wait before sending any more data. -A value greater than 60000 indicates choking. - |
| 7 | FLAG_MAX_PACKET_SIZE_INCLUDED | 2 byte integer | -Sent with FLAG_SYNCHRONIZE or with a retransmission, -could be optimized to only send with a SYN. - |
| 8 | FLAG_PROFILE_INTERACTIVE | no option data | -Apparently unused or ignored - |
| 9 | FLAG_ECHO | no option data | -Unused except by ping programs - |
| 10 | FLAG_NO_ACK | no option data | -Apparently unused, an ACK is always included. -This flag simply tells the recipient to ignore the ackThrough field in the header. - |
| 11-15 | unused | - |
Control Block Sharing
+Control Block Sharing
-As of release 0.7.1, the streaming lib supports "TCP" Control Block sharing. +The streaming lib supports "TCP" Control Block sharing. This shares two important streaming lib parameters (window size and round trip time) 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 RFC 2140). +not "ensemble" sharing during a connection (See +RFC 2140). 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.
-Future Work and Proposals
+Other Parameters
+The following parameters are hardcoded, but may be of interest for analysis: +-
+
- MIN_RESEND_DELAY = 2*1000 (minimum RTO) +
- MAX_RESEND_DELAY = 45*1000 (maximum RTO) +
- MIN_WINDOW_SIZE = 1 +
- TREND_COUNT = 3 +
- RTT_DAMPENING = 0.875 +
- MIN_MESSAGE_SIZE = 512 (minimum MTU) +
- INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2) +
- INITIAL_TIMEOUT = 1.5 * initialRTT +
- PASSIVE_FLUSH_DELAY = 250 +
- Maximum RTT estimate: 60*1000 +
History
+The streaming library has grown organically for I2P - first mihi implemented the +"mini streaming library" as part of I2PTunnel, which was limited to a window +size of 1 message (requiring an ACK before sending the next one), and then it was +refactored out into a generic streaming interface (mirroring TCP sockets) and the +full streaming implementation was deployed with a sliding window protocol and +optimizations to take into account the high bandwidth x delay product. Individual +streams may adjust the maximum packet size and other options. The default +message size is selected to fit precisely in two 1K I2NP tunnel messages, +and is a reasonable tradeoff between the bandwidth costs of +retransmitting lost messages, and the latency and overhead of multiple messages. +
+ + + + + +Future Work
+The behavior of the streaming library has a profound impact on +application-level performance, and as such, is an important +area for further analysis. +-
+
- +Additional tuning of the streaming lib parameters may be necessary. + +
- +Another area for research is the interaction of the streaming lib with the +NTCP and SSU transport layers. +See the NTCP discussion page for details. + +
- +The interaction of the routing algorithms with the streaming lib strongly affects performance. +In particular, random distribution of messages to multiple tunnels in a pool +leads to a high degree of out-of-order delivery which results in smaller window +sizes than would otherwise be the case. +The router currently routes messages for a single from/to destination pair +through a consistent set of tunnels, until tunnel expiration or deli>very failure. +The router's failure and tunnel selection algorithms should be reviewed +for possible improvements. + +
- +The data in the first SYN packet may exceed the receiver's MTU. + +
- +The DELAY_REQUESTED field could be used more. + +
- +Duplicate initial SYNCHRONIZE packets on short-lived streams may not be recognized and removed. + +
- +Don't send the MTU in a retransmission. + +
- + Data is sent along unless the outbound window is full. + (i.e. no-Nagle or TCP_NODELAY) + Probably should have a configuration option for this. + +
- +zzz has added debug code to the streaming library to log packets in a wireshark-compatible +(pcap) format; Use this to further analyze performance. +The format may require enhancement to map more streaming lib parameters to TCP fields. + +
- There are proposals to replace the streaming lib with standard TCP (or perhaps a null layer together with raw sockets). This would unfortunately be incompatible with the streaming lib but it would be good to compare the performance of the two. - + +
Supported Applications
+This is intended to be a comprehensive listing of applications used with I2P. If you know of something that’s missing please submit a ticket on Trac, and be sure to select the “www” component in the submission form.
Supported applications are tagged with one or more of the following:
- bundled
Bundled application — I2P ships with a few officially supported applications that let new users take immediate advantage of some of I2P’s more useful capabilities.
- plugin
Third-party plugin — I2P’s plugin system provides convenient deployment of I2P-enabled applications and allows tighter integration with the router.
- standalone, standalone/mod
Third-party standalone application — Many standard network applications only require careful setup and configuration to communicate anonymously over I2P. These are tagged with standalone. Some applications, tagged with standalone/mod, require patching to function properly over I2P or to prevent inadvertent disclosure of identifying information such as the user’s hostname or external IP address.
- service
Third-party essential network service — Services which on the I2P network are analogous to those provided on the public Internet by hosting providers, ISPs, and Google: eepsite indexes and jump services, search engines, email, DNS-style name services, hosting, proxies, etc. These services focus on boosting the usefulness of the network as a whole, and making network content more discoverable.
- unmaintained
Unmaintained — This is used to tag plugins, applications, and services which appear to be unmaintained and may be removed from this listing in the future.
Warning: Using an application, plugin, or service with I2P doesn’t automatically protect your anonymity. I2P is merely a set of tools which can help you mitigate certain identified threats to anonymity. We do not and cannot make any guarantees about the safety of the applications, plugins, and services listed below. Most applications and plugins must be properly configured, and some will need to be patched — and even then your anonymity might not be assured. Similarly, services could put your anonymity at risk, either by design or through carelessness on their part or your own.
If you have doubts about the suitability of an application, plugin, or service for use with I2P, you are urged to inquire about privacy issues with its maintainers, to search its mailing lists and bug tracker if one exists, and consult trusted, knowledgeable members of the I2P community.
Take responsibility for your own anonymity and safety — always seek expert advice, educate yourself, practice good judgment, be mindful of disclosing personally identifying information, and don’t take shortcuts.
Blogging and Forums
Blojsom — Lightweight blogging platform. [plugin, standalone/mod]
El Dorado — Lightweight forum software. [standalone/mod]
Pebble — Another lightweight blogging platform. [plugin, standalone/mod]
phpBB — Most popular open source forum software. [standalone/mod]
Syndie — Distributed forums software, originally developed by jrandom. [plugin, standalone, unmaintained]
Decentralized File Storage
- Tahoe-LAFS-I2P — Port of the Tahoe-LAFS distributed file system to the I2P network. Controller plugin here. [plugin, standalone]
Development Tools
Version control
Git — Most popular distributed version control system. [standalone]
Monotone — Another distributed version control system. Currently used in I2P development. [standalone]
Domain Naming
- susidns — Provides management of addressbooks, which are part of a simple, user-controlled I2P naming system somewhat analogous to the Internet’s Domain Name System (DNS). Addressbooks map Base64 destinations to short, usually human-readable “domain” names ending with a .i2p suffix which the I2P router’s HTTP client can resolve back to Base64 addresses. (Note: While Base64 destinations are globally unique, addressbook “domain” names only resolve to unique destinations locally.) [bundled]
I2P-Bote — Serverless peer-to-peer email application using a distributed hash table (DHT) for secure mail storage. [plugin]
Postman’s anonymous email service — Provides email service within the I2P network via @mail.i2p addresses, and email gateway service between the I2P network and the public Internet via @i2pmail.org addresses. One of the oldest continuous services on I2P. [service]
susimail — Simple web browser-based email interface. Configured to use Postman’s email service by default. [bundled]
File Sharing
BitTorrent clients
I2PSnark — I2P’s integrated BitTorrent client. [bundled]
I2PSnarkXL — Modified version of I2PSnark. [standalone]
Robert — a fork of rufus that uses the Basic Open Bridge (BOB) and has many improvements, including using the latest wxwidgets and python. It also supports use of seedless if installed for trackerless torrents and magnet-link like fetching of torrents within i2p. [plugin, standalone]
Transmission — Clean, full-featured cross-platform BitTorrent client with official ports for several GUI toolkits. [standalone/mod]
Azureus/Vuze — Had a built-in I2P transport for a while. [standalone, unmaintained]
BitTorrent trackers and indexers
For a detailed feature comparison of I2P-enabled trackers/indexers, see here.
Bytemonsoon — The code that powered one of the first major tracker/indexer sites on the Internet. Patched for I2P. [standalone/mod]
opentracker — Lightweight tracker/indexer. I2P mod available in the i2p.opentracker branch of the I2P Monotone repository. [standalone/mod]
zzzot — zzz’s Java-based open tracker. More info here. [plugin]
ED2K
- iMule — I2P port of the aMule ED2K client. [standalone]
Gnutella
I2Phex — Port of the Phex Gnutella client. Website for plugin version here. [plugin, standalone]
jwebcache — Cache for Gnutella peers on I2P. Website for plugin version here. [plugin, standalone]
Network Administration
General-purpose socket utilities
netcat — Unix standard tool for socket relaying. Several clones, ports, and forks have appeared over the years. [standalone]
socat — Like netcat but more powerful. [standalone]
tsocks — Proxy providing simple, transparent SOCKS-ification of network applications. [standalone]
SSH/SCP/SFTP
OpenSSH — Most popular implementation of the Secure Shell (SSH) protocol and related tools. [standalone]
PuTTY — Open source Secure Shell (SSH) client for Windows. [standalone]
Real-time Chat
Instant messaging clients
- I2P Messenger — IM client with multiple incarnations. [standalone]
IRC clients
Many IRC clients leak identifying information to servers or other clients, so I2P’s IRC and SOCKS IRC client tunnels filter certain inbound and outbound messages to scrub data such as LAN IP addresses, external IP addresses, local hostnames, and the name and version of the IRC client. Two message types in particular, DCC and CTCP, can’t be sufficiently anonymized without changes to the protocols or to IRC client/server code, so they are completely blocked, except for CTCP ACTION (the message emitted by the /me command) which isn’t inherently dangerous.
I2P’s IRC filtering may not cover every possible leak — users should also check if their client is sending their real name or local username. Packet sniffers such as Wireshark are useful here. Eliminating remaining leaks may be as simple as changing the client’s default configuration. If that doesn’t help, inform the I2P developers; they may be able to solve it via additional filtering.
jIRCii — Small Java-based IRC client. Plugin available here. [plugin, standalone]
XChat — Cross-platform graphical IRC client. [standalone]
irssi — Unixy terminal-based IRC client. [standalone]
WeeChat — Another Unixy terminal-based IRC client. [standalone]
IRC servers
ngIRCd — IRC server developed from scratch. [standalone/mod]
UnrealIRCd — Most popular IRC server. [standalone/mod]
Web Browsing
Anonymous websites
Eepsites — Any website hosted anonymously on I2P, reachable through the I2P router’s HTTP proxy. [service]
Deepsites — Distributed anonymous websites hosted using Tahoe-LAFS-I2P, currently only reachable with Tahoe-LAFS-I2P clients or through the Tahoe-LAFS-I2P HTTP proxy. [service]
i2host.i2p — Website for sponge’s jump service. Source code available. [service]
i2jump.i2p — Another jump service. [service]
perv.i2p — Dynamically updated eepsite index. [service]
Proxy software
Polipo — SOCKS-enabled caching web proxy with basic filtering capabilities. [standalone]
Privoxy — Privacy-focused non-caching web proxy with advanced filtering capabilities. Excels at removing ads and other junk. [standalone]
Squid — Venerable caching web proxy. [standalone]
Inproxies
Gateways allowing users on the public Internet to access eepsites.
Outproxies
Gateways allowing I2P users to access content hosted on the public Internet.
- false.i2p — Publicly advertised outproxy running Squid. Appears to be located in Germany. [service]
Website Hosting
- Jetty — Lightweight web server and Java servlet container. I2P is tightly integrated with a bundled copy of Jetty which by default is configured to host the user’s eepsite. The bundled Jetty also serves the I2P router console and web applications bundled with I2P. [bundled, standalone]
Web servers
In addition to Jetty, any web server should function over I2P without modification so long as it’s HTTP-compliant. Some web servers known to currently serve content on the I2P network are:
Apache HTTP Server — Most popular web server on the public WWW. [standalone]
Apache Tomcat — Web server and Java servlet container. More features than Jetty. [standalone]
lighttpd — Fast lightweight web server. [standalone]
nginx — High-performance lightweight web server. [standalone]
I2P: A scalable framework for anonymous communication
--
-IN THIS DOCUMENT |
- - |
- - |
-
| - | -||
-FOR MORE INFORMATION |
-
|
-
|
-
Table of Contents
+-
+
- Introduction +
-
+ I2P Operation
+
-
+
- Overview +
- Tunnels +
- Network Database +
- Transport protocols +
- Cryptography +
+
Introduction
@@ -168,7 +112,13 @@ and an end point. Messages can be sent only in one way. To send messages back, another tunnel is required.
-
+
+ + Figure 1: Two types of tunnels exist: inbound and outbound. +
Two types of tunnels exist: "outbound" tunnels send messages away from the tunnel creator, @@ -186,24 +136,42 @@ inbound gateway (the gateway to "Bob").
- A third critical concept to understand is I2P's "network database" (or "netDb") + A third critical concept to understand is I2P's "network database" (or "netDb") - a pair of algorithms used to share network metadata. The two types of metadata - carried are "routerInfo" and "leaseSets" - the routerInfo gives routers the + carried are "routerInfo" and "leaseSets" - the routerInfo gives routers the data necessary for contacting a particular router (their public keys, transport addresses, etc), while the leaseSet gives routers the information necessary - for contacting a particular destination. Within each leaseSet, there are any - number of "leases", each of which specifies the gateway for one of that destination's - inbound tunnels as well as when that tunnel will expire. The leaseSet also - contains a pair of public keys which can be used for layered garlic encryption. + for contacting a particular destination. A leaseSet contains a number of "leases". + Each of this leases specifies a tunnel gateway, which allows reaching a specific destination. + The full information contained in a lease: +
-
+
- Inbound gateway for a tunnel that allows reaching a specific destination. +
- Time when a tunnel expires. +
- Pair of public keys to be able to encrypt messages (to send through the tunnel and reach the destination). +
When Alice wants to send a message to Bob, she first does a lookup in the +
+ We can combine the above concepts to build successful connections in the network. +
++ To build up her own inbound and outbound tunnels, Alice does a lookup in the netDb to collect routerInfo. + This way, she gathers lists of peers she can use as hops in her tunnels. + She can then send a build message to the first hop, requesting the construction of a tunnel, and asking + that router to send the construction message onward, until the tunnel has been constructed. +
+
+
+ 
+ + Figure 2: Router information is used to build tunnels. +
+
+ When Alice wants to send a message to Bob, she first does a lookup in the netDb to find Bob's leaseSet, giving her his current inbound tunnel gateways. She then picks one of her outbound tunnels and sends the message down it with instructions for the outbound tunnel's endpoint to forward the message on @@ -211,12 +179,22 @@ I2P's operation can be understood by putting those three concepts together: receives those instructions, it forwards the message as requested, and when Bob's inbound tunnel gateway receives it, it is forwarded down the tunnel to Bob's router. If Alice wants Bob to be able to reply to the message, she - needs to transmit her own destination explicitly as part of the message itself - (taken care of transparently in the streaming - library). Alice may also cut down on the response time by bundling her most + needs to transmit her own destination explicitly as part of the message itself. + This can be done by introducing a higher-level layer, which is done in the + streaming library. + Alice may also cut down on the response time by bundling her most recent leaseSet with the message so that Bob doesn't need to do a netDb lookup - for it when he wants to reply, but this is optional.
-While the tunnels themselves have layered encryption to prevent unauthorized + for it when he wants to reply, but this is optional. +
+
+ + Figure 3: Leasesets are used to connect outbound and inbound tunnels. +
+
+ While the tunnels themselves have layered encryption to prevent unauthorized disclosure to peers inside the network (as the transport layer itself does to prevent unauthorized disclosure to peers outside the network), it is necessary to add an additional end to end layer of encryption to hide the message from @@ -227,16 +205,20 @@ I2P's operation can be understood by putting those three concepts together: those messages say, or where those individual cloves are destined. For typical end to end communication between Alice and Bob, the garlic will be encrypted to the public key published in Bob's leaseSet, allowing the message to be - encrypted without giving out the public key to Bob's own router.
-Another important fact to keep in mind is that I2P is entirely message based + encrypted without giving out the public key to Bob's own router. +
++ Another important fact to keep in mind is that I2P is entirely message based and that some messages may be lost along the way. Applications using I2P can use the message oriented interfaces and take care of their own congestion control and reliability needs, but most would be best served by reusing the provided streaming library to view I2P as a streams - based network.
+ based network. +Tunnels
-Both inbound and outbound tunnels work along similar principles - the tunnel - gateway accumulates a number of tunnel messages, eventually preprocessing +
+ Both inbound and outbound tunnels work along similar principles. + The tunnel gateway accumulates a number of tunnel messages, eventually preprocessing them into something for tunnel delivery. Next, the gateway encrypts that preprocessed data and forwards it to the first hop. That peer and subsequent tunnel participants add on a layer of encryption after verifying that it isn't a duplicate before @@ -246,18 +228,22 @@ I2P's operation can be understood by putting those three concepts together: the creator is the endpoint and they simply decrypt all of the layers added, while for outbound tunnels, the creator is the gateway and they pre-decrypt all of the layers so that after all of the layers of per-hop encryption are - added, the message arrives in the clear at the tunnel endpoint.
-The choice of specific peers to pass on messages as well as their particular + added, the message arrives in the clear at the tunnel endpoint. +
++ The choice of specific peers to pass on messages as well as their particular ordering is important to understanding both I2P's anonymity and performance characteristics. While the network database (below) has its own criteria for - picking what peers to query and store entries on, tunnels may use any peers + picking what peers to query and store entries on, tunnel creators may use any peers in the network in any order (and even any number of times) in a single tunnel. If perfect latency and capacity data were globally known, selection and ordering would be driven by the particular needs of the client in tandem with their threat model. Unfortunately, latency and capacity data is not trivial to gather anonymously, and depending upon untrusted peers to provide this information - has its own serious anonymity implications.
-From an anonymity perspective, the simplest technique would be to pick peers + has its own serious anonymity implications. +
++ From an anonymity perspective, the simplest technique would be to pick peers randomly from the entire network, order them randomly, and use those peers in that order for all eternity. From a performance perspective, the simplest technique would be to pick the fastest peers with the necessary spare capacity, @@ -266,8 +252,10 @@ I2P's operation can be understood by putting those three concepts together: former is both brittle and inefficient, the later requires inaccessible information and offers insufficient anonymity. I2P is instead working on offering a range of peer selection strategies, coupled with anonymity aware measurement code - to organize the peers by their profiles.
-As a base, I2P is constantly profiling the peers with which it interacts + to organize the peers by their profiles. +
++ As a base, I2P is constantly profiling the peers with which it interacts with by measuring their indirect behavior - for instance, when a peer responds to a netDb lookup in 1.3 seconds, that round trip latency is recorded in the profiles for all of the routers involved in the two tunnels (inbound and outbound) @@ -281,19 +269,22 @@ I2P's operation can be understood by putting those three concepts together: to be. These calculations are then compared for active peers to organize the routers into four tiers - fast and high capacity, high capacity, not failing, and failing. The thresholds for those tiers are determined dynamically, and - while they currently use fairly simple algorithms, alternatives exist.
+ while they currently use fairly simple algorithms, alternatives exist. +Using this profile data, the simplest reasonable peer selection strategy is to pick peers randomly from the top tier (fast and high capacity), and this is currently deployed for client tunnels. Exploratory tunnels (used for - netDb and tunnel management) pick peers randomly from the not failing tier + netDb and tunnel management) pick peers randomly from the "not failing" tier (which includes routers in 'better' tiers as well), allowing the peer to sample routers more widely, in effect optimizing the peer selection through randomized hill climbing. These strategies alone do however leak information regarding the peers in the router's top tier through predecessor and netDb harvesting attacks. In turn, several alternatives exist which, while not balancing the load as evenly, will address the attacks mounted by particular classes of - adversaries.
-By picking a random key and ordering the peers according to their XOR distance + adversaries. +
++ By picking a random key and ordering the peers according to their XOR distance from it, the information leaked is reduced in predecessor and harvesting attacks according to the peers' failure rate and the tier's churn. Another simple strategy for dealing with netDb harvesting attacks is to simply fix the inbound @@ -309,89 +300,79 @@ I2P's operation can be understood by putting those three concepts together: using individual peers if all of them agree to participate in the same way each time. This varies from the XOR based ordering in that the predecessor and successor of each peer is always the same, while the XOR only makes sure - their order doesn't change.
-As mentioned before, I2P currently (release 0.6.1.1) includes the tiered - random strategy above. Release 0.6.1.33 will contain the XOR-based ordering - strategy. Additional improvements may be included in the 0.6.2 release. A + their order doesn't change. +
++ As mentioned before, I2P currently (release 0.8) includes the tiered + random strategy above, with XOR-based ordering. A more detailed discussion of the mechanics involved in tunnel operation, management, and peer selection can be found in the tunnel spec.
Network Database
-Kademlia has been disabled - see NetDb - Status
-As mentioned earlier, I2P's netDb works to share the network's metadata. - Two algorithms are used to accomplish this - primarily, a small set of routers - are designated as "floodfill peers", while the rest of the routers participate - in the Kademlia derived - distributed hash table for redundancy. To integrate the two algorithms, each - router always uses the Kademlia style store and fetch, but acts as if the - floodfill peers are 'closest' to the key in question. Additionally, when a - peer publishes a key into the netDb, after a brief delay they query another - random floodfill peer, asking them for the key, and if that peer does not - have it, they move on and republish the key again. Behind the scenes, when - one of the floodfill peers receives a new valid key, they republish it to - the other floodfill peers who then cache it locally.
-Each piece of data in the netDb is self authenticating - signed by the appropriate - party and verified by anyone who uses or stores it. In addition, the data - has liveliness information within it, allowing irrelevant entries to be dropped, - newer entries to replace older ones, and, for the paranoid, protection against - certain classes of attack. This is also why I2P bundles the necessary code - for maintaining the correct time, occasionally querying some SNTP servers - (the pool.ntp.org round robin by default) - and detecting skew between routers at the transport layer.
-The routerInfo structure itself contains all of the information that one - router needs to know to securely send messages to another router. This includes - their identity (made up of a 2048bit ElGamal public key, a 1024bit DSA public - key, and a certificate), the transport addresses which they can be reached - on, such as an IP address and port, when the structure was published, and - a set of arbitrary uninterpreted text options. In addition, there is a signature - against all of that data as generated by the included DSA public key. The - key for this routerInfo structure in the netDb is the SHA256 hash of the router's - identity. The options published are often filled with information helpful - in debugging I2P's operation, but when I2P reaches the 1.0 release, the options - will be disabled and kept blank.
-The leaseSet structure is similar, in that it includes the I2P destination - (comprised of a 2048bit ElGamal public key, a 1024bit DSA public key, and - a certificate), a list of "leases", and a pair of public keys for garlic encrypting - messages to the destination. Each of the leases specify one of the destination's - inbound tunnel gateways by including the SHA256 of the gateway's identity, - a 4 byte tunnel id on that gateway, and when that tunnel will expire. The - key for the leaseSet in the netDb is the SHA256 of the destination itself. +
+ As mentioned earlier, I2P's netDb works to share the network's metadata. + This is detailed in the networkdatabase page, + but a basic explanation is available below. +
++ A percentage of I2P users are appointed as 'floodfill peers'. + Currently, I2P installations that have a lot of bandwidth and are fast enough, + will appoint themselves as floodfill as soon as the number of existing floodfill routers + drops too low. +
++ Other I2P routers will store their data and lookup data by sending simple 'store' and 'lookup' queries to the floodfills. + If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers + using the Kademlia algorithm. + The 'lookup' queries currently function differently, to avoid an important + security issue. + When a lookup is done, the floodfill router will not forward the lookup to other peers, + but will always answer by itself (if it has the requested data). +
++ Two types of information are stored in the network database. +
-
+
- A routerInfo stores information on a specific I2P router and how to contact it +
- A leaseSet stores information on a specific destination (e.g. I2P website, e-mail server...) +
+ Some additional remarks are also important. +
-
+
-
+ Unpublished and encrypted leasesets:
+
+ One could only want specific people to be able to reach a destination. + This is possible by not publishing the destination in the netDb. You will however have to transmit the destination by other means. + An alternative are the 'encrypted leaseSets'. These leaseSets can only be decoded by people with access to the decryption key. +
+
+ -
+ Bootstrapping:
+
+ Bootstrapping the netDb is quite simple. Once a router manages to receive a single routerInfo of a reachable peer, + it can query that router for references to other routers in the network. + Currently, a number of users post their routerInfo files to a website to make this information available. + I2P automatically connects to one of these websites to gather routerInfo files and bootstrap. +
+
+ -
+ Lookup scalability:
+
+ Lookups in the I2P network are not forwarded to other netDb routers. + Currently, this is not a major problem, since the network is not very large. + However, as the network grows, not all routerInfo and leaseSet files will be present + on each netDb router. This will cause a deterioration of the percentage of successful lookups. + Because of this, refinements to the netDb will be done in the next releases. +
+
+
As the router currently automatically bundles the leaseSet for the sender - inside a garlic message to the recipient, the leaseSet for destinations which - will not receive unsolicited messages do not need to be published in the netDb - at all. If the destination itself is sensitive, the leaseSet could instead - be transmitted through other means without ever going into the netDb.
-Bootstrapping the netDb itself is simple - once a router has at least one - routerInfo of a reachable peer, they query that router for references to other - routers in the network with the Kademlia healing algorithm. Each routerInfo - reference is stored in an individual file in the router's netDb subdirectory, - allowing people to easily share their references to bootstrap new users.
-Unlike traditional DHTs, the very act of conducting a search distributes - the data as well, since rather passing Kademlia's standard IP+port pairs, - references are given to the routers that the peer should query next (namely, - the SHA256 of those routers' identities). As such, iteratively searching for - a particular destination's leaseSet or router's routerInfo will also provide - you with the routerInfo of the peers along the way. In addition, due to the - time sensitivity of the data published, the information doesn't often need - to migrate between peers - since a tunnel is only valid for 10 minutes, the - leaseSet can be dropped after that time has passed. To take into account Sybil - attacks on the netDb, the Kademlia routing location used for any given key - varies over time. For instance, rather than storing a routerInfo on the peers - closest to SHA256(routerInfo.identity), they are stored on the peers closest - to SHA256(routerInfo.identity + YYYYMMDD), requiring an adversary to remount - the attack again daily so as to maintain their closeness to the current routing - key. As the very fact that a router is making a lookup for a given key may - expose sensitive data (and the fact that a router is publishing a given - key even more so), all netDb messages are transmitted through the router's - exploratory tunnels.
-The netDb plays a very specific role in the I2P network, and the algorithms - have been tuned towards our needs. This also means that it hasn't been tuned - to address the needs we have yet to run into. As the network grows, the primary - floodfill algorithm will need to be refined to exploit the capacity available, - or perhaps replaced with another technique for securely distributing the network - metadata.
Transport protocols
Communication between routers needs to provide confidentiality and integrity against external adversaries while authenticating that the router contacted @@ -520,7 +501,8 @@ I2P's operation can be understood by putting those three concepts together:
Restricted route operation
I2P is an overlay network designed to be run on top of a functional packet switched network, exploiting the end to end principle to offer anonymity and - security. While the Internet no longer fully embraces the end to end principle, + security. While the Internet no longer fully embraces the end to end principle + (due to the usage of NAT), I2P does require a substantial portion of the network to be reachable - there may be a number of peers along the edges running using restricted routes, but I2P does not include an appropriate routing algorithm for the degenerate @@ -789,7 +771,7 @@ What other tunnel peer selection and ordering strategies should be available? needs for security and anonymity. Rather than building its own content distribution network, Syndie is designed to run on top of existing networks, syndicating content through eepsites, Tor hidden services, Freenet freesites, normal websites, - usenet newgroups, email lists, RSS feeds, etc. Data published with Syndie + usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie is done so as to offer pseudonymous authentication to anyone reading or archiving it.
diff --git a/www.i2p2/pages/todo.html b/www.i2p2/pages/todo.html index 27b3cda5..93a7d539 100644 --- a/www.i2p2/pages/todo.html +++ b/www.i2p2/pages/todo.html @@ -31,11 +31,7 @@Performance [link]
- +Performance [link]
Core functionality
- @@ -342,73 +338,8 @@
Performance
--
-
-
-
Persistent Tunnel / Lease Selection
- Outbound tunnel selection implemented in 0.6.1.30, inbound lease selection - implemented in release 0.6.2 -Selecting tunnels and leases at random for every message creates a large - incidence of out-of-order delivery, which prevents the streaming lib from - increasing its window size as much as it could. By persisting with the - same selections for a given connection, the transfer rate is much faster. -
-
- -
-
Reduction of Reply LeaseSet Bundling
- Implemented in release 0.6.2 -I2P bundled a reply leaseset (typically 1056 bytes) with every outbound - client message, which was a massive overhead. Fixed in 0.6.2.
-
- -
-
Migrate sessionTag to synchronized PRNG
-Right now, our ElGamal/AES+SessionTag - algorithm works by tagging each encrypted message with a unique random - 32 byte nonce (a "session tag"), identifying that message as being encrypted - with the associated AES session's key. This prevents peers from distinguishing - messages that are part of the same session, since each message has a completely - new random tag. To accomplish this, every few messages bundle a whole - new set of session tags within the encrypted message itself, transparently - delivering a way to identify future messages. We then have to keep track - of what messages are successfully delivered so that we know what tags - we may use.
-This works fine and is fairly robust, however it is inefficient in terms - of bandwidth usage, as it requires the delivery of these tags ahead of - time (and not all tags may be necessary, or some may be wasted, due to - their expiration). On average though, predelivering the session tag costs - 32 bytes per message (the size of a tag). As Taral suggested though, that - size can be avoided by replacing the delivery of the tags with a synchronized - PRNG - when a new session is established (through an ElGamal encrypted - block), both sides seed a PRNG for use and generate the session tags on - demand (with the recipient precalculating the next few possible values - to handle out of order delivery).
-
- -
-
Full streaming protocol improvements
- Several improvements implemented in I2P 0.6.1.28, and significant - additional fixes in 0.6.1.33, but still lots here to investigate -
-
-
-
Since I2P 0.4.2, - we have had a full sliding window streaming library, improving upon the - older fixed window size and resend delay implementation greatly. However, - there are still a few avenues for further optimization:
--
-
- some algorithms to share congestion and RTT information across streams - (per target destination? per source destination? for all of the local destinations?) -
- further optimizations for interactive streams (most of the focus in the - current implementation is on bulk streams) -
- more explicit use of the new streaming lib's features in I2PTunnel and - the SAM bridge, reducing the per-tunnel overhead. -
- client level bandwidth limiting (in either or both directions on a stream, - or possibly shared across multiple streams). This would be in addition to - the router's overall bandwidth limiting, of course. -
- various controls for destinations to throttle how many streams they accept - or create (we have some basic code, but largely disabled) -
- access control lists (only allowing streams to or from certain other known - destinations) -
- web controls and monitoring the health of the various streams, as well - as the ability to explicitly close or throttle them -
+ Performance related improvements are listed on the + Performance page. +
{% endblock %} diff --git a/www.i2p2/pages/transport.html b/www.i2p2/pages/transport.html index 10ba7c25..4dba232a 100644 --- a/www.i2p2/pages/transport.html +++ b/www.i2p2/pages/transport.html @@ -42,7 +42,6 @@ The transport subsystem in I2P provides the following services:+Analyze +Breaking and Improving Protocol Obfuscation +and see how transport-layer padding may improve things. +
+ {% endblock %} diff --git a/www.i2p2/pages/tunnel-alt-creation.html b/www.i2p2/pages/tunnel-alt-creation.html index 2e955f4b..ed9a8154 100644 --- a/www.i2p2/pages/tunnel-alt-creation.html +++ b/www.i2p2/pages/tunnel-alt-creation.html @@ -17,9 +17,13 @@ for an overview of the process, including peer selection and ordering methods. the path of peers in the tunnel, rewritten in place, and transmitted back to the tunnel creator. This single tunnel message is made up of a variable number of records (up to 8) - one for each potential peer in -the tunnel. Individual records are asymmetrically encrypted to be +the tunnel. Individual records are asymmetrically +(ElGamal) +encrypted to be read only by a specific peer along the path, while an additional -symmetric layer of encryption is added at each hop so as to expose +symmetric layer of encryption +(AES) +is added at each hop so as to expose the asymmetrically encrypted record only at the appropriate time.Number of Records
@@ -37,7 +41,7 @@ with the desired amount of tunnel length obfuscation. In the current network, most tunnels are 2 or 3 hops long. The current implementation uses a 5-record VTBM to build tunnels of 4 hops or less, and the 8-record TBM for longer tunnels. -The 5-record VTBM (which fits in 3 1KB tunnel messaages) reduces network traffic +The 5-record VTBM (which, when fragmented, fits in three 1KB tunnel messaages) reduces network traffic and increases build sucess rate, because smaller messages are less likely to be dropped.The reply message must be the same type and length as the build message. @@ -56,11 +60,11 @@ Also specified in the bytes 72-103: AES-256 tunnel layer key bytes 104-135: AES-256 tunnel IV key bytes 136-167: AES-256 reply key - bytes 168-183: reply IV + bytes 168-183: AES-256 reply IV byte 184: flags bytes 185-188: request time (in hours since the epoch) bytes 189-192: next message ID - bytes 193-222: uninterpreted / random padding + bytes 193-221: uninterpreted / random padding
The next tunnel ID and next router identity hash fields are used to specify the next hop in the tunnel, though for an outbound tunnel @@ -73,23 +77,44 @@ message ID that the message (or reply) should use.
Bit order: 76543210 (bit 7 is MSB) bit 7: if set, allow messages from anyone bit 6: if set, allow messages to anyone, and send the reply to the - specified next hop in a tunnel message + specified next hop in a Tunnel Build Reply Message bits 5-0: Undefined Bit 7 indicates that the hop will be an inbound gateway (IBGW). Bit 6 indicates that the hop will be an outbound endpoint (OBEP). +If neither bit is set, the hop will be an intermediate participant. -Request Encryption
+Request Record Creation
++Every hop gets a random Tunnel ID. +The current and next-hop Tunnel IDs are filled in. +Every record gets a random tunnel IV key, and reply IV. +The layer and reply key pairs are generated. +
+ + +Request Record Encryption
That cleartext record is ElGamal 2048 encrypted with the hop's public encryption key and formatted into a 528 byte record:
bytes 0-15: First 16 bytes of the SHA-256 of the current hop's router identity bytes 16-527: ElGamal-2048 encrypted request record+In the 512-byte encrypted record, +the ElGamal data contains bytes 1-256 and 258-513 of the +514-byte ElGamal encrypted block. +The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed. +
Since the cleartext uses the full field, there is no need for
additional padding beyond SHA256(cleartext) + cleartext.
+Each 528-byte record is then iteratively encrypted +(using AES decryption, with the reply key and reply IV for each hop) so that the router identity will only be in cleartext +for the hop in question. +
+Hop Processing and Encryption
When a hop receives a TunnelBuildMessage, it looks through the @@ -103,9 +128,17 @@ are dropped.
After deciding whether they will agree to participate in the tunnel or not, they replace the record that had contained the request with -an encrypted reply block. All other records are AES-256/CBC -encrypted with the included reply key and IV (though each is -encrypted separately, rather than chained across records).
+an encrypted reply block. All other records are AES-256 +encrypted with the included reply key and IV. Each is +encrypted separately, rather than chained across records. + ++Each hop knows only its own response. +If it agrees, it will maintain the tunnel until expiration, +even if it will not be used, +as it cannot know whether all other hops agreed. +
+Reply Record Specification
@@ -140,19 +173,23 @@ The padding is placed before the status byte: This is also described in the I2NP spec. -Request Preparation
+Tunnel Build Message Preparation
-When building a new request, all of the records must first be -built and asymmetrically encrypted. Each record should then be -decrypted with the reply keys and IVs of the hops earlier in the -path. That decryption should be run in reverse order so that the +
When building a new Tunnel Build Messaage, all of the Build Request Records must first be +built and asymmetrically encrypted using +ElGamal. +Each record is then +premptively decrypted with the reply keys and IVs of the hops earlier in the +path, using +AES. +That decryption should be run in reverse order so that the asymmetrically encrypted data will show up in the clear at the right hop after their predecessor encrypts it.
The excess records not needed for individual requests are simply filled with random data by the creator.
-Request Delivery
+Tunnel Build Message Delivery
For outbound tunnels, the delivery is done directly from the tunnel creator to the first hop, packaging up the TunnelBuildMessage as if @@ -163,7 +200,7 @@ If no outbound tunnel is available in that pool, an outbound exploratory tunnel At startup, when no outbound exploratory tunnel exists yet, a fake 0-hop outbound tunnel is used.
-Endpoint Handling
+Tunnel Build Message Endpoint Handling
For creation of an outbound tunnel, @@ -179,10 +216,12 @@ or (the type of message and number of records must match that of the request) and delivers it to the reply tunnel specified within the request record. That reply tunnel -forwards the reply records down to the tunnel creator for -processing, as below.
+forwards the Tunnel Build Reply Message back to the tunnel creator, +just as for any other message. +The tunnel creator then +processes it, as described below. -The reply tunnel was specified by the creator as follows: +
The reply tunnel was selected by the creator as follows: Generally it is an inbound tunnel from the same pool as the new outbound tunnel being built. If no inbound tunnel is available in that pool, an inbound exploratory tunnel is used. At startup, when no inbound exploratory tunnel exists yet, a fake 0-hop @@ -191,10 +230,10 @@ inbound tunnel is used.
For creation of an inbound tunnel, when the request reaches the inbound endpoint (also known as the -tunnel creator), there is no need to generate an explicit Reply Message, and +tunnel creator), there is no need to generate an explicit Tunnel Build Reply Message, and the router processes each of the replies, as below.
-Reply Processing by the Request Creator
+Tunnel Build Reply Message Processing
To process the reply records, the creator simply has to AES decrypt each record individually, using the reply key and IV of each hop in @@ -262,9 +301,12 @@ update
Future Work
- -It appears that, in the current implementation, the originator leaves one record empty -for itself, which is not necessary. Thus a message of n records can only build a -tunnel of n-1 hops. This is to be researched and verified. +In the current implementation, the originator leaves one record empty +for itself. Thus a message of n records can only build a +tunnel of n-1 hops. +This appears to be necessary for inbound tunnels (where the next-to-last hop +can see the hash prefix for the next hop), but not for outbound tunnels. +This is to be researched and verified. If it is possible to use the remaining record without compromising anonymity, we should do so.
- @@ -274,7 +316,11 @@ Therefore the request time field is unused. This should be researched and possibly changed.
- Further analysis of possible tagging and timing attacks described in the above notes. -
1) Tunnel overview
+Tunnel overview
Within I2P, messages are passed in one direction through a virtual tunnel of peers, using whatever means are available to pass the message on to the next hop. Messages arrive at the tunnel's -gateway, get bundled up and/or fragmented into fixed sizes tunnel messages, +gateway, get bundled up and/or fragmented into fixed-size tunnel messages, and are forwarded on to the next hop in the tunnel, which processes and verifies the validity of the message and sends it on to the next hop, and so on, until -it reaches the tunnel endpoint. That endpoint takes the messages +it reaches the tunnel endpoint. That endpoint takes the messages bundled up by the gateway and forwards them as instructed - either to another router, to another tunnel on another router, or locally.
@@ -27,8 +27,8 @@ out to the remote endpoint.The tunnel's creator selects exactly which peers will participate in the tunnel, and provides each with the necessary configuration -data. They may have any number of hops, but may be constrained with various -proof-of-work requests to add on additional steps. It is the intent to make +data. They may have any number of hops. +It is the intent to make it hard for either participants or third parties to determine the length of a tunnel, or even for colluding participants to determine whether they are a part of the same tunnel at all (barring the situation where colluding peers are @@ -48,31 +48,93 @@ the core I2P layer, there is an optional end to end streaming library available for client applications, exposing TCP-esque operation, including message reordering, retransmission, congestion control, etc.
-2) Tunnel operation
++An overview of I2P tunnel terminology is +on the tunnel overview page. +
-Tunnel operation has four distinct processes, taken on by various -peers in the tunnel. First, the tunnel gateway accumulates a number -of tunnel messages and preprocesses them into something for tunnel -delivery. Next, that gateway encrypts that preprocessed data, then -forwards it to the first hop. That peer, and subsequent tunnel +
Tunnel Operation (Message Processing)
+Overview
+ +After a tunnel is built, I2NP messages are processed and passed through it. +Tunnel operation has four distinct processes, taken on by various +peers in the tunnel.
- First, the tunnel gateway accumulates a number +of I2NP messages and preprocesses them into tunnel messages for +delivery.
- Next, that gateway encrypts that preprocessed data, then +forwards it to the first hop.
- That peer, and subsequent tunnel participants, unwrap a layer of the encryption, verifying that it isn't a duplicate, then forward it on to the next peer. -Eventually, the message arrives at the endpoint where the messages -bundled by the gateway are split out again and forwarded on as -requested. +
- Eventually, the tunnel messages arrive at the endpoint where the I2NP messages +originally bundled by the gateway are reassembled and forwarded on as +requested.
Tunnel IDs are 4 byte numbers used at each hop - participants know what -tunnel ID to listen for messages with and what tunnel ID they should be forwarded -on as to the next hop, and each hop chooses the tunnel ID which they receive messages -on. Tunnels themselves are short-lived (10 minutes). -Even if subsequent tunnels are built using the same sequence of -peers, each hop's tunnel ID will change.
++Intermediate tunnel participants do not know whether they are in an +inbound or an outbound tunnel; they always "encrypt" for the next hop. +Therefore, we take advantage of symmetric AES encryption +to "decrypt" at the outbound tunnel gateway, +so that the plaintext is revealed at the outbound endpoint. +
++
+2.1) Message preprocessing
+| Role | +Preprocessing | +Encryption Operation | +Postprocessing | +
|---|---|---|---|
| Outbound Gateway (Creator) | +Fragment, Batch, and Pad | +Iteratively encrypt (using decryption operations) | +Forward to next hop | +
| Participant | ++ | Decrypt (using an encryption operation) | +Forward to next hop | +
| Outbound Endpoint | ++ | Decrypt (using an encryption operation) to reveal plaintext tunnel message | +Reassemble Fragments, Forward as instructed to Inbound Gateway or Router | +
| Inbound Gateway | +Fragment, Batch, and Pad | +Encrypt | +Forward to next hop | +
| Participant | ++ | Encrypt | +Forward to next hop | +
| Inbound Endpoint (Creator) | ++ | Iteratively decrypt to reveal plaintext tunnel message | +Reassemble Fragments, Receive data | +
Gateway Processing
+Message Preprocessing
A tunnel gateway's function is to fragment and pack I2NP messages into fixed-size -tunnel messages +tunnel messages and encrypt the tunnel messages. Tunnel messages contain the following: @@ -81,17 +143,31 @@ Tunnel messages contain the following:
Tunnel IDs are 4 byte numbers used at each hop - participants know what +tunnel ID to listen for messages with and what tunnel ID they should be forwarded +on as to the next hop, and each hop chooses the tunnel ID which they receive messages +on. Tunnels themselves are short-lived (10 minutes). +Even if subsequent tunnels are built using the same sequence of +peers, each hop's tunnel ID will change.
+ +To prevent adversaries from tagging the messages along the path by adjusting +the message size, all tunnel messages are a fixed 1024 bytes in size. To accommodate +larger I2NP messages as well as to support smaller ones more efficiently, the +gateway splits up the larger I2NP messages into fragments contained within each +tunnel message. The endpoint will attempt to rebuild the I2NP message from the +fragments for a short period of time, but will discard them as necessary.
+Details are in the -tunnel message specification. +tunnel message specification. -
2.2) Gateway Processing
+Gateway Encryption
After the preprocessing of messages into a padded payload, the gateway builds a random 16 byte IV value, iteratively encrypting it and the tunnel message as @@ -106,7 +182,7 @@ data with the IV and layer keys for all hops in the tunnel. The result of the o tunnel encryption is that when each peer encrypts it, the endpoint will recover the initial preprocessed data.
-2.3) Participant Processing
+Participant Processing
When a peer receives a tunnel message, it checks that the message came from the same previous hop as before (initialized when the first message comes through @@ -129,7 +205,7 @@ false positive. The unique value fed into the Bloom filter is the XOR of the IV and the first block so as to prevent nonsequential colluding peers in the tunnel from tagging a message by resending it with the IV and first block switched.
-2.4) Endpoint Processing
+Endpoint Processing
After receiving and validating a tunnel message at the last hop in the tunnel, how the endpoint recovers the data encoded by the gateway depends upon whether @@ -143,23 +219,6 @@ layer and IV keys of each step in reverse order.
which it may then parse out into the included I2NP messages and forwards them as requested in their delivery instructions. -These padding strategies can be used on a variety of levels, addressing the -exposure of message size information to different adversaries. After gathering -and reviewing some statistics -from the 0.4 network, as well as exploring the anonymity tradeoffs, we're starting -with a fixed tunnel message size of 1024 bytes. Within this however, the fragmented -messages themselves are not padded by the tunnel at all (though for end to end -messages, they may be padded as part of the garlic wrapping).
- -2.6) Tunnel Fragmentation
- -To prevent adversaries from tagging the messages along the path by adjusting -the message size, all tunnel messages are a fixed 1024 bytes in size. To accommodate -larger I2NP messages as well as to support smaller ones more efficiently, the -gateway splits up the larger I2NP messages into fragments contained within each -tunnel message. The endpoint will attempt to rebuild the I2NP message from the -fragments for a short period of time, but will discard them as necessary.
-Tunnel Building
@@ -172,7 +231,7 @@ reply. There are three important dimensions to keep in mind when producing the tunnels: what peers are used (and where), how the requests are sent (and replies received), and how they are maintained. -3.1) Peer Selection
+Peer Selection
Beyond the two types of tunnels - inbound and outbound - there are two styles of peer selection used for different tunnels - exploratory and client. @@ -235,7 +294,7 @@ within a single pool but not between different pools. New keys are generated at each router restart. -
3.2) Request delivery
+Request delivery
A multi-hop tunnel is built using a single build message which is repeatedly @@ -267,7 +326,7 @@ the router in question. For more information on peer profiling, see the Peer Profiling and Selection page. -
3.3) Tunnel Pools
+Tunnel Pools
To allow efficient operation, the router maintains a series of tunnel pools, each managing a group of tunnels used for a specific purpose with their own @@ -286,9 +345,9 @@ lengths should be randomized, as well as any of the other settings allowed when configuring individual tunnels. Configuration options are specified on the I2CP page. -
Default Tunnel Lengths
+Tunnel Lengths and Defaults
-TODO +On the tunnel overview page.Anticipatory Build Strategy and Priority
@@ -322,4 +381,14 @@ automatically, how much should be configured as a per tunnel or per hop setting, and how should the tunnel's creator (and in turn, user) control this operation? All of this is left as unknown, to be worked out for a distant future release. + +Padding
+The padding strategies can be used on a variety of levels, addressing the +exposure of message size information to different adversaries. +The current fixed tunnel message size is 1024 bytes. Within this however, the fragmented +messages themselves are not padded by the tunnel at all, though for end to end +messages, they may be padded as part of the garlic wrapping.
+ + + {% endblock %} diff --git a/www.i2p2/pages/tunnel_message_spec.html b/www.i2p2/pages/tunnel_message_spec.html index 8dc65f8e..3c8d20c5 100644 --- a/www.i2p2/pages/tunnel_message_spec.html +++ b/www.i2p2/pages/tunnel_message_spec.html @@ -276,7 +276,7 @@ Total length: 7 bytes {% endfilter %} -Delivery Instructions Javadoc
+Delivery Instructions Javadoc
Notes
I2NP Message Maximum Size
diff --git a/www.i2p2/pages/udp.html b/www.i2p2/pages/udp.html index c55dfe61..20788903 100644 --- a/www.i2p2/pages/udp.html +++ b/www.i2p2/pages/udp.html @@ -13,9 +13,6 @@ The other is NTCP. SSU is the newer of the two transports, introduced in I2P release 0.6. In a standard I2P installation, the router uses both NTCP and SSU for outbound connections. -A router -The selection of a transport for a connection. -SSU Services
diff --git a/www.i2p2/pages/updates.html b/www.i2p2/pages/updates.html index 39b91e4c..0c7ced5e 100644 --- a/www.i2p2/pages/updates.html +++ b/www.i2p2/pages/updates.html @@ -46,7 +46,7 @@ The header contains:The signature covers only the zip archive - not the prepended version. diff --git a/www.i2p2/static/images/I2PTunnel-streamr.png b/www.i2p2/static/images/I2PTunnel-streamr.png new file mode 100644 index 00000000..cfd973e8 Binary files /dev/null and b/www.i2p2/static/images/I2PTunnel-streamr.png differ diff --git a/www.i2p2/static/images/cz.png b/www.i2p2/static/images/cz.png new file mode 100644 index 00000000..c8403dd2 Binary files /dev/null and b/www.i2p2/static/images/cz.png differ diff --git a/www.i2p2/static/images/garliccloves.png b/www.i2p2/static/images/garliccloves.png new file mode 100644 index 00000000..2a00a9d1 Binary files /dev/null and b/www.i2p2/static/images/garliccloves.png differ diff --git a/www.i2p2/static/images/i2ptunnel_peertopeer.png b/www.i2p2/static/images/i2ptunnel_peertopeer.png new file mode 100644 index 00000000..8dd19f99 Binary files /dev/null and b/www.i2p2/static/images/i2ptunnel_peertopeer.png differ diff --git a/www.i2p2/static/images/i2ptunnel_serverclient.png b/www.i2p2/static/images/i2ptunnel_serverclient.png new file mode 100644 index 00000000..282a656f Binary files /dev/null and b/www.i2p2/static/images/i2ptunnel_serverclient.png differ diff --git a/www.i2p2/static/images/netdb_get_leaseset.png b/www.i2p2/static/images/netdb_get_leaseset.png new file mode 100644 index 00000000..3667e9a7 Binary files /dev/null and b/www.i2p2/static/images/netdb_get_leaseset.png differ diff --git a/www.i2p2/static/images/netdb_get_routerinfo_1.png b/www.i2p2/static/images/netdb_get_routerinfo_1.png new file mode 100644 index 00000000..c60a6d79 Binary files /dev/null and b/www.i2p2/static/images/netdb_get_routerinfo_1.png differ diff --git a/www.i2p2/static/images/netdb_get_routerinfo_2.png b/www.i2p2/static/images/netdb_get_routerinfo_2.png new file mode 100644 index 00000000..22a03cc0 Binary files /dev/null and b/www.i2p2/static/images/netdb_get_routerinfo_2.png differ diff --git a/www.i2p2/static/images/protocol_stack.png b/www.i2p2/static/images/protocol_stack.png new file mode 100644 index 00000000..147f330c Binary files /dev/null and b/www.i2p2/static/images/protocol_stack.png differ