Protocole Client I2P (I2CP)

Aperçu

Ceci est la spécification du protocole de contrôle I2P (I2CP), l’interface de bas niveau entre les clients et le router. Les clients Java utiliseront l’API client I2CP, qui implémente ce protocole.

Il n’existe aucune implémentation connue non-Java d’une bibliothèque côté client qui implémente I2CP. De plus, les applications orientées socket (streaming) auraient besoin d’une implémentation du protocole de streaming, mais il n’existe pas non plus de bibliothèques non-Java pour cela. Par conséquent, les clients non-Java devraient plutôt utiliser le protocole de niveau supérieur SAM SAMv3 , pour lequel des bibliothèques existent dans plusieurs langages.

Il s’agit d’un protocole de bas niveau pris en charge à la fois en interne et en externe par le router I2P Java. Le protocole n’est sérialisé que si le client et le router ne sont pas dans la même JVM ; sinon, les objets Java des messages I2CP sont transmis via une interface JVM interne. I2CP est également pris en charge en externe par le router C++ i2pd.

Plus d’informations sont disponibles sur la page de présentation I2CP I2CP .

Sessions

Le protocole a été conçu pour gérer plusieurs “sessions”, chacune avec un ID de session de 2 octets, sur une seule connexion TCP, cependant, les sessions multiples n’ont pas été implémentées jusqu’à la version 0.9.21. Voir la section multisession ci-dessous . N’essayez pas d’utiliser plusieurs sessions sur une seule connexion I2CP avec des routeurs antérieurs à la version 0.9.21.

Il semble également qu’il existe certaines dispositions pour qu’un seul client puisse communiquer avec plusieurs routeurs via des connexions séparées. Ceci n’a également pas été testé et n’est probablement pas utile.

Il n’existe aucun moyen de maintenir une session après une déconnexion, ou de la récupérer sur une connexion I2CP différente. Lorsque le socket est fermé, la session est détruite.

Exemples de séquences de messages

Note : Les exemples ci-dessous ne montrent pas l’octet de protocole (0x2a) qui doit être envoyé du client vers le router lors de la première connexion. Plus d’informations sur l’initialisation de connexion sont disponibles sur la page de présentation I2CP I2CP .

Établissement de Session Standard

  Client                                           Router

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

Obtenir les limites de bande passante (session simple)

  Client                                           Router

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

Recherche de Destination (Session Simple)

  Client                                           Router

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

Message sortant

Session existante, avec i2cp.messageReliability=none

  Client                                           Router

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

Session existante, avec i2cp.messageReliability=none et nonce non nul

  Client                                           Router

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

Session existante, avec i2cp.messageReliability=BestEffort

  Client                                           Router

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

Message entrant

Session existante, avec i2cp.fastReceive=true (depuis la version 0.9.4)

  Client                                           Router

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

Session existante, avec i2cp.fastReceive=false (OBSOLÈTE)

  Client                                           Router

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

Notes multi-sessions

Les sessions multiples sur une seule connexion I2CP sont prises en charge depuis la version 0.9.21 du router. La première session créée est la “session primaire”. Les sessions supplémentaires sont des “sous-sessions”. Les sous-sessions sont utilisées pour prendre en charge plusieurs destinations partageant un ensemble commun de tunnels. L’application initiale consiste à ce que la session primaire utilise des clés de signature ECDSA, tandis que la sous-session utilise des clés de signature DSA pour la communication avec les anciens eepsites.

Les sous-sessions partagent les mêmes pools de tunnels entrants et sortants que la session principale. Les sous-sessions doivent utiliser les mêmes clés de chiffrement que la session principale. Ceci s’applique à la fois aux clés de chiffrement du leaseSet et aux clés de chiffrement de destination (non utilisées). Les sous-sessions doivent utiliser des clés de signature différentes dans la destination, de sorte que le hash de destination soit différent de la session principale. Comme les sous-sessions utilisent les mêmes clés de chiffrement et tunnels que la session principale, il est évident pour tous que les destinations s’exécutent sur le même router, donc les garanties d’anonymat anti-corrélation habituelles ne s’appliquent pas.

Les sous-sessions sont créées en envoyant un message CreateSession et en recevant un message SessionStatus en réponse, comme d’habitude. Les sous-sessions doivent être créées après que la session principale ait été créée. La réponse SessionStatus contiendra, en cas de succès, un ID de session unique, distinct de l’ID de la session principale. Bien que les messages CreateSession doivent être traités dans l’ordre, il n’y a pas de moyen sûr de corréler un message CreateSession avec la réponse, donc un client ne devrait pas avoir plusieurs messages CreateSession en attente simultanément. Les options SessionConfig pour la sous-session peuvent ne pas être respectées lorsqu’elles diffèrent de la session principale. En particulier, puisque les sous-sessions utilisent le même pool de tunnel que la session principale, les options de tunnel peuvent être ignorées.

Le router enverra des messages RequestVariableLeaseSet séparés pour chaque Destination au client, et le client doit répondre avec un message CreateLeaseSet pour chacune. Les leases pour les deux Destinations ne seront pas nécessairement identiques, même si elles sont sélectionnées depuis le même pool de tunnels.

Une sous-session peut être détruite avec le message DestroySession comme d’habitude. Cela ne détruira pas la session principale ni n’arrêtera la connexion I2CP. Détruire la session principale détruira cependant toutes les sous-sessions et arrêtera la connexion I2CP. Un message Disconnect détruit toutes les sessions.

Notez que la plupart des messages I2CP, mais pas tous, contiennent un ID de session. Pour ceux qui n’en contiennent pas, les clients peuvent avoir besoin d’une logique supplémentaire pour traiter correctement les réponses du router. DestLookup et DestReply ne contiennent pas d’ID de session ; utilisez plutôt les plus récents HostLookup et HostReply. GetBandwidthLimts et BandwidthLimits ne contiennent pas d’ID de session, cependant la réponse n’est pas spécifique à une session.

Notes de version

L’octet de version de protocole initial (0x2a) envoyé par le client ne devrait pas changer. Avant la version 0.8.7, les informations de version du router n’étaient pas disponibles pour le client, empêchant ainsi les nouveaux clients de fonctionner avec les anciens routers. Depuis la version 0.8.7, les chaînes de version de protocole des deux parties sont échangées dans les messages Get/Set Date. À l’avenir, les clients peuvent utiliser ces informations pour communiquer correctement avec les anciens routers. Les clients et routers ne doivent pas envoyer de messages non supportés par l’autre partie, car ils déconnectent généralement la session lors de la réception d’un message non supporté.

Les informations de version échangées correspondent à la version de l’API “core” ou à la version du protocole I2CP, et ne correspondent pas nécessairement à la version du router.

Un résumé de base des versions du protocole I2CP est le suivant. Pour plus de détails, voir ci-dessous.

En-tête de message I2CP

Description

En-tête commun à tous les messages I2CP, contenant la longueur du message et le type de message.

Sommaire

1. Entier de 4 octets spécifiant la longueur du corps du message
2. Entier de 1 octet spécifiant le type de message.
3. Le corps du message I2CP, 0 octet ou plus

Notes

La limite de longueur de message réelle est d’environ 64 Ko.

ID de Message

Description

Identifie de manière unique un message en attente sur un router particulier à un moment donné. Ceci est toujours généré par le router et n’est PAS identique au nonce généré par le client.

Contenu

1. 4 octets Integer

Notes

Les identifiants de messages sont uniques uniquement au sein d’une session ; ils ne sont pas uniques globalement.

Charge utile

Description

Cette structure est le contenu d’un message livré d’une Destination à une autre.

Sommaire

1. 4 octets longueur Integer
2. Ce nombre d’octets

Notes

La charge utile est dans un format gzip comme spécifié sur la page de présentation I2CP I2CP-FORMAT .

La limite de longueur de message réelle est d’environ 64 Ko.

Configuration de Session

Description

Définit les options de configuration pour une session client particulière.

Sommaire

1. Destination
2. Mapping d’options
3. Date de création
4. Signature des 3 champs précédents, signée par la SigningPrivateKey

Notes

• Les options sont spécifiées sur la page de présentation I2CP I2CP-OPTIONS .
• Le Mapping doit être trié par clé afin que la signature soit validée correctement dans le router.
• La date de création doit être comprise dans un intervalle de +/- 30 secondes par rapport à l’heure actuelle lors du traitement par le router, sinon la configuration sera rejetée.

Signatures hors ligne

• Si la Destination est signée hors ligne, le Mapping doit contenir les trois options i2cp.leaseSetOfflineExpiration, i2cp.leaseSetTransientPublicKey, et i2cp.leaseSetOfflineSignature. La Signature est alors générée par la SigningPrivateKey transitoire et est vérifiée avec la SigningPublicKey spécifiée dans i2cp.leaseSetTransientPublicKey. Voir I2CP-OPTIONS pour les détails.

ID de Session

Description

Identifie de manière unique une session sur un router particulier à un moment donné.

Sommaire

1. 2 octets Integer

Notes

L’ID de session 0xffff est utilisé pour indiquer “aucune session”, par exemple pour les recherches de nom d’hôte.

Messages

Voir aussi la documentation Javadoc I2CP .

Types de messages

Description

Indiquer au client quelles sont les limites de bande passante.

Envoyé du router au client en réponse à un GetBandwidthLimitsMessage .

Sommaire

1. 4 octets Integer Limite entrante du client (Ko/s)
2. 4 octets Integer Limite sortante du client (Ko/s)
3. 4 octets Integer Limite entrante du router (Ko/s)
4. 4 octets Integer Limite de rafale entrante du router (Ko/s)
5. 4 octets Integer Limite sortante du router (Ko/s)
6. 4 octets Integer Limite de rafale sortante du router (Ko/s)
7. 4 octets Integer Temps de rafale du router (secondes)
8. Neuf Integer de 4 octets (non définis)

Notes

Les limites du client peuvent être les seules valeurs définies, et peuvent être les limites réelles du router, ou un pourcentage des limites du router, ou spécifiques au client particulier, selon l’implémentation. Toutes les valeurs étiquetées comme limites du router peuvent être 0, selon l’implémentation. Depuis la version 0.7.2.

BlindingInfoMessage

Description

Informe le router qu’une Destination est masquée, avec un mot de passe de recherche optionnel et une clé privée optionnelle pour le déchiffrement. Voir les propositions 123 et 149 pour plus de détails.

Le router doit savoir si une destination est masquée. Si elle est masquée et utilise une authentification secrète ou par client, il doit également disposer de ces informations.

Une recherche d’hôte d’une adresse b32 de nouveau format (“b33”) indique au router que l’adresse est aveuglée, mais il n’y a pas de mécanisme pour transmettre la clé secrète ou privée au router dans le message de recherche d’hôte. Bien que nous puissions étendre le message de recherche d’hôte pour ajouter cette information, il est plus propre de définir un nouveau message.

Ce message fournit un moyen programmatique pour le client d’informer le router. Sinon, l’utilisateur devrait configurer manuellement chaque destination.

Utilisation

Avant qu’un client envoie un message à une destination masquée, il doit soit rechercher le “b33” dans un message Host Lookup, soit envoyer un message Blinding Info. Si la destination masquée nécessite un secret ou une authentification par client, le client doit envoyer un message Blinding Info.

Le router n’envoie pas de réponse à ce message. Envoyé du Client vers le Router.

Sommaire

1. ID de session
2. 1 octet Integer Drapeaux

• Ordre des bits : 76543210 > - Bit 0 : 0 pour tout le monde, 1 pour par-client > - Bits 3-1 : Schéma d’authentification, si le bit 0 est défini à 1 pour > par-client, sinon 000 > - 000 : Authentification client DH (ou pas d’authentification par-client) > - 001 : Authentification client PSK > - Bit 4 : 1 si secret requis, 0 si aucun secret requis > - Bits 7-5 : Inutilisés, définis à 0 pour compatibilité future

3. 1 octet Integer Type de point de terminaison

• Le Type 0 est un Hash > - Le Type 1 est un nom d’hôte String > - Le Type 2 est une Destination > - Le Type 3 est un Sig Type et > SigningPublicKey

4. 2 octets Integer Type de Signature Aveugle
5. 4 octets Integer Secondes d’Expiration depuis l’époque
6. Point de terminaison : Données comme spécifié, un des

• Type 0 : Hash de 32 octets > > - Type 1 : nom d’hôte String > > - Type 2 : Destination binaire > > > > - Type 3 : type de signature Integer de 2 octets, suivi par > > - SigningPublicKey (longueur telle > qu’impliquée par le type de signature)

7. PrivateKey Clé de déchiffrement Présente uniquement si le bit de drapeau 0 est défini à 1. Une clé privée ECIES_X25519 de 32 octets, little-endian
8. String Mot de passe de recherche Présent uniquement si le bit de drapeau 4 est défini à 1.

Notes

• Depuis la version 0.9.43.
• Le type de point de terminaison Hash n’est probablement pas utile à moins que le router puisse effectuer une recherche inversée dans le carnet d’adresses pour obtenir la Destination.
• Le type de point de terminaison hostname n’est probablement pas utile à moins que le router puisse effectuer une recherche dans le carnet d’adresses pour obtenir la Destination.

CreateLeaseSetMessage

DÉPRÉCIÉ. Ne peut pas être utilisé pour LeaseSet2, les clés hors ligne, les types de chiffrement non-ElGamal, les types de chiffrement multiples, ou les LeaseSets chiffrés. Utilisez CreateLeaseSet2Message avec tous les routeurs 0.9.39 ou supérieurs.

Description

Ce message est envoyé en réponse à un RequestLeaseSetMessage ou RequestVariableLeaseSetMessage et contient toutes les structures Lease qui doivent être publiées dans la base de données réseau I2NP.

Envoyé du Client vers le Router.

Sommaire

1. ID de session
2. DSA SigningPrivateKey ou 20 octets ignorés
3. PrivateKey
4. LeaseSet

Notes

La SigningPrivateKey correspond à la SigningPublicKey du leaseSet, uniquement si le type de clé de signature est DSA. Ceci est destiné à la révocation de leaseSet, qui n’est pas implémentée et ne le sera probablement jamais. Si le type de clé de signature n’est pas DSA, ce champ contient 20 octets de données aléatoires. La longueur de ce champ est toujours de 20 octets, elle n’est jamais égale à la longueur d’une clé privée de signature non-DSA.

La PrivateKey correspond à la PublicKey du LeaseSet. La PrivateKey est nécessaire pour déchiffrer les messages routés par garlic encryption.

La révocation n’est pas implémentée. La connexion à plusieurs routers n’est implémentée dans aucune bibliothèque client.

CreateLeaseSet2Message

Description

Ce message est envoyé en réponse à un RequestLeaseSetMessage ou RequestVariableLeaseSetMessage et contient toutes les structures Lease qui devraient être publiées dans la base de données réseau I2NP.

Envoyé du Client vers le Router. Depuis la version 0.9.39. L’authentification par client pour EncryptedLeaseSet est prise en charge depuis la version 0.9.41. MetaLeaseSet n’est pas encore pris en charge via I2CP. Voir la proposition 123 pour plus d’informations.

Sommaire

1. ID de session
2. Un octet de type de leaseSet qui suit.

• Le Type 1 est un LeaseSet (déprécié) > - Le Type 3 est un LeaseSet2 > - Le Type 5 est un EncryptedLeaseSet > - Le Type 7 est un MetaLeaseSet

3. LeaseSet ou LeaseSet2 ou EncryptedLeaseSet ou MetaLeaseSet
4. Un octet représentant le nombre de clés privées qui suivent.
5. Liste de PrivateKey . Une pour chaque clé publique dans le lease set, dans le même ordre. (Absent pour Meta LS2)

• Type de chiffrement (2 octets Integer ) > - Longueur de la clé de chiffrement (2 octets Integer ) > - PrivateKey de chiffrement (nombre d’octets > spécifiés)

Notes

Les PrivateKeys correspondent à chacune des PublicKey du LeaseSet. Les PrivateKeys sont nécessaires pour déchiffrer les messages routés par garlic encryption.

Voir la proposition 123 pour plus d’informations sur les leaseSets chiffrés.

Le contenu et le format du MetaLeaseSet sont préliminaires et sujets à modification. Aucun protocole n’est spécifié pour l’administration de plusieurs routers. Voir la proposition 123 pour plus d’informations.

La clé privée de signature, précédemment définie pour la révocation et inutilisée, n’est pas présente dans LS2.

La version préliminaire avec le type de message 40 était dans la 0.9.38 mais le format a été modifié. Le type 40 est abandonné et n’est pas pris en charge. Le type 41 n’est pas valide avant la 0.9.39.

CreateSessionMessage

Description

Ce message est envoyé depuis un client pour initier une session, où une session est définie comme la connexion d’une seule Destination au réseau, vers laquelle tous les messages pour cette Destination seront livrés et depuis laquelle tous les messages que cette Destination envoie vers toute autre Destination seront transmis.

Envoyé du Client vers le Router. Le router répond avec un SessionStatusMessage .

Sommaire

1. Configuration de Session

Notes

• Il s’agit du deuxième message envoyé par le client. Précédemment, le client a envoyé un GetDateMessage et a reçu une réponse SetDateMessage .
• Si la Date dans la Session Config est trop éloignée (plus de +/- 30 secondes) de l’heure actuelle du router, la session sera rejetée.
• S’il existe déjà une session sur le router pour cette Destination, la session sera rejetée.
• Le Mapping dans la Session Config doit être trié par clé pour que la signature soit validée correctement dans le router.

DestLookupMessage

Description

Envoyé du Client au Router. Le router répond avec un DestReplyMessage .

Sommaire

1. SHA-256 Hash

Notes

À partir de la version 0.7.

À partir de la version 0.8.3, plusieurs recherches en cours sont prises en charge, et les recherches sont supportées à la fois dans I2PSimpleSession et dans les sessions standard.

HostLookupMessage est préféré depuis la version 0.9.11.

DestReplyMessage

Description

Envoyé du Router vers le Client en réponse à un DestLookupMessage .

Sommaire

1. Destination en cas de succès, ou Hash en cas d’échec

Notes

À partir de la version 0.7.

À partir de la version 0.8.3, le Hash demandé est retourné si la recherche échoue, afin que le client puisse avoir plusieurs recherches en cours et corréler les réponses aux recherches. Pour corréler une réponse Destination avec une requête, prenez le Hash de la Destination. Avant la version 0.8.3, la réponse était vide en cas d’échec.

DestroySessionMessage

Description

Ce message est envoyé par un client pour détruire une session.

Envoyé du Client vers le Router. Le router devrait répondre avec un SessionStatusMessage (Destroyed). Cependant, voir les notes importantes ci-dessous.

Sommaire

1. ID de session

Notes

Le router à ce stade doit libérer toutes les ressources liées à la session.

Jusqu’à l’API 0.9.66, le router I2P Java et les bibliothèques client s’écartent substantiellement de cette spécification. Le router n’envoie jamais de réponse SessionStatus(Destroyed). S’il ne reste aucune session, il envoie un DisconnectMessage . S’il y a des sous-sessions ou si la session primaire reste, il ne répond pas.

La bibliothèque client Java répond à un message SessionStatus en détruisant toutes les sessions et en se reconnectant.

La destruction de sous-sessions individuelles sur une connexion avec plusieurs sessions pourrait ne pas être entièrement testée ou fonctionnelle sur diverses implémentations de router et de client. Soyez prudent.

Les implémentations devraient traiter une destruction pour une session primaire comme une destruction pour toutes les sous-sessions, mais permettre une destruction pour une seule sous-session et garder la connexion ouverte, mais Java I2P ne fait pas cela actuellement. Si le comportement de Java I2P est modifié dans les versions ultérieures, cela sera documenté ici.

DisconnectMessage

Description

Informe l’autre partie qu’il y a des problèmes et que la connexion actuelle est sur le point d’être détruite. Ceci met fin à toutes les sessions sur cette connexion. Le socket sera fermé sous peu. Envoyé soit du router vers le client, soit du client vers le router.

Sommaire

1. Raison String

Notes

Seulement implémenté dans la direction router-vers-client, au moins dans Java I2P.

GetBandwidthLimitsMessage

Description

Demander au router d’indiquer quelles sont ses limites de bande passante actuelles.

Envoyé du Client au Router. Le router répond avec un BandwidthLimitsMessage .

Sommaire

Aucune

Notes

À partir de la version 0.7.2.

À partir de la version 0.8.3, pris en charge à la fois dans I2PSimpleSession et dans les sessions standard.

GetDateMessage

Description

Envoyé du Client vers le Router. Le router répond avec un SetDateMessage .

Sommaire

1. Version de l’API I2CP String
2. Authentification Mapping (optionnel, depuis la version 0.9.11)

Notes

• Généralement le premier message envoyé par le client après avoir envoyé l’octet de version du protocole.
• La chaîne de version est incluse à partir de la version 0.8.7. Ceci n’est utile que si le client et le router ne sont pas dans la même JVM. Si elle n’est pas présente, le client est en version 0.8.6 ou antérieure.
• À partir de la version 0.9.11, l’authentification Mapping peut être incluse, avec les clés i2cp.username et i2cp.password. Le Mapping n’a pas besoin d’être trié car ce message n’est pas signé. Avant et jusqu’à la version 0.9.10, l’authentification est incluse dans le Session Config Mapping, et aucune authentification n’est imposée pour GetDateMessage , GetBandwidthLimitsMessage , ou DestLookupMessage . Quand elle est activée, l’authentification via GetDateMessage est requise avant tout autre message à partir de la version 0.9.16. Ceci n’est utile qu’en dehors du contexte router. Il s’agit d’un changement incompatible, mais qui n’affectera que les sessions en dehors du contexte router avec authentification, ce qui devrait être rare.

HostLookupMessage

Description

Envoyé du Client vers le Router. Le router répond avec un HostReplyMessage .

Ceci remplace le DestLookupMessage et ajoute un ID de requête, un délai d’expiration, et la prise en charge de la recherche de nom d’hôte. Comme il prend également en charge les recherches de Hash, il peut être utilisé pour toutes les recherches si le router le prend en charge. Pour les recherches de nom d’hôte, le router interrogera le service de nommage de son contexte. Ceci n’est utile que si le client est en dehors du contexte du router. À l’intérieur du contexte router, le client devrait interroger lui-même le service de nommage, ce qui est beaucoup plus efficace.

Sommaire

1. Session ID
2. 4 octets Integer ID de requête
3. 4 octets Integer timeout (ms)
4. 1 octet Integer type de requête
5. SHA-256 Hash ou nom d’hôte String ou Destination

Types de requête :

Notes

• À partir de la version 0.9.11. Utilisez DestLookupMessage pour les routeurs plus anciens.
• L’ID de session et l’ID de requête seront retournés dans le HostReplyMessage . Utilisez 0xFFFF pour l’ID de session s’il n’y a pas de session.
• Le délai d’expiration est utile pour les recherches de Hash. Minimum recommandé 10 000 (10 sec.). À l’avenir, il pourra également être utile pour les recherches de service de nommage distant. La valeur peut ne pas être respectée pour les recherches de nom d’hôte locales, qui devraient être rapides.
• La recherche de nom d’hôte en base 32 est prise en charge mais il est préférable de le convertir en Hash d’abord.

HostReplyMessage

Description

Envoyé du Router au Client en réponse à un HostLookupMessage .

Sommaire

1. Session ID
2. Integer d’ID de requête sur 4 octets
3. Integer de code de résultat sur 1 octet

• 0: Succès > - 1: Échec > - 2: Mot de passe de recherche requis (depuis 0.9.43) > - 3: Clé privée requise (depuis 0.9.43) > - 4: Mot de passe de recherche et clé privée requis (depuis 0.9.43) > - 5: Échec de déchiffrement du leaseSet (depuis 0.9.43) > - 6: Échec de recherche du leaseSet (depuis 0.9.66) > - 7: Type de recherche non pris en charge (depuis 0.9.66)

4. Destination , présente uniquement si le code de résultat est zéro, sauf qu’elle peut également être retournée pour les types de recherche 2-4. Voir ci-dessous.
5. Mapping , présente uniquement si le code de résultat est zéro, retournée uniquement pour les types de recherche 2-4. À partir de 0.9.66. Voir ci-dessous.

Réponses pour les types de recherche 2-4

La proposition 167 définit des types de recherche supplémentaires qui retournent toutes les options du leaseSet, si présentes. Pour les types de recherche 2-4, le router doit récupérer le leaseSet, même si la clé de recherche est dans le carnet d’adresses.

En cas de succès, le HostReply contiendra les options Mapping du leaseSet, et les inclura comme élément 5 après la destination. S’il n’y a pas d’options dans le Mapping, ou si le leaseSet était de version 1, il sera tout de même inclus comme un Mapping vide (deux octets : 0 0). Toutes les options du leaseSet seront incluses, pas seulement les options d’enregistrement de service. Par exemple, des options pour des paramètres définis dans le futur peuvent être présentes. Le Mapping retourné peut être trié ou non, selon l’implémentation.

En cas d’échec de recherche de leaseSet, la réponse contiendra un nouveau code d’erreur 6 (Échec de recherche de leaseSet) et n’inclura pas de mappage. Lorsque le code d’erreur 6 est retourné, le champ Destination peut être présent ou non. Il sera présent si une recherche de nom d’hôte dans le carnet d’adresses a réussi, ou si une recherche précédente a réussi et que le résultat a été mis en cache, ou si la Destination était présente dans le message de recherche (type de recherche 4).

Si un type de recherche n’est pas pris en charge, la réponse contiendra un nouveau code d’erreur 7 (type de recherche non pris en charge).

Notes

• Depuis la version 0.9.11. Voir les notes de HostLookupMessage .
• L’ID de session et l’ID de requête sont ceux du HostLookupMessage .
• Le code de résultat est 0 pour le succès, 1-255 pour l’échec. 1 indique un échec générique. Depuis la version 0.9.43, les codes d’échec supplémentaires 2-5 ont été définis pour prendre en charge les erreurs étendues pour les recherches “b33”. Voir les propositions 123 et 149 pour des informations supplémentaires. Depuis la version 0.9.66, les codes d’échec supplémentaires 6-7 ont été définis pour prendre en charge les erreurs étendues pour les recherches de type 2-4. Voir la proposition 167 pour des informations supplémentaires.

MessagePayloadMessage

Description

Livrer la charge utile d’un message au client.

Envoyé du router vers le client. Si i2cp.fastReceive=true, ce qui n’est pas la valeur par défaut, le client répond avec un ReceiveMessageEndMessage .

Sommaire

1. ID de session
2. ID de message
3. Charge utile

Notes

MessageStatusMessage

Description

Notifie le client du statut de livraison d’un message entrant ou sortant. Envoyé du Router vers le Client. Si ce message indique qu’un message entrant est disponible, le client répond avec un ReceiveMessageBeginMessage . Pour un message sortant, il s’agit d’une réponse à un SendMessageMessage ou SendMessageExpiresMessage .

Sommaire

1. Session ID
2. Message ID généré par le router
3. 1 octet Integer statut
4. 4 octets Integer taille
5. 4 octets Integer nonce précédemment généré par le client

Notes

Jusqu’à la version 0.9.4, les valeurs de statut connues sont 0 pour message disponible, 1 pour accepté, 2 pour meilleur effort réussi, 3 pour meilleur effort échoué, 4 pour garanti réussi, 5 pour garanti échoué. L’Integer de taille spécifie la taille du message disponible et n’est pertinent que pour statut = 0. Bien que le mode garanti ne soit pas implémenté (le meilleur effort est le seul service), l’implémentation actuelle du router utilise les codes de statut garantis, pas les codes de meilleur effort.

À partir de la version 0.9.5 du router, des codes de statut supplémentaires sont définis, cependant ils ne sont pas nécessairement implémentés. Consultez la documentation Javadocs de MessageStatusMessage pour plus de détails. Pour les messages sortants, les codes 1, 2, 4 et 6 indiquent un succès ; tous les autres sont des échecs. Les codes d’échec retournés peuvent varier et sont spécifiques à l’implémentation.

Tous les codes de statut :

ReceiveMessageBeginMessage

OBSOLÈTE. Non pris en charge par i2pd.

Description

Demander au router de livrer un message dont il a été préalablement notifié. Envoyé du Client vers le Router. Le router répond avec un MessagePayloadMessage .

Sommaire

1. ID de session
2. ID de message

Notes

Le ReceiveMessageBeginMessage est envoyé en réponse à un MessageStatusMessage indiquant qu’un nouveau message est disponible pour récupération. Si l’identifiant de message spécifié dans le ReceiveMessageBeginMessage est invalide ou incorrect, le router peut simplement ne pas répondre, ou il peut renvoyer un DisconnectMessage .

Ceci n’est pas utilisé en mode “réception rapide”, qui est le mode par défaut depuis la version 0.9.4.

ReceiveMessageEndMessage

OBSOLÈTE. Non pris en charge par i2pd.

Description

Indiquer au router que la livraison d’un message s’est terminée avec succès et que le router peut supprimer le message.

Envoyé du Client vers le Router.

Sommaire

1. ID de session
2. ID de message

Notes

Le ReceiveMessageEndMessage est envoyé après qu’un MessagePayloadMessage ait entièrement livré la charge utile d’un message.

Ceci n’est pas utilisé en mode “réception rapide”, qui est le mode par défaut depuis la version 0.9.4.

ReconfigureSessionMessage

Description

Envoyé du Client vers le Router pour mettre à jour la configuration de session. Le router répond avec un SessionStatusMessage .

Sommaire

1. ID de session
2. Configuration de session

Notes

• À partir de la version 0.7.1.
• Si la Date dans la Configuration de Session est trop éloignée (plus de +/- 30 secondes) de l’heure actuelle du router, la session sera rejetée.
• Le Mapping dans la Configuration de Session doit être trié par clé afin que la signature soit validée correctement dans le router.
• Certaines options de configuration ne peuvent être définies que dans le CreateSessionMessage , et les changements ici ne seront pas reconnus par le router. Les modifications des options de tunnel inbound.* et outbound.* sont toujours reconnues.
• En général, le router devrait fusionner la configuration mise à jour avec la configuration actuelle, donc la configuration mise à jour n’a besoin de contenir que les options nouvelles ou modifiées. Cependant, à cause de la fusion, les options ne peuvent pas être supprimées de cette manière ; elles doivent être définies explicitement à la valeur par défaut désirée.

ReportAbuseMessage

OBSOLÈTE, INUTILISÉ, NON PRIS EN CHARGE

Description

Informer l’autre partie (client ou router) qu’elle est sous attaque, potentiellement en référence à un MessageId particulier. Si le router est sous attaque, le client peut décider de migrer vers un autre router, et si un client est sous attaque, le router peut reconstruire ses routers ou bannir certains des pairs qui lui ont envoyé des messages délivrant l’attaque.

Envoyé soit du router vers le client ou du client vers le router.

Sommaire

1. Session ID
2. 1 octet Integer gravité d’abus (0 étant minimalement abusif, 255 étant extrêmement abusif)
3. Raison String
4. Message ID

Notes

Inutilisé. Non entièrement implémenté. Le router et le client peuvent tous deux générer un ReportAbuseMessage , mais aucun des deux n’a de gestionnaire pour le message lorsqu’il est reçu.

RequestLeaseSetMessage

OBSOLÈTE. Non pris en charge par i2pd. Non envoyé par Java I2P aux clients version 0.9.7 ou supérieure (2013-07). Utilisez RequestVariableLeaseSetMessage.

Description

Demande qu’un client autorise l’inclusion d’un ensemble particulier de tunnels entrants. Envoyé du router vers le client. Le client répond avec un CreateLeaseSetMessage .

Le premier de ces messages envoyés sur une session est un signal au client que les tunnels sont construits et prêts pour le trafic. Le router ne doit pas envoyer le premier de ces messages tant qu’au moins un tunnel entrant ET un tunnel sortant n’ont pas été construits. Les clients devraient expirer et détruire la session si le premier de ces messages n’est pas reçu après un certain temps (recommandé : 5 minutes ou plus).

Table des matières

1. Session ID
2. 1 octet nombre Integer de tunnels
3. Autant de paires de :
   1. Hash
   2. TunnelId
4. Date de fin

Notes

Cela demande un LeaseSet avec toutes les entrées Lease configurées pour expirer en même temps. Pour les versions client 0.9.7 ou supérieures, RequestVariableLeaseSetMessage est utilisé.

RequestVariableLeaseSetMessage

Description

Demander qu’un client autorise l’inclusion d’un ensemble particulier de tunnels entrants.

Envoyé du Router vers le Client. Le client répond avec un CreateLeaseSetMessage ou CreateLeaseSet2Message .

Le premier de ces messages envoyé sur une session est un signal au client que les tunnels sont construits et prêts pour le trafic. Le router ne doit pas envoyer le premier de ces messages tant qu’au moins un tunnel entrant ET un tunnel sortant n’ont pas été construits. Les clients devraient expirer et détruire la session si le premier de ces messages n’est pas reçu après un certain temps (recommandé : 5 minutes ou plus).

Sommaire

1. ID de session
2. 1 octet nombre Integer de tunnels
3. Autant d’entrées Lease

Notes

Ceci demande un LeaseSet avec un temps d’expiration individuel pour chaque Lease .

À partir de la version 0.9.7. Pour les clients antérieurs à cette version, utilisez RequestLeaseSetMessage .

SendMessageMessage

Description

Voici comment un client envoie un message (la charge utile) vers la Destination . Le router utilisera une expiration par défaut.

Envoyé du Client au Router. Le router répond avec un MessageStatusMessage .

Sommaire

1. ID de session
2. Destination
3. Charge utile
4. 4 octets Integer nonce

Notes

Dès que le SendMessageMessage arrive complètement intact, le router devrait retourner un MessageStatusMessage indiquant qu’il a été accepté pour livraison. Ce message contiendra le même nonce envoyé ici. Plus tard, basé sur les garanties de livraison de la configuration de session, le router peut également renvoyer un autre MessageStatusMessage mettant à jour le statut.

Depuis la version 0.8.1, le router n’envoie aucun MessageStatusMessage si i2cp.messageReliability=none.

Avant la version 0.9.4, une valeur de nonce de 0 n’était pas autorisée. Depuis la version 0.9.4, une valeur de nonce de 0 est autorisée et indique au router qu’il ne doit envoyer aucun MessageStatusMessage , c’est-à-dire qu’il agit comme si i2cp.messageReliability=none pour ce message uniquement.

Avant la version 0.9.14, une session avec i2cp.messageReliability=none ne pouvait pas être remplacée message par message. À partir de la version 0.9.14, dans une session avec i2cp.messageReliability=none, le client peut demander la livraison d’un MessageStatusMessage avec le succès ou l’échec de la livraison en définissant le nonce à une valeur non nulle. Le router n’enverra pas le MessageStatusMessage “accepted” mais il enverra plus tard au client un MessageStatusMessage avec le même nonce, et une valeur de succès ou d’échec.

SendMessageExpiresMessage

Description

Envoyé du Client vers le Router. Identique à SendMessageMessage , sauf qu’il inclut une expiration et des options.

Sommaire

1. Session ID
2. Destination
3. Payload
4. Nonce Integer de 4 octets
5. 2 octets de drapeaux (options)
6. Date d’expiration tronquée de 8 octets à 6 octets

Notes

À partir de la version 0.7.1.

En mode “best effort”, dès que le SendMessageExpiresMessage arrive complètement intact, le router devrait retourner un MessageStatusMessage indiquant qu’il a été accepté pour livraison. Ce message contiendra le même nonce envoyé ici. Plus tard, selon les garanties de livraison de la configuration de session, le router peut également renvoyer un autre MessageStatusMessage mettant à jour le statut.

À partir de la version 0.8.1, le router n’envoie aucun Message Status Message si i2cp.messageReliability=none.

Avant la version 0.9.4, une valeur de nonce de 0 n’était pas autorisée. À partir de la version 0.9.4, une valeur de nonce de 0 est autorisée, et indique au router qu’il ne doit envoyer aucun Message Status Message, c’est-à-dire qu’il agit comme si i2cp.messageReliability=none pour ce message uniquement.

Avant la version 0.9.14, une session avec i2cp.messageReliability=none ne pouvait pas être remplacée message par message. Depuis la version 0.9.14, dans une session avec i2cp.messageReliability=none, le client peut demander la livraison d’un Message Status Message avec le succès ou l’échec de la livraison en définissant le nonce sur une valeur non nulle. Le router n’enverra pas le Message Status Message “accepted” mais il enverra plus tard au client un Message Status Message avec le même nonce, et une valeur de succès ou d’échec.

Champ des drapeaux

À partir de la version 0.8.4, les deux octets supérieurs de la Date sont redéfinis pour contenir des drapeaux. Les drapeaux doivent par défaut être tous à zéro pour la compatibilité ascendante. La Date n’empiétera pas sur le champ des drapeaux avant l’année 10889. Les drapeaux peuvent être utilisés par l’application pour fournir des indications au router quant à savoir si un leaseSet et/ou des ElGamal/AES Session Tags doivent être livrés avec le message. Les paramètres affecteront significativement la quantité de surcharge protocolaire et la fiabilité de livraison des messages. Les bits individuels des drapeaux sont définis comme suit, à partir de la version 0.9.2. Les définitions sont sujettes à changement. Utilisez la classe SendMessageOptions pour construire les drapeaux.

Ordre des bits : 15…0

Bits 15-11

Inutilisé, doit être zéro

Bits 10-9

Remplacement de fiabilité des messages (Non implémenté, à supprimer).

: Si 1, ne pas inclure un leaseSet dans le garlic avec ce message. Si

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

Bits 7-4

Seuil bas de tags. S’il y a moins de tags disponibles que ce nombre,

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

: Nombre de tags à envoyer si nécessaire. Ceci est consultatif et ne

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

Description

Informe le client du statut de sa session.

Envoyé du Router au Client, en réponse à un CreateSessionMessage , ReconfigureSessionMessage , ou DestroySessionMessage . Dans tous les cas, y compris en réponse à CreateSessionMessage , le router doit répondre immédiatement (ne pas attendre que les tunnels soient construits).

Sommaire

1. ID de session
2. 1 octet Integer statut

Les valeurs de statut sont définies ci-dessus. Si le statut est Created, l’ID de session est l’identifiant à utiliser pour le reste de la session.

SetDateMessage

Description

La date et l’heure actuelles. Envoyées du router au client dans le cadre de la négociation initiale. Depuis la version 0.9.20, peuvent également être envoyées à tout moment après la négociation pour notifier le client d’un décalage d’horloge.

Sommaire

1. Date
2. Version de l’API I2CP String

Notes

Il s’agit généralement du premier message envoyé par le router. La chaîne de version est incluse depuis la version 0.8.7. Ceci n’est utile que si le client et le router ne sont pas dans la même JVM. Si elle n’est pas présente, le router est en version 0.8.6 ou antérieure.

Des messages SetDate supplémentaires ne seront pas envoyés aux clients dans la même JVM.

Références

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