I2P Client Protocol (I2CP)

Überblick

Dies ist die Spezifikation des I2P Control Protocol (I2CP), der Low-Level-Schnittstelle zwischen Clients und dem router. Java-Clients werden die I2CP-Client-API verwenden, die dieses Protokoll implementiert.

Es gibt keine bekannten Implementierungen einer clientseitigen Bibliothek außerhalb von Java, die I2CP implementiert. Zusätzlich benötigen socket-orientierte (streaming) Anwendungen eine Implementierung des Streaming-Protokolls, aber es gibt auch dafür keine Bibliotheken außerhalb von Java. Daher sollten Nicht-Java-Clients stattdessen das höhere Protokoll SAM SAMv3 verwenden, für das Bibliotheken in mehreren Sprachen existieren.

Dies ist ein Low-Level-Protokoll, das sowohl intern als auch extern vom Java I2P router unterstützt wird. Das Protokoll wird nur serialisiert, wenn sich Client und router nicht in derselben JVM befinden; andernfalls werden I2CP-Nachrichten-Java-Objekte über eine interne JVM-Schnittstelle übertragen. I2CP wird auch extern vom C++ router i2pd unterstützt.

Weitere Informationen finden Sie auf der I2CP-Übersichtsseite I2CP .

Sitzungen

Das Protokoll wurde entwickelt, um mehrere “Sessions” mit jeweils einer 2-Byte Session-ID über eine einzelne TCP-Verbindung zu verwalten. Allerdings wurden mehrere Sessions erst ab Version 0.9.21 implementiert. Siehe den Multisession-Abschnitt unten . Versuchen Sie nicht, mehrere Sessions auf einer einzelnen I2CP-Verbindung mit Routern zu verwenden, die älter als Version 0.9.21 sind.

Es scheint auch, dass es einige Vorkehrungen dafür gibt, dass ein einzelner Client über separate Verbindungen mit mehreren Routern kommunizieren kann. Dies ist ebenfalls ungetestet und wahrscheinlich nicht nützlich.

Es gibt keine Möglichkeit, eine Session nach einer Trennung aufrechtzuerhalten oder sie über eine andere I2CP-Verbindung wiederherzustellen. Wenn der Socket geschlossen wird, wird die Session zerstört.

Beispiel-Nachrichtensequenzen

Hinweis: Die folgenden Beispiele zeigen nicht das Protokoll-Byte (0x2a), das vom Client an den router gesendet werden muss, wenn zum ersten Mal eine Verbindung hergestellt wird. Weitere Informationen zur Verbindungsinitialisierung finden Sie auf der I2CP-Übersichtsseite I2CP .

Standard-Sitzungsaufbau

  Client                                           Router

                           --------------------->  Get Date Message
        Set Date Message  <---------------------
                           --------------------->  Create Session Message
  Session Status Message  <---------------------
Request LeaseSet Message  <---------------------
                           --------------------->  Create LeaseSet Message

Bandbreitenlimits abrufen (Einfache Sitzung)

  Client                                           Router

                           --------------------->  Get Bandwidth Limits Message
Bandwidth Limits Message  <---------------------

Ziel-Lookup (Einfache Sitzung)

  Client                                           Router

                           --------------------->  Dest Lookup Message
      Dest Reply Message  <---------------------

Ausgehende Nachricht

Bestehende Sitzung, mit i2cp.messageReliability=none

  Client                                           Router

                           --------------------->  Send Message Message

Bestehende Sitzung, mit i2cp.messageReliability=none und von Null verschiedener Nonce

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (succeeded)

Bestehende Sitzung, mit i2cp.messageReliability=BestEffort

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (accepted)
  Message Status Message  <---------------------
  (succeeded)

Eingehende Nachricht

Bestehende Sitzung, mit i2cp.fastReceive=true (ab 0.9.4)

  Client                                           Router

 Message Payload Message  <---------------------

Bestehende Sitzung, mit i2cp.fastReceive=false (VERALTET)

  Client                                           Router

  Message Status Message  <---------------------
  (available)
                           --------------------->  Receive Message Begin Message
 Message Payload Message  <---------------------
                           --------------------->  Receive Message End Message

Multisession-Hinweise

Mehrere Sessions auf einer einzelnen I2CP-Verbindung werden ab router Version 0.9.21 unterstützt. Die erste Session, die erstellt wird, ist die “primäre Session”. Zusätzliche Sessions sind “Subsessions”. Subsessions werden verwendet, um mehrere Ziele zu unterstützen, die sich einen gemeinsamen Satz von tunnels teilen. Die ursprüngliche Anwendung ist, dass die primäre Session ECDSA-Signaturschlüssel verwendet, während die Subsession DSA-Signaturschlüssel für die Kommunikation mit alten eepsites nutzt.

Subsessions teilen sich die gleichen eingehenden und ausgehenden tunnel-Pools wie die primäre Session. Subsessions müssen die gleichen Verschlüsselungsschlüssel wie die primäre Session verwenden. Dies gilt sowohl für die leaseSet-Verschlüsselungsschlüssel als auch für die (nicht verwendeten) Destination-Verschlüsselungsschlüssel. Subsessions müssen unterschiedliche Signierschlüssel im Destination verwenden, sodass sich der Destination-Hash von der primären Session unterscheidet. Da Subsessions die gleichen Verschlüsselungsschlüssel und tunnel wie die primäre Session verwenden, ist für alle ersichtlich, dass die Destinations auf demselben router laufen, weshalb die üblichen Anti-Korrelations-Anonymitätsgarantien nicht gelten.

Subsessions werden durch das Senden einer CreateSession-Nachricht und den Empfang einer SessionStatus-Nachricht als Antwort erstellt, wie üblich. Subsessions müssen nach der Erstellung der primären Session erstellt werden. Die SessionStatus-Antwort wird bei Erfolg eine eindeutige Session-ID enthalten, die sich von der ID der primären Session unterscheidet. Obwohl CreateSession-Nachrichten in der richtigen Reihenfolge verarbeitet werden sollten, gibt es keine sichere Möglichkeit, eine CreateSession-Nachricht mit der Antwort zu korrelieren, daher sollte ein Client nicht mehrere CreateSession-Nachrichten gleichzeitig ausstehend haben. SessionConfig-Optionen für die Subsession werden möglicherweise nicht berücksichtigt, wenn sie sich von der primären Session unterscheiden. Insbesondere können tunnel-Optionen ignoriert werden, da Subsessions denselben tunnel-Pool wie die primäre Session verwenden.

Der router wird separate RequestVariableLeaseSet-Nachrichten für jedes Destination an den Client senden, und der Client muss mit einer CreateLeaseSet-Nachricht für jedes antworten. Die leases für die beiden Destinations werden nicht unbedingt identisch sein, obwohl sie aus demselben tunnel pool ausgewählt werden.

Eine Untersitzung kann wie üblich mit der DestroySession-Nachricht zerstört werden. Dies zerstört nicht die primäre Sitzung und stoppt nicht die I2CP-Verbindung. Das Zerstören der primären Sitzung wird jedoch alle Untersitzungen zerstören und die I2CP-Verbindung stoppen. Eine Disconnect-Nachricht zerstört alle Sitzungen.

Beachte, dass die meisten, aber nicht alle, I2CP-Nachrichten eine Session ID enthalten. Für diejenigen, die keine enthalten, benötigen Clients möglicherweise zusätzliche Logik, um Router-Antworten ordnungsgemäß zu verarbeiten. DestLookup und DestReply enthalten keine Session IDs; verwende stattdessen die neueren HostLookup und HostReply. GetBandwidthLimts und BandwidthLimits enthalten keine Session IDs, jedoch ist die Antwort nicht session-spezifisch.

Versionshinweise

Das anfängliche Protokollversionsbyte (0x2a), das vom Client gesendet wird, wird voraussichtlich nicht geändert. Vor der Version 0.8.7 waren die Versionsinformationen des routers für den Client nicht verfügbar, was verhinderte, dass neue Clients mit alten routern funktionieren. Ab Version 0.8.7 werden die Protokollversionszeichenketten beider Parteien in den Get/Set Date Messages ausgetauscht. In Zukunft können Clients diese Informationen nutzen, um korrekt mit alten routern zu kommunizieren. Clients und router sollten keine Nachrichten senden, die von der anderen Seite nicht unterstützt werden, da sie die Sitzung beim Empfang einer nicht unterstützten Nachricht normalerweise trennen.

Die ausgetauschten Versionsinformationen sind die “Kern”-API-Version oder I2CP-Protokollversion und entsprechen nicht zwangsläufig der Router-Version.

Eine grundlegende Zusammenfassung der I2CP-Protokollversionen ist wie folgt. Für Details siehe unten.

I2CP Nachrichtenkopf

Beschreibung

Gemeinsamer Header für alle I2CP-Nachrichten, der die Nachrichtenlänge und den Nachrichtentyp enthält.

Inhaltsverzeichnis

1. 4 Byte Integer , der die Länge des Nachrichtenkörpers angibt
2. 1 Byte Integer , der den Nachrichtentyp angibt.
3. Der I2CP Nachrichtenkörper, 0 oder mehr Bytes

Notizen

Die tatsächliche Nachrichtenlängenbegrenzung liegt bei etwa 64 KB.

Message ID

Beschreibung

Identifiziert eindeutig eine Nachricht, die zu einem bestimmten Zeitpunkt auf einem bestimmten router wartet. Diese wird immer vom router generiert und ist NICHT dieselbe wie die vom Client generierte Nonce.

Inhaltsverzeichnis

1. 4 Byte Integer

Hinweise

Nachrichten-IDs sind nur innerhalb einer Sitzung eindeutig; sie sind nicht global eindeutig.

Payload

Beschreibung

Diese Struktur ist der Inhalt einer Nachricht, die von einer Destination zu einer anderen übermittelt wird.

Inhalt

1. 4 Byte Integer Länge
2. So viele Bytes

Notizen

Die Nutzdaten sind im gzip-Format wie auf der I2CP-Übersichtsseite I2CP-FORMAT spezifiziert.

Die tatsächliche Nachrichtenlängenbegrenzung liegt bei etwa 64 KB.

Session-Konfiguration

Beschreibung

Definiert die Konfigurationsoptionen für eine bestimmte Client-Sitzung.

Inhalt

1. Destination
2. Mapping der Optionen
3. Erstellungs-Date
4. Signature der vorherigen 3 Felder, signiert durch den SigningPrivateKey

Notizen

• Die Optionen sind auf der I2CP-Übersichtsseite I2CP-OPTIONS angegeben.
• Das Mapping muss nach Schlüssel sortiert sein, damit die Signatur im router korrekt validiert wird.
• Das Erstellungsdatum muss innerhalb von +/- 30 Sekunden der aktuellen Zeit liegen, wenn es vom router verarbeitet wird, andernfalls wird die Konfiguration abgelehnt.

Offline-Signaturen

• Wenn die Destination offline signiert ist, muss das Mapping die drei Optionen i2cp.leaseSetOfflineExpiration, i2cp.leaseSetTransientPublicKey und i2cp.leaseSetOfflineSignature enthalten. Die Signature wird dann vom temporären SigningPrivateKey generiert und mit dem SigningPublicKey verifiziert, der in i2cp.leaseSetTransientPublicKey angegeben ist. Siehe I2CP-OPTIONS für Details.

Session ID

Beschreibung

Identifiziert eindeutig eine Sitzung auf einem bestimmten Router zu einem bestimmten Zeitpunkt.

Inhalt

1. 2 Byte Integer

Hinweise

Session ID 0xffff wird verwendet, um “keine Session” anzuzeigen, beispielsweise für Hostname-Lookups.

Nachrichten

Siehe auch die I2CP Javadocs .

Nachrichtentypen

Beschreibung

Teile dem Client die Bandbreitenbeschränkungen mit.

Vom Router an den Client als Antwort auf eine GetBandwidthLimitsMessage gesendet.

Inhalt

1. 4 Byte Integer Client eingehend Limit (KBps)
2. 4 Byte Integer Client ausgehend Limit (KBps)
3. 4 Byte Integer Router eingehend Limit (KBps)
4. 4 Byte Integer Router eingehend Burst-Limit (KBps)
5. 4 Byte Integer Router ausgehend Limit (KBps)
6. 4 Byte Integer Router ausgehend Burst- Limit (KBps)
7. 4 Byte Integer Router Burst-Zeit (Sekunden)
8. Neun 4-Byte Integer (undefiniert)

Hinweise

Die Client-Limits können die einzigen gesetzten Werte sein und können die tatsächlichen router-Limits, oder ein Prozentsatz der router-Limits, oder spezifisch für den jeweiligen Client sein, implementierungsabhängig. Alle Werte, die als router-Limits bezeichnet sind, können 0 sein, implementierungsabhängig. Ab Release 0.7.2.

BlindingInfoMessage

Beschreibung

Teilt dem router mit, dass eine Destination geblendet ist, mit optionalem Lookup-Passwort und optionalem privaten Schlüssel für die Entschlüsselung. Siehe Vorschläge 123 und 149 für Details.

Der router muss wissen, ob ein Ziel geblendet ist. Wenn es geblendet ist und eine geheime oder pro-Client-Authentifizierung verwendet, muss er diese Informationen ebenfalls haben.

Ein Host Lookup einer neuen b32-Adresse im Format (“b33”) teilt dem Router mit, dass die Adresse geblendet ist, aber es gibt keinen Mechanismus, um das Geheimnis oder den privaten Schlüssel in der Host Lookup-Nachricht an den Router zu übermitteln. Obwohl wir die Host Lookup-Nachricht erweitern könnten, um diese Informationen hinzuzufügen, ist es sauberer, eine neue Nachricht zu definieren.

Diese Nachricht bietet dem Client eine programmgesteuerte Möglichkeit, es dem Router mitzuteilen. Andernfalls müsste der Benutzer jedes Ziel manuell konfigurieren.

Verwendung

Bevor ein Client eine Nachricht an ein geblindetes Ziel sendet, muss er entweder das “b33” in einer Host Lookup-Nachricht nachschlagen oder eine Blinding Info-Nachricht senden. Wenn das geblindete Ziel ein Geheimnis oder eine clientspezifische Authentifizierung erfordert, muss der Client eine Blinding Info-Nachricht senden.

Der router sendet keine Antwort auf diese Nachricht. Gesendet vom Client zum Router.

Inhalt

1. Session ID
2. 1 Byte Integer Flags

• Bit-Reihenfolge: 76543210 > - Bit 0: 0 für alle, 1 für pro-Client > - Bits 3-1: Authentifizierungsschema, falls Bit 0 auf 1 für > pro-Client gesetzt ist, andernfalls 000 > - 000: DH Client-Authentifizierung (oder keine pro-Client-Authentifizierung) > - 001: PSK Client-Authentifizierung > - Bit 4: 1 falls Geheimnis erforderlich, 0 falls kein Geheimnis erforderlich > - Bits 7-5: Unbenutzt, für zukünftige Kompatibilität auf 0 setzen

3. 1 Byte Integer Endpunkt-Typ

• Typ 0 ist ein Hash > - Typ 1 ist ein Hostname String > - Typ 2 ist eine Destination > - Typ 3 ist ein Sig Type und > SigningPublicKey

4. 2 Byte Integer Blinded Signature Type
5. 4 Byte Integer Ablaufzeit in Sekunden seit Epoche
6. Endpunkt: Daten wie spezifiziert, einer von

• Typ 0: 32 Byte Hash > > - Typ 1: Hostname String > > - Typ 2: binäre Destination > > > > - Typ 3: 2 Byte Integer Signaturtyp, gefolgt von > > - SigningPublicKey (Länge wie > durch Signaturtyp impliziert)

7. PrivateKey Entschlüsselungsschlüssel Nur vorhanden, wenn Flag-Bit 0 auf 1 gesetzt ist. Ein 32-Byte ECIES_X25519 privater Schlüssel, little-endian
8. String Lookup-Passwort Nur vorhanden, wenn Flag-Bit 4 auf 1 gesetzt ist.

Hinweise

• Ab Release 0.9.43.
• Der Hash-Endpunkt-Typ ist wahrscheinlich nicht nützlich, es sei denn, der router kann eine Rückwärtssuche im Adressbuch durchführen, um das Destination zu erhalten.
• Der Hostname-Endpunkt-Typ ist wahrscheinlich nicht nützlich, es sei denn, der router kann eine Suche im Adressbuch durchführen, um das Destination zu erhalten.

CreateLeaseSetMessage

VERALTET. Kann nicht für LeaseSet2, Offline-Schlüssel, Nicht-ElGamal-Verschlüsselungstypen, mehrere Verschlüsselungstypen oder verschlüsselte LeaseSets verwendet werden. Verwenden Sie CreateLeaseSet2Message mit allen Routern 0.9.39 oder höher.

Beschreibung

Diese Nachricht wird als Antwort auf eine RequestLeaseSetMessage oder RequestVariableLeaseSetMessage gesendet und enthält alle Lease -Strukturen, die in der I2NP Network Database veröffentlicht werden sollen.

Vom Client zum Router gesendet.

Inhaltsverzeichnis

1. Session ID
2. DSA SigningPrivateKey oder 20 Bytes ignoriert
3. PrivateKey
4. LeaseSet

Notizen

Der SigningPrivateKey entspricht dem SigningPublicKey aus dem LeaseSet nur dann, wenn der Signaturschlüsseltyp DSA ist. Dies dient der LeaseSet-Widerrufung, die nicht implementiert ist und wahrscheinlich niemals implementiert werden wird. Wenn der Signaturschlüsseltyp nicht DSA ist, enthält dieses Feld 20 Bytes zufälliger Daten. Die Länge dieses Feldes beträgt immer 20 Bytes, sie entspricht niemals der Länge eines privaten Signaturschlüssels, der nicht DSA ist.

Der PrivateKey entspricht dem PublicKey aus dem LeaseSet. Der PrivateKey ist erforderlich für die Entschlüsselung von garlic routed Nachrichten.

Widerruf ist nicht implementiert. Die Verbindung zu mehreren Routern ist in keiner Client-Bibliothek implementiert.

CreateLeaseSet2Message

Beschreibung

Diese Nachricht wird als Antwort auf eine RequestLeaseSetMessage oder RequestVariableLeaseSetMessage gesendet und enthält alle Lease -Strukturen, die in der I2NP Network Database veröffentlicht werden sollen.

Vom Client zum Router gesendet. Seit Version 0.9.39. Client-spezifische Authentifizierung für EncryptedLeaseSet wird seit 0.9.41 unterstützt. MetaLeaseSet wird noch nicht über I2CP unterstützt. Siehe Vorschlag 123 für weitere Informationen.

Inhaltsverzeichnis

1. Session ID
2. Ein Byte Typ des zu folgenden leaseSet.

• Typ 1 ist ein LeaseSet (veraltet) > - Typ 3 ist ein LeaseSet2 > - Typ 5 ist ein EncryptedLeaseSet > - Typ 7 ist ein MetaLeaseSet

3. LeaseSet oder LeaseSet2 oder EncryptedLeaseSet oder MetaLeaseSet
4. Ein Byte mit der Anzahl der folgenden privaten Schlüssel.
5. PrivateKey -Liste. Einer für jeden öffentlichen Schlüssel im leaseSet, in derselben Reihenfolge. (Nicht vorhanden für Meta LS2)

• Verschlüsselungstyp (2 Byte Integer ) > - Verschlüsselungsschlüssel-Länge (2 Byte Integer ) > - Verschlüsselung PrivateKey (Anzahl der > angegebenen Bytes)

Notizen

Die PrivateKeys entsprechen jedem der PublicKey aus dem LeaseSet. Die PrivateKeys sind notwendig für die Entschlüsselung von garlic-gerouteten Nachrichten.

Siehe Vorschlag 123 für weitere Informationen zu verschlüsselten LeaseSets.

Der Inhalt und das Format für MetaLeaseSet sind vorläufig und können sich ändern. Es ist kein Protokoll für die Verwaltung mehrerer router spezifiziert. Siehe Vorschlag 123 für weitere Informationen.

Der private Signaturschlüssel, der zuvor für den Widerruf definiert und nicht verwendet wurde, ist in LS2 nicht vorhanden.

Die vorläufige Version mit Nachrichtentyp 40 war in 0.9.38 enthalten, aber das Format wurde geändert. Typ 40 ist aufgegeben und wird nicht unterstützt. Typ 41 ist erst ab 0.9.39 gültig.

CreateSessionMessage

Beschreibung

Diese Nachricht wird von einem Client gesendet, um eine Session zu initiieren, wobei eine Session als die Verbindung einer einzelnen Destination zum Netzwerk definiert ist, über die alle Nachrichten für diese Destination zugestellt werden und über die alle Nachrichten gesendet werden, die diese Destination an jede andere Destination sendet.

Vom Client an Router gesendet. Der Router antwortet mit einer SessionStatusMessage .

Inhaltsverzeichnis

1. Session-Konfiguration

Notizen

• Dies ist die zweite Nachricht, die vom Client gesendet wird. Zuvor hat der Client eine GetDateMessage gesendet und eine SetDateMessage Antwort erhalten.
• Wenn das Datum in der Session Config zu weit (mehr als +/- 30 Sekunden) von der aktuellen Zeit des routers abweicht, wird die Session abgelehnt.
• Wenn bereits eine Session auf dem router für diese Destination existiert, wird die Session abgelehnt.
• Das Mapping in der Session Config muss nach Schlüssel sortiert sein, damit die Signatur im router korrekt validiert wird.

DestLookupMessage

Beschreibung

Gesendet vom Client zum Router. Der Router antwortet mit einer DestReplyMessage .

Inhaltsverzeichnis

1. SHA-256 Hash

Notizen

Ab Release 0.7.

Ab Release 0.8.3 werden mehrere ausstehende Lookups unterstützt, und Lookups werden sowohl in I2PSimpleSession als auch in Standard-Sessions unterstützt.

HostLookupMessage wird seit Version 0.9.11 bevorzugt.

DestReplyMessage

Beschreibung

Vom Router an den Client als Antwort auf eine DestLookupMessage gesendet.

Inhalte

1. Destination bei Erfolg, oder Hash bei Fehler

Notizen

Ab Version 0.7.

Ab Version 0.8.3 wird der angeforderte Hash zurückgegeben, wenn die Suche fehlgeschlagen ist, damit der Client mehrere ausstehende Suchen haben und die Antworten mit den Suchen korrelieren kann. Um eine Destination-Antwort mit einer Anfrage zu korrelieren, nehmen Sie den Hash der Destination. Vor Version 0.8.3 war die Antwort bei einem Fehlschlag leer.

DestroySessionMessage

Beschreibung

Diese Nachricht wird von einem Client gesendet, um eine Sitzung zu beenden.

Gesendet vom Client zum Router. Der Router sollte mit einer SessionStatusMessage (Destroyed) antworten. Siehe jedoch wichtige Hinweise unten.

Inhaltsverzeichnis

1. Session ID

Notizen

Der router sollte zu diesem Zeitpunkt alle mit der Sitzung verbundenen Ressourcen freigeben.

Bis zur API 0.9.66 weichen die Java I2P router- und Client-Bibliotheken erheblich von dieser Spezifikation ab. Der router sendet niemals eine SessionStatus(Destroyed)-Antwort. Wenn keine Sessions mehr vorhanden sind, sendet er eine DisconnectMessage . Wenn Subsessions vorhanden sind oder die primäre Session bestehen bleibt, antwortet er nicht.

Die Java-Client-Bibliothek reagiert auf eine SessionStatus-Nachricht, indem sie alle Sitzungen zerstört und die Verbindung wiederherstellt.

Das Zerstören einzelner Untersitzungen bei einer Verbindung mit mehreren Sitzungen ist möglicherweise nicht vollständig getestet oder funktioniert nicht bei verschiedenen Router- und Client-Implementierungen. Vorsicht ist geboten.

Implementierungen sollten eine Zerstörung einer primären Session als Zerstörung aller Subsessions behandeln, aber eine Zerstörung für eine einzelne Subsession erlauben und die Verbindung offen halten, aber Java I2P macht das derzeit nicht. Falls das Verhalten von Java I2P in zukünftigen Versionen geändert wird, wird es hier dokumentiert.

DisconnectMessage

Beschreibung

Teile der anderen Partei mit, dass es Probleme gibt und die aktuelle Verbindung kurz vor der Zerstörung steht. Dies beendet alle Sitzungen auf dieser Verbindung. Der Socket wird in Kürze geschlossen. Wird entweder vom Router zum Client oder vom Client zum Router gesendet.

Inhalt

1. Grund String

Notizen

Nur in Router-zu-Client-Richtung implementiert, zumindest in Java I2P.

GetBandwidthLimitsMessage

Beschreibung

Fordere an, dass der Router seine aktuellen Bandbreitenbegrenzungen mitteilt.

Vom Client an den Router gesendet. Der Router antwortet mit einer BandwidthLimitsMessage .

Inhaltsverzeichnis

Keine

Notizen

Stand Release 0.7.2.

Ab Release 0.8.3 wird dies sowohl in I2PSimpleSession als auch in Standard-Sessions unterstützt.

GetDateMessage

Beschreibung

Vom Client an den Router gesendet. Der Router antwortet mit einer SetDateMessage .

Inhaltsverzeichnis

1. I2CP API Version String
2. Authentifizierung Mapping (optional, seit Release 0.9.11)

Notizen

• Normalerweise die erste Nachricht, die vom Client nach dem Senden des Protokoll-Versions-Bytes gesendet wird.
• Der Versions-String ist ab Release 0.8.7 enthalten. Dies ist nur nützlich, wenn sich Client und router nicht in derselben JVM befinden. Wenn er nicht vorhanden ist, ist der Client Version 0.8.6 oder früher.
• Ab Release 0.9.11 kann das Authentifizierungs- Mapping enthalten sein, mit den Schlüsseln i2cp.username und i2cp.password. Das Mapping muss nicht sortiert sein, da diese Nachricht nicht signiert ist. Vor und einschließlich 0.9.10 ist die Authentifizierung im Session Config Mapping enthalten, und keine Authentifizierung wird für GetDateMessage , GetBandwidthLimitsMessage , oder DestLookupMessage durchgesetzt. Wenn aktiviert, ist die Authentifizierung über GetDateMessage vor allen anderen Nachrichten ab Release 0.9.16 erforderlich. Dies ist nur außerhalb des router- Kontexts nützlich. Dies ist eine inkompatible Änderung, wird aber nur Sessions außerhalb des router-Kontexts mit Authentifizierung betreffen, was selten sein sollte.

HostLookupMessage

Beschreibung

Gesendet vom Client an den Router. Der Router antwortet mit einer HostReplyMessage .

Dies ersetzt die DestLookupMessage und fügt eine Anfrage-ID, ein Timeout und Unterstützung für Hostnamen-Lookups hinzu. Da es auch Hash-Lookups unterstützt, kann es für alle Lookups verwendet werden, wenn der router es unterstützt. Für Hostnamen-Lookups fragt der router den Naming Service seines Kontexts ab. Dies ist nur nützlich, wenn sich der Client außerhalb des router-Kontexts befindet. Innerhalb des router-Kontexts sollte der Client den Naming Service selbst abfragen, was viel effizienter ist.

Inhaltsverzeichnis

1. Session ID
2. 4 Byte Integer Anfrage-ID
3. 4 Byte Integer Timeout (ms)
4. 1 Byte Integer Anfragetyp
5. SHA-256 Hash oder Hostname String oder Destination

Anfrage-Typen:

Notizen

• Ab Release 0.9.11. Verwenden Sie DestLookupMessage für ältere router.
• Die Session-ID und Anfrage-ID werden in der HostReplyMessage zurückgegeben. Verwenden Sie 0xFFFF für die Session-ID, wenn keine Session vorhanden ist.
• Timeout ist nützlich für Hash-Lookups. Empfohlenes Minimum 10.000 (10 Sek.). In Zukunft könnte es auch für Remote-Naming-Service- Lookups nützlich sein. Der Wert wird möglicherweise nicht für lokale Hostnamen-Lookups berücksichtigt, die schnell sein sollten.
• Base-32-Hostnamen-Lookup wird unterstützt, aber es ist bevorzugt, ihn zuerst in einen Hash zu konvertieren.

HostReplyMessage

Beschreibung

Vom Router zum Client als Antwort auf eine HostLookupMessage gesendet.

Inhalt

1. Session ID
2. 4 Byte Integer Anfrage-ID
3. 1 Byte Integer Ergebniscode

• 0: Erfolg > - 1: Fehler > - 2: Lookup-Passwort erforderlich (ab 0.9.43) > - 3: Privater Schlüssel erforderlich (ab 0.9.43) > - 4: Lookup-Passwort und privater Schlüssel erforderlich (ab 0.9.43) > - 5: leaseSet-Entschlüsselungsfehler (ab 0.9.43) > - 6: leaseSet-Lookup-Fehler (ab 0.9.66) > - 7: Lookup-Typ nicht unterstützt (ab 0.9.66)

4. Destination , nur vorhanden wenn der Ergebniscode null ist, außer kann auch für Nachschlagetypen 2-4 zurückgegeben werden. Siehe unten.
5. Mapping , nur vorhanden wenn der Ergebniscode null ist, nur für Nachschlagetypen 2-4 zurückgegeben. Ab 0.9.66. Siehe unten.

Antworten für Lookup-Typen 2-4

Proposal 167 definiert zusätzliche Lookup-Typen, die alle Optionen aus dem leaseSet zurückgeben, falls vorhanden. Für Lookup-Typen 2-4 muss der router das leaseSet abrufen, auch wenn der Lookup-Schlüssel im Adressbuch vorhanden ist.

Falls erfolgreich, enthält die HostReply die Options-Mapping aus dem leaseSet und schließt diese als Element 5 nach dem Ziel ein. Falls es keine Optionen im Mapping gibt, oder das leaseSet Version 1 war, wird es trotzdem als leeres Mapping eingeschlossen (zwei Bytes: 0 0). Alle Optionen aus dem leaseSet werden eingeschlossen, nicht nur Service-Record-Optionen. Zum Beispiel können Optionen für in der Zukunft definierte Parameter vorhanden sein. Das zurückgegebene Mapping kann sortiert sein oder auch nicht, implementierungsabhängig.

Bei einem leaseSet-Nachschlagefehler enthält die Antwort einen neuen Fehlercode 6 (leaseSet-Nachschlagefehler) und wird keine Zuordnung enthalten. Wenn Fehlercode 6 zurückgegeben wird, kann das Destination-Feld vorhanden sein oder nicht. Es wird vorhanden sein, wenn eine Hostname-Suche im Adressbuch erfolgreich war, oder wenn eine vorherige Suche erfolgreich war und das Ergebnis zwischengespeichert wurde, oder wenn die Destination in der Nachschlagenachricht vorhanden war (Nachschlagetyp 4).

Falls ein Lookup-Typ nicht unterstützt wird, enthält die Antwort einen neuen Fehlercode 7 (Lookup-Typ nicht unterstützt).

Notizen

• Ab Release 0.9.11. Siehe HostLookupMessage Hinweise.
• Die Session-ID und Request-ID sind die aus der HostLookupMessage .
• Der Result-Code ist 0 für Erfolg, 1-255 für Fehler. 1 zeigt einen generischen Fehler an. Ab 0.9.43 wurden die zusätzlichen Fehlercodes 2-5 definiert, um erweiterte Fehler für “b33”-Lookups zu unterstützen. Siehe Proposals 123 und 149 für zusätzliche Informationen. Ab 0.9.66 wurden die zusätzlichen Fehlercodes 6-7 definiert, um erweiterte Fehler für Typ 2-4 Lookups zu unterstützen. Siehe Proposal 167 für zusätzliche Informationen.

MessagePayloadMessage

Beschreibung

Liefere die Nutzlast einer Nachricht an den Client.

Vom Router an den Client gesendet. Falls i2cp.fastReceive=true, was nicht die Standardeinstellung ist, antwortet der Client mit einer ReceiveMessageEndMessage .

Inhaltsverzeichnis

1. Sitzungs-ID
2. Nachrichten-ID
3. Nutzdaten

Notizen

MessageStatusMessage

Beschreibung

Benachrichtigt den Client über den Zustellstatus einer eingehenden oder ausgehenden Nachricht. Wird vom Router an den Client gesendet. Wenn diese Nachricht anzeigt, dass eine eingehende Nachricht verfügbar ist, antwortet der Client mit einer ReceiveMessageBeginMessage . Für eine ausgehende Nachricht ist dies eine Antwort auf eine SendMessageMessage oder SendMessageExpiresMessage .

Inhaltsverzeichnis

1. Session ID
2. Message ID generiert vom router
3. 1 Byte Integer Status
4. 4 Byte Integer Größe
5. 4 Byte Integer Nonce zuvor generiert vom Client

Notizen

Bis Version 0.9.4 sind die bekannten Status-Werte 0 für Nachricht ist verfügbar, 1 für akzeptiert, 2 für best effort erfolgreich, 3 für best effort fehlgeschlagen, 4 für guaranteed erfolgreich, 5 für guaranteed fehlgeschlagen. Der size Integer gibt die Größe der verfügbaren Nachricht an und ist nur für status = 0 relevant. Obwohl guaranteed nicht implementiert ist (best effort ist der einzige Service), verwendet die aktuelle router-Implementierung die guaranteed Status-Codes, nicht die best effort Codes.

Ab Router-Version 0.9.5 sind zusätzliche Statuscodes definiert, diese sind jedoch nicht unbedingt implementiert. Siehe MessageStatusMessage Javadocs für Details. Für ausgehende Nachrichten zeigen die Codes 1, 2, 4 und 6 Erfolg an; alle anderen sind Fehlschläge. Zurückgegebene Fehlercodes können variieren und sind implementierungsspezifisch.

Alle Statuscodes:

ReceiveMessageBeginMessage

VERALTET. Nicht von i2pd unterstützt.

Beschreibung

Fordert den router auf, eine Nachricht zu übermitteln, über die er zuvor benachrichtigt wurde. Wird vom Client an den router gesendet. Der router antwortet mit einer MessagePayloadMessage .

Inhaltsverzeichnis

1. Sitzungs-ID
2. Nachrichten-ID

Hinweise

Die ReceiveMessageBeginMessage wird als Antwort auf eine MessageStatusMessage gesendet, die angibt, dass eine neue Nachricht zur Abholung bereitsteht. Wenn die in der ReceiveMessageBeginMessage angegebene Nachrichten-ID ungültig oder falsch ist, kann der router einfach nicht antworten oder eine DisconnectMessage zurücksenden.

Dies wird im “Fast Receive”-Modus nicht verwendet, der seit Version 0.9.4 standardmäßig aktiviert ist.

ReceiveMessageEndMessage

VERALTET. Wird von i2pd nicht unterstützt.

Beschreibung

Teile dem router mit, dass die Zustellung einer Nachricht erfolgreich abgeschlossen wurde und dass der router die Nachricht verwerfen kann.

Vom Client an den Router gesendet.

Inhaltsverzeichnis

1. Session ID
2. Nachrichten-ID

Hinweise

Die ReceiveMessageEndMessage wird gesendet, nachdem eine MessagePayloadMessage die Nutzlast einer Nachricht vollständig übertragen hat.

Dies wird im “schnellen Empfangsmodus” nicht verwendet, welcher seit Version 0.9.4 die Standardeinstellung ist.

ReconfigureSessionMessage

Beschreibung

Vom Client an den Router gesendet, um die Sitzungskonfiguration zu aktualisieren. Der Router antwortet mit einer SessionStatusMessage .

Inhalt

1. Sitzungs-ID
2. Sitzungskonfiguration

Notizen

• Ab Release 0.7.1.
• Wenn das Datum in der Session Config zu weit (mehr als +/- 30 Sekunden) von der aktuellen Zeit des routers abweicht, wird die Session abgelehnt.
• Das Mapping in der Session Config muss nach Schlüssel sortiert sein, damit die Signatur im router korrekt validiert wird.
• Einige Konfigurationsoptionen können nur in der CreateSessionMessage gesetzt werden, und Änderungen hier werden vom router nicht erkannt. Änderungen an tunnel-Optionen inbound.* und outbound.* werden immer erkannt.
• Im Allgemeinen sollte der router die aktualisierte Konfiguration mit der aktuellen Konfiguration zusammenführen, sodass die aktualisierte Konfiguration nur die neuen oder geänderten Optionen enthalten muss. Aufgrund der Zusammenführung können Optionen jedoch nicht auf diese Weise entfernt werden; sie müssen explizit auf den gewünschten Standardwert gesetzt werden.

ReportAbuseMessage

VERALTET, UNGENUTZT, NICHT UNTERSTÜTZT

Beschreibung

Teile der anderen Partei (client oder router) mit, dass sie unter Angriff steht, möglicherweise mit Verweis auf eine bestimmte MessageId. Wenn der router unter Angriff steht, kann der client entscheiden, zu einem anderen router zu migrieren, und wenn ein client unter Angriff steht, kann der router seine router neu aufbauen oder einige der Peers auf die Bannliste setzen, die ihm Nachrichten mit dem Angriff zugestellt haben.

Wird entweder vom router zum Client oder vom Client zum router gesendet.

Inhaltsverzeichnis

1. Session ID
2. 1 Byte Integer Missbrauchsschweregrad (0 ist minimal missbräuchlich, 255 ist extrem missbräuchlich)
3. Grund String
4. Message ID

Notizen

Nicht verwendet. Nicht vollständig implementiert. Sowohl der router als auch der Client können eine ReportAbuseMessage generieren, aber keiner von beiden hat einen Handler für die Nachricht, wenn sie empfangen wird.

RequestLeaseSetMessage

VERALTET. Wird von i2pd nicht unterstützt. Wird von Java I2P nicht an Clients der Version 0.9.7 oder höher gesendet (2013-07). Verwenden Sie RequestVariableLeaseSetMessage.

Beschreibung

Anfrage, dass ein Client die Einbeziehung eines bestimmten Satzes von eingehenden tunnels autorisiert. Gesendet vom Router zum Client. Der Client antwortet mit einer CreateLeaseSetMessage .

Die erste dieser Nachrichten, die in einer Sitzung gesendet wird, ist ein Signal an den Client, dass tunnel erstellt und für den Verkehr bereit sind. Der router darf die erste dieser Nachrichten nicht senden, bis mindestens ein eingehender UND ein ausgehender tunnel erstellt wurde. Clients sollten die Sitzung mit einem Timeout beenden und zerstören, wenn die erste dieser Nachrichten nach einiger Zeit nicht empfangen wird (empfohlen: 5 Minuten oder mehr).

Inhalt

1. Session ID
2. 1 Byte Integer Anzahl der Tunnel
3. So viele Paare von:
   1. Hash
   2. TunnelId
4. End Date

Hinweise

Dies fordert ein LeaseSet an, bei dem alle Lease -Einträge so gesetzt sind, dass sie zur gleichen Zeit ablaufen. Für Client-Versionen 0.9.7 oder höher wird RequestVariableLeaseSetMessage verwendet.

RequestVariableLeaseSetMessage

Beschreibung

Anfrage, dass ein Client die Einbeziehung einer bestimmten Gruppe von eingehenden tunnels autorisiert.

Gesendet vom Router zum Client. Der Client antwortet mit einer CreateLeaseSetMessage oder CreateLeaseSet2Message .

Die erste dieser Nachrichten, die in einer Sitzung gesendet wird, ist ein Signal an den Client, dass tunnel erstellt und bereit für den Datenverkehr sind. Der router darf die erste dieser Nachrichten nicht senden, bis mindestens ein eingehender UND ein ausgehender tunnel erstellt wurden. Clients sollten eine Zeitüberschreitung einleiten und die Sitzung beenden, wenn die erste dieser Nachrichten nach einiger Zeit nicht empfangen wird (empfohlen: 5 Minuten oder mehr).

Inhalt

1. Session ID
2. 1 Byte Integer Anzahl der tunnel
3. Entsprechend viele Lease Einträge

Notizen

Dies fordert ein LeaseSet mit einer individuellen Ablaufzeit für jede Lease an.

Ab Release 0.9.7. Für Clients vor diesem Release verwenden Sie RequestLeaseSetMessage .

SendMessageMessage

Beschreibung

So sendet ein Client eine Nachricht (die Nutzdaten) an die Destination . Der Router verwendet eine Standard-Ablaufzeit.

Vom Client zum Router gesendet. Der Router antwortet mit einer MessageStatusMessage .

Inhaltsverzeichnis

1. Session ID
2. Destination
3. Payload
4. 4 Byte Integer Nonce

Hinweise

Sobald die SendMessageMessage vollständig unversehrt ankommt, sollte der router eine MessageStatusMessage zurücksenden, die besagt, dass sie zur Zustellung angenommen wurde. Diese Nachricht wird dieselbe hier gesendete Nonce enthalten. Später, basierend auf den Zustellungsgarantien der Sitzungskonfiguration, kann der router zusätzlich eine weitere MessageStatusMessage zurücksenden, die den Status aktualisiert.

Seit Version 0.8.1 sendet der router keine MessageStatusMessage wenn i2cp.messageReliability=none.

Vor Release 0.9.4 war ein nonce-Wert von 0 nicht erlaubt. Ab Release 0.9.4 ist ein nonce-Wert von 0 erlaubt und teilt dem router mit, dass er keine MessageStatusMessage senden soll, d.h. es verhält sich so, als ob i2cp.messageReliability=none nur für diese Nachricht gilt.

Vor der Veröffentlichung 0.9.14 konnte eine Session mit i2cp.messageReliability=none nicht auf Nachrichten-Basis überschrieben werden. Ab der Veröffentlichung 0.9.14 kann der Client in einer Session mit i2cp.messageReliability=none die Zustellung einer MessageStatusMessage mit dem Zustellungserfolg oder -fehler anfordern, indem die Nonce auf einen Wert ungleich Null gesetzt wird. Der Router wird die “accepted” MessageStatusMessage nicht senden, aber später eine MessageStatusMessage mit derselben Nonce und einem Erfolgs- oder Fehlschlagwert an den Client senden.

SendMessageExpiresMessage

Beschreibung

Vom Client an den Router gesendet. Wie SendMessageMessage , jedoch mit Ablaufzeit und Optionen.

Inhalt

1. Session ID
2. Destination
3. Payload
4. 4 Byte Integer Nonce
5. 2 Bytes Flags (Optionen)
6. Ablauf-Date von 8 Bytes auf 6 Bytes gekürzt

Notizen

Ab Release 0.7.1.

Im “best effort”-Modus sollte der router, sobald die SendMessageExpiresMessage vollständig intakt ankommt, eine MessageStatusMessage zurücksenden, die besagt, dass sie zur Zustellung angenommen wurde. Diese Nachricht wird dieselbe hier gesendete Nonce enthalten. Später kann der router basierend auf den Zustellungsgarantien der Sitzungskonfiguration zusätzlich eine weitere MessageStatusMessage zurücksenden, die den Status aktualisiert.

Seit Release 0.8.1 sendet der router keine Message Status Message, wenn i2cp.messageReliability=none ist.

Vor Version 0.9.4 war ein nonce-Wert von 0 nicht erlaubt. Ab Version 0.9.4 ist ein nonce-Wert von 0 erlaubt und teilt dem router mit, dass er keine Message Status Message senden soll, d.h. es verhält sich so, als ob i2cp.messageReliability=none nur für diese Nachricht gesetzt wäre.

Vor Version 0.9.14 konnte eine Sitzung mit i2cp.messageReliability=none nicht auf Basis einzelner Nachrichten überschrieben werden. Ab Version 0.9.14 kann der Client in einer Sitzung mit i2cp.messageReliability=none die Zustellung einer Message Status Message mit dem Erfolg oder Fehlschlag der Zustellung anfordern, indem er die nonce auf einen Wert ungleich null setzt. Der router wird die “accepted” Message Status Message nicht senden, aber später dem Client eine Message Status Message mit derselben nonce und einem Erfolgs- oder Fehlschlagswert senden.

Flags-Feld

Ab Release 0.8.4 sind die oberen zwei Bytes des Date-Feldes neu definiert, um Flags zu enthalten. Die Flags müssen standardmäßig auf alle Nullen gesetzt sein, um Rückwärtskompatibilität zu gewährleisten. Das Date-Feld wird das Flags-Feld nicht beeinträchtigen bis zum Jahr 10889. Die Flags können von der Anwendung verwendet werden, um dem Router Hinweise zu geben, ob ein LeaseSet und/oder ElGamal/AES Session Tags mit der Nachricht übermittelt werden sollen. Die Einstellungen beeinflussen erheblich die Menge an Protokoll-Overhead und die Zuverlässigkeit der Nachrichtenübermittlung. Die einzelnen Flag-Bits sind wie folgt definiert, ab Release 0.9.2. Die Definitionen können sich ändern. Verwenden Sie die SendMessageOptions-Klasse, um die Flags zu konstruieren.

Bit-Reihenfolge: 15…0

Bits 15-11

Ungenutzt, muss null sein

Bits 10-9

Message Reliability Override (Nicht implementiert, wird entfernt).

: Wenn 1, kein leaseSet im garlic mit dieser Nachricht bündeln. Wenn

0, the router may bundle a lease set at its discretion.

Bits 7-4

Niedrige Tag-Schwelle. Wenn weniger als diese Anzahl von Tags verfügbar sind,

send more. This is advisory and does not force tags to be delivered. For ElGamal only. Ignored for ECIES-Ratchet.

: Anzahl der zu sendenden Tags, falls erforderlich. Dies ist ein Richtwert und ist nicht

force tags to be delivered. For ElGamal only. Ignored for
ECIES-Ratchet.

Beschreibung

Den Client über den Status seiner Sitzung informieren.

Vom Router an den Client gesendet, als Antwort auf eine CreateSessionMessage , ReconfigureSessionMessage oder DestroySessionMessage . In allen Fällen, einschließlich als Antwort auf eine CreateSessionMessage , sollte der Router sofort antworten (nicht warten, bis tunnel erstellt sind).

Inhalt

1. Session ID
2. 1 Byte Integer Status

Statuswerte sind oben definiert. Wenn der Status Created ist, ist die Session ID der Identifikator, der für den Rest der Sitzung verwendet werden soll.

SetDateMessage

Beschreibung

Das aktuelle Datum und die Uhrzeit. Wird vom Router an den Client als Teil des initialen Handshakes gesendet. Ab Release 0.9.20 kann es auch jederzeit nach dem Handshake gesendet werden, um den Client über eine Uhrzeitverschiebung zu informieren.

Inhalt

1. Datum
2. I2CP API-Version String

Hinweise

Dies ist im Allgemeinen die erste Nachricht, die vom router gesendet wird. Der Versionsstring ist ab Release 0.8.7 enthalten. Dies ist nur nützlich, wenn sich Client und router nicht in derselben JVM befinden. Wenn er nicht vorhanden ist, handelt es sich um router Version 0.8.6 oder früher.

Zusätzliche SetDate-Nachrichten werden nicht an Clients in derselben JVM gesendet.

Referenzen

• Date
• Destination
• EncryptedLeaseSet
• Hash
• I2CP Überblick
• I2CP Javadocs
• Integer
• Lease
• LeaseSet
• LeaseSet2
• Mapping
• MetaLeaseSet
• MessageStatusMessage Javadocs
• PrivateKey
• PublicKey
• RouterIdentity
• SAMv3
• Signature
• SigningPrivateKey
• SigningPublicKey
• String
• TunnelId