Vue d’ensemble

I2P est livré avec une bibliothèque générique de nommage et une mise en œuvre de base conçue pour marcher à partir d’un nom local vers la cartographie de destination, ainsi qu’avec une application add-on appelée le carnet d’adresses. I2P permet aussi les noms d’hôtes en Base32 de façon similaire aux adresses en .onion de Tor.

Le carnet d’adresses est conduit par Web de confiance sécurisé, distribué, et système de nommage lisible par humain, sacrifiant seulement l’appel pour tous les noms lisibles par humain qu’il soient globalement uniques en mandatant seulement l’unicité locale. Tandis que tous les messages dans I2P sont cryptographiquement adressés par leur destination, des gens différents peuvent avoir des entrées de carnet d’adresse locales pour "Alice" qui réfère aux destinations différentes. Les gens peuvent toujours découvrir de nouveaux noms en important les carnets d’adresses publiés de pairs indiqués dans leur Web de confiance, ceci en ajoutant les entrées fournies par personne interposée, ou (si quelques personnes organisent une série de carnets d’adresses publiés utilisant un système d’enregistrement de type premier arrivé premier servi) les gens peuvent vouloir traiter ces carnets d’adresses comme des serveurs de nom, émulant un DNS traditionnel.

NOTE : Pour comprendre le raisonnement qui sous-tend le système de nommage d’I2P, les arguments contre ce dernier et les solutions de remplacement possibles, consultez la page discussion sur le nommage.

Composants système de nommage

Il n’y a aucune autorité centrale de nommage dans I2P. Tous les noms d’hôtes sont locaux.

Le système de nommage est assez simple et la plupart de cela est mis en œuvre dans des applications externes au routeur, mais empaquetées avec la distribution I2P. Les composants sont :

1. Le service de noms local qui assure les consultations et gère aussi les noms d’hôtes Base32.
2. Le mandataire HTTP qui demande au routeur des consultations et dirige l’utilisateur vers des services de saut distants afin de pallier les échecs de consultation.
3. formulaires HTTP basés-hôte qui permettent aux utilisateurs d’ajouter des hôtes à leur hosts.txt local
4. Services de saut HTTP qui fournissent leurs propres consultations et redirection.
5. Le carnet d’adresses l’application qui mêle des listes d’hôtes externes, recouvrées via HTTP, avec la liste locale.
6. L’application SusiDNS qui est qui est un simple frontal Web simple pour la configuration du carnet d’adresses et le visionnage des listes locales d’hôtes.

Services de noms

All destinations in I2P are 516-byte (or longer) keys. (To be more precise, it is a 256-byte public key plus a 128-byte signing key plus a 3-or-more byte certificate, which in Base64 representation is 516 or more bytes. Non-null Certificates are in use now for signature type indication. Therefore, certificates in recently-generated destinations are more than 3 bytes.

Si une application (i2ptunnel ou le mandataire HTTP) souhaite accéder à une destination par son nom, le routeur fait une très simple consultation locale afin de résoudre ce nom.

Service de noms hosts.txt

Le service de noms hosts.txt effectue une simple recherche linéaire de fichiers texte. Ce système de noms était celui par défaut jusqu’à la version 0.8.8. Il fut alors remplacé par le système de noms Blockfile. Le format hosts.txt était devenu trop lent après que le fichier a grossi à plusieurs milliers d’entrées.

Il fait une recherche linéaire à travers trois fichiers locaux, dans l’ordre, afin de chercher des noms d’hôte et les convertir en des clés de destination 516–octets. Chaque fichier est un simple format de fichier de configuration, avec hostname=base64, un par ligne. Les fichiers sont :

1. privatehosts.txt
2. userhosts.txt
3. hosts.txt

Service de noms Blockfile

Le service de noms Blockfile enregistre plusieurs « carnets d’adresses » dans un seul fichier de base de données nommé hostsdb.blockfile. Ce système de noms est le système par défaut depuis la version 0.8.8.

Un blockfile est simplement un stockage sur disque de plusieurs mappages triés (paires valeur-clés, mise en oeuvre en tant que liste « à ignorer ».Le format blockfile est spécifié sur la page Blockfile. Il permet la consultation rapide de destinations dans un format compact. Alors que la surcharge du blockfile est substantiel, les destinations sont stockées en binaire plutôt qu’en Base64 comme dans le format de hosts.txt. De plus, le blockfile apporte la capacité de stockage arbitraire de métadonnées (telles que date ajoutée, source et commentaires) pour chaque entrée pour mettre en oeuvre les fonctions évoluées de carnet d’adresses. L’exigence en stockage du blockfile est une modeste augmentation par relevé au format hosts.txt et le blockfile permet de réduire approximativement de dix fois le temps de consultation.x

Lors de la création, le service de noms importe des entrées des trois fichiers utilisés par le service de noms hosts.txt. Le blockfile imite la mise en œuvre précédente en maintenant trois cartes qui sont consultées en ordre, nommées privatehosts.txt, userhosts.txt et hosts.txt. Il maintient aussi une carte de consultation inversée pour mettre en œuvre des consultations inversés rapides.

Autres services de noms

La consultation est insensible à la casse. La première correspondance est utilisée et les conflits ne sont pas détectés. Aucune règle de nommage n’est observée lors de consultations. Les consultations sont mises en cache durant quelques minutes. La résolution Base32 est décrite ci-dessous. Pour obtenir une description complète de l’API de service de noms, consulter la documentation Jave sur les services de noms. Cette API a été significativement augmentée dans la version 0.8.7 pour offrir des ajouts et retraits, un stockage de propriétés arbitraires avec le nom d’hôte et d’autres fonctions.

Services de noms de substitution et expérimentaux

Le service de noms est indiqué par la propriété de configuration i2p.naming.impl=class. D’autres mises en œuvre sont possibles. Par exemple, il y a une possibilité expérimentale pour les consultations en temps réel (de type DNS) par le réseau et dans le routeur. Pour de plus amples informations, consulter les autres possibilités sur la page de discussion.

The HTTP proxy does a lookup via the router for all hostnames ending in '.i2p'. Otherwise, it forwards the request to a configured HTTP outproxy. Thus, in practice, all HTTP (I2P Site) hostnames must end in the pseudo-Top Level Domain '.i2p'.

Nous nous sommes appliqués à réserver le TLD .i2p en suivant les procédures indiquées dans le RFC 6761.

Si le routeur n’arrive pas à résoudre le nom d’hôte, le mandataire HTTP retourne à l’utilisateur une page d’erreur avec des liens vers plusieurs services de « saut ». Voir ci-dessous pour plus de précisions.

Carnet d’adresses

Abonnements entrants et fusion

L’application carnet d’adresses récupère périodiquement les fichiers hosts.txt d’autres utilisateurs et les mêle avec le hosts.txt local, après plusieurs contrôles. Les conflits de nommage sont résolus sur une base premier-arrivé premier-servi.

S’abonner au fichier hosts.txt d’un autre utilisateur implique de lui accorder une certaine confiance. Vous ne voulez pas, par exemple, qu’ils « détournent » un nouveau site en saisissant rapidement leur propre clé pour un nouveau site avant de vous passer la nouvelle entrée d’hôte, de clé.

Pour cette raison, le seul abonnement configuré par défaut est http://i2p-projekt.i2p/hosts.txt (http://udhdrtrcetjm5sxzskjyr5ztpeszydbh4dpl3pl4utgqqw2v4jna.b32.i2p/hosts.txt) qui contient un exemplaire du hosts.txt inclus dans la version d’I2P. Les utilisateurs doivent configurer les abonnements supplémentaires dans leur application locale de carnet d’adresses (avec subscriptions.txt ou SusiDNS).

Some other public address book subscription links:

• http://i2host.i2p.xyz/cgi-bin/i2hostetag
• http://stats.i2p/cgi-bin/newhosts.txt

Les opérateurs de ces services peuvent avoir différentes politiques de listage des hôtes. La présence dans cette liste n’implique pas une approbation.

Règles de nommage

Bien que nous espérions qu’il n’y a pas de restrictions techniques dans I2P concernant les noms d’hôtes, le carnet d’adresses impose plusieurs restrictions aux noms d’hôtes importés d’abonnements. Il le fait par justesse typographique, compatibilité avec les navigateurs et sécurité. Les règles sont essentiellement identiques à celles présentées par RFC2396 section 3.2.2. Tout nom d’hôte enfreignant ces règles ne peut pas être propagé à d’autres routeurs.

Règles de nommage:

• Les noms sont convertis en minuscule lors de l’importation.
• Les noms sont vérifiés contre le conflit avec des noms existants dans userhosts.txt existant et hosts.txt (mais pas privatehosts.txt) après conversion en minuscule.
• Doivent contenir seulement [a-z] [0-9] '.' et '-' après conversion en minuscules.
• Ne doivent pas commencer avec '.' ni '-'.
• Doivent terminer par 'i2p'.
• 67 caractères au maximum, le '.i2p' compris.
• Ne doivent pas contenir '..'.
• Ne doivent pas contenir '..' ou '-.' (depuis la 0.6.1.33).
• Ne doivent pas contenir '--' excepté dans 'xn--' pour IDN.
• Les noms d’hôte Base32 (*.b32.i2p) sont réservés pour un usage Base32 et ne peuvent donc pas être importés.
• Certains noms d’hôtes réservés pour l’usage du projet ne sont pas autorisés (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, et autres)
• La validité Base64 des clés est vérifiée.
• Les clés sont vérifiées contre le conflit avec des clés existantes dans hosts.txt (mais pas privatehosts.txt).
• Longueur minimum de clé : 516 octets.
• Longueur maximum de clé : 616 octets (pour tenir compte des certs jusqu’à 100 octets).

Tout nom reçu par abonnement qui subit avec succès toutes les vérifications est ajouté par le système local de noms.

Notez que les symboles '.' dans un nom hôte n’ont aucune signification et ne dénotent pas de hiérarchie de nommage ni de confiance. Si le nom 'host.i2p' existe déjà, il n’y a rien pour empêcher quelqu’un d’ajouter un nom 'a.host.i2p' à son hosts.txt, et ce nom pourra être importé par les carnets d’adresses d’autres personnes. Des méthodes pour refuser des sous-domaines aux 'propriétaires' de non-domaines (des certificats ?) et la désirabilité et la faisabilité de ces méthodes sont sujets de discussions futures.

Les noms de domaine internationaux (IDN) marchent aussi dans i2p (utilisant le punycode de forme 'xn--'). Pour voir les noms de domaine IDN .i2p rendus correctement dans la barre d’adresse de Firefox, ajoutez 'network.IDN.whitelist.i2p (boolean) = true' dans about:config.

Comme l’application carnet d’adresses n’utilise pas du tout privatehosts.txt, en pratique ce fichier est le seul endroit où il est approprié de placer des alias privés ou "pet names" pour des sites déjà présents dans hosts.txt.

Format évolué de flux d’abonnement

Abonnements sortants

Address Book will publish the merged hosts.txt to a location (traditionally hosts.txt in the local I2P Site's home directory) to be accessed by others for their subscriptions. This step is optional and is disabled by default.

Hosting and HTTP Transport Issues

L’application de carnet d’adresses, de concert avec eepget, enregistre l’Etag ou les informations de dernière modification retournées par le serveur Web de l’abonnement. Cela réduit grandement la bande passante exigée, car le serveur Web retournera « 304 non modifié » lors de la prochaine récupération si rien n’a été modifié.

Cependant hosts.txt est téléchargé en entier si il a changé. Voir ci-dessous pour la discussion sur cette question.

Les hôtes servant un hosts.txt fixe ou une application CGI équivalente sont fortement encouragés à livrer un en-tête de longueur de contenu et soit une balise Etag, soit un en-tête de dernière modification. Cela garantit aussi que le serveur livre un « 304 not modified » (304 non modifié) si nécessaire. La bande passante du réseau sera considérablement réduite et les risques de corruption seront aussi réduits.

Services d’ajout d’hôtes

Un service d’ajout d’hôte est une simple application CGI qui prend un nom d’hôte et une clé en Base64 comme paramètres et ajoute cela à son hosts.txt local. Si d’autres routeurs s’abonnent à ce hosts.txt, le nouveau nom d’hôte ou clé seront propagés à travers le réseau.

Il est recommandé que les services de nom d’hôte imposent, au minimum, les restrictions imposées par la l’application carnet d’adresses inscrite ci–dessus. Les services d’ajout d’hôtes peuvent imposer des restrictions supplémentaires de nom d’hôtes et de clés, par exemple :

• Une limite concernant le nombre de 'sous-domaines'.
• Autorisation de 'sous-domaines' à travers diverses méthodes.
• Certificats signés ou hashcash.
• Révision des noms d’hôte ou du contenu.
• Catégorisation par contenu des noms d’hôtes.
• Réservation ou refus de certains noms hôtes.
• Restrictions sur le nombre de noms enregistrés durant une période donnée.
• Retards entre enregistrement et publication.
• Exiger que l’hôte soit en ligne afin d’être vérifié.
• Expiration ou révocation.
• Refus d’usurpation IDN

Services de saut

Un service de saut est une simple application CGI qui prend un nom d’hôte comme paramètre et retourne une redirection 301 vers l’URL appropriée en ajoutant une chaîne ?i2paddresshelper=key. Le mandataire HTTP interprétera la chaîne ajoutée et utilisera cette clé comme destination effective. De plus, le mandataire mettra cette clé en cache afin que l’aide d’adresse ne soit plus nécessaire jusqu’au redémarrage.

Notez que, comme avec les abonnements, utiliser un service de saut implique une certaine confiance, car un service de saut pourrait de façon malveillante rediriger un utilisateur vers une destination incorrecte.

Pour fournir le meilleur service, un service de saut devrait être abonné à plusieurs fournisseurs hosts.txt afin que sa liste d’hôtes locaux soit actuelle.

SusiDNS

SusiDNS is simply a web interface front-end to configuring address book subscriptions and accessing the four address book files. All the real work is done by the 'address book' application.

Currently, there is little enforcement of address book naming rules within SusiDNS, so a user may enter hostnames locally that would be rejected by the address book subscription rules.

Noms Base32

I2P prend en charge les noms d’hôte en Base32 semblables aux adresses .onion de Tor. Les adresses Base32 sont beaucoup plus courtes et plus faciles à manipuler que les destinations complètes Base64 à 516 caractères ou que les aides d’adresse. Exemple : ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p

In Tor, the address is 16 characters (80 bits), or half of the SHA-1 hash. I2P uses 52 characters (256 bits) to represent the full SHA-256 hash. The form is {52 chars}.b32.i2p. Tor has a proposal to convert to an identical format of {52 chars}.onion for their hidden services. Base32 is implemented in the naming service, which queries the router over I2CP to lookup the LeaseSet to get the full Destination. Base32 lookups will only be successful when the Destination is up and publishing a LeaseSet. Because resolution may require a network database lookup, it may take significantly longer than a local address book lookup.

Les adresses Base32 peuvent être utilisées dans la plupart des endroits où noms d’hôte ou des destinations pleines sont utilisées, cependant il y a quelques exceptions où elles peuvent échouer si le nom n’est pas résolu immédiatement . I2PTunnel échouera, par exemple, si le nom ne résout pas à une destination.