Aperçu de I2CP

Aperçu

Le protocole client I2P (I2CP) assure une séparation stricte des responsabilités entre le routeur et tout client souhaitant communiquer via le réseau. Il permet des échanges sécurisés et asynchrones en envoyant et en recevant des messages sur une seule socket TCP. Grâce à I2CP, une application cliente indique au routeur son identité (sa « destination »), les compromis souhaités en matière d’anonymat, de fiabilité et de latence, ainsi que les destinataires des messages. En retour, le routeur utilise I2CP pour informer le client de l’arrivée de messages et pour demander l’autorisation d’utiliser certains tunnels.

Le protocole lui-même est implémenté en Java, afin de fournir le SDK client. Ce SDK est exposé dans le paquet i2p.jar, qui implémente le côté client d’I2CP. Les clients ne devraient jamais avoir à accéder au paquet router.jar, qui contient le routeur lui-même ainsi que le côté routeur d’I2CP. Un client non-Java devrait également implémenter la bibliothèque de streaming pour les connexions de type TCP.

Les applications peuvent tirer parti de l’I2CP de base ainsi que des bibliothèques de flux et de datagrammes en utilisant le protocole Simple Anonymous Messaging (SAM) , qui ne demande pas aux clients de gérer quelque forme de cryptographie que ce soit. De plus, les clients peuvent accéder au réseau via plusieurs types de proxys - HTTP, CONNECT, et SOCKS 4/4a/5. Alternativement, les clients Java peuvent accéder à ces bibliothèques via ministreaming.jar et streaming.jar. Il existe donc plusieurs options pour les applications Java comme pour celles qui ne le sont pas.

Le chiffrement de bout en bout côté client (chiffrement des données sur la connexion I2CP) a été désactivé dans la version 0.6 d’I2P, laissant en place le chiffrement de bout en bout ElGamal/AES qui est implémenté au niveau du routeur. La seule cryptographie que les bibliothèques clientes doivent encore implémenter est la signature de clés publique/privée DSA pour les LeaseSets et les Configurations de session , ainsi que la gestion de ces clés.

Dans une installation standard d’I2P, le port 7654 est utilisé par les clients Java externes pour communiquer avec le routeur local via I2CP. Par défaut, le routeur s’associe à l’adresse 127.0.0.1. Pour s’associer à 0.0.0.0, définissez l’option de configuration avancée du routeur i2cp.tcp.bindAllInterfaces=true et redémarrez. Les clients situés dans la même machine virtuelle Java (JVM) que le routeur transmettent les messages directement au routeur via une interface JVM interne.

Certaines implémentations de routeur et de client peuvent également prendre en charge les connexions externes via SSL, comme configuré par l’option i2cp.SSL=true. Bien que SSL ne soit pas activé par défaut, son utilisation est fortement recommandée pour tout trafic susceptible d’être exposé à Internet. Le nom d’utilisateur et le mot de passe d’autorisation (le cas échéant), la clé privée et la clé privée de signature pour la Destination sont tous transmis en clair sauf si SSL est activé. Certaines implémentations de routeur et de client peuvent également prendre en charge les connexions externes via des sockets de domaine.

Spécification du protocole I2CP

Voir la page de spécification I2CP pour la spécification complète du protocole.

Initialisation I2CP

Lorsqu’un client se connecte au routeur, il envoie d’abord un unique octet indiquant la version du protocole (0x2A). Ensuite, il envoie un message GetDate et attend la réponse SetDate . Puis, il envoie un message CreateSession contenant la configuration de la session. Il attend ensuite un message RequestLeaseSet provenant du routeur, indiquant que les tunnels entrants ont été créés, et répond avec un message CreateLeaseSet contenant le LeaseSet signé. Le client peut désormais initier ou recevoir des connexions depuis d’autres destinations I2P.

Options I2CP

Options côté routeur

Les options suivantes sont traditionnellement transmises au routeur via un SessionConfig contenu dans un message CreateSession ou un message ReconfigureSession .

Remarque : À partir de la version 0.7.7, les noms et valeurs des options doivent utiliser l’encodage UTF-8. Cela est principalement utile pour les surnoms. Avant cette version, les options contenant des caractères multioctets étaient corrompues. Étant donné que les options sont encodées dans une Mapping , les noms et valeurs d’options sont limités à un maximum de 255 octets (et non caractères).

Options côté client

Les options suivantes sont interprétées côté client et seront prises en compte si elles sont transmises à la I2PSession via l’appel I2PClient.createSession(). La bibliothèque de streaming devrait également transmettre ces options à I2CP. D’autres implémentations peuvent avoir des valeurs par défaut différentes.

Format des données utiles I2CP et multiplexage

Les messages de bout en bout gérés par I2CP (c’est-à-dire les données envoyées par le client dans un SendMessageMessage et reçues par le client dans un MessagePayloadMessage ) sont compressés avec un en-tête gzip standard de 10 octets commençant par 0x1F 0x8B 0x08, tel que spécifié par la RFC 1952 . À compter de la version 0.7.1, I2P utilise des parties ignorées de l’en-tête gzip pour inclure des informations sur le protocole, le port d’origine (from-port) et le port de destination (to-port), permettant ainsi aux flux et aux datagrammes d’utiliser la même destination, et rendant fiables les échanges requête/réponse par datagrammes en présence de plusieurs canaux.

La fonction gzip ne peut pas être complètement désactivée, mais définir i2cp.gzip=false règle l’effort de compression gzip à 0, ce qui peut permettre d’économiser un peu de CPU. Les implémentations peuvent choisir différents niveaux d’effort gzip selon les sockets ou les messages, en fonction d’une évaluation de la compressibilité du contenu. En raison de la compressibilité du remplissage de destination mise en œuvre dans l’API 0.9.57 (proposition 161), il est recommandé de compresser les paquets SYN de flux dans les deux sens ainsi que les datagrammes avec accusé de réception, même si la charge utile n’est pas compressible. Les implémentations peuvent souhaiter écrire une fonction gzip/gunzip simplifiée pour un effort gzip de 0, ce qui offrirait de grandes améliorations d’efficacité par rapport à une bibliothèque gzip dans ce cas précis.

L’intégrité des données est vérifiée à l’aide du CRC-32 standard gzip tel que spécifié par la RFC 1952 .

Différences importantes par rapport à l’IP standard

Les ports I2CP sont destinés aux sockets et aux datagrammes I2P. Ils n’ont aucun rapport avec vos sockets ou ports locaux. Étant donné qu’I2P ne prenait pas en charge les ports et les numéros de protocole avant la version 0.7.1, les ports et les numéros de protocole sont légèrement différents de ceux utilisés dans l’IP standard, pour des raisons de compatibilité ascendante :

• Le port 0 est valide et a une signification particulière.
• Les ports 1 à 1023 ne sont ni spéciaux ni privilégiés.
• Les serveurs écoutent sur le port 0 par défaut, ce qui signifie « tous les ports ».
• Les clients envoient vers le port 0 par défaut, ce qui signifie « n’importe quel port ».
• Les clients envoient depuis le port 0 par défaut, ce qui signifie « non spécifié ».
• Un serveur peut avoir un service à l’écoute sur le port 0 et d’autres services à l’écoute sur des ports supérieurs. Dans ce cas, le service sur le port 0 est celui par défaut, et une connexion sera établie avec lui si le port de la socket entrante ou du datagramme ne correspond à aucun autre service.
• La plupart des destinations I2P n’exécutent qu’un seul service, vous pouvez donc utiliser les valeurs par défaut et ignorer la configuration du port I2CP.
• Le protocole 0 est valide et signifie « n’importe quel protocole ». Toutefois, cela n’est pas recommandé et ne fonctionnera probablement pas. Le streaming nécessite que le numéro de protocole soit défini à 6.
• Les sockets de streaming sont suivis par un identifiant de connexion interne. Par conséquent, il n’est pas nécessaire que le 5-tuple de dest:port:dest:port:protocole soit unique. Par exemple, il peut exister plusieurs sockets avec les mêmes ports entre deux destinations. Les clients n’ont pas besoin de choisir un « port libre » pour une connexion sortante.

Travaux futurs

• Le mécanisme d’autorisation actuel pourrait être modifié pour utiliser des mots de passe hachés.
• La clé privée de signature est incluse dans le message Create Lease Set, ce qui n’est pas nécessaire. La révocation n’est pas implémentée. Elle devrait être remplacée par des données aléatoires ou supprimée.
• Certaines améliorations pourraient être capables d’utiliser des messages précédemment définis mais non implémentés.