i2p.www/www.i2p2/pages/naming_fr.html

{% extends "_layout_fr.html" %}
{% block title %}Nommage et carnet d'adresses{% endblock %}
{% block content %}
Traduction d'avril 2011. <a href="naming.html">Version anglaise actuelle</a>
<h1>Nommage dans I2P</h1>
<h2 id="overview">Aperçu</h2>

<p>
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 
<a href="#addressbook">carnet d'adresses</a>. 
I2P supporte également les <a href="#base32">noms d'hôtes Base32</a> identiques aux adresses .onion de Tor.</p>

<p>
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.
</p>

<p>
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 <a href="naming_discussion.html">discussion sur le nommage</a>.
</p>

<h2 id="components">Composants du système de nommage</h2>
<p>
Il n'y a pas d'autorité de nommage centrale dans I2P. Tous les noms d'hôtes sont locaux.
</p>
<p>
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 :
</p>
<ol>
<li>L'<a href="#lookup">application cliente</a>, qui effectue les recherches locales dans le fichier hosts.txt et gère 
les <a href="#base32">noms d'hôtes Base32</a>.
<li>Le <a href="#httpproxy">mandataire HTTP</a>, qui confie les recherches au routeur et dirige l'utilisateur vers les 
services de saut distants en tant qu'assistance en cas recherches infructueuses.
<li>Des <a href="#add-services">formulaires d'ajout d'hôte</a> HTTP, qui permettent aux utilisateurs&hellip; d'ajouter 
des hôtes à leur hosts.txt local.
<li>Des <a href="#jump-services">services de sauts</a> HTTP, qui fournissent leur propres recherches et listes de 
redirections.
<li>L'application <a href="#addressbook">carnet d'adresses</a>, qui fusionne les listes externes d'hôtes trouvées par 
HTTP à la liste locale.
<li>L'application <a href="#susidns">SusiDNS</a>, simple interface web de configuration du carnet d'adresses et 
d'affichage les listes d'hôtes locales.
</ol>

<h2 id="lookup">Fichiers de nommage et recherches</h2>
<p>
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 <a href="naming_discussion.html#certificates">certificats</a> 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 <a href="todo_fr.html#hashcash">épreuve de travail</a>.)
</p><p>
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 :
<ol>
<li>privatehosts.txt
<li>userhosts.txt
<li>hosts.txt
</ol>
<p>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.
</p><p>
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 
<a href="naming_discussion.html#alternatives">Alternatives sur la page de discussion</a>).
</p> 

<h2 id="httpproxy">Mandataire HTTP</h2>
<p>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'.
</p>

<p>
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).
</p>

<h2 id="addressbook">Carnet d'adresses</h2>
<h3>Abonnements entrants et fusionnement</h3>
<p>
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".
</p><p>
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é.
</p><p>
Pour cette raison, le seul abonnement configuré par défaut est <code>http://www.i2p2.i2p/hosts.txt</code>,
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 
<a href="#susidns">SusiDNS</a>).
</p><p>
Quelques autres liens d'abonnement de carnets d'adresses publics :
</p>
<ul>
<li><a href="http://i2host.i2p/cgi-bin/i2hostetag">http://i2host.i2p/cgi-bin/i2hostetag</a>
<li><a href="http://stats.i2p/cgi-bin/newhosts.txt">http://stats.i2p/cgi-bin/newhosts.txt</a>
<li><a href="http://tino.i2p/hosts.txt">http://tino.i2p/hosts.txt</a>
</ul>
<p>
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.
</p>

<h3>Règles de nommage</h3>
<p>
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é.
</p><p>
Règles de nommage :</p>
<ul>
<li>Les noms sont convertis en minuscules à l'importation.
<li>Les noms sont vérifiés pour détecter les conflits avec des noms pré-existants dans les fichiers userhosts.txt et 
hosts.txt (mais pas dans privatehosts.txt) après la conversion en minuscules.
<li>Ils ne doivent contenir que [a-z] [0-9] '.' et '-' après la conversion.
<li>Ils ne doivent pas commencer par '.' or '-'.
<li>Ils doivent finir par '.i2p'.
<li>Longueur maximum de 67 caractères, '.i2p' inclus.
<li>Ils ne doivent pas contenir '..'.
<li>Ils ne doivent pas contenir '.-' ou '-.' (depuis la version 0.6.1.33).
<li>Ils ne doivent pas contenir '--', à part dans 'xn--' pour les noms de domaines internationalisés (IDN).
<li>Les noms d'hôtes Base32 (*.b32.i2p) ne sont pas permis.
<li>Certains noms d'hôtes réservés au projet ne sont pas permis (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, 
*.router.i2p, *.proxy.i2p).
<li>Une vérification de validité base64 des clés est effectuée.
<li>Les clés font l'objet d'une vérification de conflit par rapport au fichier hosts.txt (mais pas privatehosts.txt).
<li>La longueur minimum des clés est 516 octets.
<li>La longueur maximum des clés est 616 octets (pour permettre des certificats de longueur pouvant aller jusqu'à 100 
octets).
</ul>
<p>
Tout nom reçu via un abonnement est ajouté à hosts.txt s'il passe tous ces tests avec succès.		
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p>

<h3>Abonnements sortants</h3>
<p>
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.
</p>

<h3>Problèmes d'hébergement et de transport</h3>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>

<h2 id="add-services">Services d'ajout d'hôtes</h2>
<p>
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é.
</p><p>
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 
: </p>
<ul>
<li>une limite au nombre de sous-domaines.
<li>autorisations de sous-domaines via diverses méthodes.
<li>pénalités de contrôle (Hashcash) ou certificats signés.
<li>vérification d'éditorial et/ou de contenu du site.
<li>catégorisation des hôtes par contenu.
<li>réservation ou rejet de certains noms d'hôtes.
<li>restrictions du nombre d'enregistrements par unité de temps.
<li>délais entre enregistrement et publication.
<li>vérification de l'état fonctionnel de l'hôte comme prérequis à l'enregistrement.
<li>expiration et/ou révocation.
<li>rejet d'usurpation d'IDN.
</ul>

<h2 id="jump-services">Services de saut</h2>
<p>
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 <code>?i2paddresshelper=clé</code>. 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.</p>
<p>
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.</p>
<p>
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.
</p>

<h2 id="susidns">SusiDNS</h2>
<p>
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'.</p>
<p>
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.</p>

<h2 id="base32">Noms Base32</h2>
<p>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: <code>ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p</code>
</p><p>
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.
</p><p>
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.
</p>
{% endblock %}