Übersicht
Das I2P-Client-Protokoll (I2CP) stellt eine klare Trennung der Zuständigkeiten zwischen dem Router und jedem Client her, der über das Netzwerk kommunizieren möchte. Es ermöglicht sichere und asynchrone Nachrichtenübermittlung, indem Nachrichten über einen einzelnen TCP-Socket gesendet und empfangen werden. Über I2CP teilt eine Client-Anwendung dem Router mit, wer sie ist (ihre „Zieladresse“), welche Kompromisse hinsichtlich Anonymität, Zuverlässigkeit und Latenz akzeptabel sind, und wohin Nachrichten gesendet werden sollen. Der Router nutzt I2CP wiederum, um dem Client mitzuteilen, wenn Nachrichten eingetroffen sind, und um die Genehmigung anzufordern, bestimmte Tunnel verwenden zu dürfen.
Das Protokoll selbst ist in Java implementiert, um das Client-SDK bereitzustellen. Dieses SDK wird im i2p.jar-Paket bereitgestellt, das die Client-Seite von I2CP implementiert. Clients sollten niemals auf das router.jar-Paket zugreifen müssen, das den Router selbst sowie die Router-Seite von I2CP enthält. Ein Nicht-Java-Client müsste außerdem die Streaming-Bibliothek für TCP-ähnliche Verbindungen implementieren.
Anwendungen können die Basis-I2CP-Protokolle sowie die Streaming - und Datagramm -Bibliotheken nutzen, indem sie das Simple Anonymous Messaging (SAM) -Protokoll verwenden, das es Clients erspart, sich mit kryptografischen Verfahren beschäftigen zu müssen. Außerdem können Clients über verschiedene Proxys auf das Netzwerk zugreifen – HTTP, CONNECT sowie SOCKS 4/4a/5. Alternativ können Java-Clients direkt auf die Bibliotheken in ministreaming.jar und streaming.jar zugreifen. Damit stehen sowohl Java- als auch Nicht-Java-Anwendungen mehrere Möglichkeiten zur Verfügung.
Die Ende-zu-Ende-Verschlüsselung auf Clientseite (Verschlüsselung der Daten über die I2CP-Verbindung) wurde in I2P-Version 0.6 deaktiviert, wodurch die im Router implementierte ElGamal/AES-Ende-zu-Ende-Verschlüsselung beibehalten wurde. Die einzige Kryptografie, die Client-Bibliotheken weiterhin implementieren müssen, ist die DSA-Verschlüsselung mit öffentlichen/privaten Schlüsseln für LeaseSets und Sitzungskonfigurationen sowie die Verwaltung dieser Schlüssel.
Bei einer Standard-I2P-Installation wird Port 7654 von externen Java-Clients verwendet, um über I2CP mit dem lokalen Router zu kommunizieren. Standardmäßig bindet der Router an die Adresse 127.0.0.1. Um an 0.0.0.0 zu binden, setzen Sie die erweiterte Konfigurationsoption i2cp.tcp.bindAllInterfaces=true und starten Sie den Router neu. Clients in derselben JVM wie der Router leiten Nachrichten direkt über eine interne JVM-Schnittstelle an den Router weiter.
Einige Router- und Client-Implementierungen können auch externe Verbindungen über SSL unterstützen, wie durch die Option i2cp.SSL=true konfiguriert. Obwohl SSL nicht standardmäßig aktiviert ist, wird es dringend empfohlen, wenn der Datenverkehr dem offenen Internet ausgesetzt sein könnte. Der Autorisierungs-Benutzername/Passwort (falls vorhanden), der Private Schlüssel
und der Signierungs-Private-Schlüssel
für das Ziel (Destination)
werden alle unverschlüsselt übertragen, sofern SSL nicht aktiviert ist. Einige Router- und Client-Implementierungen können außerdem externe Verbindungen über Domain-Sockets unterstützen.
I2CP-Protokollspezifikation
Siehe die I2CP-Spezifikationsseite für die vollständige Protokollspezifikation.
I2CP-Initialisierung
Wenn ein Client eine Verbindung zum Router herstellt, sendet er zunächst ein einzelnes Protokoll-Versionsbyte (0x2A). Danach sendet er eine GetDate-Nachricht und wartet auf die Antwort in Form einer SetDate-Nachricht . Anschließend sendet er eine CreateSession-Nachricht , die die Sitzungskonfiguration enthält. Danach wartet er auf eine RequestLeaseSet-Nachricht vom Router, die anzeigt, dass die eingehenden Tunnel erstellt wurden, und antwortet mit einer CreateLeaseSet-Nachricht, die das signierte LeaseSet enthält. Der Client kann nun Verbindungen zu anderen I2P-Zielen aufbauen oder von ihnen empfangen.
I2CP-Optionen
Routerseitige Optionen
Die folgenden Optionen werden traditionell über eine SessionConfig , die in einer CreateSession-Nachricht oder einer ReconfigureSession-Nachricht enthalten ist, an den Router übergeben.
| Router-side Options | |||||
|---|---|---|---|---|---|
| Option | As Of Release | Recommended Arguments | Allowable Range | Default | Description |
| clientMessageTimeout | 8*1000 - 120*1000 | 60*1000 | The timeout (ms) for all sent messages. Unused. See the protocol specification for per-message settings. | ||
| crypto.lowTagThreshold | 0.9.2 | 1-128 | 30 | Minimum number of ElGamal/AES Session Tags before we send more. Recommended: approximately tagsToSend * 2/3 | |
| crypto.ratchet.inboundTags | 0.9.47 | 1-? | 160 | Inbound tag window for ECIES-X25519-AEAD-Ratchet. Local inbound tagset size. See proposal 144. | |
| crypto.ratchet.outboundTags | 0.9.47 | 1-? | 160 | Outbound tag window for ECIES-X25519-AEAD-Ratchet. Advisory to send to the far-end in the options block. See proposal 144. | |
| crypto.tagsToSend | 0.9.2 | 1-128 | 40 | Number of ElGamal/AES Session Tags to send at a time. For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower. | |
| explicitPeers | null | Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only | |||
| i2cp.dontPublishLeaseSet | true, false | false | Should generally be set to true for clients and false for servers | ||
| i2cp.fastReceive | 0.9.4 | true, false | false | If true, the router just sends the MessagePayload instead of sending a MessageStatus and awaiting a ReceiveMessageBegin. | |
| i2cp.leaseSetAuthType | 0.9.41 | 0 | 0-2 | 0 | The type of authentication for encrypted LS2. 0 for no per-client authentication (the default); 1 for DH per-client authentication; 2 for PSK per-client authentication. See proposal 123. |
| i2cp.leaseSetEncType | 0.9.38 | 4,0 | 0-65535,... | 0 | The encryption type to be used, as of 0.9.38. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. As of 0.9.39, may be comma-separated values for multiple types. See PublicKey in common structures spec for values. See proposals 123, 144, and 145. |
| i2cp.leaseSetOfflineExpiration | 0.9.38 | The expiration of the offline signature, 4 bytes, seconds since the epoch. See proposal 123. | |||
| i2cp.leaseSetOfflineSignature | 0.9.38 | The base 64 of the offline signature. See proposal 123. | |||
| i2cp.leaseSetPrivKey | 0.9.41 | A base 64 X25519 private key for the router to use to decrypt the encrypted LS2 locally, only if per-client authentication is enabled. Optionally preceded by the key type and ':'. Only "ECIES_X25519:" is supported, which is the default. See proposal 123. Do not confuse with i2cp.leaseSetPrivateKey which is for the leaseset encryption keys. | |||
| i2cp.leaseSetSecret | 0.9.39 | "" | Base 64 encoded UTF-8 secret used to blind the leaseset address. See proposal 123. | ||
| i2cp.leaseSetTransientPublicKey | 0.9.38 | [type:]b64 The base 64 of the transient private key, prefixed by an optional sig type number or name, default DSA_SHA1. See proposal 123. | |||
| i2cp.leaseSetType | 0.9.38 | 1,3,5,7 | 1-255 | 1 | The type of leaseset to be sent in the CreateLeaseSet2 Message. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. See proposal 123. |
| i2cp.messageReliability | BestEffort, None | BestEffort | Guaranteed is disabled; None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4 | ||
| i2cp.password | 0.8.2 | string | For authorization, if required by the router. If the client is running in the same JVM as a router, this option is not required. Warning - username and password are sent in the clear to the router, unless using SSL (i2cp.SSL=true). Authorization is only recommended when using SSL. | ||
| i2cp.username | 0.8.2 | string | |||
| inbound.allowZeroHop | true, false | true | If incoming zero hop tunnel is allowed | ||
| outbound.allowZeroHop | true, false | true | If outgoing zero hop tunnel is allowed | ||
| inbound.backupQuantity | number from 0 to 3 | No limit | 0 | Number of redundant fail-over for tunnels in | |
| outbound.backupQuantity | number from 0 to 3 | No limit | 0 | Number of redundant fail-over for tunnels out | |
| inbound.IPRestriction | number from 0 to 4 | 0 to 4 | 2 | Number of IP bytes to match to determine if two routers should not be in the same tunnel. 0 to disable. | |
| outbound.IPRestriction | number from 0 to 4 | 0 to 4 | 2 | Number of IP bytes to match to determine if two routers should not be in the same tunnel. 0 to disable. | |
| inbound.length | number from 0 to 3 | 0 to 7 | 3 | Length of tunnels in | |
| outbound.length | number from 0 to 3 | 0 to 7 | 3 | Length of tunnels out | |
| inbound.lengthVariance | number from -1 to 2 | -7 to 7 | 0 | Random amount to add or subtract to the length of tunnels in. A positive number x means add a random amount from 0 to x inclusive. A negative number -x means add a random amount from -x to x inclusive. The router will limit the total length of the tunnel to 0 to 7 inclusive. The default variance was 1 prior to release 0.7.6. | |
| outbound.lengthVariance | number from -1 to 2 | -7 to 7 | 0 | Random amount to add or subtract to the length of tunnels out. A positive number x means add a random amount from 0 to x inclusive. A negative number -x means add a random amount from -x to x inclusive. The router will limit the total length of the tunnel to 0 to 7 inclusive. The default variance was 1 prior to release 0.7.6. | |
| inbound.nickname | string | Name of tunnel - generally used in routerconsole, which will use the first few characters of the Base64 hash of the destination by default. | |||
| outbound.nickname | string | Name of tunnel - generally ignored unless inbound.nickname is unset. | |||
| outbound.priority | 0.9.4 | number from -25 to 25 | -25 to 25 | 0 | Priority adjustment for outbound messages. Higher is higher priority. |
| inbound.quantity | number from 1 to 3 | 1 to 16 | 2 | Number of tunnels in. Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are incompatible with older releases. | |
| outbound.quantity | number from 1 to 3 | No limit | 2 | Number of tunnels out | |
| inbound.randomKey | 0.9.17 | Base 64 encoding of 32 random bytes | Used for consistent peer ordering across restarts. | ||
| outbound.randomKey | 0.9.17 | Base 64 encoding of 32 random bytes | |||
| inbound.* | Any other options prefixed with "inbound." are stored in the "unknown options" properties of the inbound tunnel pool's settings. | ||||
| outbound.* | Any other options prefixed with "outbound." are stored in the "unknown options" properties of the outbound tunnel pool's settings. | ||||
| shouldBundleReplyInfo | 0.9.2 | true, false | true | Set to false to disable ever bundling a reply LeaseSet. For clients that do not publish their LeaseSet, this option must be true for any reply to be possible. "true" is also recommended for multihomed servers with long connection times. Setting to “false” may save significant outbound bandwidth, especially if the client is configured with a large number of inbound tunnels (Leases). If replies are still required, this may shift the bandwidth burden to the far-end client and the floodfill. There are several cases where “false” may be appropriate:
| |
Hinweis: Ab Version 0.7.7 müssen Optionennamen und -werte die UTF-8-Kodierung verwenden. Dies ist vor allem für Spitznamen nützlich. Vor dieser Version wurden Optionen mit mehrbyte-Zeichen beschädigt. Da Optionen in einer Mapping kodiert sind, sind alle Optionennamen und -werte auf maximal 255 Bytes (nicht Zeichen) begrenzt.
Optionen auf Client-Seite
Die folgenden Optionen werden auf der Client-Seite interpretiert und werden berücksichtigt, wenn sie über den I2PClient.createSession()-Aufruf an die I2PSession übergeben werden. Die Streaming-Bibliothek sollte diese Optionen außerdem an I2CP weiterleiten. Andere Implementierungen können andere Standardwerte haben.
| Client-side Options | |||||
|---|---|---|---|---|---|
| Option | As Of Release | Recommended Arguments | Allowable Range | Default | Description |
| i2cp.closeIdleTime | 0.7.1 | 1800000 | 300000 minimum | (ms) Idle time required (default 30 minutes) | |
| i2cp.closeOnIdle | 0.7.1 | true, false | false | Close I2P session when idle | |
| i2cp.encryptLeaseSet | 0.7.1 | true, false | false | Encrypt the lease | |
| i2cp.fastReceive | 0.9.4 | true, false | true | If true, the router just sends the MessagePayload instead of sending a MessageStatus and awaiting a ReceiveMessageBegin. | |
| i2cp.gzip | 0.6.5 | true, false | true | Gzip outbound data | |
| i2cp.leaseSetAuthType | 0.9.41 | 0 | 0-2 | 0 | The type of authentication for encrypted LS2. 0 for no per-client authentication (the default); 1 for DH per-client authentication; 2 for PSK per-client authentication. See proposal 123. |
| i2cp.leaseSetBlindedType | 0.9.39 | 0-65535 | See prop. 123 | The sig type of the blinded key for encrypted LS2. Default depends on the destination sig type. See proposal 123. | |
| i2cp.leaseSetClient.dh.nnn | 0.9.41 | b64name:b64pubkey | The base 64 of the client name (ignored, UI use only), followed by a ':', followed by the base 64 of the public key to use for DH per-client auth. nnn starts with 0. See proposal 123. | ||
| i2cp.leaseSetClient.psk.nnn | 0.9.41 | b64name:b64privkey | The base 64 of the client name (ignored, UI use only), followed by a ':', followed by the base 64 of the private key to use for PSK per-client auth. nnn starts with 0. See proposal 123. | ||
| i2cp.leaseSetEncType | 0.9.38 | 0 | 0-65535,... | 0 | The encryption type to be used, as of 0.9.38. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. As of 0.9.39, may be comma-separated values for multiple types. See also i2cp.leaseSetPrivateKey. See PublicKey in common structures spec for values. See proposals 123, 144, and 145. |
| i2cp.leaseSetKey | 0.7.1 | For encrypted leasesets. Base 64 SessionKey (44 characters) | |||
| i2cp.leaseSetOption.nnn | 0.9.66 | srvKey=srvValue | A service record to be placed in the LeaseSet2 options. Example: "_smtp._tcp=1 86400 0 0 25 ...b32.i2p". nnn starts with 0. See proposal 167. | ||
| i2cp.leaseSetPrivateKey | 0.9.18 | Base 64 private keys for encryption. Optionally preceded by the encryption type name or number and ':'. For LS1, only one key is supported, and only "0:" or "ELGAMAL_2048:" is supported, which is the default. As of 0.9.39, for LS2, multiple keys may be comma-separated, and each key must be a different encryption type. I2CP will generate the public key from the private key. Use for persistent leaseset keys across restarts. See proposals 123, 144, and 145. See also i2cp.leaseSetEncType. Do not confuse with i2cp.leaseSetPrivKey which is for encrypted LS2. | |||
| i2cp.leaseSetSecret | 0.9.39 | "" | Base 64 encoded UTF-8 secret used to blind the leaseset address. See proposal 123. | ||
| i2cp.leaseSetSigningPrivateKey | 0.9.18 | Base 64 private key for signatures. Optionally preceded by the key type and ':'. DSA_SHA1 is the default. Key type must match the signature type in the destination. I2CP will generate the public key from the private key. Use for persistent leaseset keys across restarts. | |||
| i2cp.leaseSetType | 0.9.38 | 1,3,5,7 | 1-255 | 1 | The type of leaseset to be sent in the CreateLeaseSet2 Message. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. See proposal 123. |
| i2cp.messageReliability | BestEffort, None | None | Guaranteed is disabled; None implemented in 0.8.1; None is the default as of 0.9.4 | ||
| i2cp.reduceIdleTime | 0.7.1 | 1200000 | 300000 minimum | (ms) Idle time required (default 20 minutes, minimum 5 minutes) | |
| i2cp.reduceOnIdle | 0.7.1 | true, false | false | Reduce tunnel quantity when idle | |
| i2cp.reduceQuantity | 0.7.1 | 1 | 1 to 5 | 1 | Tunnel quantity when reduced (applies to both inbound and outbound) |
| i2cp.SSL | 0.8.3 | true, false | false | Connect to the router using SSL. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. | |
| i2cp.tcp.host | 127.0.0.1 | Router hostname. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. | |||
| i2cp.tcp.port | 1-65535 | 7654 | Router I2CP port. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. | ||
I2CP-Nutzdatenformat und Multiplexing
Die von I2CP verarbeiteten Ende-zu-Ende-Nachrichten (d. h. die Daten, die vom Client in einer SendMessageMessage gesendet und vom Client in einer MessagePayloadMessage empfangen werden), werden mit einem standardmäßigen 10-Byte-Gzip-Header komprimiert, der gemäß RFC 1952 mit 0x1F 0x8B 0x08 beginnt. Ab Version 0.7.1 nutzt I2P ungenutzte Teile des Gzip-Headers, um Protokoll-, From-Port- und To-Port-Informationen einzufügen, wodurch Streaming und Datagramme am selben Ziel unterstützt werden und Abfrage/Antwort mittels Datagrammen zuverlässig funktioniert, auch bei mehreren Kanälen.
Die gzip-Funktion kann nicht vollständig deaktiviert werden. Durch die Einstellung i2cp.gzip=false wird jedoch der gzip-Aufwand auf 0 gesetzt, was etwas CPU-Leistung sparen kann. Implementierungen können je nach Einschätzung der Komprimierbarkeit des Inhalts für jeden Socket oder jede Nachricht unterschiedliche gzip-Aufwände wählen. Aufgrund der in API 0.9.57 (Vorschlag 161) implementierten Komprimierbarkeit der Ziel-Padding-Daten wird empfohlen, die Streaming-SYN-Pakete in beide Richtungen sowie repliable Datagramme zu komprimieren, auch wenn die Nutzlast nicht komprimierbar ist. Implementierungen könnten eine triviale gzip/gunzip-Funktion für einen gzip-Aufwand von 0 schreiben, was in diesem Fall deutliche Effizienzvorteile gegenüber einer gzip-Bibliothek bietet.
| Bytes | Content |
|---|---|
| 0-2 | Gzip header 0x1F 0x8B 0x08 |
| 3 | Gzip flags |
| 4-5 | I2P Source port (Gzip mtime) |
| 6-7 | I2P Destination port (Gzip mtime) |
| 8 | Gzip xflags (set to 2 to be indistinguishable from the Java implementation) |
| 9 | I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS) |
Die Datenintegrität wird mit dem standardmäßigen gzip CRC-32 gemäß RFC 1952 überprüft.
Wichtige Unterschiede zum Standard-IP
I2CP-Ports sind für I2P-Sockets und -Datagramme vorgesehen. Sie haben keine Beziehung zu Ihren lokalen Sockets oder Ports. Da I2P vor der Version 0.7.1 keine Unterstützung für Ports und Protokollnummern bot, unterscheiden sich Ports und Protokollnummern in I2P etwas von denen im Standard-IP-Protokoll, aus Gründen der Abwärtskompatibilität:
- Port 0 ist gültig und hat eine besondere Bedeutung.
- Die Ports 1–1023 sind nicht besonders oder privilegiert.
- Server lauschen standardmäßig auf Port 0, was „alle Ports“ bedeutet.
- Clients senden standardmäßig an Port 0, was „beliebiger Port“ bedeutet.
- Clients senden standardmäßig von Port 0, was „nicht angegeben“ bedeutet.
- Server können einen Dienst auf Port 0 und andere Dienste auf höheren Ports lauschen haben. In diesem Fall ist der Dienst auf Port 0 der Standard und wird verwendet, wenn der eingehende Socket- oder Datagramm-Port mit keinem anderen Dienst übereinstimmt.
- Auf den meisten I2P-Zielen läuft nur ein einziger Dienst, daher können Sie die Standardwerte verwenden und die I2CP-Port-Konfiguration ignorieren.
- Protokoll 0 ist gültig und bedeutet „beliebiges Protokoll“. Dies wird jedoch nicht empfohlen und funktioniert wahrscheinlich nicht. Für Streaming muss die Protokollnummer auf 6 gesetzt sein.
- Streaming-Sockets werden über eine interne Verbindungs-ID verfolgt. Daher ist es nicht erforderlich, dass das 5-Tupel aus Ziel:Port:Ziel:Port:Protokoll eindeutig ist. Beispielsweise kann es mehrere Sockets mit denselben Ports zwischen zwei Zielen geben. Clients müssen keinen „freien Port“ für eine ausgehende Verbindung wählen.
Zukünftige Arbeiten
- Der aktuelle Autorisierungsmechanismus könnte so angepasst werden, dass gehashte Passwörter verwendet werden.
- Der Signatur-Privatschlüssel ist in der „Create Lease Set“-Nachricht enthalten, was nicht erforderlich ist. Die Sperrung ist nicht implementiert. Er sollte durch zufällige Daten ersetzt oder entfernt werden.
- Einige Verbesserungen könnten möglicherweise bereits definierte, aber bisher nicht implementierte Nachrichten nutzen.