I2P est distribué avec une bibliothèque générique de nommage et une implémentation de base conçue pour fonctionner à partir d'une correspondance nom/destination locale, ainsi qu'avec une application compagne appelée le carnet d'adresses. I2P supporte également les noms d'hôtes Base32 identiques aux adresses .onion de Tor.
Le carnet d'adresses est un système de nommage fondé sur un réseau de confiance, décentralisé et lisible par un être humain, qui ne déroge au principe d'unicité globale de ces systèmes de nommages lisibles par l'humain en n'exigeant qu'une unicité locale. Comme tous les messages dans I2P sont adressés à leur destination sur une base cryptographique, différentes personnes peuvent avoir l'entrée "Alice" dans leur carnet d'adresses local qui représente des destinations différentes. Les utilisateurs découvrir de nouveaux noms en important les carnets d'adresses publiés par les pairs de leur réseau de confiance, en ajoutant des entrées fournies par un tiers, ou (si quelques uns organisent une série de carnets d'adresses publiés en utilisant un système d'enregistrement "premier venu, premier servi") en choisissant de se servir de ces carnets d'adresses en tant que serveurs de noms, émulant ainsi le DNS traditionnel.
NOTE : pour en savoir plus sur les raisons de ce choix de nommage pour I2P, sur les arguments courants à son encontre, et sur alternatives possibles, voir la page discussion sur le nommage.
Il n'y a pas d'autorité de nommage centrale dans I2P. Tous les noms d'hôtes sont locaux.
Le système de nommage est assez simple et sa plus grande partie est implémentée dans des applications externes au routeur, mais incluses dans sa distribution. Les composants :
Dans I2P toutes les destinations sont des clés de 516 octets. (Plus précisément, c'est une clé publique de 256 octets plus une clé de signature de 128 octets et un certificat blanc, ce qui fait 516 octets une fois tout ceci représenté dans le code base64. Les certificats ne sont pas utilisés actuellement. Les clés seront plus longues quand ils le seront. Une utilisation possible des certificats est le mécanisme de vérification par épreuve de travail.)
Si une application (i2ptunnel ou le mandataire HTTP) veut accéder à une destination par son nom, le routeur effectue une recherche locale très simple pour résoudre ce nom. L'application cliente (techniquement, le côté client du protocole I2CP dans l'API I2P) fait une recherche linéaire dans trois fichiers locaux, dans l'ordre suivant, pour trouver un nom d'hôte et le convertir en clé de destination de 516 octets :
Le recherche n'est pas sensible à la casse. La première occurrence est utilisée, et les conflits ne sont pas détectés. Il n'y a pas d'obligation de règles de nommage pour les recherches.
Les recherches sont conservées en mémoire quelques minutes. Il y a une fonctionnalité expérimentale de recherches en temps réel (à la DNS) sur le réseau intégrée au routeur, mais par défaut elle n'est pas activée (voir "EepGet" dans Alternatives sur la page de discussion).
Le proxy HTTP fait une recherche via le routeur pour tous les noms d'hôtes en '.i2p'. Pour les autres, il transfère la requête à un mandataire sortant HTTP configuré. Donc en pratique, tous les noms d'hôtes eepsites HTTP doivent se terminer par le pseudo domaine de plus haut niveau '.i2p'.
Si le routeur échoue dans sa requête de résolution, le mandataire HTTP renvoie une page d'erreur indiquant des liens vers plusieurs services de saut (voir détails plus bas).
L'application carnet d'adresses trouve régulièrement le fichier hosts.txt d'autres utilisateurs et les fusionne au fichier local après plusieurs vérifications. Les conflits sont résolus par la règle "premier entré/premier servi".
L'abonnement au fichier hosts.txt d'un autre utilisateur implique l'octroi d'un certain niveau de confiance. Vous ne souhaitez par exemple pas qu'il détourne un nouveau site en vous indiquant une autre clé.
Pour cette raison, le seul abonnement configuré par défaut est http://www.i2p2.i2p/hosts.txt,
qui contient une copie du hosts.txt inclus dans la distribution d'I2P. Les utilisateurs doivent configurer des
abonnements supplémentaires dans leur application carnet d'adresses locale (via subscriptions.txt ou
SusiDNS).
Quelques autres liens d'abonnement de carnets d'adresses publics :
Les opérateurs de ces services peuvent avoir diverses politiques de référencement des hôtes. Leur présence sur cette page n'implique pas l'aval de l'équipe d'I2P.
Bien qu'il n'y ait heureusement pas de limitations techniques dans les noms d'hôtes I2P, le carnet d'adresses applique certaines restrictions aux noms d'hôtes importés par les abonnements. Il fait ceci pour la propreté typographique et la compatibilité avec les navigateurs, et par sécurité. Les règles sont principalement celles de la section 3.2.2 de la RFC2396. Tout nom d'hôte qui viole ces règles n'est pas importé.
Règles de nommage :
Tout nom reçu via un abonnement est ajouté à hosts.txt s'il passe tous ces tests avec succès.
Notons que caractère '.' dans un nom d'hôte n'a aucune signification, et ne signale aucune hiérarchie de confiance. Si le nom 'hôte.i2p' existe déjà, rien n'empêche personne d'ajouter un nom 'a.hôte.i2p' à son hosts.txt, et ce nom sera alors importé par les autres. Des méthodes pour refuser des sous-domaines aux non-"propriétaires" du domaine (par des certificats?), ainsi que l'intérêt et la faisabilité de ces méthodes sont l'objet de discutions ultérieures.
Les IDN fonctionnent aussi sur I2P (en utilisant la forme punycode 'xn--'). Pour voir les IDN .i2p correctement affichés dans la barre d'adresses de Firefox, ajouter 'network.IDN.whitelist.i2p (boolean) = true' dans about:config.
Comme l'application carnet d'adresses n'utilise pas du tout le fichier privatehosts.txt, ce fichier est tout désigné pour recevoir des alias privés ou des noms abrégés pour des hôtes déjà présents dans hosts.txt.
Le carnet d'adresses publie le fichier fusionné hosts.txt à un endroit (habituellement hosts.txt dans le répertoire home du site eep) accessible aux autres pour leurs abonnements. Cette étape optionnelle est désactivée par défaut.
L'application carnet d'adresses, avec eepget, enregistre l'Etag et/ou l'info dernière modification renvoyée par le serveur de l'abonnement. Ceci réduit grandement la bande passante nécessaire car le serveur renvoie un '304 Not Modified' si rien n'a changé à la tentative suivante.
Cependant le fichier hosts.txt est entièrement téléchargé s'il a été modifié. Voir la discussion plus bas sur ce problème.
Les hôtes qui fournissent un fichier hosts.txt statique ou une application CGI équivalente sont vivement encouragés à utiliser une en-tête de longueur de contenu, et soit une en-tête Etag, soit une en-tête de date de dernière modification. Assurez-vous aussi que le serveur envoie le message '304 Not Modified' quand c'est nécessaire, eu égard à la bande passante et pour diminuer les risques de corruption.
Un service d'ajout d'hôte est une simple application CGI qui prend en paramètres un nom d'hôte et et une clé base64 pour les ajouter au fichier hosts.txt local. Si d'autres routeurs s'abonnent à ce fichier, l'ajout sera propagé.
Il est recommandé que le service impose au minimum les mêmes restrictions que celles en vigueur au niveau de l'application carnet d'adresses listées plus haut. Le service peut ajouter des restriction supplémentaires, par exemple :
Un service de saut est une application CGI simple qui prend en paramètres un nom d'hôte et retourne un message '301
redirect' vers la bonne URL, complété d'une chaîne ?i2paddresshelper=clé. Le mandataire HTTP interceptera
la chaîne et utilisera la clé en tant que destination réelle. De plus, le proxy mettra cette clé en cache de sorte que
l'assistant d'adresse ne soit plus nécessaire pour elle jusqu'au prochain redémarrage du routeur.
Remarquons au passage, que comme pour les abonnements, l'utilisation d'un service de saut implique un certain niveau de confiance, car le service pourrait insidieusement rediriger vers une destination usurpée.
Pour apporter le meilleur service, un service de saut devrait être abonné à plusieurs fournisseurs de fichiers hosts.txt pour que sa liste d'hôtes soit récente.
SusiDNS est simplement une interface web destinée à configurer les abonnements de carnets d'adresses et accéder au quatre fichiers de carnets d'adresses. Tout le travail réel est effectué par l'application 'carnet d'adresses'.
Actuellement, il n'y a pas de vérification des règles de nommage du carnet d'adresses intégrée dans SusiDNS, si bien que vous pouvez entrer des noms d'hôtes qui pourraient être rejetés par vos propres abonnements ou ceux des autres.
I2P supporteles noms d'hôtes Base32 similaires aux adresses '.onion' de Tor. Les adresses base32 sont plus courtes
et plus faciles à manipuler que les adresses complètes des destinations base64 à 516 caractères ou les assistants
d'adresses. Exemple: ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p
Dans Tor, l'adresse fait 16 caractères (80 bits), soit la moitié de l'empreinte SHA-1. I2P utilise 52 caractères (256 bits) pour représenter l'empreinte SHA-256 complète. La forme est {52 caractères}.b32.i2p. Le codage base32 est implémenté dans les service de nommage HostsTxt, qui interroge le routeur sur le protocole I2CP pour chercher le jeu de baux afin d'obtenir la destination complète. Les recherches base32 ne réussissent que lorsque la destination est active et qu'elle publie un jeu de baux.
Les adresses Base32 peuvent être utilisées dans la plupart des situations où les noms d'hôtes ou les destinations complètes sont utilisées, sauf quelques exceptions où elles peuvent échouer si le nom n'est pas résolu immédiatement. Par exemple, I2PTunnel échouera si le nom ne se résout pas en destination.
{% endblock %}