Mon blog

On se souvient que Microsoft avait annoncé officiellement que la compagnie n'entendait pas gérer les noms de domaine internationaux (IDN) dans son navigateur Internet Explorer tant qu'il n'était pas possible d'internationaliser tout l'URL.

En effet, si IDN (RFC 3490) permet d'écrire http://www.académie-française.fr/seances, il ne permet pas de gérer http://www.académie-française.fr/séances. Les IRI, que normalisent le RFC 3987, permettent cela et, si Microsoft tient parole, devraient permettre au dernier navigateur Web sans support IDN de rejoindre ses concurrents.

Les IRI fonctionnent en complément des IDN. Dans l'IRI http://www.académie-française.fr/séances, le nom de machine est géré par IDN et apparaitra donc comme www.xn--acadmie-franaise-npb1a.fr lors des échanges entre logiciels. En revanche, la partie droite de l'IRI, /séances, restera parfois en Unicode. Elle n'est interprétée que par le serveur final et n'a pas forcément à subir les règles très restrictives qui affectent les noms de machines.

La nécessité de traduire l'IRI (en Unicode) en URI (en US-ASCII) dépendra du schéma de l'IRI (le schéma est indiqué par le premier terme, avant le deux-points). Certains schémas existants comme "http" n'acceptent pas forcément l'Unicode et il faudra alors que le logiciel traduise l'IRI en URI, selon un mécanisme analogue à celui des IDN, en utilisant le traditionnel encodage en %. Les schémas les plus récents et les futurs schémas pourront éviter cette étape.

Naturellement, il faudra mettre à jour navigateurs et serveurs, mais les navigateurs gèrent déjà tous Unicode pour l'affichage et cela ne devrait pas être trop difficile pour eux.

Malgré les inquiétudes habituelles de ceux qui verraient bien l'Internet rester exclusivement en anglais, les IRI marquent donc une nouvelle étape vers une internationalisation réelle.

Un bon article sur le sujet est An Introduction to Multilingual Web Addresses.

Le Web repose sur trois piliers : le format HTML, le protocole HTTP et, surtout, le concept d'URI, une famille d'identificateurs à la fois compréhensibles par les humains et automatiquement analysables par les programmes. La syntaxe des URI est normalisée dans ce RFC.

Il y a des URI partout aujourd'hui. Sur le côté des autobus, sur les cartes de visite, dans les documentations techniques, dans les articles de la presse papier. Ils sont une des marques les plus spectaculaires du succès du Web. Peu de gens il y a quinze ans osaient dire qu'on verrait des URI à la devanture des boulangeries et des teintureries. Le Minitel n'avait pas d'équivalent (« Tapez 3615 JERAQUE puis choisissez le menu Locations puis allez dans Dernières locations ») et même les informaticiens connectés à Internet utilisaient souvent de telles descriptions (avant les URI, il n'y avait pas de syntaxe standard et analysable pour un nom de fichier accessible en FTP, on disait « ftp.sunet.se, dans /mirrors/macarchive/decoders/foobar.bin ». (Les URI ont été normalisés pour la première fois dans le RFC 1630 en 1994.) Même si certains utilisateurs n'ont pas encore compris les URI et donnent des instructions assez miniteliennes à leurs interlocuteurs comme « Tapez Locations en Bretagne dans Google » ou bien « Allez sur www.exemple.fr et choisissez Locations puis Bretagne », ils sont largement diffusés, bien au-delà du cercle des quelques informaticiens et physiciens qui les utilisaient en 1990.

Grâce aux URI, on a donc, pour la première fois, des identificateurs standards, à la syntaxe rigoureuse (donc pouvant être traités par un programme) mais décodables et mémorisables par des humains. Ils permettent de désigner sans ambiguïté une ressource (contrairement aux moteurs de recherche et aux systèmes de mots-clés, qui sont une référence floue et instable).

Aujourd'hui, qu'est-ce qu'un URI, du point de vue des normes ? URI est le terme qui désigne toute la famille des identificateurs du Web. Les deux membres les plus connus de cette famille sont les URL (RFC 1738) et les URN mais notre RFC préfère ne pas trop utiliser ces termes et ne parler que d'URI (section 1.1.3, voir aussi RFC 3305), entre autres parce que le statut de « localisateur » (locator) n'est pas clair (un URI http n'est pas forcément un URL, voir section 1.2.2). La syntaxe qui est décrite dans le RFC est générique, elle s'applique à tous les URI, quel que soit leur plan (scheme), la partie de l'URI avant le premier deux-points. Des syntaxes plus précises et plus restrictives peuvent être spécifiées par certains plans (le plus connu des plans est http). Notre RFC fournit, lui, ce qui est commun à tous les plans.

Le « cahier des charges » avait été écrit dans les RFC 1736 et RFC 1737. Le premier RFC qui l'avait mis en œuvre était le RFC 2396, que notre RFC 3986 remplace. Les trois lettres du sigle URI indiquent bien la démarche (section 1.1) :

• « Uniform » car un URI peut décrire une très grande variété de ressources, accessibles (ou pas) via de nombreux protocoles, avec une syntaxe commune,
• « Resource » car un URI identifie des ressources, sans poser de limites à ce que peut être une ressource (cela peut être un fichier mais aussi bien d'autres choses),
• « Identifier » car un URI nomme une ressource, il ne dit pas forcément où la trouver (tous les URI ne sont pas des URL). Les URI s'inscrivent donc dans la grande tribu des identificateurs formels.

La section 1.1.1 décrit la syntaxe générique, détaillée en section 3 : un URI commence par un plan, suivi d'un deux-points, d'une autorité optionnelle (par exemple le nom de domaine d'une machine), puis d'un chemin (path), dont la syntaxe dépend du plan, d'une requête optionnelle et d'un fragment optionnel. Voici quelques exemples d'URI, inspirés du RFC :

http://fr.wikipedia.org/wiki/Jacques_Brel

ldap://[2001:DB8::7:23A]/dc=example,dc=org?objectClass?one

tel:+1-816-555-1212
      
urn:oasis:names:specification:docbook:dtd:xml:4.1.2

Ainsi, droite://example.org:8042/par/ici?label=ChezMoi#note se décompose en :

• droite : le plan,
• example.org:8042 : l'autorité,
• /par/ici : le chemin,
• label=ChezMoi : la requête,
• note : l'identificateur d'un fragment.

En Python, on peut facilement analyser un URI avec le module urlparse :

>>> from urlparse import urlparse
>>> scheme,authority,path,params,query,fragment = urlparse("http://fr.wikipedia.org/wiki/Jacques_Brel#Discographie")
>>> scheme
'http'
>>> path
'/wiki/Jacques_Brel'
>>> fragment
'Discographie'

La section 1.2 revient sur les choix de conception. Elle part d'un scénario où deux personnes échangent des URI en les notant sur une nappe en papier dans un restaurant, ce qui nécessite des URI parlants, mais écrits dans un alphabet répandu (demande qui peut être contradictoire avec la précédente). D'une manière générale, il est préférable d'utiliser de beaux URI. C'est également dans cette section qu'est posé le principe que les URI n'utilisent qu'un jeu de caractères très limité, un sous-ensemble d'ASCII. Cette limite très contraignante est levée avec les IRI du RFC 3987.

La suite de la section parle du problème important de la récupération (retrieval) d'une ressource. Une des utilisations les plus courantes d'un URI est pour accéder à une ressource. Cela nécessite que l'URI soit résolvable (ce qui n'est pas, en général, le cas des URN). Mais tous les URI ne sont pas forcément résolvables, ne serait-ce que parce qu'ils peuvent n'être utilisés que comme identificateurs (c'est le cas, par exemple, des URI identifiant un espace de noms XML). Le RFC insiste aussi sur le fait que le plan n'est pas, en général, un protocole réseau. Même quand cela semble être le cas (URI http), divers mécanismes font que la ressource peut être récupérée par d'autres moyens que le protocole indiqué (par exemple, pour les documents XML, on utilise typiquement un catalogue qui indique une correspondance entre un URI et un fichier local, de sorte que le processeur XML n'aie pas besoin d'aller sur le réseau).

Puis cette section 1.2 discute le caractère hiérarchique des URI, avec ses composants allant du plus significatif, le plan, tout à fait à gauche, au moins significatif, à droite (à noter que les séparateurs des composants varient, ce que n'auraient pas apprécié Rob Pike et Peter J. Weinberger).

La section 2 est consacrée aux caractères utilisés pour former un URI, uniquement ASCII, on l'a vu. La section 2.2 donne une liste des caractères qui, quoique présents dans ASCII, ne peuvent pas être utilisés pour un URI car ils ont une signification spéciale. C'est le cas par exemple du # qui introduit l'identificateur d'un fragment de la ressource. La section 2.1 normalise le codage « pour cent » où les caractères non-ASCII sont remplacés par le signe % suivi de leur valeur en hexadécimal. (C'est hélas la valeur de chaque octet, pas le point de code Unicode.) Malheureusement, la section 2 précise qu'aucun encodage particulier n'est choisi. Il est donc très difficile de faire des URI utilisant des caractères non-ASCII, même en utilisant le codage « pour cent » puisqu'il n'y a pas de moyen d'indiquer l'encodage utilisé. Ainsi, http://example.org/caf%E9 est sans doute du Latin-1 mais sans qu'on puisse en être sûr. On limite les risques en supposant que l'encodage est UTF-8 comme dans l'URI http://fr.wikipedia.org/wiki/caf%C3%A9 (C3 A9 est l'encodage en UTF-8 du e accent aigu).

L'encodage d'une chaîne de caractères pour en faire un URI peut être effectuée en XSLT par la fonction EXSLT str:encode-uri, par exemple ainsi :

 <xsl:value-of select="str:encode-uri($word, true())"/>

ou bien en Python avec la fonction quote de la bibliothèque urllib :

>>> from urllib import quote
>>> quote("foo # bar ?")
'foo%20%23%20bar%20%3F'

Voyons plus en détail les différents composants d'un URI. Le plan, d'abord, décrit en section 3.1. Notre RFC ne contient pas de liste de plans. Ils doivent être enregistrés à l'IANA, comme indiqué dans le RFC 7595 (on peut aussi voir le RFC 2718). Les plans les plus connus sont http, mailto et urn. tag (RFC 4151) est moins connu mais est un de mes favoris.

L'autorité (section 3.2) indique quelle entité va gérer le reste de l'URI. Pour un URN, c'est un simple nom (comme isbn pour les ISBN du RFC 8254).Pour le plan http, l'autorité est un nom de domaine ou une adresse IP. Dans ce cas, elle peut aussi inclure un nom d'utilisateur, pour l'authentification. Si l'adresse IP est IPv6, il faudra un échappement spécial (la mettre entre crochets), décrit dans le RFC. Enfin, il peut y avoir un numéro de port, bien que cela pose un problème avec les enregistrements SRV (RFC 2782) qui peuvent aussi spécifier un port.

Le chemin (section 3.3) indique une ressource particulière pour une autorité. Il est composé de plusieurs parties séparées par une barre oblique (pour des raisons historiques : c'est le séparateur de répertoires sur Unix). Si l'URI est de type http et que les pages Web sont des fichiers HTML statiques, le chemin est un répertoire sur le disque dur, mais ce n'est pas forcément le cas pour tous les URI, loin de là !

La requête (section 3.4), située après le ? est un composant optionnel de l'URI. Elle est utilisée typiquement pour les ressources générées dynamiquement, en réponse à la question que représente ce composant, mais rien dans la norme n'oblige à les utiliser pour cela.

Le fragment (section 3.5), qui se place après le # désigne une partie de la ressource. Si l'URI est résolvable, le fragment est interprété par le client uniquement, le serveur ne le voit pas. L'exemple le plus courant est un fragment composé d'un nom, par exemple, si la ressource est en HTML, un attribut name ou id d'un élément HTML.

La section 4 explique l'utilisation des URI par un programme. Elle couvre le cas d'URI relatifs (la section 5 développe ce point) ou bien, dans la section 4.5, d'URI dont le début, par exemple le plan, manque. De tels URI sont courants dans la presse ou la publicité, par exemple www.afnic.fr au lieu de http://www.afnic.fr/. Le RFC note que cette pratique, quoique courante, est dangereuse car elle dépend du contexte pour une bonne résolution. Elle ne devrait pas être utilisé pour des URI à longue durée de vie.

La section 6 s'attaque à un problème difficile, la normalisation des URI. On a souvent besoin de comparer deux URI. Par exemple, un navigateur Web affiche les pages déjà visitées avec une couleur différente. Pour cela, il doit comparer les URI présents dans la page Web avec son historique des liens visités. Or, faire cette comparaison octet par octet peut rater beaucoup d'égalités. Par exemple, le plan est insensible à la casse donc urn:bortzmeyer:exemple:1 est égal à URN:bortzmeyer:exemple:1. D'autres canonicalisations dépendent du plan. Par exemple, avec les URI http, l'autorité est un nom de domaine et les noms de domaine sont insensibles à la casse donc http://www.demaziere.fr/eve/ est égal à http://www.Demaziere.FR/eve/ (la section 6.2.2.1 détaille les comparaisons insensibles à la casse ; sauf indiqué explicitement, les composants d'un URI sont sensibles à la casse). Le navigateur doit donc normaliser les URI avant de les comparer.

Le RFC note qu'aucune normalisation ne sera parfaite. Après tout, deux URI différents peuvent parfaitement indiquer la même ressource, sans que le logiciel ne puisse le deviner.

Une section 7 détaille les questions de sécurité associées aux URI. Elle note que beaucoup de ces questions n'ont pas de solution technique et qu'elles dépendent d'une approche sociale. Par exemple, la persistence des URI, un sujet de recherche très actif, dépend plutôt de bonnes pratiques sociales (notamment d'organisations stables, et qui peuvent voir sur le long terme) que d'une technique particulière. Une autre question de sécurité est traitée dans la section 7.6, c'est celle du hameçonnage, pour les cas où l'auteur du site de hameçonnage tente de fabriquer des URI trompeurs (très peu d'utilisateurs vérifient les URI et la plupart des hameçonneurs ne se donnent même pas la peine d'en fabriquer de vraisemblables). La syntaxe des URI est suffisamment compliquée pour que certains URI soient difficiles à décoder par un humain.

Enfin, notons que l'appendice D expose toutes les différences entre ce RFC et son prédécesseur, le RFC 2396. La principale est la section sur la normalisation, qui a été complètement refaite, mais il y en a beaucoup d'autres, en général de faible importance.

Le protocole IRIS d'accès aux informations dites « sociales » qui sont stockées dans un registre, par exemple un registre d'adresses IP, est défini indépendemment du schéma des données stockées. Il faut donc le compléter, pour chaque registre, par un schéma indiquant comment sont structurées les données. Notre RFC le fait pour les registres de noms de domaine.

Comme tous les schémas IRIS, ce document utilise le langage W3C Schema pour spécifier les éléments XML qui peuvent être présents dans les requêtes au serveur IRIS et dans ses réponses. Le schéma a reçu le nom de DREG (Domain Registry). La section 3 liste en langue naturelle les éléments possibles de DREG, la section 4 contenant le schéma formel.

Par exemple, l'élément <findDomainsByName> (section 3.1.3) permet des interogations analogues à celles de whois en interrogeant le registre sur les données liées à un domaine dont on connait le nom.

Mais il contient aussi des requêtes qui ne sont pas possibles avec tous les serveurs whois comme <findDomainsByContact> (section 3.1.2) qui permet de retrouver tous les domaines d'une personne ou d'une organisation donnée (très intrusive, cette requête ne sera probablement jamais disponible publiquement).

Et les réponses ? La section 3.2.2 décrit la forme d'un élément <domain>. Cet élément contient les informations associées à un domaine comme ses serveurs de noms, sa date de création ou son état (status). Les états possibles sont énumérés, on y trouve, par exemple, reservedDelegation (réservé mais pas publié dans le DNS, un état qui n'existe pas aujourd'hui dans .fr mais qui peut être présent dans d'autres TLD).

Il faut noter que la liste des états possibles n'est pas la même qu'avec EPP (RFC 4931), cela serait trop simple...

D'autres types d'objet peuvent être stockés par le registre et interrogés via IRIS, comme les contacts (les personnes ou organisations responsables d'un domaine), traités en section 3.2.4.

Ce schéma DREG ne semble pas encore utilisé dans aucun serveur IRIS publiquement accessible.

Emprunté à l'annexe A du RFC, voici un exemple de requête IRIS/DREG :

<?xml version="1.0"?>
<request xmlns="urn:ietf:params:xml:ns:iris1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
  <searchSet>
    <lookupEntity
      registryType="urn:ietf:params:xml:ns:dreg1"
      entityClass="domain-name"
      entityName="example.com" />
  </searchSet>
</request>

et la réponse possible d'un serveur IRIS :

<?xml version="1.0"?>
<iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <iris:resultSet>
    <iris:answer>
      <domain xmlns="urn:ietf:params:xml:ns:dreg1"
        authority="iana.org" registryType="dreg1"
        entityClass="domain-handle" entityName="example-com-1">

        <domainName>example.com</domainName>
        <domainHandle>tcs-com-1</domainHandle>

        <nameServer iris:referentType="host" authority="iana.org"
          registryType="dreg1" entityClass="host-handle"
          entityName="research7" />
        <nameServer iris:referentType="host" authority="iana.org"
          registryType="dreg1" entityClass="host-handle"
          entityName="nsol184" />

        <technicalContact iris:referentType="contact"
          authority="iana.org" registryType="dreg1"
          entityClass="contact-handle" entityName="dbarton" />

        <status>
          <assignedAndActive denied="true" />
        </status>

        <registry iris:referentType="registrationAuthority"
          authority="com" registryType="dreg1"
          entityClass="contact-handle" entityName="VGRS" />
        <initialDelegationDateTime xsi:nil="true"/>
        <iris:seeAlso iris:referentType="ANY" authority="iana.org"
          registryType="dreg1" entityClass="local"
          entityName="notice"  />
      </domain>
    </iris:answer>
  </iris:resultSet>
</iris:response>

Le RFC, 3981, décrit le protocole IRIS, Internet Registry Information Service, qui va tenter de remplacer le protocole whois.

Les limites du protocole whois d'accès à l'information sociale du registre sont connues depuis longtemps (et citées dans le cahier des charges du groupe de travail CRISP, le RFC 3707). Citons notamment :

• aucun mécanisme d'authentification (donc pas possible de donner des réponses différentes selon le client),
• pas de structuration des données (donc nécessité d'analyser une sortie texte en essayant plus ou moins de deviner, tâche pour laquelle Gandi avait développé un script Perl de 6000 lignes),
• pas de mécanisme standard de redirection, permettant par exemple de faire des requêtes hiérarchiques (cas des registres minces, ou bien cas d'allocation en cascade comme avec les adresses IP ou encore cas d'un prestataire ayant sa propre base, avec davantage de détails, comme le fait EuroDNS).

IRIS va tenter de résoudre ces limites. Il est bâti sur le langage XML, et le mécanisme des W3C Schema. Le RFC 3982 décrit le premier schéma, "dreg", conçu pour les registres de noms de domaine, un autre schéma, "areg", pour les RIR, étant en préparation. Notons donc qu'un registre de nom de domaines pourrait utiliser le protocole IRIS (RFC 3981) avec un autre schéma que dreg (RFC 3982), par exemple si son modèle de données est très différent du consensus de Marina de Rey.

Le RFC 3981 n'est pas évident à lire et le lecteur pressé peut se contenter du RFC 3707, puis de l'appendice B du RFC 3981, "IRIS Design Philosophy". Le RFC 3982 est tout aussi trappu mais c'est une tentative de formaliser le modèle de données d'un registre de noms de domaines et c'est donc un document important.

IRIS, par ses nouvelles possibilités, pose plein de questions politiques ou sociales. Par exemple, par son mécanisme d'authentification, il permet des réponses différenciées, peut-être verra t-on des registres faire payer pour avoir accès à plus de renseignements. D'autre part, en faisant sauter une limite technique aux redirections, IRIS encouragera peut-être le déploiement de serveurs IRIS privés, en plus de ceux des TLD ou des RIR.

La question du déploiement effectif d'IRIS est ouverte. Il faut rappeler que IRIS n'est pas le premier protocole à tenter d'éjecter whois : rwhois, whois++ et LDAP avaient déjà essayé. whois, simple et bien connu, a toujours résisté. Verisign a déjà créé deux mises en œuvre libres d'IRIS, je n'en connais pas encore d'autres : le choix des W3C Schema rend de toute façon très complexe la mise en œuvre d'IRIS. Le RIPE-NCC dispose d'un serveur IRIS pilote.

(Depuis, IRIS n'a eu aucun succès et, en mars 2015, un autre candidat à la succession de whois est apparu, RDAP.)

L'appropriation intellectuelle est partout aujourd'hui (je recommande d'ailleurs l'excellent article du Monde Diplomatique pour une analyse en profondeur de ce phénomène) et donc logiquement aussi dans les organismes de normalisation. Même l'IETF, traditionnellement un rassemblement de gros barbus qui savent programmer en assembleur mais ne connaissent rien au droit, a dû évoluer. C'était l'objet de ce RFC, qui mettait à jour le RFC 2026 sur les questions de brevets (nommées, à tort, questions de « propriété intellectuelle », alors que les brevets ne sont pas la même chose que les copyrights, traités dans le RFC 5378). Lui-même a été remplacé depuis par le RFC 8179.

Donc, sur quels principes repose la politique de l'IETF au sujet des brevets ? L'idée de base est de s'assurer que l'IETF disposera d'information sur les brevets pouvant s'appliquer à une norme donnée, de façon à pouvoir prendre une décision en toute connaissance de cause. Il n'y a par contre pas de mécanisme automatique de décision, par exemple « Ne jamais normaliser des technologies brevetées ». En effet, compte-tenu du fait que l'écrasante majorité des brevets logiciels est futile, enregistrée uniquement parce que les organismes de brevetage ont un intérêt financier à accepter tout et n'importe quoi, une telle politique mènerait à ne rien pouvoir normaliser.

En pratique, tout ce RFC 3979 pourrait donc se résumer à « Tout participant à l'IETF qui connait ou devrait connaitre un brevet pouvant s'appliquer à une technique en cours de discussion doit en informer l'IETF ». C'est tout. Mais il y a quelques détails pratiques.

D'abord, il faut rappeler que ce sont officiellement des individus qui participent à l'IETF, pas des sociétés. Donc l'obligation s'applique à ces individus et ils ne peuvent pas y échapper en prétendant que leur compagnie leur interdit de réveler un brevet sous-marin (brevet sur lequel on fait peu de publicité, pour le ressortir une fois que la technique brevetée a été largement adoptée). Ensuite, le RFC définit ce que signifie contribuer à l'IETF (section 1). Par exemple, écrire sur une liste de diffusion d'un groupe de travail est une contribution. Cette règle est régulièrement rappelée par le fameux Note Well.

La section 1 définit formellement bien d'autres choses. Un concept essentiel mais souvent oublié est le Reasonably and personally known. Il désigne une information que le participant connait ou devrait connaitre, vue sa position dans l'entreprise qui l'emploie. L'idée est que le participant IETF n'est pas obligé de chercher activement dans le portefeuille de brevets de son entreprise, que l'obligation ne s'applique qu'à ce qu'il connait forcément, depuis son poste. Le but de l'ajout reasonably est d'éviter qu'une entreprise ne dissimule un brevet à ses propres employés.

Le RFC sur le mécanisme de l'IETF, le RFC 2026, dans sa section 10, exposait déjà les principes de gestion des brevets. Le RFC 3979 le met à jour uniquement en clarification, les principes restent les mêmes :

• L'IETF ne va pas chercher à déterminer si un brevet est futile ou pas (cela peut être un très gros travail, la plupart des brevets étant rédigés en termes incompréhensibles),
• L'IETF peut normaliser ou pas une technique brevetée, il n'y a pas de refus systématique,
• Pour pouvoir néanmoins savoir où on va, l'IETF a besoin d'information et c'est de là que découle l'exigence de divulgation des brevets.

La section 3 rentre dans le concret, même si elle commence par un bel exercice de langue de bois (« The intent is to benefit the Internet community and the public at large, while respecting the legitimate rights of others. »). C'est elle qui impose que le contributeur à l'IETF ait bien divulgué tous les brevets qu'il connaissait « raisonnablement ». La section 4 indique ce que l'IETF va en faire, de ces divulgations : indication dans le RFC du fait qu'il existe des brevets pouvant s'y appliquer et publication de ces divulgations en http://www.ietf.org/ipr/. L'IETF n'ajoutera aucune appréciation sur la validité du brevet, ou sur les conditions de licence (section 4.1). Une telle appréciation nécessiterait en effet un long et coûteux travail juridique. Cette section 4 a fait l'objet d'une légère clarification ultérieure dans le RFC 4879.

La note à inclure dans le RFC est précisée en section 5. Tirée d'un RFC réel, le RFC 5336, voici un exemple :

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; 
...

Quel est exactement le brevet que pourrait enfreindre ce RFC ? Le moteur de recherche des divulgations nous apprend qu'il n'y a pas de divulgations directement liées à ce RFC mais qu'il en existe pour des RFC dont il dépend (comme la #1000, futile et due à un patent troll connu). Autre exemple, plus grave, la divulgation #1154 se réclame d'un brevet sur les courbes elliptiques qui s'appliquerait à tous les RFC parlant d'un protocole qui peut utiliser ces courbes, comme le RFC 5246.

Les divulgations ne sont pas incluses dans les RFC eux-mêmes (section 11) car elles peuvent évoluer dans le temps alors que le RFC est stable. Il faut donc aller voir sur http://www.ietf.org/ipr/.

Les divulgations sont-elles spécifiées plus en détail ? Oui, en section 6. La 6.1 précise qui doit faire la divulgation (le participant, en tant que personne physique), la section 6.2 donne les délais (« aussi vite que possible »), la section 6.4.3 rappelle que la divulgation doit être précise et qu'un contributeur ne peut pas se contenter de vagues généralités. Le tout est aussi mis en ligne, en http://www.ietf.org/ipr-instructions.

Et si un tricheur, comme la société RIM, ne respecte pas cette obligation de divulgation ? La section 7 ne prévoit aucune dérogation : si, par exemple, une société empêche ses employés de divulguer les brevets, ces employés ne doivent pas participer à l'IETF. Le RFC 6701 liste les sanctions possibles contre les tricheurs et le RFC 6702 expose comment encourager le respect des règles.

Bien, donc, arrivé là, l'IETF a ses informations et peut prendre ses décisions. Sur la base de quelles règles ? La section 8 rappelle le vieux principe qu'une technique sans brevets est meilleure ou, sinon, à la rigueur, une technique où le titulaire des brevets a promis des licences gratuites. Mais ce n'est pas une obligation, l'IETF peut choisir une technologie brevetée, même sans promesses sur la licence, si cette technologie en vaut la peine.

La seule exception concerne les techniques de sécurité obligatoires : comme tout en dépend, elles ne doivent être normalisées que s'il n'existe pas de brevet ou bien si la licence est gratuite.

Je rappelle que ce RFC n'est plus d'actualité, il a été remplacé par le RFC 8179.

Ce RFC décrit un moyen d'authentifier son adresse IP en utilisant la cryptographie.

Dans le protocole IPv6, une machine sur un réseau découvre les voisins par le biais du protocole NDP. Ce protocole n'est pas sûr et rien ne garantit que le voisin qui annonce l'adresse IP du routeur du réseau local est bien le bon routeur. La norme originelle (RFC 2461) propose comme seule solution d'utiliser IPsec. Le protocole SEND, normalisé dans le RFC 3971 suggère autrement : les adresses IP sont signées par une clé cryptographique.

Notre RFC, compagnon du RFC 3971 explique comment générer des adresses IP de façon à ce que la signature puisse être vérifiée. L'adresse est simplement un résumé cryptographique calculé à partir de la clé publique et de quelques paramètres.

On notera que le problème auquel s'attaque notre RFC est presque l'opposé de celui traité par le RFC 4941, qui cherchait au contraire à empêcher de tracer un ordinateur utilisant IPv6. Les adresses CGA, définies par notre RFC, visent au contraire à permettre l'authentification.

Pour trouver l'adresse MAC d'un voisin, une machine IPv6 utilise le protocole NDP (Neighbor Discovery Protocol), normalisé dans le RFC 4861. Ce protocole ressemble beaucoup au traditionnel ARP (RFC 826) d'IPv4 et il partage notamment sa principale vulnérabilité : une machine peut tout à fait se faire passer pour une autre et recevoir ainsi les paquets qui ne lui sont pas destinés. En outre, NDP dispose d'autres fonctions qu'ARP, comme la découverte des routeurs, fonctions qui sont tout aussi critiques et tout aussi vulnérables. Au début d'IPv6, l'enthousiasme pour IPsec était sans limite et il était donc censé résoudre ce problème, comme beaucoup d'autres. En réalité, IPsec a été peu implémenté et encore moins déployé et il a donc fallu trouver une autre solution, SEND (SEcure Neighbor Discovery) qui fait l'objet de ce RFC.

Les détails sur les vulnérabilités de NDP figurent dans le RFC 3756. Ils sont aussi résumés dans la section 11.1 du RFC 4861 et rappelés dans la section 1 de notre RFC 3971. Exemple ironique, à chaque réunion physique de l'IETF, certains portables sont configurés pour créer des réseaux ad hoc et envoient des annonces RA (Router Advertisement) concurrents de ceux du routeur légitime. La seule solution est de donner au micro les adresses MAC des routeurs « pirates » pour les filtrer.

Cette section 1 explique aussi, en plus des problèmes généraux d'IPsec, pourquoi il ne peut pas être utilisé pour sécuriser un protocole de découverte des voisins et du réseau, en raison des limites du bootstrap (on a besoin du réseau pour IKE mais on a besoin d'IPsec pour initialiser le réseau..).

Sur un réseau local qui n'offre pas de sécurité physique (Ethernet sans 802.1x ou bien WiFi), NDP est très vulnérable et c'est la raison d'être de SEND.

Résumé brièvement, SEND consiste à utiliser des adresses CGA (adresses auto-signées) sur les machines non-routeuses et des signatures cryptographiques avec certificat pour authentifier les annonces des routeurs.

La section 3 résume les fonctions de NDP :

• Découverte automatique des routeurs (une autre solution étant d'utiliser DHCP),
• Auto-configuration, sans état, des adresses IP des machines (RFC 4862),
• Détection des conflits d'adresses (lorsque deux machines ont reçues la même adresse IP),
• Résolution d'adresses IP en adresses MAC (section 7.2 du RFC 4861).

Toutes ces fonctions sont mises en œuvre par des messages portés sur ICMP (RFC 4443) qui contiennent des données et des options encodées en TLV. (Voir la liste dans le registre IANA.)

Comment fonctionne SEND ? C'est l'objet du reste du RFC, à commencer par la section 4 qui décrit le fonctionnement général. SEND comprend :

• Un système de certificats, permettant de valider les annonces d'un routeur, en suivant un chemin de certificats signés (l'annonce du routeur n'a pas besoin d'inclure tous les certificats du chemin, des nouveaux messages NDP permettent au récepteur de demander les certificats qui lui manquent).
• Des adresses cryptographiques, les CGA du RFC 3972, permettent de s'assurer que la machine qui répond aux requêtes Neighbor Discovery est bien la « propriétaire » de l'adresse. (Donc, contrairement aux annonces des routeurs, SEND n'utilise pas de certificat pour authentifier les simples machines. Cette possibilité est uniquement mentionnée pour un usage possible dans le futur.)
• Une nouvelle option NDP, RSA signature, permet de vérifier l'intégrité du message. La clé publique utilisée pour la signature est récupérée, soit par les certificats, si l'émetteur est un routeur, soit, pour le cas de CGA par une autre option qui permet d'inclure cette clé dans les messages. À noter que RSA est le seul algorithme normalisé, pour garantir l'interopérabilité (puisque SEND tourne dans des environnements où il ne serait pas réaliste de se lancer dans des négociations entre émetteur et récepteur). S'il fallait changer d'algorithme, par exemple suite aux progrès de la cryptanalyse, il faudrait alors développer une nouvelle version de SEND (ce qui est précisement en cours).
• Et enfin un mécanisme de nonce contre les attaques par rejeu.

Le détail de ces nouvelles options et de leur format figure en section 5. Par exemple, l'option CGA (section 5.1) permet au répondeur qui utilise des adresses IP CGA d'inclure la clé publique utilisée dans la réponse. La section 5.1.1 détaille comment l'émetteur doit remplir cette option et la 5.1.2 comment le récepteur peut l'utiliser pour vérifier que le détenteur de la clé est bien celui de l'adresse

La section 5.2, elle, normalise l'option CGA signature, où le message SEND contient une signature au format PKCS#1. Là encore, la section décrit en détail ce que doit faire l'émetteur pour remplir cette option et le récepteur pour la vérifier. Toute aussi indispensable, la section 5.2.3 traite de la configuration de l'option par l'administrateur système et note qu'une mise en œuvre de SEND doit pouvoir être configurée pour vérifier cette signature par différents moyens, comme une trust anchor, une clé publique de départ, à laquelle on fait confiance et qui peut à son tour signer d'autres clés.

Un enjeu de sécurité important de SEND est la protection contre le rejeu. Pour cela, les options Timestamp et Nonce, décrites en section 5.3 sont indispensables. Timestamp indique le temps de l'émetteur et permet, si les horloges de l'émetteur et du récepteur sont raisonnablement synchronisées (la section 5.3.4.2 précise les tolérances admises), d'empêcher qu'un méchant n'enregistre une réponse tout à fait légitime et ne la réutilise plus tard, alors qu'elle n'est plus valable. Nonce, elle, stocke un nombre aléatoire (de taille variable, au moins 48 bits) envoyé par le solliciteur et retourné par le répondant. Ainsi, on peut être sûr que le paquet SEND est bien une réponse à une question qu'on avait posé. Les règles de génération imposent l'usage de ces deux options (et les récepteurs doivent considérer les messages SEND sans une de ces options comme étant non-SEND donc non sûrs).

La section 6 entreprend de résoudre le difficile problème de la validation des certificats des routeurs. La méthode normale, si on n'a pas déjà l'information dans son magasin de certificats, est d'aller la chercher sur l'Internet. Mais, ici, comme il s'agit de découvrir le routeur, cette solution n'est pas possible puisque, justement, on n'a pas encore de routeur pour aller sur l'Internet. Comment SEND traite t-il ce problème ?

Le modèle général est celui de X.509, comme l'utilisent, par exemple, les navigateurs Web. Chaque machine doit avoir un magasin de certificats (qui ne sont pas forcément les mêmes que ceux utilisés, après la configuration d'IP, pour des activités comme le Web) et se sert de ce ou ces certificats comme trust anchors, comme points de départ de la validation (sections 6.1 et 6.5). La machine terminale n'a pas de certificats à elle (à part avec CGA, elle ne s'authentifie pas, seul le routeur le fait). Le routeur, lui, reçoit son certificat et sa clé privée. Le certificat l'autorise non seulement à agir comme routeur mais également à annoncer certains préfixes IP et pas les autres.

Qui attribue ces certificats ? La section 6.2 mentionne une autorité de certification mondiale unique pour les routeurs... qui n'existe pas (et n'est sans doute pas près d'exister). Elle pourrait émaner de l'IANA ou bien d'un consortium formé par les RIR.

Une autre solution mentionnée par le RFC (nommée dans le RFC le « modèle décentralisé », un terme incorrect), et la seule possible aujourd'hui, est celle d'un nuage de diverses autorités de certification, chacune reconnue par certains sites mais pas par d'autres. Cela rend très difficile la mobilité (un portable en visite sur un autre site n'a aucun moyen de valider les annonces SEND du routeur local).

Le format des certificats, lui, est expliqué en section 6.3. C'est du X.509 v3, avec le profil des RFC 3779 et RFC 5280, RFC qui permet de décrire dans le certificat les ressources Internet qu'on peut annoncer (les adresses IP, par exemple, section 4.2.1.6 du RFC 5280).

Enfin, pour permettre la réception de certificats non contenus dans le magasin, mais nécessaires pour boucler la chaîne de validation, la section 6.4 prévoit des types de messages ICMP Certificat Path Solicitation et Certification Path Advertisement. Avec elles, on peut construire des messages pour demander ou obtenir des certificats.

L'usage des adresses IP par SEND fait l'objet de la section 7. Une machine SEND est censée n'utiliser que CGA (section 7.1) et donc pas les adresses IP temporaires du RFC 4941. Sécurité ou vie privée, il faut choisir ! Pour travailler avec d'autres adresses, rien n'est encore trop précisé, à part l'API du RFC 5014. Autre exemple (section 7.4), SEND ne fournit aucun moyen d'authentifier les messages NDP pour les adresses IPv6 statiques, ou bien les adresses autoconfigurées à partir de l'adresse MAC.

SEND est aujourd'hui très peu déployé. Comme tous les protocoles récents (il date quand même de plus de quatre ans), il fait face à des problèmes de transition avec l'ancienne méthode (qui est de ne pas sécuriser du tout). La section 8 expose ces problèmes. Comme, en pratique, une machine SEND va certainement rencontrer des réseaux non-SEND, le RFC demande que les messages non sécurisés soient également acceptés. La machine SEND qui reçoit deux sortes de messages doit évidemment donner la priorité à ceux qui sont sécurisés. Le RFC recommande également une option de configuration « paranoïaque » où seuls les messages NDP sécurisés soient acceptés (à condition qu'elle ne soit pas active par défaut). Inversement, le RFC admet une option de ne pas envoyer de messages SEND (au cas où ils perturbent le réseau mais, si tout le monde suit la norme IPv6 correctement, cela ne devrait pas arriver, les options SEND des messages NDP devraient simplement être ignorées) mais cette option doit être activée explicitement.

La cohabitation de réseaux SEND (sécurisés) et non-SEND (non sécurisés) peut avoir pour conséquence la réception d'un message non sécurisé qui essaie de remplacer l'information issue d'un message sécurisé. Notre RFC 3971 impose que les caches (comme celui des voisins qui, sur Linux, peut être affiché avec ip -f inet6 neighbour show) doivent garder trace du caractère sûr ou non sûr de l'information et ne doivent pas remplacer une information sûre par une non sûre.

SEND est entièrement voué à la sécurité donc l'obligatoire section Sécurité pourrait être inutile mais, ici, la section 9.1 couvre un problème utile : les menaces que SEND ne résout pas. Ainsi, SEND ne protège pas la confidentialité des échanges NDP. SEND ne rend pas complètement sûr un réseau physique non sûr (par exemple, une machine malveillante peut toujours envoyer des paquets avec une adresse MAC source mensongère).

À l'heure actuelle, un groupe de travail de l'IETF, csi, travaille à améliorer SEND. Par exemple, SEND est limité à SHA1 et RSA alors que le groupe de travail explore la meilleure façon d'utiliser de nouveaux algorithmes cryptographiques.

Quells mises en œuvres de SEND sont disponibles ? DoCoMo en avait une mais qui n'est plus maintenue. On trouve quelques bouts de code par ci par là, quelques projets pas finis, mais apparemment pas d'implémentation libre complète qui marche sur des systèmes comme Linux ou FreeBSD. Donc, je ne crois pas que je pourrai activer SEND sur ma Freebox. En revanche, Cisco a une mise en œuvre de SEND sur ses routeurs (mais pas, semble t-il, Juniper).

Pourquoi SEND n'est-il pratiquement pas déployé ? Il y a sans doute plusieurs raisons : le déploiement est difficile puisqu'il faut mettre la clé publique des routeurs dans chaque machine et la sécurité du protocole NDP n'est pas vraiment un problème aujourd'hui (à part sur le réseau de Defcon, les attaques réelles sont rares).

Ce RFC décrivait brièvement le nouveau rôle de l'IESG dans l'évaluation des RFC soumis directement au RFC editor. Il a été depuis remplacé par le RFC 5742.

Tous les RFC ne sont pas développés à l'IETF. Certains sont soumis directement au RFC editor, un service dépendant de l'ISOC. Traditionnellement, l'IESG procédait néanmoins à un examen de ces RFC indépendants mais cela lui prenait beaucoup de temps, en plus du travail normal de l'IETF. (Il est également possible, bien que cela ne soit pas indiqué dans le RFC, que l'IESG ait craint la responsabilité que représente un tel examen.)

La section 3 du RFC décrit donc la nouvelle procédure, où l'IESG n'évalue pas le fond du document, mais détermine simplement s'il y a un risque de conflit avec le travail de l'IETF. Par exemple, le RFC cite le cas de Photuris (RFC 2522), qui concurrençait la technologie IETF de IKE (RFC 2409) ou bien le cas d'une proposition, finalement non publiée comme RFC, qui réutilisait certains bits de l'en-tête IP.

Les remarques éventuelles de l'IESG font l'objet d'un texte standard, décrit dans la section 4, et qui est ajouté au début du RFC publié et qui permettra d'éviter toute confusion avec un travail de l'IETF. C'est ainsi que, par exemple, le RFC 4765 s'est trouvé muni de l'avertissement « Ce protocole avait été étudié à l'IETF mais abandonné en cours de route »,

Le protocole L2TP est aujourd'hui très utilisé notamment pour la collecte des abonnés ADSL et l'acheminement de leurs données au FAI auquel ils sont abonnés (l'opérateur de la collecte, celui qui a accès aux autocommutateurs n'étant pas toujours le FAI). Ce RFC spécifie la nouvelle version, la 3.

Le principe de L2TP est simple : un protocole de contrôle permet d'établir des sessions L2TP au dessus d'un protocole non connecté et un protocole de données permet ensuite d'encapsuler et de décapsuler les données du protocole de niveau 2 (typiquement Ethernet ou PPP) qu'on achemine. Le grand changement de L2TP version 3 est justement une plus grande indépendance par rapport au protocole transporté.

L2TP peut fonctionner au dessus d'UDP ou directement au dessus d'IP.

On notera que les mises en œuvre de ce protocole pour Linux ou autres Linux libres, comme l2tpd, semblent toutes non maintenues désormais, alors que le protocole est très utilisé.

Ce RFC normalise une pratique ancienne, l'attribution automatique d'adresses IP à des machines sur des réseaux "non-gérés". Il existe plein d'ordinateurs qui ne sont pas administrés par un professionnel et qui ont besoin d'adresses IP pour communiquer. C'est le problème connu à l'IETF sous le nom de "problème du bureau du dentiste" : le dentiste est riche, il a plusieurs ordinateurs, mais il n'est pas informaticien, il ne va pas configurer un serveur DHCP (RFC 2131) pour attribuer une adresse à ses ordinateurs.

IPv6 résout ce problème avec l'autoconfiguration sans état, RFC 4862, un mécanisme peer-to-peer, qui ne demande pas de serveur central (DHCP étant l'autoconfiguration avec état, il dépend d'un serveur central).

Depuis des années, une solution pour IPv4 existe dans Microsoft Windows mais n'était pas encore normalisée : c'est désormais chose faite avec ce RFC.

Selon notre RFC, lorsque une machine se retrouve connectée à un réseau, elle peut utiliser un algorithme normalisé pour obtenir une adresse dans la plage 169.254.0.0/16, qui avait été réservée dans le RFC 3330.

L'algorithme est simple dans son principe, même si le RFC a besoin de beaucoup de pages pour expliquer les détails : chaque machine choisit au hasard une adresse dans la plage et elle n'a ensuite qu'à tester pour voir si une autre machine ne l'utilise pas déjà.

Cette norme correspond à l'expansion des réseaux non-gérés, ceux du bureau du dentiste, bien sûr, mais aussi à tous ces réseaux d'appareils qui ne sont pas des ordinateurs mais ont déjà ou auront bientôt une adresse IP (lecteurs RFID, imprimantes, badgeuses, etc).

On note que ce RFC ne résout pas le problème des noms de ces machines, qui, à l'IETF, a été traité par le groupe de travail DNS extensions via Linklocal Multicast Name Resolution (LLMNR) (RFC 4795).

Jabber est le nom original, et XMPP le nom IETF d'un protocole d'échange d'informations encodées en XML, protocole surtout connu pour son utilisation dans la messagerie instantanée.

La messagerie instantanée est une application très populaire surtout chez les moins de dix ans. Elle permet d'échanger des messages sans prendre le temps de réfléchir et en général sans craindre qu'ils soient archivés (contrairement au courrier électronique où il faut réfléchir car ce que l'on écrit restera). Elle sert à de nombreux usages, discussions entre geeks, systèmes de surveillance avec notification des problèmes, etc. À l'exception du vénérable protocole IRC (décrit - insuffisamment - dans le RFC 2810 et suivants), les systèmes existants de messagerie instantanée sont tous basés sur des protocoles privés et fermés comme MSN. La normalisation qui fait le succès du courrier électronique n'a pas réussi ici.

D'où le vieux projet (RFC 2779) de développer un protocole moderne et ouvert, adapté à cette application. C'est ce qu'on fait les développeurs du protocole Jabber en 1999, projet adopté ultérieurement par l'IETF, rebaptisé XMPP en 2002 et qui était normalisé dans ce RFC (l'annexe D liste les différences entre Jabber et XMPP, la plupart liées à la sécurité et à l'internationalisation). Depuis, il a été remplacé par le RFC 6120. Notre RFC décrit un protocole généraliste, un RFC compagnon, le RFC 3921, normalise les aspects spécifiques à la messagerie instantanée.

Quels sont les principes de XMPP ? Les données sont encodées en XML (avec quelques bémols notés en section 11), dans des strophes (stanzas) qui sont des petits paquets d'information. Ces strophes sont transmises sur une connexion TCP (section 4.2) entre client et serveur, ou bien entre serveur et serveur. Les entités qui communiquent (ce ne sont pas forcément des humains, Jabber ayant été conçu pour permettre également la communication entre programmes) sont identifiées par une adresse, qui a une forme syntaxique proche de celle du courrier électronique. Par exemple, mon adresse XMPP est bortzmeyer@gmail.com.

XMPP, comme le courrier électronique, fonctionne par le connexion de serveurs, chacun chargé d'un ou plusieurs domaines. Les clients transmettent les messages aux serveurs, qui se chargent de les acheminer au serveur suivant (section 2.1 du RFC).

Les adresses (JID pour Jabber Identifier) sont décrites dans la section 3. Outre le classique nom@domaine, elles peuvent comporter une ressource, indiquée après la barre oblique (par exemple bortzmeyer@gmail.com/AFNIC).

La représentation des données en XML est décrite dans la section 4. Un flux de données, un stream, est un élément XML <stream>, qui comporte une ou plusieurs strophes, <stanza>. Il existe de nombreux types de strophes (section 9) sans compter les messages d'erreur, décrits en 4.7. Voici un exemple classique d'un échange (C étant le client et S le serveur), avec des strophes de type message :

   C:   <message from='juliet@example.com'
                 to='romeo@example.net'
                 xml:lang='en'>
   C:     <body>Art thou not Romeo, and a Montague?</body>
   C:   </message>
   S:   <message from='romeo@example.net'
                 to='juliet@example.com'
                 xml:lang='en'>
   S:     <body>Neither, fair saint, if either thee dislike.</body>
   S:   </message>

Contrairement à beaucoup d'autres protocoles de messagerie instantanée, conçus uniquement pour jouer, XMPP, étant prévu aussi pour le travail, dispose de fonctions de sécurité très riches. La section 5 précise l'utilisation de TLS et la 6 celle de SASL.

La section 9 détaille les types de strophes disponibles. Trois types sont définis dans ce RFC, <message>, <presence> et <iq>. <message>, dont la sémantique est décrite en section 9.2.1, transporte un... message, tandis que <iq> (section 9.2.3) est une interrogation (Info / Query). Ces éléments XML ont un certain nombre d'attributs par exemple l'attribut to, section 9.1.1, qui spécifie l'adresse du destinataire (romeo@example.net dans la pemière strophe de l'exemple ci-dessus). La syntaxe complète, exprimée en W3C Schema, figure dans l'annexe C.

XMPP est aujourd'hui mis en œuvre dans de nompbreux logiciels. C'est ainsi que le service de messagerie instantanée Google Talk utilise XMPP. Le client XMPP (qui est aussi un client de nombreux autres protocoles) le plus populaire sur Unix est sans doute Pidgin (ex-Gaim). Côté serveurs, le plus pittoresque (et pas le moins utilisé) est sans doute ejabberd, écrit en Erlang.

Les développeurs liront avec intérêt le livre Programming Jabber qui explique comment utiliser Jabber/XMPP dans ses propres programmes.

Depuis longtemps, les opérateurs des réseaux ont besoin de récolter des informations agrégées sur le trafic que voient passer leurs routeurs. IPFIX, dont le cahier des charges figure dans ce RFC, sera le protocole IETF pour cela.

Compter chaque paquet IP est clairement irréaliste. Cela reproduirait le problème de X.25 où les routeurs passaient plus de temps à faire de la facturation qu'à faire circuler les paquets. Il faut donc agréger en flots. Un flot est un ensemble de paquets, qui partagent des caractéristiques communes par exemple, appartenance à la même connexion TCP. Le protocole Netflow, de Cisco (décrit dans le RFC 3954), a été le premier à avoir la possibilité de compter par flot et non plus par paquets, et aussi le premier à formaliser la différence entre l'observateur, qui voit les flots et produit l'information agrégée, et le récolteur qui reçoit ces chiffres et les traite. Il existe aujourd'hui une offre logicielle abondante pour récolter et traiter les flots Netflow. IPFIX sera un descendant direct de Netflow.

Notre RFC met donc par écrit le cahier des charges du nouveau protocole : le modèle de données, la terminologie, ... Il précise quelles catactéristique on peut utiliser pour définir un flot. Une liste des données minimales que IPFIX doit permettre de transmettre est aussi donnée (adresses IP, numéros de port, nombre de paquets transmis, etc).

Une part importante est consacrée aux questions de sécurité : les flots contiennent typiquement des informations assez sensibles et qui ne doivent pas être révélées.

Les RFC normalisant IPFIX sont aujourd'hui tous finis, le RFC 5470 sur l'architecture, le RFC 5472 sur les considérations générales d'applicabilité, le RFC 5101 sur le protocole, le RFC 5102 sur le modèle de données, le RFC 5471 sur les tests du protocole et le RFC 5153 sur les détails d'implémentation ont été publiés. Ils ont été remplacés en septembre 2013 par une seconde série, avec le RFC 7011 sur le protocole et le RFC 7012 sur le modèle de données.

Un RFC très attendu que ce 3912. Non pas par ce qu'il apporte une révolution technologique mais parce qu'il est le premier à réussir à remplacer le très vieux RFC 954, qui spécifiait le protocole whois.

Le RFC 954, qui décrit le désormais célèbre protocole whois, souffrait de nombreux défauts. Celui que résout le RFC 3912 était le mélange, dans le même texte, de la description technique d'un protocole et de la politique d'utilisation. Le RFC 954, méprisant toute considération de vie privée, rendait obligatoire le fait d'avoir un serveur whois et de publier au monde entier les noms et adresses des titulaires de noms de domaine.

Tout le monde était d'accord pour trouver ce mélange des genres intolérable mais il a fallu du temps, l'obstination de Leslie Daigle (et son poste à l'IAB) pour publier le nouveau RFC.

Le RFC 3912 ne garde donc que la description technique du protocole et supprime toute référence politique. Il est donc reconnu officiellement par l'IETF qu'un registre est libre de définir sa politique de protection des données personnelles. Espérons que cela fera taire les éradicateurs de rfc-ignorant.org qui mettaient en liste noire tous les TLD sans serveur whois !

Le protocole whois est trivial: le client se connecte sur le port 43 du serveur, envoie une ligne qui contient la question (par exemple bortzmeyer.org) et reçoit la réponse sous forme de texte (dont la syntaxe n'est pas spécifiée).

Une mise en œuvre presque complète (n'y manque que la sélection du nom du serveur) en Go prend soixante lignes.

Whois souffre de nombreuses limites. Parmi celles-ci, l'absence d'un standard pour le format de sortie. L'étude faite dans le RFC 7485 montre la variété des serveurs whois, à la fois de format et de modèle de données.

De nombreuses tentatives ont été faites pour remplacer l'antédiluvien protocole whois, la plus récente étant RDAP. Aucune n'a encore réussi, le vieux dinosaure reste indécrochable.

L'IETF n'a jamais apprécié les identificateurs à portée purement locale, comme le TLD .local ou comme les adresses IP privées du RFC 1918. Ces identificateurs locaux, dont la signification est spécifique à un site donné, soulèvent plusieurs problèmes, par exemple une question pratique : que faire si deux organisations fusionnent et qu'elles utilisent toutes les deux de tels identificateurs, qui sont en collision ?

Les RFC successifs sur l'adressage IPv6 prévoyaient des identificateurs « site-local », spécifiques à un site, dans le préfixe FEC0::/10 (RFC 3513, section 2.5.6, ce RFC ayant depuis été remplacé par le RFC 4291). Toute organisation pouvait piocher librement dans ces adresses, tout en faisant attention à ne pas les laisser sortir de son site. Cela a permis à beaucoup d'organisations de commencer à expérimenter avec IPv6.

Mais ces identificateurs posaient des problèmes, en général communs avec tous les problèmes des identificateurs locaux. La section 2 du RFC les détaille :

• Si des applications se passent des adresses IP, comme le font FTP ou SIP, elles doivent connaitre les frontières de site pour savoir si elles peuvent passer des adresses privées (section 2.2).
• Commes les domaines privées, les adresses IP privées tendent à « fuir », à être transmises en dehors du site (par exemple dans les en-têtes Received: du courrier électronique ou via des requêtes DNS comme celles qu'absorbe l'AS112). Comme elles perdent toute signification en dehors du site d'origine, cela sème la confusion (section 2.3).
• Elles nécessitent un traitement spécial par les routeurs (section 2.4).
• Selon le RFC 3879, le concept de « site » lui-même n'est pas clairement défini (section 2.5). Est-ce une entité administrative unique ? Un site géographique unique ? Un AS ? Je dois avouer que cette section est la moins convaincante de tous et qu'elle donne l'impression que les auteurs ont voulu charger la barque. Puisque les adresses « site-local » sont spécifiques à un site, rien n'empêchait chaque site d'avoir sa propre définition.

Du point de vue pratique, pour l'opérateur d'un réseau, ces inconvénients pouvaient sembler légers et, de toute façon, un mécanisme de remplacement était nécessaire. C'est au développement de ce mécanisme que s'attaque la section 3 qui réclame un mécanisme alternatif assurant l'unicité des adresses « locales ». Cela ne supprimera pas, par exemple, les fuites, mais cela les rendra plus facile à déboguer. Ce mécanisme, les ULA (Unique Local Addresses) a finalement été créé par le RFC 4193.

Un détail important : la section 5, consacrée à la sécurité, rappelle que, contrairement à ce que croient beaucoup d'administrateurs réseaux débutants, le fait d'avoir des adresses privées n'offre à peu près aucune protection (par exemple parce que des techniques comme le changement DNS permettent d'attaquer de l'intérieur). La bonne technique est l'emploi de filtres et elle s'applique aux adresses privées comme aux publiques.

Il ne faut cependant pas considérer que les identificateurs locaux sont systématiquement une mauvaise idée. Ils sont nécessaires lorsque l'obtention d'identificateurs globaux, valables partout, est difficile ou coûteuse. C'est le cas des adresses IPv4 privées du RFC 1918 : vue la pénurie d'adresses IPv4 et les obstacles financiers et bureaucratiques à franchir pour en obtenir, il est logique d'utiliser ces adresses privées. C'était également le cas à l'époque pour les adresses IPv6 privées. Pendant longtemps, il était complètement impossible d'en obtenir (par diplomatie, pour éviter de vexer les RIR, le RFC 3879 évite de rappeler cet épisode). Il est donc déplorable que ce RFC aie été publié avant que son successeur, le RFC 4193, soit prêt. Désormais, les ULA de ce RFC fournissent une meilleure solution, qui évite notamment les collisions entre deux sites qui fusionneraient. On peut donc enterrer FEC0::/10 sans remords.

Le RFC 3865, "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", vient de sortir.

Il est écrit par un praticien expérimenté de l'Internet, Carl Malamud, l'auteur du "Internet Travelogue", qui a toujours été très proche des questions sociales et politiques. Il était co-auteur de la proposition de reprise de ".org" par une organisation sans but lucratif (le registre a finalement été donné à l'ISOC).

Ce RFC transpose dans le domaine du courrier électronique le principe des affichettes "Pas de pub" que l'on trouve dans de nombreux pays. Un serveur de courrier peut désormais indiqué, via le protocole SMTP, qu'il ne veut pas de spam.

Evidemment, les spammeurs ne respecteront pas ce message. Mais, s'appuyant sur une importante jurisprudence que décrit le RFC, Malamud estime probablement que cet avertissement clair et analysable automatiquement par le logiciel d'émission permettra de prouver clairement que le spammeur ne tenait pas compte des désiderata du destinataire, et ne pouvait donc pas invoquer la liberté d'expression (puisqu'on est toujours libre de ne pas écouter).

C'est donc une mesurette technique, bien plus modérée que les redoutables filtres bayésiens ou que les brutales listes noires, mais qui a pour but de déblayer le terrain juridique pour une éventuelle offensive devant les tribunaux.

Ce RFC normalise un préfixe IPv6 à seule fin de permettre aux auteurs de documentations de ne pas tomber sur des adresses réellement utilisées. (Cet espace a depuis été agrandi par le RFC 9637.)

Traditionnellement, les auteurs de documentation qui avaient besoin de mettre des adresses IP dans les exemples les choisissaient un peu au hasard. Ce faisant, ils tombaient parfois sur des adresses utilisées dans le monde réel et, si le lecteur de la documentation était inattentif et tapait littéralement les adresses qu'il venait de lire, des problèmes pouvaient survenir. Dans l'inimitable style juridique états-unien, on a même vu des documentations IP, comme celles de Cisco, commencer par de longs textes expliquant que ces adresses IP ne sont là qu'à titre d'exemple et que le fournisseur décline toute responsabilité si ces adresses se révèlent être utilisées pour de bon, etc, etc.

Dans le monde IPv4, un compromis parfois utilisé était l'utilisation d'adresses privées (RFC 1918). Cela n'était pas complètement satisfaisant, puisque ces adresses étaient parfois réellement utilisées sur le réseau local. D'où l'importance d'adresses réservées à la documentation.

Pour IPv4, ces adresses sont décrites dans le RFC 5737, la plus connue étant 192.0.2.0/24. Pour IPv6, notre RFC annonce que 2001:db8::/32 a été réservé et que les adresses de ce bloc doivent donc désormais être les seules utilisées pour la documentation. C'est ce que je fais dans ce blog, par exemple pour les articles sur les RFC 5234 ou RFC 5006. (Le RFC 9637 a depuis ajouté un un /20 supplémentaire.)

Après le RFC 3752, qui décrit à quoi peut servir OPES, le cadre conceptuel des entités intermédiaires qui se mettent entre client et serveur pour modifier requêtes et/ou réponses, ce RFC décrit l'architecture d'OPES.

Notre RFC décrit donc le vocabulaire d'OPES (producteurs, consommateurs, flux, entités) et explique leur rôle. L'entité va, soit modifier un flux (en s'insérant entre producteur et consommateur), soit distribuer le travail à une autre entité OPES. Plusieurs entités OPES peuvent en effet transformer successivement le flot.

La communication avec ces "sous-traitants" se fera avec le futur OCP (OPES Callout Protocol), dont le cahier des charges est le RFC 3836 et qui est décrit dans le RFC 4037.

Le RFC décrit également les règles que suit un entité OPES et qu'il faut donc lui transmettre.

Comme OPES a suscité beaucoup de réserves, notamment de la part de l'IAB (dans le RFC 3238), notre RFC consacre toute sa section 4 à y répondre.

Tel qu'il est donc spécifié, le service OPES doit donc :

• Rendre obligatoire le consentement explicite du producteur ou du consommateur,
• Être accessible en IP, donc ne pas être totalement invisible,
• Révéler sa présence en marquant son intervention (par exemple, en HTTP, en ajoutant un en-tête),
• Permettre d'exprimer des préférences de protection des données, par exemple avec P3P.
• Et d'autres obligations.

Tout le monde reçoit des messages du genre « Je suis absent, merci de vous adresser à Mme Durand ou à M. Dupont » après avoir envoyé un message sur une liste de diffusion. Et ceci alors qu'on ne connait pas du tout l'expéditeur de cette réponse automatique. C'est parce que la plupart des répondeurs automatiques ont été développés par un stagiaire qui n'avait pas lu le RFC 3834 (ni, probablement, aucun autre RFC).

Par exemple, un article d'Olivier Zilbertin dans le Monde du 23 Mai 2006 dit : « Il est utile de configurer le répondeur automatique du logiciel de courrier électronique. Cette fonction répond par un message d'absence à chacun de vos expéditeurs. Une telle fonction existe pratiquement sur tous les lecteurs et sur tous les webmails. » OK, bon conseil mais la suite est plus étonnante : « Ensuite, il faudra également songer à vous désabonner provisoirement, le temps des vacances, des listes de diffusion. Sans quoi, dès qu'un membre enverra un message, tous les membres - dont vous - recevront de votre boîte un message d'absence. » Le Monde suppose donc acquis que tous les répondeurs sont bogués. Heureusement, ce n'est pas le cas. Mais c'est quand même fréquent.

Notre RFC a donc été écrit pour formaliser les règles que doivent suivre ces répondeurs. La première, qui va de soi, est qu'ils ne doivent répondre que si leur maître est dans le champ To: (ou à la rigueur le Cc: ou un équivalent). Cette simple règle, tellement évidente que beaucoup de répondeurs la mettaient en œuvre avant même la publication de ce RFC, éviterait déjà les réponses envoyées par de parfaits inconnus, lorqu'on écrit à une liste de diffusion.

L'autre règle importante est que le répondeur ne doit pas dire à chaque message que son maître est absent. Il doit le faire de temps en temps seulement, notre RFC recommandant une fois par semaine au maximum. Cette règle éviterait le syndrôme de l'apprenti sorcier où deux répondeurs se répondent sans fin.

Une autre question que se posent (ou que devraient se poser) les auteurs de répondeurs est « À quelle adresse faut-il répondre ? From: ? Sender: ? » Le RFC est clair sur ce point (section 4), il faut utiliser l'expéditeur tel qu'il apparait dans l'enveloppe du message (il est typiquement indiqué dans l'en-tête Return-Path:).

Les auto-répondeurs sur Unix se nomment souvent vacation mais attention, plusieurs programmes portent ce nom. Voici un exemple d'un tel programme, en Perl, conforme au RFC et conçu pour fonctionner en coopération avec procmail.

Comme beaucoup de protocoles Internet, le DNS avait été conçu sans se préoccuper de la sécurité. Comme souvent, on s'aperçoit avec DNSsec que l'ajout de la sécurité à un protocole n'est pas si triviale que ça. Mais, avant de penser à la solution,il faut étudier le problème : c'est ce que fait ce RFC qui analyse les risques liés au DNS et les possibilités qu'offre ces failles aux fraudeurs.

Modifier des réponses DNS ou bien injecter de fausses réponses qui seraient acceptées par les clients permet en effet nombre d'attaques, comme de rediriger les requêtes censées aller au serveur d'une banque vers le serveur d'un méchant qui copierait les mots de passe.

Il faut noter que le RFC ne parle que des faiblesses du protocole, pas des bogues des mises en œuvre.

Enfin, rappelons que beaucoup d'attaques d'usurpation ne nécessitent pas de faille du DNS : ces attaques peuvent simplement exploiter la crédulité ou bien la distraction de l'utilisateur. D'où l'importance de mesures de sécurité comme celles de SSH qui contrôle la clé cryptographique du serveur où il se connecte.

Le RFC note que les attaques suivantes sont possibles :

• Interception des paquets (questions ou réponses) et émission par l'attaquant d'un autre paquet. Tous les protocoles permettent cela mais c'est plus facile avec le DNS, où question et réponse tiennent souvent dans un seul paquet chacune. Cela nécessite en général que l'attaquant soit situé entre le client et le serveur.
• Fabrication d'une réponse vraisemblable. Cela peut se faire en devinant l'ID (un numéro choisi par le client DNS et qui lui permet de mettre en correspondance requêtes et réponses) d'une requête (et le nom demandé), ce que la faible taille des ID (16 bits) rend possible.
• Chainage de noms, une technique qui consiste à injecter des données dans le cache de la victime en utilisant une indirection. Par exemple, une réponse de type NS (name server) va entrainer des requêtes dans un domaine potentiellement complètement différent, pour résoudre les noms en partie droite de la réponse.
• Trahison par un serveur : si je branche mon portable sur un réseau que je ne contrôle pas, le serveur cache de ce réseau peut envoyer à ses clients des données mensongères. Même chose si un des secondaires d'un domaine décide de tricher, alors qu'il devrait n'envoyer que ce qu'a décidé son primaire.
• Déni de service

Le RFC discute également des problèmes qui ne sont pas des vulnérabilités à proprement parler mais qui compliquent la solution de sécurité, comme la nécessité de pouvoir signer la non-existence d'un domaine ou bien les jokers (wildcards), qui compliquent tant de protocoles liés au DNS.

Le RFC se termine par une discussion des problèmes liés à DNSsec lui-même (DNSsec ne résout pas toutes les failles de sécurité du DNS).

Traditionnellement, les applications Internet reposent sur deux protocoles de transport : TCP et UDP, qui couvrent quasiment tous les besoins. Mais il y a toujours des applications qui demandent autre chose et certaines auront désormais UDP-Lite.

Comme son nom l'indique, UDP-Lite est proche d'UDP. Le principal changement est que la somme de contrôle des paquets qui, en UDP, couvrait tout le paquet ou pas du tout (elle est optionnelle en UDP), peut en UDP-Lite n'en couvrir qu'une partie.

Cela correspond aux demandes de certaines applications, notamment dans le domaine du multimédia, comme AMR (RFC 3267) ou H.264. Ces applications peuvent préférer recevoir des paquets partiellement corrompus et réparer elles-mêmes.

UDP-Lite permet donc à une application de spécifier quelle partie du paquet est importante (et doit donc être couverte par la somme de contrôle) et quelle partie ne l'est pas et qu'il n'est donc pas nécessaire de protéger. Notons que la somme de contrôle est souvent calculée dans une autre couche et que cela limite de toute façon l'intérêt d'UDP-Lite.

Bien que le RFC aie plus de deux ans, le déploiement est lent : je ne trouve même pas trace du protocole 136 (UDP-Lite) dans le fichier /etc/protocols de ma machine...

UDP-lite vient d'être intégré au noyau Linux, dans sa version 2.6.20.

Comment faire un tirage au sort dont tout le monde puisse vérifier la sincérité ? C'est à ce problème que s'attaque ce RFC. Il a des applications pratiques, notamment pour la désignation d'un des groupes de l'IETF, le NomCom.

L'approche classique du tirage au sort est de désigner une ou plusieurs personnes supposées dignes de confiance. Ces personnes vont superviser le tirage. On voit ainsi souvent des affirmations du genre « Tirage contrôlé par huissier ». Outre son coût, les faiblesses de ces méthode sont que la personne qui supervise n'est pas forcément digne de la confiance qu'on met en elle et, surtout, que cette personne peut être trompée par l'organisateur. Par exemple, si le tirage est effectué par un logiciel, comment diable l'huissier va-t-il s'assurer que le logiciel est neutre ? Même s'il a les sources et que l'huissier est en plus informaticien, il serait trivial de le tromper (le fameux article de Thompson, Reflections on Trusting Trust explique bien comment).

Notre RFC propose une solution qui est bien plus dans l'esprit de l'Internet : permettre à chacun de vérifier que le tirage est honnête. Le principe est simple : on désigne à l'avance une série de sources de hasard, comme la quantité de transactions à une Bourse ou bien le résultat d'une loterie d'État et on utilise ces sources comme entrée d'une fonction de hachage, qui va produire un nombre aléatoire, que chacun pourra vérifier (puisque les sources de hasard et l'algorithme utilisé sont publics).

La bonne dispersion fournie par la fonction de hachage fait que l'algorithme fonctionne même si l'une des sources de hasard est de médiocre qualité.

Le RFC détaille les qualités qu'on attend d'une bonne source de hasard. Elle doit évidemment être publique, mais il faut aussi qu'elle ne puisse pas être influencée facilement, ce qui conduit, pour la Bourse, à préférer le nombre de transactions au cours des actions, plus influençables.

Cette technique est utilisée par exemple pour la désignation du NomCom (Nominating Committee, décrit dans le RFC 7437), comité tiré au hasard parmi des volontaires et qui désigne les membres de l'IAB. Elle a aussi été utilisée par l'ICANN, pour choisir le préfixe (ce fut xn) des noms de domaines internationalisés, afin d'éviter tout cybersquatting préventif (voir la méthode et l'annonce du résultat).

Voici par exemple les paramètres sélectionnés pour le NomCom de l'IETF (tirage du 6 juillet 2014) :

Date: Fri, 20 Jun 2014 11:20:28 -0700
From: NomCom Chair 2014 <nomcom-chair-2014@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.or>
Subject: NOMCOM 2014 random seed selection

As per RFC3777, and using the RFC3797,
   Publicly Verifiable Nominations Committee (NomCom) Random Selection

the following are the seed selection that will be used on 2014-07-06.

Seeds:
-------
The following are the seed sources (in order) that will be used in
selecting the 2014-15 NomCom members:

Canadian Lottery Lotto 649
Wednesday, July 2, 2014 Results:
http://lotoquebec.com/loteries/nav/en/draw-games/lotto-6-49/results-past-year#2014-07-02
  (7 numbers including the bonus number: numbers between 1 and 49)

US National debt ("Debt Held by the Public"), published by the
Treasury department as of Thursday, July 7, 2014
http://www.treasurydirect.gov/NP/BPDLogin?application=np
http://www.treasurydirect.gov/NP/debt/search?startMonth=07&startDay=7&startYear=2014&endMonth=&endDay=&endYear=
  Last 8 digits, ignore the commas and periods

US National debt ("Intragovernmental Holdings"), published by the
Treasury department as of Thursday, July 7, 2014
http://www.treasurydirect.gov/NP/BPDLogin?application=np
http://www.treasurydirect.gov/NP/debt/search?startMonth=07&startDay=7&startYear=2014&endMonth=&endDay=&endYear=
  Last 8 digits, ignore the commas and periods

Euromillions Lottery
Friday July 5, 2014 Results:
http://www.europeanlotteryguild.com/lottery_results/euromillions_results/
http://www.europeanlotteryguild.com/lottery_results/euromillions_results/draw_history?results_date=2014-07-05
  (7 numbers including the star balls: 5 numbers between 1 and 50 and 2
   star balls between 1 and 11)

All the above seeds will be provided (in the order listed above) as
input to the RFC 3797 selection algorithm to determine the ten
voting members of the 2014-15 Nomcom.

Notez qu'il y avait deux erreurs, sur la date des Euromillions (le 5 est un samedi...) et sur celle de la dette nationale états-unienne :-)

Le protocole BGP, qui distribue les routes à travers tout l'Internet, est peu sûr car il ne vérifie absolument pas la validité des routes qu'il transmet. Ce RFC propose d'étendre les certificats cryptographiques X.509 pour y stocker les routes et les numéros de systèmes autonomes autorisés à un émetteur. Les routeurs pourraient alors utiliser ces certificats pour s'assurer de la validité d'une annonce.

BGP est spécifié dans le RFC 4271. Le RFC 4272 détaille quant à lui ses problèmes de sécurité. L'un des principaux est le fait qu'authentifier un routeur ne sert pas à grand'chose, il faut pouvoir authentifier les routes qui peuvent être annoncées. Ainsi, même si je suis sûr de l'identité du routeur pair (celui avec qui je suis connecté en BGP), comment savoir s'il dit la vérité en annonçant une route pour tel ou tel réseau ? C'est d'autant plus difficile à déterminer que le pair a en fait souvent relayé cette annonce et qu'on ne peut pas être sûr que tous les routeurs le long de l'AS path ont bien vérifié.

Voici par exemple une mise à jour (message BGP UPDATE) envoyée par un pair :

2003/02/21 06:28:32 BGP: 213.248.70.225 rcvd 193.9.124.0/22
2003/02/21 06:28:32 BGP: 213.248.70.225 rcvd UPDATE w/ attr: nexthop 213.248.70.225, origin i, path 1299 3356 13126 12842

Le pair 213.248.70.225 nous dit qu'il a une route pour le préfixe 193.9.124.0/22 et que cette route a été émise par l'AS 12842. Elle a ensuite été relayée par trois autres AS différents avant de nous arriver. Quelle confiance faire à cette annonce, qui est passée par tant d'acteurs différents et arfois inconnus de nous ?

Il existe des projets de protocole effectuant des vérifications (comme S-BGP) mais tous achoppent sur le problème principal de toute vérification : examiner les papiers d'identité, OK, mais qui va les émettre ? À qui faire confiance ?

Notre RFC propose donc une technique qui a fait se preuves dans d'autres domaines : la signature numérique. Il reprend les certificats de X.509 qui permettent à une autorité de certification de dire que, par exemple, telle entité est autorisée à exploiter www.example.com. Et il les étend avec de nouveaux types de données :

• Adresses IP ou préfixes,
• Numéros de système autonome.

Ainsi, le routeur méfiant pourra vérifier la signature (en remontant la chaine des autorités de certification jusqu'aux RIR) et s'assurer qu'une route est valide.

OpenSSL sait afficher ces extensions. Mais attention, il doit avoir été compilé avec l'option enable-rfc3779, ce qui n'est pas le cas chez Debian. Avec un bon OpenSSL, on obtient :

% openssl x509 -inform DER -text -in ./rpki.afrinic.net/repository/89208CE4119211E0B3FFDB1BAE001804/zYtk-DB4UWmZmTobZ9wfWkpP_Eg.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 6824 (0x1aa8)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=1320AEA9/serialNumber=374E802284C331BCF6A6282BFDDDB798F2B37479
        Validity
            Not Before: Apr 30 09:47:38 2012 GMT
            Not After : Mar 31 00:00:00 2013 GMT
        Subject: CN=F36432B6/serialNumber=CD8B64F83078516999993A1B67DC1F5A4A4FFC48
...
            sbgp-autonomousSysNum: critical
                Autonomous System Numbers:
                  36992

            sbgp-ipAddrBlock: critical
                IPv4:
                  41.152.0.0/15
                  41.222.128.0/21
                  197.120.0.0/13
                  197.192.0.0/13
                IPv6:
                  2c0f:fc88::/32

Aujourd'hui, de tels certificats sont surtout émis par les RIR et les opérateurs réseau, dans le cadre de la RPKI.

ENUM est un mécanisme pour faire correspondre des valeurs à un numéro de téléphone, en passant par un nom de domaine et le DNS. Cela peut servir, par exemple, à permettre à de vieux postes téléphoniques de joindre des nouveaux services accessibles normalement via un URL SIP. Il est désormais normalisé dans le RFC 6116, dont notre RFC 3761 était un prédecesseur.

Le point de départ d'ENUM est d'utiliser comme identificateur principal un numéro de téléphone, au format E.164. Cet identificateur est pénible à utiliser pour un humain, car non mémorisable et est probablement amené à disparaitre dans le futur, au profit d'URL par exemple sip:stephane@bortzmeyer.org.

En attendant, un certain nombre d'équipements, par exemple les vieux postes téléphoniques, ne savent utiliser que des numéros de téléphone et ENUM permet de prolonger leur durée de vie en mettant en correspondance les numéros qu'ils composent avec des ressources modernes, comme SIP.

ENUM utilise pour cela le mécanisme DDDS décrit dans le RFC 3403, avec les enregistrements de type NAPTR. L'algorithme est décrit dans la section 2.4 du RFC. Si le numéro de téléphone est +33 1 38 30 83 00, il est transformé dans le nom de domaine 0.0.3.8.0.3.8.3.1.3.3.e164.arpa. (Le domaine e164.arpa est donc l'équivalent pour les numéros de téléphone de in-addr.arpa pour les adresses IPv4, et il est délégué au RIPE-NCC.)

Une requête DNS de ce nom donne alors des ressources, par exemple (l'option "u" indique la fin de l'algorithme NAPTR, cf. RFC 3404) :

0.0.3.8.0.3.8.3.1.3.3.e164.arpa.   NAPTR 10  100  "u"   "E2U+sip" "!^.*$!sip:info@afnic.fr" . 
              NAPTR 10  110  "u"   "E2U+msg" "!^.*$!mailto:info@afnic.fr" . 

qui indiquent que deux ressources, identifiées par leurs URL, correspondent à ce numéro. Ces ressources sont un accès SIP et un accès par courrier électronique. Si le vieux poste téléphonique cité en exemple est connecté à un autocommutateur ENUM (par exemple Asterisk), l'appel vers +33 1 38 30 83 00 sera automatiquement routé vers l'accès SIP sip:info@afnic.fr (l'accès par courrier ayant une préférence moins forte).

L'enregistrement direct de numéros de téléphone dans le DNS par leurs titulaires (ce qu'on nomme User ENUM par opposition à l'Infrastructure ENUM qui est réservé aux opérateurs) n'est pour l'instant possible que dans peu de pays (par exemple l'Allemagne) et n'a pas été un grand succès (en partie sans doute parce que tout le monde préfère un URL à un numéro de téléphone). En France, le 3.3.e164.arpa est actuellement délégué à l'AFNIC (Tier 1 en terminologie ENUM) mais pas ouvert à l'enregistrement (l'ARCEP a demandé à ce qu'elle soit seule responsable d'ENUM en France - voir « la page du gouvernement » - et l'ouverture d'un service User ENUM pose toujours de délicates questions liées à la portabilité du numéro, à la sécurité et à la protection des données personnelles).

Le protocole DNSSEC de signature des enregistrements DNS par des signatures cryptographiques repose sur des clés dont la partie publique est distribuée dans le DNS lui-même. La partie privée sert à signer les enregistrements ou d'autres clés. Certaines de ces clés ne servent qu'à signer des clés, afin d'être moins exposées que les autres. Pour permettre de distinguer ces clés, un bit spécial est réservé par ce RFC.

DNSSEC est normalisé dans les RFC 4033 et suivants. Ces documents ont intégré une distinction, qui n'existait pas dans le protocole originel, et qui a été introduite par notre RFC 3757, entre les clés servant à signer les enregistrements, les ZSK (Zone Signing Key) et les clés servant à signer d'autres clés, les KSK (Key Signing Key). Depuis la publication du RFC 4034, notre RFC 3757 est donc dépassé mais il garde son intérêt historique.

Faire cette distinction entre ZSK et KSK n'est pas obligatoire. On peut parfaitement faire du DNSSEC avec une seule clé, à la fois ZSK (servant à signer la zone) et KSK (mise dans les résolveurs validateurs, ou bien envoyée au registre de la zone parente pour qu'il la publie sous forme d'enregistrement DS). Pour le protocole de validation des enregistrements (RFC 4035), ZSK et KSK sont identiques (voir section 3).

Mais cette simplification présente un inconvénient : comme la clé va servir à signer des enregistrements, qui peuvent être très nombreux, et que les signatures sont renouvelées souvent (par défaut, un mois, avec BIND), et que les données DNS sont publiques, on va fournir à un cryptanalyste beaucoup de matériel. Et, en cryptographie, plus on a de matériel signé à analyser, plus on a de chances.

Il est donc recommandé de changer de clé souvent. Mais, si cette clé a été publiée, que ce soit via une page Web (comme le fait IIS, le registre de .se) ou bien via une zone parente, changer cette clé est pénible et le risque que certains continuent à utiliser l'ancienne clé est non négligeable.

D'où l'idée, qui est au cœur de notre RFC, d'avoir deux genres de clé. Comme le note la section 1, en pastichant La ferme des animaux, « toutes les clés sont égales mais certaines sont plus égales que d'autres ».

Il y a donc désormais deux sortes de clé, différenciées par un bit dans le champ Flags de l'enregistrement DNSKEY (RFC 4034, section 2.1) :

• Les ZSK (Zone Signing Key), où ce bit vaut zéro, et qui servent à signer les enregistrements. Elles ne sont pas publiées « officiellement » et ne doivent donc jamais se retrouver dans un fichier de configuration. Pour les raisons expliquées plus haut, elles doivent être changées relativement souvent (par exemple tous les six mois).
• Les KSK (Key Signing Key), où ce bit vaut un, et qui servent uniquement à signer les ZSK. Utilisées pour un plus petit nombre d'enregistrements, elles peuvent être de longueur plus grande, et sont changées moins souvent (par exemple tous les deux ans). Elles sont typiquement publiées par la zone parente, ou bien sur une page Web sécurisée (comme au RIPE-NCC). (Comme le rappelle la section 5, l'existence du bit SEP ne suffit pas en elle-même, car un attaquant a pu le définir. Il faut donc récupérer la KSK par un canal sûr.) Les KSK peuvent alors être mises dans la configuration d'un résolveur validateur, d'où le nom de SEP (Secure Entry Point) que leur donne ce RFC.

(La section 1 du RFC détaille tous ces points.)

La section 2 normalise le format du bit SEP. C'est le quinzième du champ Flags de l'enregistrement DNSKEY donc celui du plus faible poids (il est enregistré dans le registre IANA). Si la valeur du champ Flags est paire, c'est une ZSK, si elle est impaire, c'est une KSK. Si je demande les DNSKEY du domaine generic-nic.net, j'obtiens :

% dig DNSKEY generic-nic.net.
...
generic-nic.net.        64800   IN      DNSKEY  256 3 5 AwEAAbLKp5/pZ+5E8nZgxRiUzr1hxV8Y64/63JUqttROZKqkvnAs4kFW 7qq6DTWBPW/m0n+CwPjVuwWm8xRMFugRKemOFsgyFICkunqQKWrHVmFn JwBFXDO9n82fXwCK+oU5XTiINKQzCg6pMgIrrVPJPSvuuxaVefxWJT7o pwBQZX9v
generic-nic.net.        64800   IN      DNSKEY  256 3 5 AwEAAfNNMrML2opUMF4ImMpy8fr90YCb/czyb3ASxMys1FlbbQRSlQ5v 1+9IC2R26Ow0ymHlFBugsrtEdFAqO/wkUgRxDrb3GzhUWvZBL0hMsykM QIJlsm6DXzTxDwhxetUhsjZa6EnQvGSMExei4PLc6+Jrz8rqVtS+rLQd LfgrWIat
generic-nic.net.        64800   IN      DNSKEY  257 3 5 AwEAAd+KNrUQaor2JiLB/oodx9HrUjiGBjn5WpsZHiu2a7oTQYTiVV19 hyWkQL6kwINyaWrkFKS2DJiMQHz7UQoti/J6j26gkQ5XUWviOGrA8g/S xWTVEEQ1FcmyLjBOgLDlUJyWDGO/T8B9lsObuYS1uMkZD6y8BOmRAGeg JtPyASRK5xA9pA20a2XLVWlBqfrvNZ2frXuCkEXaGOgSRTWIm0quYd7/ 2nhVcjiF3+gj4PvVPqVa2jb4iKdlQ1s1Mgx5JqKLPD6wqzHdMTIL+F3U /k/iuEi1olluyEUXM3uMIEgISh6AwHTghGX/ChIVRCz5TzHMXiO45fIk 9gVxwgbqVVBNmy4ZXQwegvMx33afKH27hx1VbiilwGjiaEeoZppXcZ/1 A+hfixRcdNoyvjMgjppDc42hFPCYYY+NFez9BLM8Xac/oq6F/a+4POZP ZV6aaqTmvQLY1wmeKvnhRwKXBtLFkSB7d7RipVVKXsLIA/qQnLTle21H U1azUy3WV5F5S+Vm/cZVv5d1X4/xcdqA+KvAnNAT4rv563Cw1sUhwdzX T1mDdw6UA62wnaZ8KWxqD1ilrk+b8pw+Ri0DXzxmclNlbUduv7UnI6px Y3OGV6K9hkt9IJbHyc02M5JhkeUUSg+AVQjX5OaRzFrPz8pwFZrBPeHf Npln89ofvqcOo9Jp

Le champ Flags est le premier après le type DNSKEY. Les deux premières clés sont des ZSK (bit de plus faible poids à zéro), la troisième une KSK (notez aussi sa longueur plus importante, elle fait 4096 bits, contre 1024 pour les ZSK, c'est l'option -b du dnssec-keygen de BIND). (Il y a deux ZSK car l'une est la future clé de signature, publiée en avance, RFC 6781, section 4.1.1.1.) -f KSK

La section 4 rappelle un mode d'emploi des différentes clés, mais le RFC 6781, plus récent, est une meilleure source.

Avec les outils de gestion de clés de BIND, la génération d'une KSK se fait simplement en ajoutant l'option -f KSK.

Traditionnellement, l'architecture de l'Internet était de bout en bout, ce qui signifie que les éléments intermédiaires ne jouaient qu'un rôle réduit. Aujourd'hui, cette architecture a de fait évolué et les "trucs au milieu", qui changent les données échangées sont de plus en plus nombreux. OPES (Open Pluggable Edge Services) tente de formaliser cette nouvelle architecture.

C'était un principe cardinal de l'Internet : mettre l'intelligence aux bords du réseau, chez le client et le serveur, et ne pas tenter de fournir des servics avancés dans le cœur du réseau. Ce principe a été informellement remis en cause par l'accumulation d'éléments intermédiaires qui ajoutent leur propre traitement. Citons par exemple :

• Un relais Web comme Squid qui garde en mémoire les pages demandées, pour les servir plus rapidement la prochaine fois,
• Un relais Web comme Junkbuster qui filtre les publicités hors des pages Web.

Ces logiciels ne relèvent pas d'une architecture commune et chacun utilise son propre protocole, son propre mécanisme de configuration, ses propres méthodes de traçabilité...

OPES va donc essayer d'ordonner tout cela. Ce premier RFC décrit des scénarios d'usage afin de donner une première approche d'OPES et des cas où il peut être utile.

Notre RFC décrit donc des services qui peuvent modifier les requêtes envoyées à un serveur ou bien modifier les réponses du serveur. Il explique ce qu'est un processeur OPES (l'entité qui va faire les modifications) et un serveur sous-traitant (callout server), auquel le processeur transmet certains traitements. Une description plus précisé de l'architecture d'OPES figure dans le RFC 3238.

Comme OPES soulève d'énormes problèmes à la fois liés à l'architecture (il redéfinit une architecture traditionnelle de l'Internet) et à la sécurité (puisqu'un processeur OPES s'interpose entre deux acteurs, il peut agir de façon maligne), l'IAB a exprimé, dans le RFC 3238 de sérieuses réserves auxquelles le RFC 3835, qui décrit l'architecture d'OPES, répond.

Il existe d'innombrables protocoles d'authentification sur Internet et ceux-ci jouent un rôle important dans la sécurité du réseau. Mais concevoir un protocole d'authentification, sans ouvrir accidentellement une faille, n'est pas trivial. D'où l'idée de créer un cadre général, qui permettra aux concepteurs de protocoles de ne pas tout réinventer : c'est EAP.

EAP n'est pas, en dépit de son nom, un protocole, c'est un cadre où installer des protocoles, comme le protocole d'authentification du GSM, spécifié dans le RFC 4186.

Notre RFC spécifie donc que EAP permet l'utilisation de différentes techniques d'authentification. EAP ne nécessite pas que IP fonctionne. Il peut donc être utilisé par PPP avant que la liaison IP ne marche (la section 3.2 fournit plus de détails sur l'interaction avec PPP). Il peut aussi être utilisé directement au dessus de réseaux locaux de type IEEE 802.

Forces désigne un mécanisme pour séparer, dans un routeur ou autre élément actif du réseau, la partie « contrôle » de la partie « transmission (des paquets) ». Ce RFC décrit l'architecture de Forces.

Le RFC 3654 décrivait le cahier des charges de Forces, l'architecture des routeurs modernes, les motivations derrière ce projet et introduisait son vocabulaire. Notre RFC est un peu plus concret et précise l'architecture de Forces. Le schéma de la section 3 l'illustre bien : Sur ce schéma fonctionnel, on voit un routeur, le Network Element (NE), qui comprend deux Forwarding Element (FE) et deux Control Element (CE). Forces ne normalise que la communication entre CE et FE (les liens en gras sur le schéma).

Sur un schéma physique, on pourrait voir, par exemple, les CE et FE être des lames connectés au même bus comme ici :

La section 5 du RFC est consacrée à l'examen des relations entre Forces et le RFC 1812, qui synthétise les obligations des routeurs IP (comme l'obligation d'être gérable par SNMP, section 5.7). Forces n'impose pas une façon particulière de séparer les tâches du CE et du FE, l'idée étant que, au fur et à mesure que l'électronique progresse, les FE assurent de plus en plus de fonctions qui étaient auparavant dévolues aux CE.

Ainsi, la section 5.5 explique que le CE devra savoir faire du TCP, qui reste par contre facultatif pour le FE typique.

Notons que la section sur la sécurité, la section 8, est très détaillée. Si, dans un routeur classique, le fait que CE et FE soient dans la même boîte physique simplifie le problème, en rendant difficiles certaines attaques, la séparation des CE et des FE que permet Forces peut entrainer des problèmes de sécurité nouveaux.

Une fois définie une norme pour les noms de domaines internationalisés, il reste à régler quelques problèmes liés à leur enregistrement. Par exemple, le chinois s'écrit couramment avec deux écritures, la traditionnelle et la simplifiée. Faut-il permettre l'enregistrement de deux noms de domaines identiques, ne se différenciant que par cette écriture ? Notre RFC propose un cadre pour spécifier de telles règles et crée la notion de lot (package), un ensemble de domaines qu'IDN considérerait différents mais que le registre préfère traiter comme équivalents, et ne pouvant donc faire l'objet que d'un seul enregistrement.

IDN, normalisé dans le RFC 3490 , permet d'exprimer des noms de domaine en Unicode. Une canonicalisation est effectuée par le mécanisme nameprep (RFC 3491) et certaines chaînes de caractères Unicode (commme Straße et strasse) sont donc identiques pour nameprep. Il ne peut donc y avoir qu'un seul nom de domaine pour ces deux chaînes.

Mais d'autres chaînes Unicode sont considérées comme distinctes par nameprep, et donc peuvent être enregistrées séparément, alors qu'un locuteur de telle ou telle langue pourrait les voir comme identiques. C'est le cas de deux mots en chinois en écriture traditionnelle ou simplifiée, par exemple. De même, en français, certains pourraient considérer que congres et congrès doivent être considérés comme identiques, car ne se différenciant que par un accent.

Notre RFC, qui n'a pas le statut de norme, n'essaie pas de décrire une telle politique pour toutes les langues du monde. Il fournit simplement un cadre permettant de décrire de telles politiques, en mettant l'accès sur les questions spécifiques des langues asiatiques, souvent désignées par le sigle CJC. Il a été co-écrit par les registres de noms de domaine de Chine, de Taïwan, de Corée et du Japon, regroupés dans une structure ad-hoc, le JET. Le RFC 4290 étendra ensuite cette méthode aux autres écritures du monde.

Avant de voir la technique, il est bon de se rappeler que l'IETF n'a aucune légitimité pour décider des politiques d'enregistrement suivies dans .tw ou .kr. Il ne peut s'agir ici que de recommandations, telles qu'exprimées dans la note de l'IESG qui précède le RFC, qui incite les autres registres à suivre le même chemin, en rappelant (à regret ?) que l'IESG ne peut pas les y obliger.

En quoi consiste le mécanisme de ce RFC ? Simplement en la définition d'une table des variantes de chaque caractère (sections 2.1.11 et 3.2.1). Toute chaîne peut donc être canonicalisée en étant réduite à la variante préférée (section 2.1.13). Les chaînes qui ont la même forme canonique font partie du même lot (package, section 2.1.18, nommé bundle dans le RFC 4290) et ne peuvent donc pas faire l'objet d'enregistrements distincts. Seule la variante préférée est enregistrée. Les autres sont réservées.

La section 3 du RFC détaille ce mécanisme et traite de certains cas particuliers, comme la suppression d'un nom de domaine (section 3.3).

Appliqué au français, avec une table de variantes telle que celle proposée pour .fr, cette méthode ferait de congres et congrès, mais aussi de côngrës et congrês les membres d'un même lot.

Notre RFC ne répond pas à la question posée plus haut sur l'équivalence des écritures chinoises traditionnelles et simplifiées. Comme expliqué en section 4, cette tâche est laissé à des tables de variantes, dont certaines sont déposées sur le registre (non obligatoire) de l'IANA.

La section 5 du RFC décrit une proposition de syntaxe pour les tables de variantes, qui sera reprise dans le RFC 4290.

EPP, normalisé dans le RFC 4930 et suivants, a une particularité importante : il est conçu pour être extensible. Ce RFC explique les précautions à prendre lorsqu'on étend EPP.

EPP est un protocole d'avitaillement, c'est-à-dire de création, modification et destruction d'objets stockés dans un registre distant. L'utilisation la plus connue d'EPP concerne les registres de noms de domaine mais EPP peut servir à bien d'autres choses. Même dans le cas de registres de noms de domaine, les différences de politique d'enregistrement font qu'il est bien difficile de proposer un protocole qui convienne à tout le monde. EPP sépare donc le protocole (décrit dans le RFC 4930) de la description des objets qu'on peut avitailler (par exemple les domaines sont dans le RFC 4931). Aussi bien le protocole que les types d'objets sont extensibles (et, naturellement, on peut aussi créer ses propres types d'objets), cf. les sections 2.4 à 2.7, ainsi que la section 3 qui explique quoi étendre. (Par exemple, le RFC recommande d'étendre un type d'objet existant plutôt que d'en créer un nouveau.)

Étendre EPP signifie écrire des schémas XML dans le langage W3C Schema. Il est prudent de valider ensuite les schémas et les exemples d'éléments XML qu'ils décrivent, ici par exemple avec xmllint :

% xmllint --noout --schema nask-extcon.xsd nask-create-contact.xml
nask-create-contact.xml validates

on teste un élément décrivant un contact, suivant l'extension au RFC 4933 créée par le NASK, registre de .pl.

Notre RFC explique que les schémas sont identifiés par un URI (par exemple http://www.nic.coop/contactCoopExt-1.0 pour l'extension du registre de .coop), doivent être documentés (section 2.1), doivent eux-même être extensibles, etc. Le protocole EPP impose que les extensions soient annoncées par le serveur et demandées par le client.

Naturellement, une fois qu'on étend EPP, les anciens programmes ne marchent plus. Chaque extension nécessite un travail de programmation spécifique. On notera que le client EPP libre Net::DRI gère pratiquement toutes les extensions EPP existantes.

Voyons quelques exemples (la liste n'est pas limitative) d'extensions à EPP (je donne la priorité aux registres où l'information est publiquement accessible).

Le RFC 4114 décrit un nouveau type d'objets avitaillés, pour les besoins d'ENUM.

Le RFC 3915 décrit une extension au type Domaine pour gérer les périodes de rédemption (le fait qu'un domaine détruit ne soit pas réenregistrable immédiatement, pour laisser une chance à son ancien titulaire).

Le RFC 4310 décrit une extension pour gérer l'information DNSSEC pour les domaines.

Le registre de .coop a plusieurs extensions (langue de l'utilisateur, connexion à leur système de tickets, pour la validation des domaines).

Le registre polonais a des extensions aux objets de type Contact pour gérer la protection des données personnelles (le fait d'être une personne physique et l'autorisation de publication).

Certains registres comme le belge, ont le concept de « groupe de serveurs de noms », qui permet d'attacher un groupe à un domaine, facilitant ainsi l'ajout ou le retrait d'un serveur de noms. Cette extension (documentée dans leur Registration guidelines) a nécessité la création d'un nouveau type d'objets, le NSgroup

Verisign fournit également de nombreuses extensions, par exemple une extension « IDN language » pour indiquer la langue associée à un nom de domaine internationalisé (une stupide idée, imposée par l'ICANN).

Enfin, d'autres registres ont des extensions EPP comme .br ou .us. Merci à Patrick Mevzek pour les détails.

Les registres, par exemple les registres de noms de domaine fonctionnent parfois sur un modèle registry/registrar c'est-à-dire, où le client final doit passer par un intermédiaire, le registrar pour enregistrer son nom de domaine. Le registrar souhaite en général avoir un protocole de communication avec le registre afin d'automatiser ses opérations, dans son langage de programmation favori. EPP, décrit dans ce RFC, est un de ces protocoles d'avitaillement (provisioning et merci à Olivier Perret pour la traduction). Notre RFC a été remplacé par un plus récent, le RFC 4930, mais les changements sont mineurs.

EPP a été réalisé sur la base du cahier des charges dans le RFC 3375. Au lieu de s'appuyer sur les protocoles classiques de communication comme XML-RPC ou SOAP, ou même sur l'architecture REST, EPP crée un protocole tout nouveau, consistant en l'établissement d'une connexion (authentifiée) puis sur l'échange d'éléments XML, spécifiés dans le langage W3C Schemas.

Par exemple, l'ouverture de la connexion se fait en envoyant l'élément XML <login> :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <login>
      <clID>ClientX</clID>
      <pw>foo-BAR2</pw>
      <newPW>bar-FOO2</newPW>
      <options>
        <version>1.0</version>
        <lang>fr-CA</lang>
      </options>
      <svcs>
        <objURI>urn:ietf:params:xml:ns:obj1</objURI>
        <objURI>urn:ietf:params:xml:ns:obj2</objURI>
        <objURI>urn:ietf:params:xml:ns:obj3</objURI>
      </svcs>
    </login>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Un des points délicats de la conception d'un tel protocole est que chaque registre a sa propre politique d'enregistrement et ses propres règles. Quoi que dise ou fasse l'ICANN, cette variété va persister. Par exemple, l'expiration automatique d'un domaine existe dans .com mais pas dans .eu ou .fr. Le protocole EPP ne prévoit donc pas d'éléments pour gérer telle ou telle catégorie d'objets (les domaines mais aussi les serveurs de noms ou les contacts). Il doit être complété par des mappings, des schémas dont certains sont spécifiés pas l'IETF comme le domain mapping (gestion des domaines) dans le RFC 3731. Plusieurs registres utilisent des mappings non-standard, pour s'adapter à leurs propres règles d'enregistrement, ce qui limite la portabilité des programmes EPP. C'est ce qu'ont fait les brésiliens ou les polonais.

Complexe, EPP n'a guère eu de succès chez les registres existants, sauf ceux qui refaisaient complètement leur logiciel comme .be. On notera que certains gros TLD comme .de n'utilisent pas EPP (Denic utilise son protocole MRI/RRI). Il existe d'autres protocoles d'avitaillement comme :

• Le registre Adams' Names a son protocole au dessus de XML-RPC,
• Le registrar Gandi utilise son protocole, au dessus de XML-RPC pour ses revendeurs,
• Le registrar BookMyName utilise son protocole, au dessus de SOAP pour ses revendeurs,

et beaucoup d'autres qui ne semblent pas forcément documentés publiquement.

Il existe plusieurs mises en œuvres d'EPP en logiciel libre par exemple le serveur EPP OpenReg de l'ISC ou bien le client EPP Net::DRI de Patrick Mevzek.

L'usurpation d'adresse IP est une des plaies de l'Internet et est à la base de nombreuses attaques. Ce RFC décrit les mécanismes de filtrage qui peuvent limiter les risques d'usurpation, dans le cas particulier de réseaux ayant plusieurs connexions à Internet (multihoming).

Avant notre RFC, le RFC 2827 s'était déjà attaqué au problème et proposait de systématiser le filtrage des adresses IP source par les FAI et les opérateurs réseau.

Le RFC 2827 notait que le filtrage simple (interdire les paquets dont l'adresse IP source n'est pas attribuée à ce réseau par le FAI) ne marchait pas en présence d'un réseau ayant plusieurs connexions à Internet (multihomed). Dans de tels réseaux, il est parfaitement possible qu'un paquet ayant une adresse IP source du fournisseur d'accès A veuille sortir par le réseau du fournisseur d'accès B. Et il ne devrait pas être filtré dans ce cas.

Notre RFC (également connu sous son numéro de bonne pratique, BCP84) s'attaque donc au cas de ces réseaux. Il propose cinq méthodes :

• ACL en entrée du réseau du FAI (Ingress Access Lists). C'est la méthode du RFC 2827 et elle ne marche pas si on est multihomé.
• Contrôle strict du routage inverse (Strict Reverse Path Forwarding ou Strict RPF). Cela consiste simplement à n'accepter un paquet que si un paquet destiné à l'adresse indiquée comme source aurait été envoyé sur la même interface. Si le routage est symétrique, cela fonctionne.
• Contrôle d'un chemin possible pour le routage inverse (Feasible Path Reverse Path Forwarding). Cette technique prend en compte le fait que la plupart des protocoles de routage peuvent gérer plusieurs chemins vers une même destination et qu'il faut donc considérer tous ces chemins, pas juste la route choisie.
• Contrôle approximatif du routage inverse (Loose Reverse Path Forwarding). Cette technique se contente de vérifier qu'une route existe, sans qu'elle passe forcément par l'interface par laquelle le paquet est entré.
• Contrôle approximatif sans route par défaut (Loose Reverse Path Forwarding ignoring default routes). Identique, à la précédente, cette dernière ignore en outre la route par défaut.

Notre RFC décrit ensuite en détail les forces et les faiblesses de chacune de ces cinq solutions, les cas où elles s'appliquent le mieux et le meilleur endroit du réseau où les appliquer.

Si le routeur est une machine Linux, le Strict RPF (celui qui ne convient pas en cas de routage asymétrique) peut se mettre en œuvre ainsi :

echo 1 > /proc/sys/net/ipv4/conf/rp_filter 

(Sur une vieille Debian, c'est la variable spoofprotect dans /etc/network/options qui indique aux scripts de démarrage d'effectuer la commande ci-dessus. Sur une Debian récente, ce fichier a disparu et on édite désormais /etc/sysctl.conf pour changer la variable net.ipv4.conf.default.rp_filter.) (Une bonne description plus complète de configuration d'une machine Linux multihomée est http://wiki.wlug.org.nz/SourceBasedRouting.)

Sur une machine FreeBSD, c'est avec ipfw qu'on peut faire ce Strict RPF avec l'option verrevpath (et le Loose RPF ignoring default route avec l'option versrcreach) :

ipfw add 100 pass log all from any to any via ${extif} verrevpath

Ce RFC présente un mécanisme de sécurité appliquable aux protocoles de routage mais aussi à bien d'autres protocoles : il consiste à tester le TTL des paquets entrants. Il a été remplacé par le RFC 5082,

Dans un protocole comme BGP, authentifier le routeur en face et s'assurer que ce n'est pas un méchant, peut être difficile. Comme deux routeurs BGP sont en général adjacents (situés sur le même lien physique), la technique GTSM que propose notre RFC est simplement de vérifier le TTL des paquets BGP entrants. Qu'est-ce que le TTL ? C'est simplement un compteur dans le paquet IP qui est décrémenté par chaque routeur traversé. Si le TTL à l'arrivée est de 255 (la valeur maximale possible), c'est qu'aucun routeur n'a été traversé, donc que le paquet provient bien du réseau local.

Notre RFC recommande donc aux routeurs BGP de ne plus envoyer des paquets avec un TTL de zéro (l'ancien comportement, qui permettait de s'assurer que les paquets ne sortent pas du réseau local, les routeurs jettant les paquets de TTL nul) mais avec un TTL de 255, permettant de détecter les attaques venues de l'extérieur.

Le RFC fournit également une spécification de l'usage de GTSM dans le cas où les deux routeurs ne sont pas adjacents. Il note que cette technique est nettement moins sûre et il est prévu de la retirer de la spécification dans le futur, ce qui a été fait dans le RFC 5082, qui l'a remplacé.

On notera que le TTL se nomme Hop Limit en IPv6 mais qu'il a la même sémantique (c'est bien un nombre de sauts, pas une durée et c'est le terme de TTL en IPv4 qui est erroné).

Le format « texte brut » pour le courrier électronique a d'immenses avantages en tant que plus grand dénominateur commun. Mais certaines de ses limites sont peu acceptables aujourd'hui et ce RFC s'attaque notamment à la gestion des paragraphes et aux citations.

Le format que je préfère pour le courrier a le type MIME text/plain. Les messages de ce type, composés uniquement de texte brut sont légers, sont lisibles avec n'importe quel logiciel (même more en cas d'urgence, même si je préfère utiliser mutt) et peuvent facilement être traités par un programme écrit dans un langage quelconque. En outre, ils ne peuvent pas transporter de virus ou autres logiciels malfaisants.

Si on s'intéresse au fond de la communication et non pas à sa forme, le texte brut demeure imbattable. Ouvrez n'importe quel roman ou essai dans une librairie. Du chef d'œuvre de la littérature au dernier des romans de gare, trouve t-on du gras, du souligné, des caractères plus gros que les autres ou bien des changements de police ? Non, le texte brut suffit à tous les auteurs, de Finkielkraut à Sulitzer. Il n'est donc pas étonnant que le format MIME Text/Plain, qui identifie ce texte brut soit toujours si répandu.

Mais le texte brut a des limites. Une des plus agaçantes est la gestion des lignes trop longues. Si je ne mets pas de saut de ligne, le message sera peu lisible par les MUA les plus primitifs. Si j'en mets, cela ne peut être qu'à une taille arbitraire (on cite souvent le chiffre magique de 72 caractères), qui n'est pas forcément la taille de l'écran du lecteur. Peut-être lit-il le courrier sur un PDA avec un petit écran qui va couper les lignes une seconde fois, produisant un texte peu élégant ?

Mettant à jour le RFC 2646, qui avait normalisé le type flowed (texte qui peut être remis en forme par le MUA de lecture), notre RFC précise comment encoder le message pour qu'il soit lisible avec un logiciel de lecture « bête » tout en étant reformatable pour un affichage dans les meilleures conditions. En gros, un espace à la fin d'une ligne indique que le saut de ligne suivant est « mou » et peut être remplacé. Cela revient à introduire le concept de paragraphe, signalé, lui, par un saut de ligne qui n'est pas précédé d'un espace.

Le gros avantage de cette astucieuse technique est qu'un logiciel antérieur à ce RFC n'aura aucun problème à afficher le texte (il traitera les sauts de lignes « mous » comme des sauts de ligne ordinaires). Ce désir de compatibilité est une des caractéristiques importantes de beaucoup de normes Internet : le réseau et ses services sont désormais tellement utilisés partout qu'il n'est pas question de casser gratuitement ce qui marchait avant.

Cet encodage permet également de gérer le cas des citations, introduites par un caractère '>'.

À noter que, pour que mon MUA, mutt, me permette d'afficher ces messages en les formattant comme indiqué dans le RFC, il semble nécessaire de spécifier explicitement :

set wrapmargin = 3 

dans le fichier de configuration (3 peut bien sûr être remplacé par une valeur au choix, il indique le nombre de caractères à laisser en marge gauche).

Par rapport à son prédécesseur, notre RFC introduit un nouveau paramètre, DelSp, qui permet de contrôler plus finement si l'espace final sera supprimé ou pas.

Bien sûr, à long terme, il faudra peut-être passer à un format de marquage plus perfectionné, peut-être avec le jeu de caractères Unicode, qui a des caractères différents pour le saut de ligne (U+2028) et le saut de paragraphe (U+2029), peut-être fondé sur XML et arrêter alors de lire son courrier avec grep et more. Mais, en attendant qu'un tel format, ouvert qui plus est, soit spécifié, mis en œuvre et largement déployé, text/plain, avec ces nouveaux paramètres, a encore de beaux jours devant lui.

Un excellent texte sur le format flowed est la format=flowed FAQ.

Ce RFC marque le début d'un processus très ambitieux, qui doit permettre l'arrivée de la normalisation non plus seulement entre les nœuds de l'Internet mais aussi à l'intérieur de ces nœuds. Le groupe de travail IETF ForCES cherche en effet à normaliser la communication entre les différents composants d'un routeur IP. Ce premier RFC du groupe est le cahier des charges du projet.

Un routeur est composé notamment d'un forwarding engine qui effectue le traitement de chaque paquet (décider où l'envoyer, puis le faire) et d'un control engine ou routing engine qui traite les protocoles de routage comme BGP ou OSPF, les statistiques, les réponses aux requêtes SNMP, etc. Sur un routeur de haut de gamme, par exemple sur les Juniper ou sur certains Cisco, la séparation entre ces deux moteurs est très avancée : le forwarding engine est mis en œuvre par des circuits matériels spécialisés, les ASIC, alors que le routing engine est un logiciel bien plus traditionnel, tournant typiquement sur un processeur ordinaire (un Pentium sur les Juniper, par exemple, en dépit de leur prix). Si on utilise un ordinateur ordinaire comme routeur, les deux moteurs sont tous les deux mis en œuvre en logiciel, dans le processeur, mais sont néanmoins séparés dans le code. Par exemple, sur une machine Unix, le forwarding engine est le noyau Unix et le routing engine est un programme en mode utilisateur, comme Quagga ou Xorp.

Les deux moteurs ont des demandes très distinctes ; besoin de RAM et d'un vrai processeur pour le control engine, qui doit faire des calculs complexes ; capacité à router à la line speed donc plutôt temps réel, pour le forwarding engine.

La communication entre ces deux moteurs se fait à chaque fois avec un protocole privé, souvent non documenté lorsqu'il s'agit de logiciel non-libre. Sur Linux, le protocole se nomme Netlink et est documenté dans le RFC 3549. Sur FreeBSD, cela se fait avec les routing sockets documentées dans route(4). Du fait du caractère privé de ces protocoles, un logiciel comme Quagga doit gérer de nombreux cas différents pour communiquer avec le noyau et une carte d'interface d'un Cisco ne peut pas être mis dans un Juniper : même si elles étaient matériellement compatibles, la carte ne pourrait pas communiquer avec le routing engine, faute d'un protocole commun.

D'où l'idée d'un protocole normalisé de façon à ce que, comme le dit le RFC, A standard set of mechanisms for connecting these components provides increased scalability and allows the control and forwarding planes to evolve independently, thus promoting faster innovation.. Notre RFC est le cahier des charges de ce futur système.

Que dit-il ? Il définit dans sa section 2 un vocabulaire standard, avec les notions de Network Element (NE) (une machine complète, vue de l'extérieur comme une entité unique), Forwarding Element (FE) (un dispositif qui sert à faire suivre les paquets) et Control Element (CE) (un dispositif qui sert à gérer les protocoles de routage). Le système ForCES concernera la communication entre FE et CE, communication qui ne passera pas forcément par IP.

ForCES conviendrait aussi bien à des cas où les éléments sont dans une même boite (cas des routeurs actuels), avec transport des messages ForCES sur le bus interne, qu'au cas où les éléments sont physiquement séparés, avec transport des messages ForCES sur TCP/IP et Ethernet.

Ensuite, la section 5 explique la nécessité de développer un modèle pour les entités gérées par ForCES. En effet, il existe de nombreuses sortes de routeurs, ayant des capacités très différentes. Pour que les FE et CE puissent se parler, il faut qu'il existe un modèle de leurs capacités, pour qu'ils puissent savoir quoi attendre de l'autre.

Enfin la section 6 décrit les exigences pour le protocole lui-même.

ForCES permettrait de résoudre le problème des routeurs Unix actuels : ils tournent typiquement sur PC, une machine qui convient parfaitement comme CE mais qui est faible en FE. La partie la plus politiquement sensible, le CE, pourrait être en logiciel libre et sous-traiter le routage effectif à des ASIC ou à des boîtiers spécialisés, situées hors du PC.

À l'heure d'aujourd'hui, bien que très avancés, les textes qui normaliseront le modèle et le protocole ForCES sont toujours à l'état d'Internet-Drafts. Le travail s'est révélé très, peut-être trop ambitieux. Seul est sorti le RFC 3746, qui n'est encore qu'un description assez générale de l'architecture.

Ce RFC, et les deux suivants, 3651 et 3652, décrivent le protocole Handle, qui est à la base du système DOI (Digital Object Identifier), système qui bénéficie d'un marketing très actif. Le 3650 donne une vision générale de Handle, le 3651 décrit le nommage et le 3652 le protocole concret.

Il existe de nombreux systèmes pour désigner un objet sur Internet. Le DNS (RFC 1034 et RFC 1035) est le plus connu, les URL du Web (Uniform Resource Locators, RFC 1738), qui s'appuient sur le DNS, sont les plus visibles dans le monde réel, mais il y a aussi LDAP (Lightweight Directory Access Protocol, RFC 3377) et bien d'autres.

Handle fait partie de ces mécanismes de désignation. Il concurrence le DNS par certains aspects et les URL par d'autres. La motivation principale pour remplacer les URL est leur manque de permanence (un URL change trop facilement et il est trop concret, trop lié à une localisation) et la motivation principale pour remplacer le DNS semble être le désir d'inventer un nouveau protocole, qui n'aurait pas à supporter l'héritage, notamment administratif (le système de l'IANA et des registres actuels) du DNS.

Handle se passe donc du DNS. Les identifiants Handle ressemblent à doi:10.1340/309registries ou à hdl:cnri.dlib/december95. Ils sont résolus par une infrastucture technique qui est distincte, avec ses propres serveurs. Le logiciel client doit connaitre ce protocole Handle (il existe un plugin pour MS Internet Explorer, par exemple).

L'enthousiasme de ses promoteurs leur fait parfois frôler les bornes. Contrairement à ce qu'ils laissent entendre, le DNS peut faire tout ce que fait Handle, à condition d'utiliser tout le DNS, par exemple les enregistrements SRV (RFC 2782).

Une autre alternative à Handle pourrait être un des membres de la grande famille des URI (Uniform Resource Identifiers, RFC 3305) comme les URN (Uniform Resource Names, voir le RFC 8254 pour un exemple : ISBN:0-395-36341-1).

C'est en raison de l'existence d'autres systèmes, moins "séparatistes", que l'IESG a ajouté une note d'avertissement au RFC 3650, indiquant que l'IETF n'approuvait pas vraiment ce protocole.

Les options DHCP IPv6 normalisées dans ce RFC permettent au serveur DHCP d'envoyer au client la liste des résolveurs (serveurs récursifs) DNS (ainsi que les domaines à utiliser pour les fonctions de recherche).

Il existe trois moyens d'indiquer à une machine IPv6 quels sont les résolveurs DNS à interroger (ceux qui, sur Unix, seront mis dans /etc/resolv.conf). Le premier moyen est statique, c'est la configuration manuelle de la machine. Les deux autres sont dynamiques. L'un utilise les RA (Router Advertisement, RFC 4862), en y ajoutant les options normalisées dans le RFC 6106. L'autre utilise DHCP pour IPv6 (RFC 3315), plus les options de notre RFC 3646. Le choix entre les deux derniers moyens dépend des capacités des clients IPv6 du réseau local et aussi de questions de goût.

La première option (section 3 du RFC) permet d'indiquer les résolveurs (ou serveurs récursifs). Elle a le code 23 (dans le registre IANA) et sa valeur est une liste d'adresses IPv6, sur lesquelles écoute un résolveur DNS.

La seconde option (section 4 du RFC) est une liste de domaines dans lesquels chercher le nom indiqué par l'utilisateur (s'il tape ping foobar et que la liste comprend example.org et internautique.fr, on essaiera foobar.example.org, puis foobar.internautique.fr). Son code est 24. À noter que le comportement d'un résolveur en présence d'une telle liste de recherche (option search dans /etc/resolv.conf si on est sur Unix) est mal spécifié et que des surprises sont fréquentes (cf. RFC 1535, notamment sa section 6).

Comme avec toute utilisation de DHCP, il n'y a aucune sécurité (section 6) : un serveur DHCP malveillant peut diriger les pauvres clients vers des résolveurs menteurs, par exemple. Notre RFC conseille l'utilisation de l'authentification DHCP (RFC 3315, section 21), qui ne semble pas déployée, ni même mise en œuvre dans les clients et serveurs courants. (Elle a même été abandonnée, dans le RFC 8415.)

Ce RFC est l'héritier d'une longue lignée de RFC sur les MIB spécifiques à Ethernet. Au fur et à mesure que le protocole Ethernet progresse, les RFC sont mis à jour. Son prédécesseur immédiat était le RFC 2665, lui même issu du RFC 1650.

La MIB standard MIB-2 ne commence qu'à la couche 3. D'autres RFC la complètent donc, ici avec des informations spécifiques à Ethernet.

Par exemple, on voit ici avec snmpwalk une portion de cette MIB sur un commutateur HP Procurve :

...
SNMPv2-SMI::transmission.7.2.1.8.83 = Counter32: 0
SNMPv2-SMI::transmission.7.2.1.8.84 = Counter32: 671028
SNMPv2-SMI::transmission.7.2.1.8.85 = Counter32: 0
...

La donnée transmission.7.2.1.8 est dot3StatsLateCollisions, qui indique le nombre de collisions tardives (se produisant alors que le délai maximal de transmission est dépassé). Notre RFC décrit cette information ainsi :

       dot3StatsLateCollisions OBJECT-TYPE
           SYNTAX      Counter32
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION "The number of times that a collision is
                       detected on a particular interface later than
                       one slotTime into the transmission of a packet.

                       A (late) collision included in a count
                       represented by an instance of this object is
                       also considered as a (generic) collision for
                       purposes of other collision-related
                       statistics.

                       This counter does not increment when the
                       interface is operating in full-duplex mode.

                       Discontinuities in the value of this counter can
                       occur at re-initialization of the management
                       system, and at other times as indicated by the
                       value of ifCounterDiscontinuityTime."
           REFERENCE   "[IEEE 802.3 Std.], 30.3.1.1.10,
                       aLateCollisions."
           ::= { dot3StatsEntry 8 }

On voit ici que le port 84 a un problème, le nombre de collisions tardives est très élevée.

On peut aussi consulter la MIB dans une version plus jolie.

Ce RFC n'est pas mis en œuvre dans Net-SNMP, l'agent SNMP le plus utilisé sur Unix.

On peut en IPv6 déléguer un préfixe d'adresse IP d'un routeur à un autre routeur. Par exemple, le routeur du FAI peut, via DHCP, déléguer au routeur CPE le préfixe que celui-ci annoncera ensuite en RA (Router Advertisement) sur le réseau local. Ce RFC a depuis été intégré au RFC 8415.

Vous verrez rarement cette option DHCP (DHCP est dans le RFC 3315) sur vos réseaux locaux. Son utilité principale est au sein du réseau d'un FAI, pour distribuer aux clients, non pas uniquement des adresses (comme on le fait en IPv4, où il n'y a pas assez d'adresses pour attribuer des préfixes), mais des préfixes entiers. Notez qu'il s'agit bien de délégation : le routeur qui reçoit un préfixe peut en faire ce qu'il veut, y compris le sous-déléguer en préfixes plus petits (les réseaux locaux n'ont pas forcément qu'un seul lien, ils peuvent être multiples, cf. RFC 7368). Cette option de délégation de préfixe est donc utile pour tous les cas où le routeur qui délègue (le déléguant, le serveur DHCP) ne connait pas la topologie du réseau chez le routeur qui reçoit la délégation (le requérant, le client DHCP) et ne peut donc pas attribuer les préfixes à chaque sous-réseau. Elle suit les exigences posées dans le RFC 3769, le cahier des charges de cette option.

Bien sûr, une autre solution serait une délégation manuelle (envoyer le préfixe par courrier au client et attendre qu'il le configure dans son routeur CPE) mais cette méthode dynamique rend beaucoup plus facile une future renumérotation.

Donc, si vous voulez le modèle général de fonctionnement, regardez la section 5 : le routeur déléguant a un certain nombre de préfixes IP à distribuer, le routeur requérant, demande en DHCP un ou plusieurs préfixes, le déléguant lui répond avec les préfixes attribués. Chaque préfixe a une durée de vie associée et le requérant devra donc demander un renouvellement.

La délégation de préfixe est indépendante de celle d'adresse. Le routeur client peut utiliser DHCP pour avoir adresse et préfixe, ou bien seulement pour l'adresse ou seulement pour le préfixe.

Les préfixes ainsi délégués ne sont pas liés à une interface réseau particulière, au sens où les adresses réseau le sont, et le routeur client, qui a reçu la délégation, peut l'utiliser sur d'autres interfaces que celle où il l'a reçue.

Maintenant, le format des options. Pour le comprendre, il faut dire un mot de la notion d'IA_PD (section 3 du RFC). Une IA_PD (Identity Association for Prefix Delegation) est un ensemble de préfixes IP gérés collectivement. Le routeur requérant ne reçoit pas un seul préfixe mais une ou plusieurs IA_PD, chacune pouvant comporter plus d'un préfixe. Chaque IA_PD est associée à un IAID, qui est un identificateur unique pour le routeur requérant, et qui lui permet d'avoir plusieurs IA_PD (par exemple si deux de ses interfaces sont connectées à des FAI différents).

En section 9, le format des messages DHCP. L'option IA_PD (code 25 dans le registre IANA des options DHCP) est envoyée par le routeur requérant dans sa question (message Solicit, cf. RFC 3315, section 17.1, pour dire qu'il veut des préfixes) et par le routeur déléguant dans sa réponse (message Advertise, cf. RFC 3315, section 17.2, pour indiquer les préfixes délégués). Dans les deux cas, elle comprend l'IAID (un nombre sur quatre octets choisi par le requérant), et une série d'options parmi lesquelles se trouvent les options IAPREFIX (code 26) qui contiennent les préfixes IP et leurs durées de vie. Dans la requête, il peut évidemment n'y avoir aucun préfixe (le routeur requérant demande mais ne propose rien). Chaque option IAPREFIX contient un seul préfixe mais il peut y avoir plusieurs options de ce type dans une option IA_PD.

Autrefois, à l'époque du RFC 20, tout était simple, tous les textes étaient en anglais et n'avaient donc besoin que des quelques caractères d'ASCII. Mais le monde a changé, les étrangers ont voulu utiliser leurs langues bizarres et Unicode est apparu. Seul problème, les encodages d'Unicode n'étaient pas tout à fait adaptés aux spécificités du monde Internet, et voilà pourquoi un RFC a finalement été écrit pour apporter au monde... UTF-8.

Unicode permet de représenter toutes les écritures du monde. Une des particularités de ce jeu de caractères est qu'il sépare le jeu lui-même, la liste des caractères et leurs noms, de l'encodage en bits de ces caractères (voir mon exposé à JRES) . Un même texte en Unicode peut être encodé en UTF-16, UTF-32, Punycode et bien d'autres encore. Chacun de ces encodages a des avantages et des inconvénients. La démarche qui a mené à UTF-8 venait de l'importance donnée à certains critères :

• Compatibilité avec l'ASCII, et notamment avec toutes les bibliothèques existantes qui s'attendent à recevoir de l'ASCII (comme les fonctions de la libc sur Unix),
• Minimisation de l'occupation mémoire dans les cas des textes écrits avec l'alphabet latin.

UTF-8 est un encodage de taille variable : un caractères Unicode est représenté avec un nombre d'octets compris entre un et six. Sa principale particularité est qu'un caractère du jeu ASCII est représenté en UTF-8 comme en ASCII. Tout fichier ASCII est donc un fichier UTF-8 (l'inverse n'étant évidemment pas vrai). De même, tout caractère dont le bit de plus fort poids est à zéro est forcément un caractère ASCII, ce qui permet d'utiliser la libc (qui s'attend à trouver des chaînes de caractères terminées par le caractère NUL).

Le support d'UTF-8 dans les logiciels aujourd'hui est variable : excellent dans les navigateurs Web, il est assez bon dans les SGBD (voir par exemple PostgreSQL), moyen dans les éditeurs et parfois absents de certains outils de base (comme le générateur d'analyseurs lexicaux Lex). C'est ainsi que certains utilisateurs ont du mal à passer à UTF-8.

Dans certains langages de programmation, comme Python ou Perl, manipuler de l'Unicode (et, entre autre, lire et écrire de l'UTF-8) est aujourd'hui très simple alors que d'autres comme Haskell, Ruby, C ou PHP n'y sont pas encore vraiment.

Normalisé à l'origine dans le RFC 2044, UTF-8 est devenu le « nouvel ASCII ». Suivant le RFC 2277, presque tous les protocoles Internet qui manipulent de l'Unicode y font référence (la principale exception étant IDN, qui préfère l'encodage Punycode décrit dans le RFC 3492).

Pendant longtemps, le seul protocole standard d'authentification entre un NAS et sa base d'utilisateurs était Radius. Diameter, normalisé dans notre RFC, vise à le remplacer, et est bien plus riche en fonctions. Ce RFC était le premier sur Diameter, il a été remplacé depuis par le RFC 6733.

Traditionnellement, lorsqu'un client PPP ou d'un protocole similaire se connecte à son FAI, sa session est terminée sur un NAS, équipement qui ne possède en général pas de base des utilisateurs autorisés. Il y a plusieurs raisons à cela, comme le fait que le NAS n'est en général pas un ordinateur généraliste, il a peu de moyens, notamment en place disque ou bien comme le fait qu'un FAI a typiquement plusieurs NAS (au moins un par POP), et qu'il souhaite centraliser l'authentification. (Dans le monde 802.11, le NAS est typiquement nommé AP (Access Point.)

Le mécanisme habituel est donc que le NAS soit client d'un protocole d'authentification et que le FAI gère un serveur de ce protocole, serveur qui connaitra les utilisateurs autorisés. Le même protocole assure en général également des fonctions de comptabilisation des accès, d'où le sigle AAA (Authentication, Authorization and Accounting). Le premier protocole standard en ce sens est Radius (RFC 2865), que Diameter vise à remplacer. (Un protocole privé, Tacacs, qui sera documenté dans le RFC 1492, avait également été utilisé.)

Que reproche Diameter à Radius ? La section 1 de notre RFC détaille les faiblesses de Radius perçues par les auteurs de Diameter. Une analyse plus détaillée figure dans le RFC 3169 :

• Utilisation d'UDP, protocole de transport n'assurant pas de fiabilité,
• Pas de mécanisme de redondance standard,
• Limites de taille pour certains paramètres (par exemple la longueur d'un attribut n'est codée que sur un octet, ce qui limite les attributs à 256 caractères).

Diameter est donc plus riche et plus complexe que Radius.

Diameter reprend aussi plusieurs idées de Radius comme le codage en doublets Attribut / Valeur (AVP pour Attribute-Value Pairs) ou comme l'utilisation des NAI du RFC 7542 pour coder l'identité vérifiée.

Le RFC est donc bien plus long et compliqué que son équivalent Radius. La section 1 introduit le protocole, et ses usages, et le compare aux exigences listées dans le RFC 2989..

La section 2 précise le protocole, par exemple le mécanisme de transport fait l'objet de la sous-section 2.1, qui impose au minimum TCP et SCTP (les détails sont dans le RFC 3539). Diameter écoute par défaut sur le port 3868. La 2.4 introduit le nouveau concept d'Application Identifier, valeur enregistrées auprès de l'IANA qui identifie un usage particulier de Diameter (plus riche que Radius, Diameter permet davantage d'usages). Par exemple, l'usage en tant que service d'authentification pour un NAS (Application Identifier n° 1) n'est pas dans le cœur du protocole, il est délégué au RFC 4005. D'autres RFC décrivent des applications de Diameter comme le RFC 4740 qui parle de son usage pour SIP. 2.5 parle de la différence entre connexions et sessions, une connexion étant un concept de la couche 4 alors qu'une session Diameter peut impliquer plusieurs connexions. En 2.8, on trouve le bestiaire des agents Diameter, les clients et les serveurs bien sûr mais également les relais ou bien les traducteurs, pour parler à des agents d'autres protocoles, notamment Radius.

La section 3 décrit l'en-tête des paquets Diameter et les codes de commande qu'ils contiennent comme Capabilities-Exchange-Request. Seuls les codes communs à toutes les applications sont définis dans la section 3.1, des codes aussi importants que AA-Request (demande d'authentification, l'équivalent du Access-Request de Radius) sont délégués à d'autres RFC (comme le RFC 4005).

En section 4, nous arrivons aux AVP eux-même, les doublets attributs-valeur qui portent l'information. On notera en 4.1 un concept désormais fréquent dans les protocoles réseaux, l'option Mandatory qui indique pour un AVP, s'il doit absolument être connu de l'implémentation (le dialogue Diameter avorte autrement) ou bien s'il peut tranquillement être ignoré, par exemple par une vieille implémentation qui ne connait pas ce nouvel AVP. La sous-section 4.3 décrit, entre autre, les URI Diameter, de plan aaa:, comme aaa://host.example.com:666:transport=stcp;protocol=diameter.

Les sections 5 à 8 spécifient les nombreuses machines à état qui doivent être mises en œuvre par les agents Diameter. Au contraire de Radius qui, comme le DNS, est purement requête/réponse, Diameter nécessite un vrai automate dans chaque agent.

La sous-section 5.2 explique comment un agent Diameter peut en trouver un autre. Avec Radius, la configuration (par exemple du serveur d'authentification) devait être manuelle. Avec Diameter, on peut utiliser SLP (RFC 2165) ou NAPTR combiné avec SRV (RFC 2782).

La section 13, sur la sécurité, est très stricte. On y notera qu'un agent Diameter doit disposer d'IPsec.

Une bonne introduction à Diameter a été publié en http://www.interlinknetworks.com/whitepapers/Introduction_to_Diameter.pdf. Il n'existe que deux implémentations de serveur Diameter en logiciel libre, Open Diameter et OpenBlox, et elles semblent peu maintenues.

Le bilan opérationnel de Diameter est mince : beaucoup plus complexe que Radius, il ne l'a pas réellement remplacé dans son secteur, l'authentification via un NAS. Diameter semble bien être une nouvelle victime de l'effet « Deuxième système ». (À noter qu'une deuxième version de Diameter est sortie, peu différente, dans le RFC 6733.)

La sécurité est désormais devenue une préoccupation constante de tous les administrateurs réseau et système. Elle concerne également les auteurs de logiciels. Mais les concepteurs de protocoles ne sont pas épargnés. L'IETF demande désormais à tout protocole conçu pour un déploiement sur l'Internet d'être impeccable, sur le plan de la sécurité, d'avoir prévu les attaques possibles, et les parades à utiliser. Pour éviter tout oubli, il est obligatoire, dans tout RFC, d'avoir une section Security considerations, qui contient l'analyse des questions de sécurité du protocole normalisé par ce RFC. Que mettre dans cette section ? C'est le but de ce RFC 3552 que de l'expliquer.

Ce RFC est donc une lecture indispensable pour l'auteur de RFC. Il porte toute l'autorité de l'IAB. Mais il est aussi un excellent tutoriel sur la sécurité sur l'Internet, notamment par son exposé des différents types d'attaques, et il est donc une lecture recommandée pour toute personne qui débute sur ce sujet. Elle y apprendra le vocabulaire et les concepts de base de la sécurité, qui font défaut à tant d'administrateurs aujourd'hui.

À quoi sert la section Sécurité des RFC, obligatoire depuis le RFC 2223 (section 9) ? Comme le rappelle la section 1 de notre RFC 3552, cette section Sécurité sert à s'assurer que les auteurs du protocole ont procédé à une analyse sérieuse de la sécurité de leur œuvre, et à informer les lecteurs des résultats de ladite analyse.

Bon, mais avant de prendre des mesures de sécurité, il faut mieux définir ce qu'est la sécurité. En avant pour la section 2, qui introduit la partie « tutoriel » du RFC. La sécurité est en fait un ensemble de propriétés diverses. On peut identifier deux catégories, la sécurité des communications et celles des systèmes qui communiquent.

La sécurité des communications est détaillée en section 2.1. Elle se subdivise entre trois sous-catégories, la confidentialité, l'intégrité des données et l'authentification du partenaire. La confidentialité est le fait que vos secrets restent secrets : personne ne doit pouvoir écouter vos communications. L'intégrité des données est le fait qu'on reçoit bien ce qui a été envoyé, aucun méchant n'a modifié ces données (un objectif très difficile à atteindre dans le monde numérique : contrairement au papier, les changements ne laissent pas de trace). Et l'authentification est le fait de s'assurer qu'on parle bien avec celui qu'on croit.

Ces trois propriétés sont liées : par exemple, sans authentification, la confidentialité est difficile à assurer (si Alice sécurise ses communications contre l'écoute, mais n'authentifie pas, qui sait si elle n'écrit pas à Ève en pensant écrire à Bob ? Auquel cas, ses précautions ne serviraient à rien.)

Une autre propriété qui ne rentre pas dans cette classification est la non-répudiation (section 2.2) qui est le fait de pouvoir prouver que le message a bien été émis.

La sécurité des systèmes est en section 2.3. Elle comprend entre autres :

• La protection contre l'usage non autorisé du système,
• La protection contre les usages inappropriés (les petites lettres dans les contrats qui limitent ce que vous avez le droit de faire),
• La protection contre les dénis de service, les attaques qui visent à empêcher tout usage de la machine.

Avec la section 3, on étudie cette fois les méchants, les agresseurs. Elle est consacrée à la modélisation des menaces. L'idée est qu'on ne peut pas se protéger contre tout (les meilleures protections contre le déni de service, par exemple, ne serviront pas si l'attaquant coupe physiquement le câble). La modélisation des menaces la plus courante sur l'Internet consiste à considérer que l'attaquant :

• N'a pas pris le contrôle d'une des deux machines qui communique (autrement, la défense devient quasi-impossible),
• Mais, en revanche, a un contrôle total du réseau qui les relie. Il peut lire n'importe quel paquet, en modifier et en fabriquer, y compris avec une adresse IP source qui n'est pas la sienne.

Il existe aussi des modèles de menaces plus limités (section 3.1) par exemple où l'attaquant est strictement passif : s'il peut lire n'importe quel paquet, il n'a pas la possibilité d'en créer ou d'en modifier. De telles attaques représentent une proportion non négligeable, dans le monde réel. (En sécurité des réseaux, Ève est un attaquant passif, Mallory un attaquant actif.)

La section 3.2 détaille donc ce que peut faire un attaquant passif. Les attaques passives nécessitent d'être quelque part sur le chemin entre les deux partenaires (section 3.5 pour cette notion d'« être sur le chemin »), par exemple parce qu'on est sur le même réseau Wifi (réseau partagé, voir aussi section 3.6) qu'une des deux machines qui communiquent, ou bien parce qu'on contrôle un routeur sur le chemin (beaucoup de routeurs sont mal protégés). Dans ces conditions, l'attaquant passif peut :

• Écouter les communications,
• Capturer des mots de passe (par exemple avec l'excellent outil dsniff),
• Faire, avec les données capturées, des attaques hors-ligne, par exemple en cryptanalysant.

Passons aux attaques actives. La section 3.3 leur est consacrée. Un attaquant actif peut fabriquer des paquets IP quelconques (en théorie, les FAI ne devraient pas laisser passer les paquets ayant une adresse IP source usurpée, mais le RFC 2827 est bien peu déployé). Il ne peut pas toujours recevoir la réponse (qui ira à celui dont il a usurpé l'adresse) mais certaines attaques, dites aveugles, sont malgré tout possibles dans ce cas.

Parmi les autres attaques possibles, il y a le rejeu (section 3.3.1) où l'attaquant réemet un paquet qu'il a déjà vu (sans même le comprendre, par exemple si le message déclenche un retrait bancaire, et que le protocole n'a pas de protection contre le rejeu, on voit ce qu'il peut advenir), la modification de message (section 3.3.4) ou l'homme du milieu où Janus, se plaçant entre Alice et Bob, se fait passer pour Bob auprès d'Alice et pour Alice auprès de Bob (et relaie les messages, pour qu'Alice et Bob ne s'aperçoivent de rien).

Maintenant, arrivé à ce stade, on connait les agresseurs et leurs capacités. Il existe évidemment de nombreuses défenses possibles mais toutes ne sont pas bonnes, loin de là. La section 4 doit donc lister des questions fréquentes, communes à beaucoup de protocoles. Par exemple, pour l'authentification des utilisateurs (section 4.1), notre RFC rappelle les forces et les faiblesses des différents mécanismes, comme le traditionnel mot de passe (désormais interdit dans les protocoles IETF, sauf si le canal est protégé par la cryptographie, le risque de sniffing étant trop élevé autrement) ou les certificats (RFC 5280), qui peuvent être également utilisés pour authentifier une machine.

En fait, concevoir un protocole sûr est une tâche tellement complexe, avec tellement de possibilités d'erreur (et, en sécurité, les erreurs ne se voient pas, avant qu'elles ne soient exploitées), que la meilleure solution est souvent... de ne pas le faire, mais de compter sur un cadre générique (section 4.2) comme SASL (RFC 2222) pour l'authentification. En disant simplement « Pour l'authentification, on utilise SASL », l'auteur de protocole prudent peut ainsi s'appuyer sur un cadre solide et prouvé. Ceci dit, rien n'est jamais simple en sécurité et le RFC 3552 rappelle que ces cadres génériques ont souvent une faiblesse, ils peuvent être victimes d'une attaque par repli, où un attaquant actif va essayer de faire en sorte qu'Alice et Bob n'utilisent pas la sécurité maximale, si d'autres sont disponibles. Bien sûr, tout protocole de sécurité où les paramètres sont négociables court ce risque mais il est plus élevé pour les cadres génériques car ils encouragent le développeur du protocole à ne pas trop réfléchir aux détails.

La section 4.4 rappelle la différence entre authentifier et autoriser (le premier permet de vérifier une identité, le second de déterminer si une entité donnée a le droit de faire telle action).

Comment fournir des communications sécurisées entre deux machines ? Un protocole donné a deux solutions, fournir lui-même cette sécurité ou bien s'appuyer sur un protocole de sécurité généraliste. Ainsi, le DNS se protège contre les modifications en transit par la signature des enregistrements (DNSSEC, RFC 4033), la première solution, celle d'une sécurité fournie par le protocole. Par contre, HTTP délègue en général sa sécurité à un protocole générique, TLS (RFC 5246 et RFC 2818 pour l'adaptation spécifique à HTTP), ce qui est la deuxième solution. La section 4.5 de notre RFC discute ces deux solutions et donne des exemples.

Par exemple, le mécanisme le plus générique est IPsec (RFC 4301). Cette solution protège toute communication IP. Mais IPsec est peu déployé, et en général sous forme de VPN. Un inconvénient de la méthode VPN est qu'elle est invisible aux applications, ce qui rend difficile pour celles-ci de savoir si leurs communications sont protégées (et donc si elles peuvent employer un mot de passe classique). Le RFC demande donc que les auteurs de protocole ne tiennent pas pour acquise la disponibilité d'IPsec (une violation de cette règle se trouve dans le RFC 5340, qui a supprimé les possibilités d'authentification qui existaient dans les précédentes versions d'OSPF, pour imposer IPsec). Pourtant, le RFC rappelle qu'IPsec est obligatoire pour IPv6 (ce qui est de la pure réthorique, la plupart des implémentations d'IPv6 n'ont pas IPsec et, même quand il est implémenté, son activation reste facultative... et compliquée).

L'autre grand mécanisme générique de protection des communications est TLS (RFC 5246) qui travaille, lui, juste en dessous de la couche 7. Il ne protège donc pas contre, par exemple, des paquets TCP RST (ReSeT) faux. Notre RFC note qu'il existe deux façons d'utiliser TLS, avec un port spécial dédié (ce que fait HTTPS, avec son port 443) ou bien avec un démarrage de TLS une fois la connexion établie. À part HTTP, où le RFC 2817 n'a eu aucun succès, cette seconde méthode est la plus employée parmi les protocoles TCP/IP, sous le nom de STARTTLS. Son avantage est qu'elle permet de n'utiliser qu'un seul port et de négocier certains paramètres avant de lancer TLS et donc de choisir le certificat en fonction de critères comme le nom demandé (ce qui est utile en HTTP, autrement, avoir plusieurs certificats sur une même machine est complexe, cf. section 4.5.2.1). Son inconvénient principal est qu'elle peut ouvrir la voie à des attaques par repli, où Mallory essaie de convaincre Alice et Bob que TLS n'est pas possible, les amenant à ne pas sécuriser leur communication.

Les attaques par déni de service forment une classe entière d'attaques, très difficiles à combattre. Très fréquentes sur l'Internet aujourd'hui (un exemple est l'attaque contre les serveurs racine du DNS en février 2007), elles n'ont pas de solution générale, contrairement à la plupart des autres attaques où la cryptographie résout tous les problèmes techniques. La section 4.6 étudie cette menace et les approches possibles. Certaines attaques par déni de service sont brutales et sans subtilité, d'autres plus avancées comme les attaques SYN flood contre TCP. Il est parfois possible de modifier les protocoles pour les rendre moins vulnérables aux attaques subtiles. Par contre, pour les attaques par force brute, les seules protections restent le surdimensionnement des infrastructures (si c'est économiquement raisonnable) et la réaction a posteriori.

Parmi les variétés de DoS, le RFC signale l'attaque aveugle (comme le TCP SYN flood cité plus haut), où l'attaquant n'a même pas besoin de pouvoir recevoir les réponses. Mais il y a aussi la DoS distribuée où des dizaines ou des centaines de milliers de machine MS-Windows, devenues des zombies, coopèrent pour l'attaque.

Quant aux protections, elles reposent sur les principes suivants :

• Faire en sorte que l'attaquant aie plus de travail que vous (section 4.6.3.1) par exemple en demandant au client de résoudre des puzzles cryptographiques comme le fait HIP (RFC 5201). Cela ne protège pas contre les attaques distribuées, où l'ennemi a une énorme puissance de calcul à sa disposition.
• Obliger l'attaquant à montrer qu'il peut recevoir les réponses par exemple en générant aléatoirement un petit gâteau, un ensemble de bits que le partenaire va devoir transmettre verbatim, prouvant ainsi qu'il reçoit les réponses. Cela empêche les attaques aveugles et valide ainsi l'adresse IP source de l'attaquant. (Photuris, RFC 2522 utilise cette technique.)

Il y a une autre façon de voir les techniques de sécurité, c'est de séparer celles qui protègent le message et celles qui protègent le canal. Dans le premier cas, le message est protégé de bout en bout, quels que soient les intermédiaires. Dans le second, on ne protège qu'un échange entre deux machines, mais des intermédiaires ont pu lire et/ou modifier le message avant ou après le canal sécurisé. Par exemple, pour le DNS, DNSSEC fournit une protection de bout en bout, il protège le message. Même si un des serveurs de noms secondaires du domaine ou un serveur de noms récursif est sous le contrôle d'un attaquant, DNSSEC permettra de détecter une modification. Au contraire, DNSCurve ne protège que le canal. Si un serveur de noms récursif triche, DNSCurve ne protège pas (le point n'est pas mentionné sur le site Web de DNSCurve, ce qui n'est pas étonnant, l'honnêteté intellectuelle n'ayant jamais été le fort de djb). Autre exemple, avec le courrier électronique, PGP (RFC 4880) sécurise le message (et il est donc protégé contre la lecture non autorisée ou la modification, quels que soient le comportement des serveurs intermédiaires) alors que SMTP + TLS (RFC 3207) ne protège qu'un canal (alors que le courrier est relayé, stocké, etc). Le RFC note que la distinction entre protection du message et protection du canal dépend de la couche qu'on regarde. Au niveau IP, chaque paquet est un message et donc IPsec peut dire que, au niveau 3, il sécurise le message alors que, au niveau 7, les applications considèrent qu'IPsec ne sécurise que le canal. Et il y a des cas encore plus compliqués comme une page Web dont les différents composants ont été récupérés par des canaux différents.

Enfin, après toutes ses considérations sur la sécurité des réseaux en général et de l'Internet en particulier, on arrive avec la section 5 aux prescriptions sur la section Security considerations des futurs RFC. Que faut-il y mettre ? Les auteurs doivent indiquer :

• quelles attaques sont exclues par l'analyse de sécurité (et pourquoi !)
• quelles attaques sont inclues dans l'analyse et, pour chacune, si le protocole est protégé contre cette attaque ou pas.

Le RFC doit également inclure un modèle des menaces, s'appliquant à l'Internet entier (pas uniquement à un réseau local déconnecté du reste du monde). Un exemple que donne le RFC concerne l'authentification traditionnelle Unix via le mot de passe et les fichiers /etc/passwd et /etc/shadow et un texte possible serait quelque chose du genre « La sécurité du système repose sur la difficulté à deviner le mot de passe et à écouter le réseau lorsque le mot de passe circule. La divination du mot de passe est possible hors-ligne avec des programmes comme Crack (surtout si la longueur du mot est limitée à huit caractères) et l'écoute est possible dès que le mot de passe est utilisé en clair, par exemple par telnet. »

Enfin, la section 6 fournit des exemples de « bonnes » sections Sécurité, tirées de RFC réels comme le RFC 2821 (avec des ajouts mis par le RFC 3552 pour traiter des problèmes que le RFC 2821 avait négligé) ou comme le RFC 2338, là encore avec quelques ajouts (le RFC 2338 oubliait de dire explicitement que la confidentialité n'était pas un but).

Deuxième pilier, après SIP (RFC 3261), de la téléphonie sur IP à normes ouvertes, RTP assure le transport des données temps-réel sur Internet.

SIP se charge de l'établissement de la session et, une fois que la communication est établie, c'est au tour de RTP de porter les données.

RTP n'est pas spécifique à la téléphonie : il peut servir à d'autres applications multimédia, voire à des applications très éloignées de ce domaine. RTP n'est pas un protocole complet, plutôt un cadre (framework) pour spécifier des protocoles : toute utilisation concrète doit faire l'objet de spécifications plus détaillées comme le profil Audio and Video Conferences décrit dans le RFC 3551. Malgré cette limitation, notre RFC est un des gros, avec plus de cent pages.

Enfin, RTP est en fait composé de deux protocoles, RTP à proprement parler et le RTCP (RTP control protocol), qui sert à transmettre les méta-informations sur la session en cours.

On notera que RTP fonctionne sur UDP, s'il avait été créé plus récemment, il aurait pu utiliser DCCP (RFC 4340, qui contient une explication détaillée sur la façon dont RTP pourrait utiliser les services de DCCP).

La page Web d'un des auteurs de RTP donne plein d'informations sur le protocole et ses mises en œuvres.

Parmi les nombreux travaux de l'IETF liés à l'internationalisation, ce RFC jouait un rôle ingrat mais utile, celui de fixer le vocabulaire. (Il a depuis été remplacé par le RFC 6365.)

Le domaine de internationalisation est difficile pour beaucoup de gens. Depuis de nombreuses années qu'il fait l'objet de travaux actifs, on lit encore des énormités comme « Internet multilingue » (qui ne veut rien dire) ou des confusions entre langue et écriture. D'où l'importance de bien fixer le vocabulaire et les définitions, faisant de ce RFC (ou de son successeur, le RFC 6365) une lecture indispensable pour tous ceux qui veulent que toutes les langues puissent être utilisées sur Internet.

Ce RFC est le compte-rendu d'un atelier de l'IAB consacré à la gestion de réseaux.

Notre RFC résume les travaux et conclusions d'un atelier qui a réuni des auteurs de protocoles IETF et des opérateurs qui déploient et gèrent ces protocoles.

L'IETF a plusieurs protocoles liés à la gestion de réseau. Il y a bien sûr l'inusable SNMP dont la version 1, spécifiée dans le RFC 1157 est, bien qu'officiellement classé comme « historique » toujours très utilisé. Il y a aussi les moins connus CIM (RFC 3060) et COPS (RFC 2748).

Logiquement, l'atelier a commencé par lister les techniques de gestion actuellement utilisées :

• SNMP est très fréquent. Excellent pour surveiller un système, il est nettement moins adapté pour le configurer (les MIB standard ont peu d'objects permettant l'écriture et même les MIB privées n'en fournissent pas assez) ou pour la récupération de grandes quantités de données (comme une table de routage).
• Tous les équipements réseau sérieux ont un CLI, accessible via telnet ou, de plus en plus souvent, via SSH. Très pratique pour l'automatisation ou la gestion de grandes quantités d'équipement (par exemple avec Rancid) mais complètement non standardisé. (C'est l'occasion de relire In the beginning was the command-line.)
• Beaucoup d'équipements réseau ont une interface Web, avec HTTP et HTML. Elle ne convient guère à la gestion de réseaux, puisqu'elle est difficilement automatisable.
• Au moment de cet atelier, certains commençaient à expérimenter avec des protocoles bâtis sur XML pour gérer les équipements réseaux. Depuis, le protocole Netconf a été défini, dans le RFC 4741.

Les opérateurs ont alors formulé (section 3) leurs demandes : des protocoles permettant la gestion en masse des équipements (et, idéalement, permettant de configurer le réseau, plutôt que chaque équipement isolément). Cela implique, par exemple, l'utilisation de protocoles « texte » permettant d'utiliser des outils comme diff. À noter qu'aucun RFC n'explicite ces demandes.

Le protocole SNMP a fait l'objet d'une étude particulière pendant l'atelier, vue son important déploiment, malgré les problèmes notées plus haut.

Ces remarques et discussions ont menées aux observations consignées dans la section 5 de notre RFC. Les principales :

• Il serait bon d'avoir un langage commun pour la configuration des équipements réseau. Il devrait permettre de sauvegarder et recharger la configuration complète du routeur ou du commutateur.
• SNMP, quels que soient ses défauts, n'est pas près de disparaitre.

Se basant sur tout ce travail, les participants à l'atelier recommandent notamment, dans la section 6 :

• D'abandonner la règle de fournir des MIB SNMP permettant l'écriture,
• De normaliser le protocole de configuration et de le bâtir sur XML (ce qui a donné Netconf, défini, dans le RFC 4741).

IMAP, protocole d'accès distant à des boîtes aux lettres n'est pas juste un protocole, c'est tout un écosystème, décrit dans de nombreux RFC. Celui-ci est le socle de la précédente version d'IMAP, « rev1 », depuis remplacée par la « rev2 » du RFC 9051.

Les protocoles traditionnels du courrier électronique, notamment SMTP ne permettaient que d'acheminer le courrier jusqu'à destination. Pour le lire, pendant longtemps, la seule solution était d'accéder directement aux fichiers où étaient stockés les messages. Cette possibilité existe toujours mais le monde du courrier s'est enrichi de nouvelles fonctions, comme le stockage du courrier dans une base de données relationnelle ou comme la récupération du courrier à distance, en mode client/serveur. Pour cette récupération, le premier protocole a été POP, dans le RFC 918 (aujourd'hui dans le RFC 1939). Et le plus courant est aujourd'hui IMAP, qui fait l'objet de notre RFC, qui remplace le RFC 2060.

POP est simple, très simple. Il est parfait lorsqu'on veut simplement télécharger les messages sur son poste. IMAP fonctionne sur un modèle différent, où les messages ont plutôt vocation à rester sur le serveur, et où les clients peuvent, non seulement les récupérer mais aussi les classer, les détruire, les marquer comme lus, etc. Certaines de ces possibilités existaient déjà avec POP mais étaient peu utilisées. IMAP permet au contraire, via ses nombreux RFC, de tout faire à distance.

IMAP est donc un protocole complexe et notre RFC annonce la couleur en disant qu'il est une norme, pas un tutoriel. Pour apprendre IMAP, il vaut mieux ne pas commencer par le RFC. (La lecture du RFC 2683 est recommandée aux implémenteurs.)

Pourtant, le principe de base est simple. IMAP est client/serveur. Le client se connecte en TCP au serveur, et envoie des commandes sous forme de texte, comme avec SMTP. Il s'authentifie avec la commande LOGIN, choisit une boîte aux lettres avec la commande SELECT, récupère un message avec la commande FETCH. Voici un exemple de session. Notons tout de suite que chaque commande est précédée d'une étiquette (tag, voir la section 2.2.1 du RFC) qui change à chaque commande et qui permet d'associer une réponse à une commande, IMAP permettant d'envoyer plusieurs commandes sans attendre de réponse). Ici, le serveur utilise le logiciel Archiveopteryx :

% telnet imap.example.org imap     
Trying 192.0.2.23...
Connected to imap.example.org.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN COMPRESS=DEFLATE ID LITERAL+ STARTTLS] imap.example.org Archiveopteryx IMAP Server
com1 LOGIN stephane vraimentsecret
com1 OK [CAPABILITY IMAP4rev1 ACL ANNOTATE BINARY CATENATE CHILDREN COMPRESS=DEFLATE CONDSTORE ESEARCH ID IDLE LITERAL+ NAMESPACE RIGHTS=ekntx STARTTLS UIDPLUS UNSELECT URLAUTH] done
com2 SELECT INBOX
* 189 EXISTS
* 12 RECENT
* OK [UIDNEXT 1594] next uid
* OK [UIDVALIDITY 1] uid validity
* FLAGS (\Deleted \Answered \Flagged \Draft \Seen)
* OK [PERMANENTFLAGS (\Deleted \Answered \Flagged \Draft \Seen \*)] permanent flags
com2 OK [READ-WRITE] done

Pour tester son serveur IMAP, on peut aussi utiliser fetchmail et lui demander d'afficher toute la session avec -v -v :

 % fetchmail -v -v -u MYLOGIN imap.1and1.fr 
Enter password for MYLOGIN@imap.1and1.fr: 
fetchmail: 6.3.6 querying imap.1and1.fr (protocol auto) at Tue Apr 15 12:00:27 2008: poll started
fetchmail: 6.3.6 querying imap.1and1.fr (protocol IMAP) at Tue Apr 15 12:00:27 2008: poll started
Trying to connect to 212.227.15.141/143...connected.
fetchmail: IMAP< * OK IMAP server ready H mimap3 65564
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ ID STARTTLS CHILDREN QUOTA IDLE NAMESPACE UIDPLUS UNSELECT SORT AUTH=LOGIN AUTH=PLAIN
fetchmail: IMAP< A0001 OK CAPABILITY finished.
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: IMAP> A0002 STARTTLS
fetchmail: IMAP< A0002 OK Begin TLS negotiation.
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Premium Server CA
fetchmail: Server CommonName: imap.1and1.fr
fetchmail: imap.1and1.fr key fingerprint: 93:13:99:6A:3F:23:73:C3:00:37:4A:39:EE:22:93:AB
fetchmail: IMAP> A0003 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ ID CHILDREN QUOTA IDLE NAMESPACE UIDPLUS UNSELECT SORT AUTH=LOGIN AUTH=PLAIN
fetchmail: IMAP< A0003 OK CAPABILITY finished.
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: imap.1and1.fr: upgrade to TLS succeeded.
fetchmail: IMAP> A0004 LOGIN "m39041005-1" *
fetchmail: IMAP< A0004 OK LOGIN finished.
fetchmail: selecting or re-polling default folder
fetchmail: IMAP> A0005 SELECT "INBOX"

IMAP a des fonctions plus riches, notamment la possibilité de chercher dans les messages (section 6.4.4 du RFC), ici, on extrait les messages de mai 2007, puis on récupère le sujet du premier message :

com10 SEARCH since 1-May-2007 before 31-May-2007
* SEARCH 12
com10 OK done
com11 FETCH 1 (BODY.PEEK[HEADER.FIELDS (SUBJECT)])
* 1 FETCH (BODY[HEADER.FIELDS (Subject)] {17}
Subject: Rapport sur les fonctions de vue dans Archiveopteryx

)
com11 OK done

IMAP est mis en œuvre dans de nombreux serveurs comme Dovecot, Courier, ou Archiveopteryx, déja cité.

Côté client, on trouve du IMAP dans beaucoup de logiciels, des webmails comme SquirrelMail, des MUA classiques comme mutt, des MUA en ligne de commande comme fetchmail, très pratique pour récupérer son courrier.

Il existe également des bibliothèques toutes faites pour programmer son client IMAP à son goût comme imaplib pour Python. Voici un exemple d'un court programme Python qui se connecte à un serveur IMAP, sélectionne les messages d'avril 2007 et les récupère. On note que la bibliothèque a choisi de rester très proche du vocabulaire du RFC :

import imaplib

connection = imaplib.IMAP4()
connection.login("stephane", "thisissecret")
connection.select() # Select the default mailbox
typee, data = connection.search(None,
                                '(since "1-Apr-2007")', 
                                '(before "1-May-2007")')
for num in data[0].split():
    # Fetches the whole message
    typ, data = connection.fetch(num, '(RFC822)')
    print 'Message %s\n%s\n' % (num, data[0][1])
connection.close()
connection.logout()

A priori, l'IETF ne normalise pas d'API (et c'est pour cela que ce RFC n'a que le statut de « pour information »), se limitant aux « bits qu'on voit passer sur le câble ». Mais le monde de la normalisation n'est pas toujours si simple et, à l'époque, il était important de publier rapidement une documentation sur la nouvelle API nécessaire aux applications pour faire de l'IPv6.

Les API Unix et réseaux sont typiquement gérées par l'IEEE, via sa norme POSIX. Mais POSIX n'est pas librement téléchargeable sur le réseau, ce qui limite son utilité. Pour cette raison et pour d'autres, l'IETF a donc publié ce RFC, dont on notera qu'un des auteurs est W. Richard Stevens, auteur de Unix network programming, le livre de référence sur le sujet. Il succède au RFC 2553 et est complété par un RFC sur l'interface « avancée », le RFC 3542.

Depuis leur apparition, les prises (socket dans la langue de Stevens) sont le principal mécanisme d'accès au réseau pour les programmes. Les programmes qui les utilisent sont relativement portables, bien au delà du système BSD où elles sont nées. Traditionnellement multi-protocoles, les prises ne permettaient néanmoins pas d'accéder à IPv6. C'est désormais le cas et l'interface décrite dans ce RFC est désormais largement présente (MacOS X a été le dernier système d'exploitation à la proposer).

Elle ne concerne que le langage C. Les autres langages disposent souvent de mécanismes de plus haut niveau que les prises comme les Streams de Java.

Idéalement, la plupart des applications ne devrait pas avoir besoin de savoir si elles utilisent IPv4 ou IPv6. Concentrée dans la couche Réseau, le protocole utilisé ne devrait pas concerner l'application. Mais C est un langage de bas niveau, et expose donc le protocole de couche 3 utilisé (même si la section 2 du RFC explique que l'API cherche à être la plus générale possible).

La section 2.1 résume les principaux changements qui ont été faits pour permettre l'utilisation d'IPv6. Ils incluent une nouvelle constante (section 3.1) pour indiquer les adresses IPv6 (AF_INET6, puisque AF_INET, comme son nom ne l'indique pas clairement, étant spécifique à IPv4) et une pour le protocole IPv6 (PF_INET6). Notons que le RFC documente aussi PF_UNSPEC, qui permet à l'application de dire qu'elle se moque du protocole utilisé (ce qui devrait être le cas le plus courant). Il y a bien sûr une nouvelle structure de données (section 3.3) pour placer les adresses IPv6, quatre fois plus grandes. Les sockaddr sont désormais des représentations de la prise, indépendantes de la famille d'adresses, les sockaddr_in6 étant spécifiques à IPv6. Elles contiennent :

struct sockaddr_in6 {
    sa_family_t     sin6_family;    /* AF_INET6 */
    in_port_t       sin6_port;      /* transport layer port # */
    uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */
    struct in6_addr sin6_addr;      /* IPv6 address */
    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
};

Les appels système sur les prises, décrits dans la section 3.5, eux, ont peu changés, socket, connect, bind, continuent comme avant.

Les sections 3.6. et 3.7 concernent l'interopérabilité avec IPv4. Le monde des applications a une forte inertie. Les développeurs, déjà très occupés, ne portent pas leurs applications vers la nouvelle interface instantanément. Ces deux sections expliquent donc comment assurer le recouvrement des deux protocoles. On notera qu'avec cette interface, pour faire un serveur qui écoute en IPv4 et IPv6, il faut créer une prise IPv6, les clients IPv4 recevront alors des adresses IPv4-mapped comme ::FFFF:192.0.2.24. Ce n'est pas très intuitif... (Heureusement, c'est plus simple pour un client.)

La section 6 du RFC parle des fonctions de bibliothèque pour effectuer les traductions de noms en adresses et réciproquement. L'ancienne gethostbyname, très spécifique à IPv4 et souffrant d'autres limitations, ne devrait plus être utilisée depuis des années (le nombre de programmes qui l'utilisent encore ou de tutoriels qui l'expliquent donne une idée de l'extrême inertie d'un secteur qui se prétend novateur et réactif). Les « nouvelles » fonctions getaddrinfo et getnameinfo (section 6.4) la remplacent. Un programme typique désormais fait :

char *server = "www.example.org";
char *port_name = "42";

int mysocket; 

/* addrinfo est défini dans netdb.h et inclus une "struct sockaddr"
(une prise, incluant l'adresse IP) dans son champ ai_addr. Sa
description figure dans la section 6.4 du RFC. */
struct addrinfo hints, *result;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;

error = getaddrinfo(server, port_name, &hints, &result);
if (error) {
          err_quit("getaddrinfo error for host: %s %s",
                   server, gai_strerror(error));
}
/* La première adresse IP sera dans result->ai_addr, pour les
suivantes, il faudra suivre result->ai_next */
mysocket = socket(...);
error = connect(mysocket, result->ai_addr, result->ai_addrlen);
...

Un des rares cas où un client réseau a besoin de manipuler des adresses IP (pas seulement de les stocker et de les passer d'une fonction à une autre) est lors de l'affichage, par exemple en mode bavard. Pour éviter que le programme ne doive connaitre les détails de syntaxe des adresses (celle d'IPv4 n'a jamais été normalisée, celle d'IPv6 est décrite dans le RFC 4291), notre RFC décrit en section 6.6 des fonctions de conversion de et vers un format texte, inet_ntop et inet_pton.

Enfin, la section 9 liste les différences avec son prédécesseur, le RFC 2553. Rien de très important ici.

L'inertie des programmeurs étant très forte, et celle des enseignants également, on peut parier, bien que le premier RFC sur le sujet soit vieux de onze ans, que beaucoup de cours de programmation réseaux sont encore donnés avec la vieille interface, qui ne marche qu'en IPv4... À l'appui de ce pari, notons que le service Code Search de Google trouve 255 000 occurrences de gethostbyname contre seulement 78 200 de getaddrinfo.

La norme IDNA, qui permet d'utiliser des caractères Unicode dans les noms de domaine, dépend de deux algorithmes spécifiés séparément, nameprep (RFC 3491) et Punycode (notre RFC), qui transforme une chaîne Unicode en un sous-ensemble d'ASCII, qui peut être utilisé dans des logiciels non-Unicode.

En effet, les applications qui gèrent des noms de machine sont tenues aux règles très restrictives du RFC 1123, qui limite ces noms à LDH, un sous-ensemble d'ASCII limité aux lettres, chiffres et au tiret. (Contrairement à ce qu'on lit souvent, cette restriction n'a rien à voir avec le DNS, qui accepte bien plus de caractères, depuis toujours.) La solution adoptée dans le cadre IDNA est donc d'encoder les caractères Unicode en Punycode, qui n'utilise que LDH. Punycode est donc un concurrent d'autres encodages d'Unicode, plus généralistes, comme UTF-8 ou UTF-7.

Punycode est spécifié en deux temps. Un algorithme général, Bootstring, présenté dans les sections 3 et 4, permet de mettre en correspondance une chaîne de caractères Unicode avec une chaîne de caractères écrite dans un sous-ensemble d'Unicode. Cet algorithme est paramétré par certaines variables, qui reçoivent ensuite en section 5 une valeur particulière, ces valeurs définissant le profil Punycode. Notons qu'à ma connaissance, il n'existe aucun autre profil de Bootstring. Donc, en pratique, il n'est pas trop gênant de confondre Bootstring et Punycode.

La section 1.1 de notre RFC détaille les propriétés de Bootstring. Il est complet (toute chaîne Unicode peut être représentée en Punycode mais notons qu'IDNA, la seule application de Bootstring aujourd'hui, interdit certains caractères comme les espaces). Et il est sans perte, toute chaîne Unicode encodée en Punycode peut être récupérée par un décodage (là encore, IDNA a un mécanisme de normalisation, nameprep - RFC 3491 - qui n'a pas cette propriété). Punycode est également compact, un gros avantage vue la limitation des labels DNS à 63 caractères.

Punycode n'est pas un algorithme très compliqué, le RFC est assez court (et une bonne partie est occupée par l'implémentation de référence). Mais il contient davantage d'algorithmique que beaucoup de RFC.

On l'a dit, la section 5 fixe les paramètres spécifiques à Punycode. Par exemple, le paramètre base est égal à 36 à cause de LDH (vingt-six lettres et dix chiffres, le tiret ayant un autre usage).

Passons maintenant à un exemple concret. Avec le code C inclus dans le RFC (un bel exemple de C ANSI, qui ne soulève aucune objection du sourcilleux compilateur GNU, même avec les options -Wall et -pedantic), convertissons le mot « café » en Punycode (ce programme ne lit les caractères Unicode que sous la forme U+nnnn) :

% gcc -o punycode punycode.c
% echo u+0063 u+0061 u+0066 u+00E9 | ./punycode -e 
caf-dma

Le mot d'origine étant essentiellement composé d'ASCII, on en reconnait une partie dans la version Punycode. Traduisons-le maintenant en sens inverse :

% echo caf-dma | ./punycode -d
u+0063
u+0061
u+0066
u+00E9

On voit qu'on a récupéré, comme prévu, exactement la même chaîne.

nameprep, sujet de notre RFC, est un profil de stringprep (RFC 3454), mécanisme de canonicalisation de noms. Il est notamment le mécanisme standard d'IDNA.

IDN nécessite un mécanisme de canonicalisation des noms de domaine, pour que la recherche d'un nom dans la mémoire du serveur DNS ne dépende pas de « détails » comme la casse ou de différences que les utilisateurs de cette écriture considèrent généralement comme non significatives. Ce mécanisme est spécifié dans notre RFC, qui s'appuie sur le cadre général stringprep. Notre RFC est donc très court, puisqu'il se limite à choisir dans les tables proposées par stringprep.

C'est donc nameprep qui décide que Pi².math est finalement équivalent à pi2.math.

On peut utiliser l'outil idn (distribué avec GNU libidn) pour tester (à noter que l'option --stringprep utilise le profil nameprep par défaut mais peut en utiliser d'autres) :

% idn --quiet --stringprep CAFÉ.fr 
café.fr

% idn --quiet --stringprep Straße.de
strasse.de

Dans la seconde version de la norme IDN, le principe d'une canonicalisation uniforme n'a finalement pas été retenu et ce RFC 3491 est donc désormais abandonné (cf. RFC 5891 et RFC 5894). nameprep n'est donc plus utilisé pour les noms de domaines. Il y a désormais plusieurs canonicalisations possibles comme celle du RFC 5895.

Sur la planète, des dizaines d'écritures différentes sont en service. Jusqu'à ce RFC, qui normalise les IDN, il n'était pas possible de les utiliser dans les noms de domaine où, pour des raisons diverses, seul un sous-ensemble d'US-ASCII était possible.

Contrairement à ce qu'on lit souvent (le nombre d'énormités publiées sur les IDN remplit beaucoup de disques durs chez Google), ce n'est pas la faute du DNS. Celui-ci est parfaitement compatible avec des encodages d'Unicode comme UTF-8 (c'est explicite dans le RFC 1035, même si sa section 2.3.1 cite une Preferred name syntax mais le RFC 2181 a enfoncé le clou et rappelant en section 11 que Those restrictions aside, any binary string whatever can be used as the label of any resource record.). BIND ou nsd acceptent n'importe quelle chaîne d'octets. PowerDNS est bogué de ce point de vue mais la résolution de cette bogue est en cours.

Non, le problème qui fait qu'on ne pouvait écrire que http://www.maconneriegenerale.fr/ au lieu de http://www.maçonneriegénérale.fr/ était plus complexe :

• les noms de machines, eux, sont soumis à des règles très restrictives, listées dans le RFC 1123.
• les serveurs DNS doivent effectuer une canonicalisation des noms demandés : par exemple, chocolat.fr et Chocolat.FR sont équivalents. Pour Unicode, une telle canonicalisation est bien plus complexe et la mettre en œuvre nécessiterait de changer tous les serveurs DNS...

L'approche imposée par l'IESG a donc été de ne pas toucher à l'« infrastructure » (les serveurs de noms) mais de tout faire dans les applications. D'où le nom d'IDNA, pour IDN in Applications.

Le principe d'IDN est le suivant : le nom en Unicode, par exemple CAFÉ.fr est d'abord canonicalisé par l'algorithme nameprep (normalisé dans le RFC 3491, nameprep est un profil de stringprep, qui était normalisé dans le RFC 3454). Il devient ici café.fr (les règles de nameprep sont évidemment bien plus complexes pour les écritures non-latines).

Ensuite, le nom est encodé en punycode, selon l'algorithme normalisé dans le RFC 3492. Il devient xn--caf-dma.fr, chaîne de caratères qu'il vaut évidemment mieux ne pas montrer à l'utilisateur. C'est cette chaîne, en pur ASCII qui va être passée au DNS. Les serveurs de noms n'ont donc besoin d'aucune mise à jour.

Notre RFC 3490 décrivait la première norme IDN, une seconde version, qui garde largement les mêmes principes, l'a remplacé en août 2010 (RFC 5890 et suivants).

Aujourd'hui, il existe de nombreuses bibliothèques, y compris en logiciel libre, pour gérer les IDN, de façon à ce que l'auteur de l'application n'aie pas à le faire lui-même. Citons par exemple GNU libidn ou comme celle qui est accessible aux programmeurs Python.

Et plusieurs TLD comme .de ou bien .no (ou évidemment les TLD chinois comme .tw) permettent l'enregistrement d'IDN.

Comme je l'ai indiqué, beaucoup d'erreurs ont été ou sont toujours colportées à propos des IDN. Par exemple, la page Web http://cr.yp.to/djbdns/idn.html montre une grave ignorance d'Unicode et une complète incompréhension de la question de la canonicalisation. Une autre erreur courante (elle est régulièrement commise par l'ICANN) est de confondre langue et écriture. IDN ne s'occupe que des écritures, pas des langues.

Le NAT a toujours été une des plaies de l'Internet, entre autres parce qu'il perturbe les applications qui veulent transmettre une référence à leur adresse IP. STUN, décrit dans ce RFC (depuis mis à jour dans le RFC 5389), est un des protocoles qui permet de limiter les dégâts.

Pour plusieurs raisons, dont le manque d'adresses IPv4, de nombreuses machines sont connectées à l'Internet derrière un routeur qui fait du NAT. Leur adresse étant alors privée, elles ne peuvent pas la transmettre à l'extérieur, ce qui est une gêne considérable pour tous les protocoles qui reposent sur la référence à des adresses IP, comme SIP. SIP lui-même (RFC 3261) marche à travers le NAT mais les données audio ou vidéo transmises (typiquement par RTP) le sont à une adresse IP que l'appelant donne à l'appelé et, si cette adresse est privée, le flux n'arrivera jamais.

La bonne solution serait de déployer IPv6, qui fournit des adresses en quantité illimitée, ou à la rigueur de permettre un meilleur contrôle du routeur NAT avec MIDCOM (RFC 3303) mais, en attendant, STUN est une solution simple et qui marche souvent.

STUN résout partiellement le problème de la manière suivante : un serveur STUN doit être installé quelque part sur l'Internet public (il existe des serveurs STUN publics) et reçoit des demandes envoyées en UDP au port 3478. Le serveur STUN peut alors connaitre l'adresse publique, celle mise par le routeur NAT et, en répondant au client, il pourra informer celui-ci « Voilà à quoi tes paquets ressemblent, vus de l'extérieur ».

Le nom du serveur STUN est typiquement configuré dans le client, puis le serveur recherché dans le DNS via les enregistrements SRV (RFC 2782).

Le principe est simple, mais le RFC est plus compliqué que cela, notamment en raison des problèmes de sécurité (la section 12 du RFC est très détaillée sur ce point). Par exemple, le client STUN doit en fait commencer par une connexion TCP pour obtenir un mot de passe temporaire.

Un autre problème est qu'il y a en fait plusieurs sortes de NAT (voir par exemple le RFC 2663). Notre RFC en rappelle certaines dans la section 5 avec sa propre terminologie (il n'existe pas réellement de norme pour le NAT). Par exemple, certains routeurs NAT (Symmetric NAT pour notre RFC) n'attribuent pas l'adresse externe uniquement en fonction de la source mais aussi en fonction de la destination. Ceux-ci ne fonctionnent pas avec STUN, qui a besoin de NAT cone, c'est-à-dire où les paquets d'une même machine auront toujours la même adresse IP externe.

Voici une démonstration d'un client STUN qui, en se connectant à un serveur STUN public va apprendre son adresse IP publique :

% ifconfig -a
hme0: [...] inet 172.19.1.2
(Adresse privée, probablement NATée...)

% ./client  stun.ekiga.net -v|& more
STUN client version 0.96
...
MappedAddress = 213.41.181.9:32143
(Voici mon adresse telle que vue de l'extérieur)
...
Primary: Indepndent Mapping, Port Dependent Filter, preserves ports, no hairpin 
(Et le type de NAT, à noter que cette partie disparaitra du successeur de STUN, 
actuellement en cours d'élaboration, car il existait trop de types de NAT, et 
leur détection n'était pas toujours fiable.)

STUN s'inscrit dans la catégorie des protocoles de « réparation » du NAT, catégorie décrite dans le RFC 3424. Il a été depuis asse profondément modifié dans le RFC 5389.

Beaucoup de protocoles ont besoin de manipuler des chaînes de caractères Unicode. La grande taille du répertoire Unicode fait qu'il est relativement fréquent de rencontrer deux chaînes différentes selon Unicode, mais identiques selon les utilisateurs. Il est donc nécessaire de définir des fonctions de normalisation. Ce que fait notre RFC. (Il a ensuite été remplacé par une méthode assez différente, décrite dans le RFC 7564.)

Avec les petits jeux de caractères comme US-ASCII, tout est simple. Deux chaînes différentes selon ASCII le sont également selon les utilisateurs humains. Le seul cas où une certaine normalisation est nécessaire est celui de l'insensibilité à la casse, lorsqu'on décide que (en prenant un exemple DNS) wikipedia.fr et WIKIpediA.Fr sont équivalents (ont la même forme canonique).

Avec Unicode, ce n'est plus le cas : par exemple, la chaîne composée de l'unique caractère U+00E8 (LATIN SMALL LETTER E WITH GRAVE) est différent de la chaîne formée des caractères U+0065 (LATIN SMALL LETTER E) et U+0300 (COMBINING GRAVE ACCENT), alors que, pour la grande majorité des applications, la première (dite « précomposée ») est certainement « identique » à la seconde.

De même, en allemand, le caractère U+00DF (LATIN SMALL LETTER SHARP S ou ß) est souvent considéré comme « identique » à la chaîne "ss".

Les protocoles qui comparent ou classent des chaînes de caractères Unicode doivent donc normaliser ces chaînes avant toute comparaison. Aucune normalisation ne convient à tous les cas et notre RFC ne spécifie donc qu'un cadre général, qui doit être décliné en profils selon les besoins de l'application.

Notre RFC normalise donc ce cadre, les tables à utiliser et les points à spécifier dans chaque profil. Ensuite, d'autres RFC font définir les profils. Par exemple, le RFC 3491 normalise le profil Nameprep, utilisé autrefois par les noms de domaines en Unicode (IDN). Selon Nameprep, Strasse.de est ainsi identique à straße.de. Plusieurs RFC spécifiaient un tel profil, comme le RFC 3491 déjà cité ou bien comme le RFC 4013, qui normalisait SASLprep, utilisé pour normaliser les noms lors d'opérations d'authentification (depuis remplacé par le RFC 7613) ou comme le RFC 6122 qui normalisait les adresses XMPP (depuis remplacé par une autre norme sans Stringprep, le RFC 7622) et les profils resourceprep ou nodeprep.

Stringprep n'est plus utilisé aujourd'hui, et la méthode pour gérer les chaînes de caractères en Unicode est désormais celle du RFC 7564.

Le NAT est aujourd'hui une des techniques les plus répandues sur Internet. Motivé à l'origine par le manque d'adresses IPv4, il est devenu tellement répandu que rares sont les utilisateurs qui ne l'ont pas rencontré. Or, le NAT, qui brise le modèle « de bout en bout » qui a fait le succès de l'Internet, est une source sans fin d'ennuis pour les applications et leurs utilisateurs. De nombreuses propositions ont donc été faites pour contourner le NAT et passer malgré lui. Pour que le remède anti-NAT ne soit pas pire que le mal, l'IAB a produit ce RFC, qui explique les contraintes auxquelles doivent se plier toutes les technologies de contournement, spirituellement baptisées UNSAF (UNilateral Self-Address Fixing).

Un protocole UNSAF fonctionne typiquement avec un client situé, pour son malheur, derrière un NAT, et qui communique avec un serveur situé à l'extérieur, pour apprendre sa « vraie » adresse IP, qu'il pourra transmettre à ses pairs.

L'introduction du RFC commence par rappeler les limites de l'exercice. Comme il existe de nombreuses variétés de NAT, aucune solution de la famille UNSAF ne pourra tout résoudre. En outre, le NAT étant un bricolage pour répondre à un problème ponctuel, les solutions anti-NAT ne doivent pas chercher à être pérennes, et à bloquer le déploiement d'une solution propre (IPv6, dont les 2 puissance 128 adresses disponibles dispensent du NAT).

La section 2 du RFC énumère plus précisément les raisons pour lesquelles il n'y aura pas de solution générale. Par exemple, s'il y a plusieurs niveaux de NAT successifs, un client UNSAF doit-il utiliser la première adresse extérieure au NAT le plus proche, ou bien l'adresse la plus éloignée, en comptant qu'elle soit publique ? Un autre problème est le fait que le comportement passé du routeur NAT ne garantit pas son comportement futur. Notons encore que l'introduction d'une nouvelle partie, le serveur UNSAF, rend la communication plus fragile.

La section 3 précise les comportements observés chez les routeurs NAT et leurs conséquences (les RFC 3489 ou RFC 4787 sont allés bien plus loin depuis).

Finalement, la section 4 du RFC liste les conditions que devrait satisfaire toute proposition UNSAF :

• Se limiter à un problème à court terme et ne pas essayer d'être trop général,
• Décrire une stratégie de sortie, pour le jour où le NAT ne sera plus utilisé,
• Insister sur le risque de fragilité de la solution UNSAF, si elle introduit des dépendances supplémentaires.

La section 5, sur la sécurité, demande, elle, que la solution UNSAF ne soit pas une occasion pour permettre des traversées du NAT qui n'auraient pas été possibles sans elle.

Tous les RFC sortis depuis se réfèrent donc à celui-ci, en expliquant comment ils répondent aux préoccupations citées (par exemple la section 14 du RFC 3489).

Cinq ans après, ce RFC semble excessivement prudent par rapport aux solutions UNSAF. D'une part, plusieurs d'entre elles, comme STUN sont devenues très répandues et permettent à leurs utilisateurs de passer la plupart des NAT. D'autre part, le rêve d'un déploiement rapide d'IPv6, permettant de se passer rapidement du NAT, ne s'est pas concrétisé. Enfin, les craintes de sécurité ont été relativisées par les analyses montrant que, de toute façon, le NAT n'apporte guère de sécurité réelle.

Le groupe de travail Behave, créé depuis a donc, logiquement, passé plus de temps à normaliser ce qu'un système NAT doit faire, plutôt que de limiter ce que peut faire un système anti-NAT.

Le RFC 2141 définissait une syntaxe pour les URN, un membre de la grande famille des URI. Dans cette syntaxe, immédiatement après la chaîne de caractères urn:, on trouve l'espace de noms (namespace), une chaîne de caractères qui identifie le domaine d'une autorité d'enregistrement. Notre RFC 3406 expliquait les procédures de création d'un nouvel espace de noms dans le registre des espaces de noms que tient l'IANA. Ces deux anciens RFC ont dépuis été remplacés par le RFC 8141.

Comme expliqué dans la section 1, ce mécanisme d'espaces de noms suppose que, dans chaque espace, il existe une autorité d'enregistrement qui accepte (ou refuse) les enregistrements et que, d'autre part, il existe une autorité qui enregistre les espaces de noms (en l'occurrence l'IANA). Tout le RFC 3406 est consacré aux procédures de cette dernière autorité et aux mécanismes pour enregistrer un identificateur d'espace de noms (NID pour namespace identifier). (La résolution des URN en autres identificateurs n'est par contre pas couverte.) Des exemples d'autorité d'enregistrement dans un espace de noms donné sont le gouvernement néo-zélandais (RFC 4350) ou l'OGC (RFC 5165).

La section 2 du RFC détaille ensuite ce qu'est un espace de noms (un ensemble d'identificateurs uniques géré, c'est-à-dire que tous les noms syntaxiquements corrects n'en font pas partie, uniquement ceux qui ont été enregistrés). Par exemple, les ISBN forment un tel espace (dont l'utilisation dans des URN a fait l'objet du RFC 3187). À l'intérieur d'un espace de noms, les règles d'enregistrement et le travail quotidien du registre ne sont pas gérés par l'IETF ou l'IANA mais par l'autorité d'enregistrement de cet espace.

La section 3 introduit les différents types d'espaces de noms. Il y a des espaces expérimentaux (section 3.1), qui ne nécessitent pas d'enregistrement auprès de l'IANA, et qui se reconnaissent à leur NID commençant par x- (leur usage est désomais découragé, cf. RFC 6963). Il y a les espaces informels (section 3.2), dont le NID commence par urn- et est composé de chiffres et les espaces formels (section 3.3) dont le NID est composé de lettres et qui, contrairement aux informels, sont censés fournir un bénéfice aux utilisateurs de l'Internet (les espaces informels ont le droit d'être réservés à une communauté déconnectée). Contrairement encore aux informels, l'enregistrement des espaces formels doit faire l'objet d'une spécification écrite, typiquement un RFC.

Un des principes des URN est la durabilité : un URN devrait être stable dans le temps. Mais cette stabilité dépend essentiellement de facteurs non-techniques, comme la permanence dans le temps du registre (une organisation privée et fermée comme l'IDF est, par exemple, typiquement un mauvais choix pour assurer la permanence). Toutefois, si on ne peut pas garantir la stabilité d'un espace de noms, on connait en revanche des facteurs qui diminuent la probabilité de permanence et l'IETF peut donc analyser les spécifications à la recherche de tels facteurs (c'est une variante du problème très riche mais bien connu de la stabilité des identificateurs).

Enfin, avec la section 4, on arrive au processus d'enregistrement lui-même. Il faut en effet un peu de bureaucratie pour s'assurer que le NID est bien enregistré et que le registre des NID soit lui-même stable. Les procédures sont différentes selon le type d'espace de noms. Les expérimentaux (section 4.1) ne sont pas enregistrés du tout. Les informels (section 4.2) ont leur propre registre, avec un processus d'enregistrement léger, mais très peu utilisé.

Le gros morceau est constitué des espaces de noms formels (section 4.3). Cette fois, le processus d'enregistrement est plus complexe, un RFC est nécessaire, mais on obtient un « vrai » NID comme MPEG (RFC 3614), OASIS (RFC 3621) ou 3gpp (RFC 5279).

Le formulaire d'enregistrement complet est disponible dans l'annexe A du RFC. Bon courage aux futurs enregistreurs. N'oubliez pas de lire tout le RFC.

Notre RFC succède au RFC 2611, les changements étant détaillés dans l'annexe C. Ils incluent une meilleure formalisation des différents types d'espace (expérimental, informel et formel) et une description plus détaillée des formalités d'enregistrement. Depuis, il a lui-même été remplacé par le RFC 8141.

Le système DDDS, décrit dans le RFC 3401 permet d'associer à un nom de domaine l'adresse d'une ressource. Le RFC 3401 en donne une vision très générale, le RFC 3402 spécifie l'algorithme et notre RFC va préciser tout le reste pour le cas d'une base de données particulière, le DNS. C'est notamment dans notre RFC que se trouve décrits les enregistrements NAPTR.

Le RFC 3401 n'impose pas une base de données particulière pour DDDS. Mais toutes les applications, aujourd'hui, se servent du DNS, selon les règles édictées dans notre RFC (qui remplace donc le RFC 2915).

Le RFC 3403 normalise donc les enregistrements NAPTR du DNS. Ces enregistrements ressemblent à ceci :

cid.urn.arpa.  IN NAPTR 100   10   ""  ""  "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i"  .

où cid.urn.arpa est le nom de domaine, 100 l'ordre (au cas où il y aie plusieurs règles), 10 la préférence (nommé priorité dans le RFC 3402), les deux chaînes vides sont les options (flags) et le service (le protocole utilisé), les deux derniers termes étant l'expression et le remplacement (ici vide).

Suivant l'exemple (hypothétique) de notre RFC, inspiré du RFC 2276 sur les URN : on veut construire un service qui va permettre de trouver un message en connaissant son Content-ID (un en-tête MIME normalisé dans le RFC 1873). Prenons urn:cid:199606121851.1@bar.example.org comme exemple d'URN. La règle bien connue (elle doit être spécifiée dans la définition de l'application DDDS) dit que la première clé est comprise entre le premier et le deuxième signe :, donc ici, "cid" et on y ajoute urn.arpa.

La première règle trouvé dans le DNS pour ce nom est :

cid.urn.arpa.  IN NAPTR 100   10   ""    ""  "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i"    .

L'expression rationnelle extrait juste le nom de domaine (en retirant le premier label) : \2 désigne le second groupe de parenthèses, ici example.org. Comme il n'y a pas d'options (flags est une chaîne vide), la règle n'est pas terminale et on recherche donc un nouvel enregistrement NAPTR en utilisant example.org comme clé. Supposons que cela donne :

example.org. IN NAPTR 100  50  "s"    "http"  ""   www.example.org.

On saurait alors qu'il faut utiliser le protocole HTTP pour demander à www.example.org ce message.

Aujourd'hui, les NAPTR sont surtout utilisés dans le contexte d'ENUM, par exemple 1.9.7.9.0.7.8.6.8.0.3.9.4.e164.arpa est un nom de domaine qui a deux enregistrements NAPTR nous donnant le numéro de téléphone de son titulaire (en Allemagne) et son adresse SIP. Mais on voit aussi des NAPTR dans les domaines http.uri.arpa et ftp.uri.arpa pour résoudre les URI (ici, avec l'outil dig) :

% dig NAPTR http.uri.arpa
http.uri.arpa.          20969   IN      NAPTR   0 0 "" "" "!^http://([^:/?#]*).*$!\\1!i" .

où ils extraient simplement le nom de machine de l'URI.

Je ne connais pas de mise en œuvre de NAPTR en logiciel libre, malheureusement (le module Perl Net::DNS::RR::NAPTR permet leur analyse mais ne met pas en œuvre l'algorithme ; même chose pour la classe NAPTR de DNS Python).

Une bonne synthèse expliquant les NAPTR figure dans le blog de Nominet.

Le cœur du système DDDS, l'algorithme, est décrit dans ce RFC. C'est un système de réécriture de règles, qui mène à la localisation de la ressource souhaitée.

DDDS, décrit dans le RFC 3401 est un système de correspondance entre une clé, un nom de domaine et la localisation d'une ressource, par un URI. Le DNS permet de trouver une adresse ou un URI à partir d'un nom de domaine mais la correspondance est rigide : le nom de domaine est utilisé littéralement, sans variables, sans expressions.

DDDS change cela en permettant l'utilisation de réécritures. Les règles de réécriture ont été popularisées par le fichier de configuration de sendmail. Aujourd'hui, peu de gens écrivent un tel fichier à la main mais des règles de réécriture sont aussi utilisées dans l'excellent module mod_rewrite d'Apache. Les règles de réécriture sont en général considérées comme un mécanisme très puissant, relativement simple à mettre en œuvre pour le programmeur mais souvent très difficile à utiliser et à déboguer.

Pour le plaisir, voici une toute petite partie des règles de réécriture d'un fichier de configuration de sendmail :

# strip group: syntax (not inside angle brackets!) and trailing semicolon
R$*                     $: $1 <@>                       mark addresses
R$* < $* > $* <@>       $: $1 < $2 > $3                 unmark <addr>
R@ $* <@>               $: @ $1                         unmark @host:...
R$* [ IPv6 : $+ ] <@>   $: $1 [ IPv6 : $2 ]             unmark IPv6 addr
R$* :: $* <@>           $: $1 :: $2                     unmark node::addr
R:include: $* <@>       $: :include: $1                 unmark :include:...
R$* : $* [ $* ]         $: $1 : $2 [ $3 ] <@>           remark if leading colon
R$* : $* <@>            $: $2                           strip colon if marked
R$* <@>                 $: $1                           unmark
R$* ;                      $1                           strip trailing semi
R$* < $+ :; > $*        $@ $2 :; <@>                    catch <list:;>
R$* < $* ; >               $1 < $2 >                    bogus bracketed semi

et les règles du module mod_rewrite d'Apache :

# Assume that you want to provide www.username.host.domain.com for the
# homepage of username via just DNS A records to the same machine and
# without any virtualhosts on this machine.  Solution:
# For HTTP/1.0 requests there is no solution, but for HTTP/1.1
# requests which contain a Host: HTTP header we can use the following
# ruleset to rewrite http://www.username.host.com/anypath internally to
# /home/username/anypath:
RewriteEngine on
RewriteCond   %{HTTP_HOST}                 ^www\.[^.]+\.host\.com$
RewriteRule   ^(.+)                        %{HTTP_HOST}$1          [C]
RewriteRule   ^www\.([^.]+)\.host\.com(.*) /home/$1$2

DDDS met donc quelques limites à ces règles, notamment en imposant que les règles ne sont pas appliquées au résultat des règles précédentes (du même groupe) mais toujours à la clé de départ.

La première règle doit être bien connue, c'est-à-dire qu'elle est codée en dur dans l'application, elle n'est pas récupérée dans la base de données.

Les règles ont une priorité, des options (par exemple pour indiquer si la règle est terminale ou pas).

La règle elle-même a pour syntaxe les expressions rationnelles et un mécanisme de substitution analogue à celui de sed. Un exemple est décrit dans l'entrée sur le RFC 3403, où la base de données est tout simplement le DNS.

DDDS (Dynamic Delegation Discovery System) est un mécanisme d'accès à l'information qui fonctionne par réécriture de chaînes de caractères, depuis la clé connue intialement, jusqu'à la ressource souhaitée.

DDDS est une généralisation d'anciens protocoles comme NAPTR, qui était décrit dans la RFC 2915.

Notre RFC ne décrit que les grandes lignes de DDDS, deux autres RFC, les RFC 3402 et RFC 3403 décrivent l'ensemble du système.

En deux mots, notre RFC explique comment spécifier une application de DDDS. Deux applications connues sont ENUM et les URN. L'algorithme de réécriture, commun à toutes les applications, est spécifié dans le RFC 3402 tandis que la base de données utilisée doit être spécifiée par l'application. Le RFC 3403 décrit une telle base : le DNS, déjà utilisé par NAPTR. Le DNS sera certainement la base la plus courante pour DDDS même si d'autres peuvent, en théorie, être utilisées.

Voici le cahier des charges du protocole de communication entre registre et registrar, EPP.

La publication de la norme EPP, le RFC 3730 (auquel a succédé le RFC 4930 et ses frères) a signifié la fin du processus de sélection d'un protocole relativement générique de communication entre un registre et ses registrars. Ce processus avait commencé avec notre RFC, le cahier des charges du projet et s'est conclu avec la dissolution du groupe de travail Provreg en avril 2004.

Écrire un tel protocole n'est pas évident. En effet, les registres ont des politiques d'enregistrement très variées. Chez certains, comme .com, le domaine expire automatiquement au bout d'un certain temps et dans d'autres, comme .fr ou .eu, la notion d'expiration n'existe pas, le domaine doit être détruit explicitement. Chez certains registres, le registrar a tous les pouvoirs, notamment sur les objets de type Contact alors qu'ailleurs les contacts peuvent se gérer eux-même. Si des organismes comme l'ICANN ont du mal à admettre cette diversité et cherchent à imposer des règles uniformes (« Le consensus de Marina del Rey »), d'autres reconnaissent la variété comme une caractéristique essentielle des registres (le titre d'un atelier du CENTR au FGI d'octobre 2007 était One size doesn't fit all).

Le cahier des charges avait commencé comme une simple transcription des politiques de .com avant d'évoluer vers un document plus équilibré, même si le biais .com reste très fort. Par exemple, la terminologie de « registre partagé » (SRS pour shared registry system) reflète une vision du monde où le registre est une simple base de données commune. De même, la terminologie (section 1) utilise un vocabulaire péjoratif, parlant de « séparation peu claire » pour désigner un modèle parfaitement valide, celui de registre à vente directe, sans registrar.

La section 2 du RFC rappelle le fonctionnement général d'un registre. Les clients (le terme est celui utilisé dans les RFC ultérieurs, car plus neutre que registrar, qu'utilise ce RFC) créent des objets, les mettent à jour, les détruisent, etc. Les objets peuvent être de plusieurs types (le RFC cite les noms de domaine, les serveurs de noms et les contacts). Si les objets sont des noms de domaine, le registre produira les fichiers DNS pour les distribuer (les RFC produits par la suite sont plus neutres et moins spécifiques des registres de noms de domaine).

La section 3 décrit ensuite les exigences pour le futur protocole. Par exemple, la section 3.4.1 demande que chaque objet aie un identificateur unique (le ROID d'EPP).

Si, dans le processus de développement de ce RFC, un réel effort avait été fait pour s'abstraire des particularités de .com et des autres TLD ICANN, le résultat n'est pas parfait. Ainsi, la section 3.5, consacrée aux statuts possibles pour un nom de domaine, liste les statuts de .com, sans mentionner que certains peuvent ne pas avoir de sens pour un autre registre.

Comment représente-t-on une date sur l'Internet ? Il existe beaucoup de RFC qui ont besoin d'un format de date et, si certaine restent fidèles à des vieux formats, la plupart des RFC modernes se réfèrent à ce RFC 3339 qui définit un sous-ensemble d'ISO 8601 pour la représentation des dates.

Un des exemples les plus connus des vieux formats est le RFC 5322 qui garde, pour le courrier électronique, l'ancien format (initialement normalisé dans le RFC 724) difficile à analyser, et qui ressemble à Date: Thu, 27 Aug 2009 08:34:30 +0200. Ce format n'a été gardé que parce qu'on ne peut plus changer la norme du courrier sur un point aussi fondamental. Mais les RFC récents définissent un autre format, celui de notre RFC 3339. C'est, par exemple, le cas du RFC 4287 qui dit que les éléments XML d'un flux de syndication Atom doivent utiliser ce format, par exemple <published>2009-08-25T00:00:00Z</published>.

Pourquoi un RFC sur ce sujet et ne pas simplement se référer à la norme ISO 8601 ? Il y a plusieurs raisons. L'une est politique, c'est le fait que l'ISO ne distribue pas librement le texte de la plupart de ses normes (une version provisoire non redistribuable traine sur le serveur de l'ISO). L'autre est que ISO 8601, comme beaucoup de normes ISO, est mal spécifiée, très complexe et pleine de détails inutiles (cf. section 5.5). L'IETF a donc choisi la voie d'un sous-ensemble de ISO 8601, le format du RFC 3339.

La section 1 du RFC résume le problème général de la transmission et de l'affichage des dates. Beaucoup de programmes se sont cassés le nez sur ce sujet (je me souviens d'un logiciel commercial de gestion de tickets, très cher, qui envoyait des messages avec des dates invalides, ce qui décidait un autre logiciel commercial très cher, chargé de la lutte contre le spam, à les jeter).

Le RFC est bâti sur quelques principes, exposés dans cette section 1. On utilise évidemment le calendrier grégorien. Comme le but est de dater des événements Internet, on se limite aux dates de l'ère actuelle (i.e. après Jésus-Christ), on suppose que le décalage entre l'horloge locale et UTC est connu, etc.

Le problème de l'heure locale fait l'objet de la section 4. Les règles définissant l'heure légale étant très compliquées et changeantes (en raison de la stupide heure d'été), le choix est de s'appuyer sur UTC (section 4.1). Puisque le décalage entre l'heure locale et UTC est supposé connu, il est prévu de permettre d'indiquer ce décalage (section 4.2). Cela se fait toujours sous forme numérique, les noms alphabétiques des fuseaux horaires n'étant pas normalisés. Enfin, la section 4.4 réenfonce le clou au sujet des horloges qui ne connaissent que l'heure locale et pas son décalage avec UTC : de telles horloges sont inutilisables sur l'Internet puisqu'elles les indications temporelles transmises à partir d'elles sont fausses 23 fois sur 24 (dès qu'on n'est pas dans le même fuseau horaire).

Les historiens notent que c'était le cas des systèmes d'exploitation Microsoft pendant longtemps : l'horloge du PC ne stockait que l'heure locale, ce qui a créé d'innombrables problèmes lorsque Windows a dû se résigner à accepter les connexions avec l'Internet.

Voici pour le concept de temps. Et le format ? Quel est le cahier des charges précis ? La section 5 commence par énumérer les caractéristiques souhaitées. Les temps doivent pouvoir être comparées lexicographiquement (section 5.1), par exemple avec strcmp() en C ou sort avec le shell Unix. Contrairement à une idée répandue, ISO 8601 ne garantit pas cette possibilité (voir la section 5.1 pour une liste des règles à observer pour qu'une telle comparaison soit possible).

Autre critère important, le format doit être compréhensible par un humain (section 5.2). C'est une caractéristique fréquente des protocoles Internet ; les formats binaires sont relativement rares. Ceci dit, un format trop lisible peut mener à des erreurs. Par exemple, le format de date du RFC 5322 a mené certains programmeurs à croire qu'ils pouvaient traduire les noms de jour et de mois, puisque ceux-ci apparaissent sous une forme non-numérique (c'était l'erreur du logiciel commercial dont je parlais plus tôt). Le format de notre RFC est donc compréhensible mais pas forcément familier à tout être humain et les logiciels doivent donc se préparer à l'afficher sous une forme plus conforme aux habitudes locales.

Autre erreur du format du RFC 5322, la redondance de l'information (section 5.4). Inclure le nom du jour est redondant (puisqu'on peut le calculer à partir de la date, l'annexe B donne un exemple de code) et augmente donc les risques d'erreur (que faire si ce jour n'est pas correct, qui croire ?).

Assez de préliminaires, quel format utiliser, maintenant ? La section 5.6 va le décrire rigoureusement, en utilisant le langage ABNF (RFC 5234). Il existe quelque options comme le fait que le temps peut être écrit en heure locale, si le décalage avec UTC est indiqué. La section 5.8 donne quelques exemples de temps corrects. Voici comment les produire avec GNU date (le fait de séparer la date et le temps par un espace et pas par la lettre T est une violation de la grammaire mais le RFC est ambigu sur ce point) :

% date --rfc-3339='ns'
2009-07-12 11:03:08.434344377+02:00

% date --rfc-3339='seconds'
2009-07-12 11:03:12+02:00

% date --rfc-3339='date'
2009-07-12

et voici un programme Python qui affiche la date actuelle en UTC (donc avec le Z à la fin, Z étant l'équivalent de +00:00) :

import time

# date+time but no fractional seconds
rfc_3339_nosecfrac = "%Y-%m-%dT%H:%M:%SZ"

# gmtime = UTC (old name)
print time.strftime(rfc_3339_nosecfrac, 
                    time.gmtime(time.time()))

Et, en C, voici un exemple possible :

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

#define MAX_SIZE 256
#define RFC_3339_NOFRAC_UTC "%Y-%m-%dT%H:%M:%SZ"

int
main()
{
    char           *result = malloc(MAX_SIZE);
    struct timeval  tv;
    struct tm      *time;
    size_t          result_len;
    (void) gettimeofday(&tv, NULL);
    time = gmtime(&tv.tv_sec);
    result_len = strftime(result, MAX_SIZE, RFC_3339_NOFRAC_UTC, time);
    if (result_len != 0) {
        printf("%s\n", result);
        exit(0);
    } else {
        printf("Error in strftime\n");
        exit(1);
    }
}

Y a t-il des problèmes de sécurité cachés derrière l'affichage de la date ? Oui, la section 7 en cite un : la connaissance de l'heure locale d'un système peut permettre à un attaquant de déterminer les heures où le système est le plus suceptible d'être surveillé et le paranoïaque peut donc avoir intérêt à n'émettre que des temps en UTC…

Notre RFC compte plusieurs annexes intéressantes. Par exemple, l'annexe A est une rétro-ingénierie de la norme ISO 8601. Comme celle-ci ne spécifie pas formellement de grammaire pour le format des dates, ce sont les auteurs du RFC qui en ont établi une, à partir de la norme. Elle est bien plus riche (avec beaucoup plus d'options) que celle de la section 5.6. L'annexe D donne les détails sur la gestion des secondes intercalaires, qu'on peut trouver en ligne.

Un certain nombre de préfixes IPv4 ont une signification spéciale et ce RFC les documente, pour éviter aux lecteurs de devoir fouiller dans les nombreux RFC originaux. (Il a été remplacé depuis par le RFC 6890.)

Normalement, les préfixes des réseaux IPv4 sont attribués par l'IANA aux RIR qui les allouent ensuite aux LIR (qui sont en général des FAI). Ces allocations et les affectations aux utilisateurs finaux sont enregistrées par les RIR et sont publiquement accessibles via des protocoles comme whois.

Mais certains préfixes sont spéciaux et échappent à ce mécanisme. Ils ont été réservés par tel ou tel RFC et sont donc dispersés à plusieurs endroits. Notre RFC, écrit par l'IANA, rassemble toutes ces réservations en un seul endroit.

Voici quelques exemples de préfixes ainsi documentés :

• 10.0.0.0/8, réservé pour les adresses privées par le RFC 1918,
• 192.0.2.0/24, réservé pour la documentation (par exemple pour rédiger des manuels, sans craindre que les adresses IP d'exemple soient utilisées) mais cette liste a été étendue depuis par le RFC 5737,
• 169.254.0.0/16, réservé pour les adresses locales au lien (cette réservation sera documentée par la suite dans le RFC 3927),
• Et bien d'autres, énumérés dans la section 2 et résumés dans la 3.

Notre RFC contient aussi des préfixes « normaux », qui ont été réservés à une époque mais ne le sont plus comme 24.0.0.0/8.

Un RFC équivalent existe pour IPv6, le RFC 5156.

DHCP est certainement un des plus grands succès de l'IETF. Le DHCP d'IPv4 est mis en œuvre dans tous les systèmes et présent dans presque tous les réseaux locaux. Mais, dans le monde IPv6, l'arrivée de DHCP est plus récente, et il est concurrencé par un autre système, l'autoconfiguration sans état. DHCP pour IPv6, initialement normalisé dans ce RFC, l'est désormais dans le RFC 8415.

DHCP permet à une machine (qui n'est pas forcément un ordinateur) d'obtenir une adresse IP (ainsi que plusieurs autres informations de configuration) à partir d'un serveur DHCP du réseau local. C'est donc une configuration « avec état », qui nécessite un serveur, par opposition aux systèmes « sans état », comme l'autoconfiguration du RFC 4862 qui ne dépendent pas d'un serveur (cette autoconfiguration sans état peut être utilisée à la place de, ou bien en plus de DHCP). Deux utilisations typiques de DHCP sont le SoHo où le routeur ADSL est également serveur DHCP pour les trois PC connectés et le réseau local d'entreprise où deux ou trois machines Unix distribuent adresses IP et informations de configuration à des centaines de machines.

Le DHCP spécifié par notre RFC (et remplacé depuis par le RFC 8415) ne fonctionne que pour IPv6, le RFC 2131 traitant d'IPv4.

DHCP fonctionne par diffusion restreinte. Un client DHCP, c'est-à-dire une machine qui veut obtenir une adresses, diffuse (DHCP fonctionne au dessus d'UDP) sa demande à l'adresse multicast locale au lien FF02::1:2. Le serveur se reconnait et lui répond. S'il n'y a pas de réponse, c'est, comme dans le DNS, au client de réémettre (section 14).

Le serveur choisit sur quels critères il alloue les adresses IP. Il peut les distribuer de manière statique (une même machine a toujours la même adresse IP) ou bien les prendre dans un pool d'adresses et chaque client aura donc une adresse « dynamique ». Le fichier de configuration ci-dessous montre un mélange des deux approches.

Il faut bien noter (et notre RFC le fait dans sa section 23) que DHCP n'offre aucune sécurité. Comme il est conçu pour servir des machines non configurées, sur lesquelles on ne souhaite pas intervenir, authentifier la communication est difficile. Un serveur DHCP pirate, ou, tout simplement, un serveur DHCP accidentellement activé, peuvent donc être très gênants. Les approches suggérées dans la section 21 ou dans la section 23 sont en général très complexes (comme l'IPsec du RFC 4301) et ne sont typiquement pas déployées.

Outre l'adresse IP, DHCP peut indiquer des options comme les adresses des serveurs DNS à utiliser (RFC 3646).

Notre version IPv6 de DHCP est assez différente de la version IPv4 (et le RFC est trois fois plus long). Par exemple, l'échange « normal » entre client et serveur prend quatre paquets IP (section 1.3) et non pas deux, l'encodage est très différent, il y a des nouveautés comme l'IA (Identity Association) de la section 10, etc. Il y a aussi des différences visibles à l'utilisateur comme le concept de DUID (DHCP Unique IDentifier), section 9, qui remplace les anciens client identifier et server identifier de DHCP v4. Les différences sont telles que le RFC précise que leur intégration n'est pas envisagée.

À l'heure actuelle, il semble qu'il existe au moins trois mises en œuvre de DHCPv6, Dibbler, celle de l'Institut Leibniz à Dresde et celle de l'ISC, à partir de la version 4.0. Le fichier de configuration de cette dernière ressemble beaucoup à ce qu'il est en v4 :

subnet6 2001:DB8:DEAD:BABE::/64 {
     range6      2001:DB8:DEAD:BABE::100 2001:DB8:DEAD:BABE::FFF; 
     # On peut aussi utiliser préfixe/longueur au lieu d'indiquer les
     # adresses de début et de fin de la plage
}

On doit lancer le serveur avec l'option -6 (le même démon ne peut pas servir le v4 et le v6 en même temps, les deux protocoles étant trop différents) :

# dhcpd -6 -d -f 
Internet Systems Consortium DHCP Server 4.0.0
...
Listening on Socket/eth0/2001:db8:dead:babe::/64
Sending on   Socket/eth0/2001:db8:dead:babe::/64

[Puis arrive une requête]

Solicit message from fe80::219:b9ff:fee4:25f9 port 546, transaction ID 0x4BB14F00
Picking pool address 2001:db8:dead:babe::fbb
Sending Advertise to fe80::219:b9ff:fee4:25f9 port 546
Request message from fe80::219:b9ff:fee4:25f9 port 546, transaction ID 0x46B10900
Sending Reply to fe80::219:b9ff:fee4:25f9 port 546

(Le concept de transaction ID est décrit sections 6 et 15.1.) La requête est émise depuis une adresse lien-local (ici fe80::219:b9ff:fee4:25f9) pas depuis une adresse « tout zéro » comme en IPv4 (section 16 du RFC). Vu avec tcpdump, la requête est :

15:07:43.455918 IP6 fe80::219:b9ff:fee4:25f9.546 > ff02::1:2.547: dhcp6 solicit
15:07:43.456098 IP6 fe80::219:b9ff:fee4:2987.547 > fe80::219:b9ff:fee4:25f9.546: dhcp6 advertise
15:07:44.512946 IP6 fe80::219:b9ff:fee4:25f9.546 > ff02::1:2.547: dhcp6 request
15:07:44.513233 IP6 fe80::219:b9ff:fee4:2987.547 > fe80::219:b9ff:fee4:25f9.546: dhcp6 reply

On note que l'échange a été celui à quatre messages (Solicit - Advertise - Request - Reply), décrit section 1.3. Le serveur n'a pas répondu directement avec un Reply, parce que le client n'a pas inclus l'option Rapid Commit (section 22.14). Cette option n'est pas actuellement gérée par le client DHCP utilisé (l'option dhcp6.rapid-commit existe mais la documentation précise qu'elle est ignorée).

Actuellement, l'attribution d'adresses statiques à une machine, en la reconnaissant, par exemple, à son adresse MAC est plus délicate avec le serveur de l'ISC (merci à Shane Kerr pour son aide). Il faut trouver le client identifier (section 22.2 du RFC, deux méthodes possibles pour le trouver sont expliquées plus loin) et le mettre dans dhcpd.conf :

host lilith {
  host-identifier option dhcp6.client-id 0:1:0:1:47:96:21:f7:0:19:b9:e4:25:f9;
  fixed-address6 2001:DB8:DEAD:BABE::2;
}

et cette adresse IP fixe est donnée au client.

Pour trouver le client identifier, une méthode spécifique au client DHCP de l'ISC est de regarder dans le fichier des baux du client (typiquement /var/db/dhclient6.leases) :

...
  option dhcp6.client-id 0:1:0:1:47:96:21:f7:0:19:b9:e4:25:f9;

Il suffit alors de le copier-coller.

Une autre méthode, plus complexe, mais qui marche avec tous les clients DHCP est de lancer tcpdump en mode bavard :

# tcpdump -n -vvv ip6 and udp and port 547
12:24:15.084006 IP6 (hlim 64, next-header UDP (17) payload length: 60) fe80::219:b9ff:fee4:25f9.546 > ff02::1:2.547: dhcp6 solicit (xid=4323ac (client ID hwaddr/time type 1 time 1201021431 0019b9e425f9) (option request DNS DNS name)[|dhcp6ext])

Le client identifier, le DUID, se fabrique en concaténant le type de DUID (ici, 1, Link-layer Address Plus Time, section 9.2 du RFC), le type de matériel (1 pour Ethernet), le temps (ici 1201021431, notons que la version actuelle du client DHCP viole le RFC en comptant les secondes à partir de 1970 et pas de 2000) et l'adresse MAC, ce qui redonne le même résultat au prix de quelques calculs avec bc.

Mais l'utilisation exclusive du DUID, au détriment de l'adresse MAC, n'est pas une obligation du RFC (le RFC, section 9, dit juste « DHCP servers use DUIDs to identify clients for the selection of configuration parameters », ce qui n'interdit pas d'autres méthodes), juste un choix des développeurs de l'ISC. Le serveur de Dresde, dhcpy6d, permet d'utiliser les adresses MAC, comme on le fait traditionnellement en IPv4. En combinaison avec des commutateurs qui filtrent sur l'adresse MAC, cela peut améliorer la sécurité.

Les middleboxes sont tous les équipements intermédiaires qui s'interposent dans une communication Internet et rendent des services ou au contraire les limitent. Difficiles à mettre à jour, souvent mal gérés, ils sont un des gros problèmes de l'Internet. Notre RFC propose une architecture pour déporter une partie de leurs fonctions à l'extérieur de la boîte, pour faciliter la maintenance.

Parmi les middleboxes ("boîtes intermédiaires", décrits dans le RFC 3234) existantes, on trouve des coupe-feu, des répartiteurs de charge, des relais filtrants, etc. Tous ou presque ont en commun d'être des boîtes fermées, difficiles à mettre à jour et manquant de souplesse.

Le RFC propose donc une architecture, nommée Midcom, pour gérer ces middleboxes. Dans ce cadre, les middleboxes seront pilotées par un "agent Midcom", stationné sur un ordinateur, et qui pilotera les middleboxes via le protocole Midcom, dont le cahier des charges est spécifié dans le RFC 3304.

Une des particularités du protocole IP est que vous avez plusieurs protocoles de transport disponibles. TCP et UDP sont les plus connus mais SCTP, présenté dans notre RFC, est également intéressant.

SCTP ressemble plutôt à TCP, notamment par le fait qu'il fournit un transport fiable. Mais il a plusieurs différences :

• il ne gère pas un flot d'octets continu mais une série de messages, bien séparés,
• il gère plusieurs flux de données séparés, qui partagent le même contrôle de congestion mais gèrent à part les pertes et retransmissions,
• il gère le cas où la machine a plusieurs adresses IP, ce qui lui fournit normalement plus de redondance, si on est connecté à plusieurs réseaux.

C'est le RFC 4960 qui normalise SCTP. Notre RFC est une introduction, donnant une vue générale du protocole.

SCTP est depuis longtemps mis en œuvre dans Linux et, depuis peu également dans FreeBSD. Sur Linux, si vous voulez tester SCTP, le plus simple est d'installer les outils du paquetage lksctp cité plus haut (sur Debian, aptitude install lksctp-tools, sur Gentoo, emerge lksctp-tools). Testez d'abord si votre noyau gère SCTP :

# Bon
% checksctp                        
SCTP supported

# Mauvais
% checksctp
checksctp: Protocol not supported

Ensuite, désignez deux machines pour tester, mettons 192.168.2.1:6666 et 192.168.2.25:8888. L'une, 192.168.2.25 va écouter avec SCTP :

%  sctp_darn -h 192.168.2.1 -p 6666 -H 192.168.2.25 -P 8888 -l     
sctp_darn listening...

L'autre, 192.168.2.1, va envoyer le message toto :

% sctp_darn -H 192.168.2.1 -P 6666 -h   192.168.2.25  -p 8888 -s 
sctp_darn ready to send...
192.168.2.1:6666-192.168.2.25:8888> toto
Recieved SCTP_COMM_UP
New connection, peer addresses
192.168.2.25:8888
192.168.2.1:6666-192.168.2.25:8888> 

Le serveur a bien reçu le message :

Recieved SCTP_COMM_UP
NOTIFICATION: ASSOC_CHANGE - COMM_UP
SNDRCV
   sinfo_stream 0
   sinfo_ssn 0
   sinfo_flags 0x0
   sinfo_ppid 0
   sinfo_context 0
   sinfo_tsn     2215576728
   sinfo_cumtsn  0
   sinfo_assoc_id  1
DATA(6):  toto.

Le protocole SIP est normalisé dans le RFC 3261 qui décrit en détail la communication entre un client et un serveur SIP. Mais comment le client trouve t-il un serveur ? C'est l'objet de ce RFC d'accompagnement.

SIP est surtout utilisé pour la téléphonie sur Internet. L'ancien numéro de téléphone y est remplacé par un URI, tel que sip:support@apnic.net. Mais un client SIP (par exemple un UAC, le logiciel avec lequel interagit directement l'utilisateur, son téléphone : mais aussi un relais SIP que l'UAC aurait utilisé) doit, pour établir une connexion avec le serveur SIP, trouver son adresse, alors qu'il n'a que cet URI et donc uniquement un nom de domaine (et que SIP peut fonctionner sur plusieurs transports).

La méthode est donc d'utiliser le DNS. Le client va utiliser les enregistrements NAPTR du RFC 3403 puis les enregistrements SRV du RFC 2782. Suivons la section 4.1 du RFC qui nous donne un exemple, où on cherche à joindre sip:helpdesk@example.net. Le domaine example.net contient les enregistrements NAPTR suivants :

;             order pref   flags    service     regexp       replacement
    IN  NAPTR   50    50     "s"     "SIPS+D2T"    ""   _sips._tcp.example.com
    IN  NAPTR   90    50     "s"     "SIP+D2T"     ""   _sip._tcp.example.com
    IN  NAPTR   100   50     "s"     "SIP+D2U"     ""   _sip._udp.example.com
    IN  NAPTR   120   50     "s"     "SIP+D2S"     ""   _sip._sctp.example.com

On notera que le champ regexp est vide : quel que soit l'URI de départ, le résultat est donné par le champ replacement. Ici, quatre NAPTR sont intéressants (ceux dont le service est de type SIPx+D2x). Le premier spécifie un transport sécurisé par TLS au dessus de TCP. Le second un transport TCP simple, le troisième un transport UDP, le quatrième un SCTP.

Une fois obtenu ces noms de domaines grâce aux NAPTR, on utilise les enregistrements SRV pour avoir les serveurs et leurs numéros de port. Par exemple, _sip._tcp.example.com aura les SRV suivants :

;               Priority Weight Port      Target
      IN    SRV  0          1     5060     main-server.example.com.
      IN    SRV  10         1     53456    backup-server.example.com.

Le client tentera alors de se connecter à main-server.example.com (on notera que cela nécessitera une requête DNS supplémentaire, pour trouver son adresse IP) se rabattant, s'il est inaccessible, sur backup-server.example.com.

Le prédécesseur de notre RFC, le RFC 2543, n'utilisait pas les NAPTR, uniquement les SRV. Dans l'exemple ci-dessus, les serveurs étant dans un domaine différent de celui de l'URI, il aurait donc échoué.

Notons enfin que la section 5 du RFC décrit comment un serveur SIP trouve un client. Si ce dernier le contacte directement en TCP, c'est trivial mais il existe des cas où le client est en fait un relais et où la réponse doit suivre un cheminement analogue (avec recherche de SRV - mais pas de NAPTR) pour le trouver.

Le protocole SIP, que spécifie ce RFC, a bien des usages mais le plus connu est celui de permettre la téléphonie sur IP. SIP est une tentative de protocole standard, dans un monde où les solutions spécifiques et fermées sont les plus médiatisées.

SIP permet d'établir, modifier et terminer des sessions multimédia (en pratique, surtout de la téléphonie). Il est important de noter que SIP ne transporte pas lui-même les données multimédia : son seul travail est de gérer les sessions, de permettre à deux entités, les User Agent, de se recontrer et d'ouvrir la session où vont passer les données. Celles-si seront transportées par un autre protocole comme RTP (RFC 3550).

Avec près de 650 000 signes, soit 270 pages, notre RFC est un des plus gros. C'est que le multimédia est chose complexe et qu'il y a énormément de détails à préciser. Mais le principe est relativement simple : l'User Agent "cliente" contacte l'User Agent "serveur", celle-ci "sonne" l'utilisateur et, s'il est d'accord, il "décroche" et son User Agent accepte alors la session. En pratique, les User Agent sont des téléphones SIP ou bien des softphones, des applications comme WengoPhone (il est possible que l'objet téléphone disparaisse dans le futur, la téléphonie devenant juste une application informatique parmi d'autres).

Pour ce dialogue, SIP utilise des commandes texte, comme SMTP ou HTTP. On les voit ici lorsqu'on utilise la commande sipsak, très pratique pour tester SIP :

 % sudo sipsak -v -v -s sip:beatrice@durand.fr 
[...]

** request **
OPTIONS sip:beatrice@durand.fr SIP/2.0
Via: SIP/2.0/UDP foobar.bortzmeyer.org:33196;rport
From: sip:sipsak@foobar.bortzmeyer.org:33196;tag=3363661c
To: sip:beatrice@sip.durand.fr
Call-ID: 862152220@foobar.bortzmeyer.org
CSeq: 1 OPTIONS
Contact: sip:sipsak@foobar.bortzmeyer.org:33196
Content-Length: 0
Max-Forwards: 70
User-Agent: sipsak 0.8.11
Accept: text/plain

message received:
SIP/2.0 200 OK -- happy sipping to you asterisk
Via: SIP/2.0/UDP foobar.bortzmeyer.org:33196;rport=33196;received=213.41.181.9
From: sip:sipsak@foobar.bortzmeyer.org:33196;tag=3363661c
To: sip:beatrice@sip.durand.fr;tag=770257e1542af587787e4362acc86da0.7432
Call-ID: 862152220@foobar.bortzmeyer.org
CSeq: 1 OPTIONS
Content-Length: 0

** reply received after 82.232 ms **
   SIP/2.0 200 OK -- happy sipping to you asterisk
   final received

sipsak a utilisé OPTIONS, qui sert surtout au débogage ou bien à découvrir les capacités de l'User Agent d'en face, mais il y a aussi INVITE, BYE, etc. La réponse favorable identifiée par le nombre 200 ne surprendra pas les connaisseurs d'HTTP.

Vous avez peut-être également noté que les adresses SIP sont des URI. Ces URI sont décrites dans la section 19 de notre RFC (c'est un autre RFC, le RFC 3263, qui décrit en détail comment trouver un User Agent SIP à partir de son nom, par exemple en utilisant les enregistrements DNS SRV). Finis les numéros de téléphone peu pratiques à mémoriser, demain, pour la téléphonie comme pour le reste des applications Internet, on utilisera un nom de domaine et on pourra dire « Appelle-moi au sip:alain@voip.wengo.fr. ».

Fréquemment, les User Agent ne connaissent pas leur nom : si je veux appeler quelqu'un, je ne sais pas derrière quel ordinateur il est. SIP permet donc d'utiliser un mandataire (proxy). Ceux-ci sont typiquement gérés par des fournisseurs de service et fournissent d'autres services, par exemple de passerelle avec le réseau téléphonique classique. Ainsi, Wengo est un tel fournisseur.

Le mandataire doit bien, lui, savoir quel est le nom actuel de l'User Agent du destinataire. Pour que cela soit possible, celui qui veut recevoir des appels doit joindre un registrar (en pratique, c'est typiquement le même service que le mandataire) et utiliser la commande SIP REGISTER pour indiquer sa localisation actuelle.

Comme le flux de données RTP doit pouvoir attendre la machine appelante, les NAT sont une des principales sources de problème pour SIP. La plupart des applications SIP utilisent STUN (RFC 3489) pour percer un trou dans le routeur NAT et permettre l'entrée des données.

Parmi les textes parlant de SIP en français, on peut consulter par exemple un projet d'étudiants de l'Université d'Avignon avec beaucoup de documentations.

SIP est aujourd'hui mis en œuvre dans plusieurs logiciels libres. Le programme SIP Communicator peut ainsi lancer et recevoir des appels via SIP. Le programme Asterisk est un auto-commutateur téléphonique tournant sur Unix et capable de faire du SIP. De nombreux autres logiciels SIP existent comme Twinkle ou Linphone.

Pour l'instant, SIP semble moins utilisé que ses concurrents fermés (et moins que la téléphonie classique). Mais cela peut changer dans le futur, au fur et à mesure que les utilisateurs comprennent les dangers qu'il y a à dépendre d'un seul fournisseur, utilisant un protocole non-standard et des logiciels dont on ne sait pas ce qu'ils font avec vos échanges téléphoniques. Là, SIP sera bien placé pour les remplacer.

Le courrier électronique, on le sait, n'offre guère de sécurité, que cela soit contre la lecture illégitime des messages ou bien contre l'injection de faux messages. Vue la complexité de son architecture (cf. RFC 5598), fruit d'une histoire longue et agitée, il ne faut pas espérer trouver la solution parfaite à tous les problèmes de sécurité du courrier. Aussi, ce RFC 3207 se contente d'apporter juste une brique à l'édifice, l'utilisation de TLS pour protéger le canal de communication entre deux MTA.

La communication normale entre deux de ces serveurs de messagerie se fait, avec le protocole SMTP, en clair. Aucune protection contre l'écoute ou la modification de données (section 1). Il n'y a pas non plus de moyen d'être sûr de l'authenticité du serveur en face. TLS, normalisé aujourd'hui dans le RFC 5246, fournit ces services de confidentialité (via le chiffrement) et d'authentification (via les certificats). Il faut noter que TLS ne sécurise ici que le canal entre deux serveurs, pas le message qui est transporté. Un message passe typiquement par plusieurs serveurs et toutes les communications ne seront pas forcément protégées par TLS. Même si elles le sont, si un des serveurs intermédiaires est malhonnête, TLS ne protégera pas (voir la section 6 du RFC qui détaille ce point de manière très complète). Au contraire, les solutions de sécurité de bout en bout comme PGP protégeront le message (mais sont peut-être plus difficiles à déployer).

Donc, le principe de ce RFC est de faire tourner SMTP au dessus de TLS. Cela se fait par le biais d'une nouvelle extension SMTP, STARTTLS, décrite en section 2 (contrairement à HTTP, il n'y a pas de port spécial où on utiliserait toujours TLS).

Cette extension est composée d'une option qu'annonce le serveur distant, STARTTLS :

220 mail.generic-nic.net ESMTP Postfix (Debian/GNU)
EHLO chezmoi.example.net
250-mail.generic-nic.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
...

et d'une nouvelle commande, également nommée STARTTLS, décrite en section 4 :

STARTTLS
220 2.0.0 Ready to start TLS
...

À cette commande, le serveur distant peut parfois répondre 454 (TLS not available due to temporary reason) auquel cas l'initiateur de la connexion devra décider s'il continue sans TLS (et est donc vulnérable à une attaque par repli, où un attaquant actif essaie de faire croire que la sécurisation n'est pas possible, voir la section 6 du RFC) ou de renoncer. Voir par exemple l'option smtp_tls_security_level = encrypt" de Postfix. Le RFC suggère (section 6) d'enregistrer le fait qu'un pair donné utilise TLS et de refuser les connexions ultérieures si TLS a été abandonné mais je ne connais aucune mise en œuvre de SMTP sur TLS qui fasse cela.

Pour que le courrier puisse continuer à fonctionner dans l'Internet, le RFC impose qu'un serveur annoncé publiquement (par exemple, placé en partie droite d'un enregistrement MX) accepte les connexions sans TLS. En revanche, l'option TLS est particulièrement intéressante (section 4.3) si l'utilisateur humain est authentifié et donc si on utilise le port de soumission (RFC 4409).

Si la commande STARTTLS est un succès (code 220), la négociation TLS habituelle commence. Les deux parties examinent ensuite ses résultats (par exemple l'algorithme de cryptographie négocié, ou bien le certificat du pair distant) et décident de continuer ou pas (section 4.1).

Parlant du certificat, faut-il vérifier celui du voisin ? En pratique, quasiment personne ne le fait, en raison du prix des certificats et de la difficulté à les obtenir et les gérer. De nos jours, SMTP sur TLS procure donc la confidentialité par rapport à des écoutants passifs mais aucune authentification. À la rigueur, on peut toujours regarder les en-têtes du message pour avoir quelques informations supplémentaires :

Received: from mail.bortzmeyer.org (unknown [IPv6:2001:4b98:41::d946:bee8:232])
        (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
        (Client CN "mail.bortzmeyer.org", Issuer "ca.bortzmeyer.org" (not verified))
        by mx1.nic.fr (Postfix) with ESMTP id 964A71714088
        for <echo@nic.fr>; Thu, 26 Nov 2009 12:08:08 +0100 (CET)

Si le MTA vérifie l'authenticité de son partenaire, le RFC lui laisse le choix des détails, recommandant seulement d'accepter un serveur situé dans le même domaine que celui qu'on cherche à contacter.

Une fois TLS négocié avec auccès, les machines doivent ignorer tout ce qui a été tapé avant et reprendre la négociation SMTP (EHLO et la suite), puisque l'information obtenue sans TLS n'est pas fiable (section 4.2).

Ce RFC est une mise à jour de la première norme, le RFC 2487, en bien plus détaillé, notamment sur les attaques possibles (une annexe résume les changements).

La plupart des MTA aujourd'hui ont la capacité de faire du TLS, comme décrit pour Postfix dans mon article. Parmi les auto-répondeurs de test, certains acceptent TLS.

Ce RFC explique pourquoi les RFC 1611 et RFC 1612 doivent être considérés comme des échecs.

Il est rare, à l'IETF comme dans beaucoup d'autres organisations, de voir les échecs être documentés. En général, on les cache soigneusement et on n'en parle pas. L'IETF a aussi son lot de normes qui ont été des flops et dont l'échec n'a jamais été admis.

Mais, ici, le travail a été fait jusqu'au bout. Tenant compte de l'absence d'implémentation des RFC sur la gestion des serveurs DNS via SNMP, c'est un des auteurs de ces RFC qui a pris le clavier pour reconnaître cet état de fait, changer le statut de ces RFC pour Historic et expliquer les raisons de l'échec.

Elles sont classiques et chacun pourra trouver dans son expérience personnelle des projets qui ont échoué pour des raisons similaires :

• Cahier des charges jamais spécifié, ce qui faisait que les membres du groupe de travail ne cherchaient en fait pas la même chose,
• Tentatives (souvent réussies) de tout mettre dans le protocole et notamment un nombre de variables SNMP impressionnant, de nature à décourager les implémenteurs,
• Utilisation d'un protocole, SNMP, qui n'avait pas été conçu pour cela et qui était peut-être utilisé en dehors de ses limites.

Un des points importants des URN est la capacité à intégrer des systèmes d'identificateurs pré-existants. Ici, ce sont les traditionnels ISBN des livres qui deviennent des URN. (Ce RFC a été remplacé depuis par le RFC 8254.)

Chaque livre papier publié dans le monde a un ISBN par exemple :

• 0-380-81593-1: In the beginning was the command line,
• 2865375447: Les cultures noires d'Amérique Centrale,
• 978-2253109952: Le maitre de Garamond.

Notre RFC, développant les idées originellement exprimées dans le RFC 2288, définit donc une syntaxe pour exprimer cet ISBN en URN et cela donne, pour les trois livres ci-dessus :

• urn:isbn:0-380-81593-1
• urn:isbn:2865375447
• urn:isbn:978-2253109952

À noter que, à ma connaissance, il n'existe pas de mécanisme de résolution standard d'un tel URN. On ne peut pas, juste en connaissant un URN trouver une description du livre (Amazon le fait, mais uniquement pour les livres à son catalogue).

De tout temps, un des plus gros problèmes de l'Internet a été de gérer la congestion, le fait qu'il y a plus de paquets IP qui veulent passer par les tuyaux que de capacité pour les faire passer. La réponse classique d'IP à la congestion est de laisser tomber certains paquets, les protocoles de plus haut niveau étant alors censés ralentir en réponse à ces pertes. Notre RFC normalise une autre méthode : lorsque le routeur sent que la congestion est proche, il marque les paquets IP pour indiquer aux machines terminales qu'il faudrait ralentir. Une excellente page, par une des auteures du RFC, ECN (Explicit Congestion Notification) in TCP/IP décrit ce système, qui n'a malheureusement pratiquement pas connu de déploiement.

C'est le RFC 2481 qui avait proposé pour la première fois ce mécanisme (et notre RFC le remplace et passe du statut « expérimental » au statut « chemin des normes »). La méthode classique, laisser tomber des paquets, rappelée dans la section 1 du RFC, a toujours bien marché. Le réseau est traité comme une boîte noire, on y envoie des paquets et la seule signalisation reçue est le fait que certains paquets ne ressortent pas. Les protocoles de plus haut niveau, comme TCP (RFC 793) ou DCCP (RFC 4340) ralentissent alors leur débit. Mais cela fait perdre des données, juste pour envoyer une indication. D'où l'idée de prévenir avant que la congestion ne soit réellement installée, en modifiant deux bits de l'en-tête IP, pour indiquer que le routeur a du mal à suivre. Les machines terminales, si elles gèrent ECN, vont alors ralentir leur débit de manière plus efficace que si elles avaient attendu en vain un paquet (Active Queue Management, décrit dans le RFC 7567 et dans la section 4 de notre RFC 3168).

Avec la section 5, commence la description des changements effectués dans IP. Deux bits de l'en-têtes sont réservés pour ECN. Ils peuvent prendre les valeurs 01, 10 (ces deux valeurs, dites ECT, indiquant que l'expéditeur du paquet comprend ECN, l'intéressante section 20 explique pourquoi il y en a deux), 00 (pas d'ECN accepté) et 11 (dite CE, cette valeur indiquant la congestion). Ces deux bits se placent juste après le DSCP (l'ancien TOS) du RFC 2474. Si le routeur détecte que la congestion est proche, par exemple parce que ses files d'attente de sortie se remplissent, et que le paquet IP indique que l'expéditeur comprend ECN, alors le routeur peut, au lieu d'attendre la congestion, mettre un bit à 1 pour indiquer le problème au destinataire.

La section 6 du RFC décrit ensuite ce que le protocole de transport au dessus d'IP devrait faire avec les bits ECN (seul TCP est couvert dans ce RFC). 6.1 couvre TCP et modifie donc la section 3.1 du RFC 793. Deux nouveaux bits sont réservés dans l'en-tête TCP, permettant aux deux machines qui se parlent en TCP de se prévenir qu'elles comprennent ECN et, si nécessaire, d'indiquer le début de congestion, détecté en regardant les paquets IP modifiés par le routeur. Une fois ECN ainsi « négocié », les paquets IP porteront le bit ECN adapté, comme on le voit avec tcpdump :

12:04:58.525094 IP (tos 0x2,ECT(0), ttl 64, id 2069, offset 0, flags [DF], proto TCP (6), length 142) 192.134.4.97.50418 > 192.134.4.69.80: P 1:91(90) ack 1 win 46 <nop,nop,timestamp 3266115 18052032>
12:04:58.525242 IP (tos 0x0, ttl 64, id 61994, offset 0, flags [DF], proto TCP (6), length 52) 192.134.4.69.80 > 192.134.4.97.50418: ., cksum 0x1463 (correct), 1:1(0) ack 91 win 46 <nop,nop,timestamp 18052032 3266115>

ECT(0) désignant le motif 10 (« je comprends ECN »). Les paquets de pur acquittement TCP (le deuxième paquet affiché ci-dessus) ne portent pas de bits ECN.

Les sections 8 à 11 du RFC discutent de détails pratiques et d'évaluation d'ECN. Les section 18 et 19 sont consacrées au cas où une middlebox dans le réseau modifie maladroitement les bits ECN. Les sections 21 et 22 ne normalisent rien mais expliquent les choix qui ont été fait dans les en-têtes de paquets, en revenant sur les anciennes définitions de ces en-têtes.

L'Internet étant infecté de machines non gérées et non modifiables, comme certains routeurs bas de gamme (les CPE, par exemple), il est très difficile de déployer de nouveaux protocoles ou de nouveaux services. Ainsi, sept ans après sa normalisation formelle, ECN ne passe toujours pas avec certains sites, où les paquets marqués sont jetés. La section 6.1.1.1 du RFC discute ce problème (voir aussi http://www.icir.org/tbit/ecn-tbit.html).

C'est pour cela que beaucoup de systèmes d'exploitation viennent avec ECN coupé par défaut. Par exemple, sur Linux, on peut voir si ECN est accepté avec :

 % sysctl net.ipv4.tcp_ecn
net.ipv4.tcp_ecn = 0

et les développeurs discutent régulièrement de son activation par défaut. FreeBSD, lui, ne semble pas avoir de support ECN du tout ? Un guide complet de configuration pour les Cisco se trouve en http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftwrdecn.html. Pour MPLS, on peut consulter le RFC 5129. Autre lecture possible, une proposition d'activer ECN par défaut.

Depuis des années, des utilisateurs demandent un support de ECN dans echoping mais ça reste à développer. Il n'est pas évident que ECN doive être sous le contrôle des applications.

Parmi les différentes métriques qu'on peut définir sur l'Internet, une est particulièrement intéressante pour les utilisateurs, c'est le débit possible lors d'un transfert de fichiers. Si l'administrateur système tend à regarder plutôt le RTT avec ping, l'utilisateur préférerait savoir le temps qu'il lui reste avant l'arrivée des copies de la dernière saison de Desperate Housewives. D'où la définition formelle de ce débit, dans ce RFC.

Bulk Transfer Capacity (Capacité de Transfert en Gros) est donc définie comme la capacité du réseau à transporter des données en quantité importante lors d'une seule connexion (typiquement TCP). Il s'agit des données utiles, excluant les en-têtes des paquets, et intégrant la retransmission de données en cas de perte de paquets. La section 1 dit que la BTC peut tout simplement être définie comme la division de la quantité de données effectivement transmise par le temps écoulé. C'est typiquement elle qu'affichent des outils comme ncftp ou netpipe.

Toute implémentation de TCP, ou d'un protocole équivalent, devrait donc, dans le cas idéal, afficher la même BTC, puisque tous doivent suivre les mêmes principes de contrôle de la congestion (RFC 5681). Ce n'est pas forcément le cas en pratique, certaines mises en œuvre de TCP affichant des résultats non-linéaires dans certaines plages de fonctionnement.

La question des algorithmes utilisés en cas de congestion est détaillée en section 2. Les définitions habituelles de ces algorithmes laissent pas mal de latitude au programmeur qui les met en œuvre et la définition d'une métrique nécessite donc de rajouter quelques contraintes. Par exemple, en cas d'utilisation d'algorithmes « avancés » comme NewReno (RFC 2582), ceux-ci doivent être complètement spécifiés dans la définition de la métrique. Même chose avec les détails de l'algorithme de retransmission (RFC 2988).

La section 3 couvre ensuite certaines métriques secondaires qui peuvent aider à comprendre le comportement du réseau. Par exemple 3.6 explique la séparation entre le chemin aller et le chemin retour, beaucoup de liens sur Internet étant asymétriques.

Parmi tous les RFC qui définissent un sous-espace de nommage des URN, celui-ci vaut surtout par le nom d'un de ses auteurs, Norman Walsh.

Le choix d'un système d'identificateurs est toujours délicat, voire polémique. Ici, tout l'intérêt de ce RFC est l'évolution ultérieure d'un de ces auteurs. Dans notre RFC, Norman Walsh normalise un espace de type URN pour le consortium OASIS. Les URN sont souvent cités comme permettant plus de pérennité et moins de liens avec un protocole particulier que les classiques URL. OASIS les utilise donc pour identifier ses normes.

C'était sans doute l'opinion de Norman Walsh à l'époque. Mais, depuis, il raconte sur son blog que, finalement, les URN n'ont pas tenu leurs promesses :

• La permanence des URL n'est pas si mauvaise que ça : en pratique, le système d'enregistrement DNS a montré sa solidité, les autres systèmes n'ont pas un tel palmarès,
• Les URL ne sont pas forcément liés à un protocole, ou à un nom de fichier, ils peuvent être utilisés comme des noms, eux aussi.

Le protocole MPLS fonctionne via des labels, que les routeurs utilisent pour aiguiller les paquets vers la bonne sortie. Ces labels peuvent être distribués par plusieurs protocoles, dont BGP, pour lequel les détails sont décrits dans ce RFC.

Le principe de MPLS (décrit dans le RFC 3031) est de faire prendre par les routeurs des décisions d'aiguillage très vite, sans appliquer l'algorithme du plus long préfixe IP, en ne regardant qu'un court label. Mais comment un routeur MPLS (on dit un LSR) sait-il quel label correspond à quelle destination ? Parce que les autres LSR lui ont dit. Ils peuvent le faire par plusieurs protocoles. Le plus connu est LDP, normalisé dans le RFC 5036. Mais on peut aussi réutiliser BGP, l'inusable protocole de routage, dont le RFC 4760 décrit l'utilisation en contexte multi-protocoles. Cette utilisation est particulièrement intéressante si deux LSR font déjà tourner BGP entre eux.

Armé de cette extension à BGP, notre court RFC n'a plus grand'chose à spécifier : un LSR qui veut distribuer des labels MPLS les met dans un attribut BGP, décrit dans la section 3, chaque label étant associé à un préfixe IP. Le label sera alors toujours transmis avec le préfixe. (Le LSR doit aussi prévenir le LSR adjacent de cette capacité, ce que décrit la section 5).

Depuis que la pénurie d'adresses IPv4 a poussé au développement d'adressages privés, spécifiques à une organisation, plusieurs techniques ont été proposées pour donner à ces mondes privés la connexion à Internet malgré leurs adresses IP non-officielles. Ce RFC décrit une expérience, le système RSIP, qui n'a eu aucun succès.

Auujourd'hui, il est relativement courant que certains réseaux connectés à Internet n'utilisent pas des adresses IP officielles, publiques, attribuées via un RIR, mais des adresses privées. Ces adresses privées sont en général tirées du RFC 1918 et la principale motivation pour les utiliser est qu'il est très difficile (et donc coûteux, même si on ne paie pas directement) d'obtenir aujourd'hui des adresses IPv4. Par exemple, si on est client d'un FAI grand public, on n'obtient au mieux qu'une seule adresse IPv4 publique, même si on a deux machines chez soi.

Pour accèder quand même à Internet, plusieurs méthodes ont été développées comme l'utilisation de relais (ALG pour Application Level Gateway aussi appelés proxies) ou comme la traduction d'adresses (NAT pour Network Address Translation). Mais toutes ces techniques remettent en cause un principe cardinal d'Internet, la connectivité de bout en bout, qui permet de déployer de nouvelles applications sans se soucier des routeurs intermédiaires. Avec des adresses IP privées, fini le modèle de bout en bout et les applications comme les soft phones doivent consacrer beaucoup d'efforts à contourner les routeurs NAT. Quant aux protocoles de sécurité comme IPsec, ils protestent évidemment si les paquets sont modifiés en cours de route.

D'où la proposition de ce RFC d'essayer un nouveau système. D'abord, RSIP (Realm Specific IP) change le vocabulaire, il n'y a plus d'adresses privées ou publiques (le terme est conservé dans le RFC mais n'a pas d'importance en pratique, RSIP peut fonctionner entre deux domaines privés, par exemple), seulement des domaines (realms) d'adressage différents. À l'intérieur d'un domaine RSIP, les machines communiquent normalement. Entre deux domaines, les deux machines sont prévenues par un routeur que les adresses appartiennent à des domaines différents et qu'il faudra donc s'adapter (encapsuler les paquets dans un paquet à destination du routeur RSIP). Le protocole lui-même est décrit dans un autre RFC, le RFC 3103.

On voit que RSIP, contrairement au NAT pur, repose sur une connaissance explicite par chaque machine « terminale » de la présence des deux domaines. Mais, au lieu d'interroger un serveur public, comme avec STUN, ici, ce sont les routeurs qui préviennent les machines terminales de l'existence de deux domaines. Ainsi, le modèle de bout en bout est relativement respecté, chaque machine ayant connaissance de son adresse IP telle qu'elle est vue par l'autre machine.

Le routeur RSIP, à la frontière de deux domaines, peut attribuer aux machines d'un domaine des adresses IP de l'autre domaine ou bien, s'il manque d'adresses IP, des couples adresse IP / port, que la machine pourra utiliser.

RSIP n'a pas été un succès et n'a connu apparemment aucun déploiement, peut-être parce que, comme le prévient l'IESG dans un avertissement inséré au début du RFC, cette technique nécessiterait une modification de toutes les machines terminales et d'une bonne partie des routeurs.

Ce RFC complète le RFC 3031 sur MPLS en spécifiant l'encodage des labels sur le câble.

Le RFC 3031, qui a introduit le nouveau protocole MPLS restait dans les généralités sur la façon exacte dont les labels étaient encodés. Notre RFC le complète sur ce point. Un label fait donc 32 bits, dont 20 pour sa valeur, celle qui est affichée par certains traceroute.

La section 2.1 détaille concrètement le format et les valeurs spéciales comme 0 (IPv4 Explicit NULL Label qui, en bas d'une pile de labels, indique qu'on est arrivé à la fin du nuage MPLS et que le routage IP « normal » doit reprendre.

La section 2.2 couvre un problème plus délicat : déterminer le protocole de couche 3 transporté, lorsqu'on doit prendre une décision basée sur ce protocole. Rien dans le label MPLS n'indique ce protocole (contrairement à Ethernet où un champ de l'en-tête indique le protocole transporté, 0x0800 indique IPv4 et 0x86DD indique IPv6). Il faut donc pouvoir le déterminer en examinant le paquet (distinguer IPv4 et IPv6 de la sorte est facile, il suffit de regarder les quatre premiers bits du paquet, qui indiquent la version) ou par une autre méthode externe au paquet.

La section 2.3 couvre un autre cas compliqué : générer un paquet ICMP si nécessaire. Si un LSR (un routeur MPLS) doit transmettre un paquet IP mais que, pour une raison ou une autre, il ne le peut pas, il est censé transmettre un paquet ICMP à la source. Cela n'est pas possible à partir des informations MPLS seules. Et ce n'est pas toujours facile puisque le LSR n'a pas toujours de moyen de joindre la source en IP (par exemple si des adresses IP privées sont « tunnelées » dans un nuage MPLS public). Notre RFC détaille donc les méthodes possibles et les précautions à prendre.

MPLS est un protocole réseau souvent décrit comme « de couche 2,5 » qui est aujourd'hui très utilisé dans l'Internet. Ce RFC est le premier décrivant MPLS.

L'IETF travaille surtout sur les protocoles de couche 3 et de couche 4 mais a aussi une activité importante dans la couche 7 et fait parfois des incursions dans les couches inférieures à 3, par exemple avec PPP ou bien avec MPLS, sujet de notre RFC.

MPLS est un mécanisme de commutation rapide de paquets, fondé sur des adresses de format fixe et sans structure hiérarchique, les labels (ou étiquettes).

En effet, avec IP, un routeur doit, pour décider de l'étape suivante (next hop), dérouler l'algorithme de l'adresse la plus spécifique (longest match) puisque le routeur peut avoir une route pour 192.0.2.0/24 et une route plus spécifique (et qui doit donc être sélectionnée) pour 192.0.2.128/26. Bien qu'il existe de nombreuses implémentations de cet algorithme, et des structures de données spécialisées pour ranger la table de routage (comme les Patricia tries), il sera toujours plus lent qu'une table avec un index. C'est ce que propose MPLS. Les labels, contrairement aux adresses IP, n'ont pas de structure, ils ne sont qu'un index dans une table.

Les labels n'ont qu'une signification locale, à l'intérieur d'un même système autonome (ou groupe de systèmes autonomes). MPLS ne prétend pas pouvoir remplacer IP, simplement faciliter la commutation rapide des paquets à l'intérieur du réseau d'un opérateur.

MPLS fonctionne donc ainsi : à l'entrée du réseau MPLS, le premier routeur MPLS (on le nomme LSR pour Label Switching Router), décide d'une classe, la FEC (Forwarding Equivalence Class, ensemble des paquets qui sont transmis au même routeur suivant et dans les mêmes conditions, par exemple parce qu'ils font partie de la même classe de service), attribue un label au paquet et l'insère (le RFC 3032 donne un exemple d'une manière de réaliser cette insertion). Tant qu'on reste dans la partie MPLS du réseau de l'opérateur, la commutation se fait sur le label et l'adresse IP est ignorée. À la sortie de la partie MPLS du réseau, le label est retiré et le routage « normal » reprend.

La réalité est un peu plus compliquée, par exemple MPLS a le concept de « pile de labels » où des labels successifs sont ajouté et retirés par les LSR, permettant ainsi de créer des sortes de tunnels, par exemple pour décider finement de l'endroit où doit passer le trafic (traffic engineering).

Comment savoir si une liaison Internet passe par MPLS ? Il existe un patch pour le programme traceroute qui affiche les labels MPLS en utilisant ICMP, si les LSR sont configurés pour signaler ces labels (tous les opérateurs ne le font pas). Ce patch est par exemple intégré dans Gentoo ou dans le traceroute de NANOG et normalisé dans le RFC 4950. Voici un exemple de ce qu'il affiche (étapes 6 et 7) :

% traceroute f.root-servers.net 
traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 46 byte packets
 1  208.75.84.1 (208.75.84.1)  0.256 ms  0.129 ms  0.201 ms
 2  host166.datotel.com (63.97.187.166)  0.478 ms  0.349 ms  0.496 ms
 3  66.236.121.49.ptr.us.xo.net (66.236.121.49)  0.983 ms  1.098 ms  0.993 ms
 4  p4-3-0.MAR1.MarylandHeights-MO.us.xo.net (207.88.84.73)  6.737 ms  1.346 ms  1.477 ms
 5  p5-2-0-2.rar1.chicago-il.us.xo.net (65.106.6.157)  7.069 ms  57.625 ms  10.694 ms
 6  p6-0-0.rar2.denver-co.us.xo.net (65.106.0.25)  30.537 ms  30.471 ms  30.487 ms
     MPLS Label=134469 CoS=0 TTL=0 S=1
 7  p0-0-0d0.rar1.denver-co.us.xo.net (65.106.1.73)  33.935 ms  31.420 ms  30.463 ms
     MPLS Label=441165 CoS=0 TTL=0 S=1
 8  p6-0-0.rar1.sanjose-ca.us.xo.net (65.106.0.21)  72.947 ms  186.167 ms  72.648 ms

À noter que la valeur du label change à chaque routeur. Ce qu'affiche traceroute n'a donc d'intérêt que si on a accès au routeur en question.

Comment sont distribués les labels ? Par le biais d'un protocole spécialisé. Il en existe plusieurs comme le LDP (RFC 5036) ou comme BGP (RFC 3107). Certains opérateurs ont ainsi un réseau interne où toute la commutation est en MPLS. Parfois, ils se passent complètement de BGP pour le routage interne.

MPLS se nommait à l'origine tag switching et avait été popularisé par une société nommée Ipsilon, rachetée par Cisco depuis. C'est pourquoi ce terme de tag (officiellement remplacé par label) apparait parfois dans les documentations.

MPLS est aujourd'hui largement déployé et on trouve des mises en œuvre de MPLS pour les routeurs Cisco (voir des exemples de configuration), Juniper, pour Linux, etc.

Merci à Sarah Tharan pour ses explications et clarifications.

MPLS n'a pas été apprécié par tout le monde, entre autre parce qu'il revient aux traditionnels circuits (l'Internet ayant été bâti autour de la commutation de paquets). Van Jacobson avait ainsi écrit une vigoureuse critique, « Circuits: the search for a cure ».

L'utilisation massive du courrier électronique fait que, même sans compter le spam, chaque utilisateur professionnel reçoit désormais des dizaines et souvent des centaines de messages quotidiens dans sa boîte aux lettres. Il n'est donc plus question de les gérer entièrement à la main, il faut disposer d'un mécanisme de filtrage automatique.

On n'imagine plus aujourd'hui d'utiliser le courrier au bureau sans un tel mécanisme, permettant de mettre les messages dans des dossiers séparés selon, par exemple, la liste de diffusion concernée. Il en existe plusieurs, certains bâtis sur une interface graphique, d'autres autour d'un langage. Ces derniers, bien plus riches et puissants, sont variés. Le plus connu est procmail, célèbre pour son pouvoir expressif (on peut tout faire en procmail) mais aussi pour sa difficulté.

Sieve, l'objet de ce RFC, est nettement moins riche que procmail, ce qui peut être un inconvénient pour les utilisateurs avancés mais un avantage pour l'administrateur : permettre aux utilisateurs de configurer procmail revient à leur donner un accès shell alors que Sieve est plus contrôlable. Comme le note bien notre RFC, Sieve n'est pas un langage de Turing (par exemple, il ne connait pas les boucles). Ses capacités sont limitées, il est sandboxable, c'est-à-dire que l'administrateur système peut facilement limiter les choses que risquent de faire les auteurs de scripts Sieve.

Autre avantage par rapport à procmail, Sieve est normalisé et il en existe plusieurs mises en œuvre, dans Cyrus, dans GNU mailutils, dans Archiveopteryx...

Sieve était à l'origine normalisé dans ce RFC, mais il a depuis été mis à jour par le RFC 5228.

Les scripts Sieve sont écrits par l'utilisateur avec un éditeur ordinaire ou bien via une interface graphique. Ils sont installés sur le serveur de messagerie via FTP ou bien par le protocole spécifique Manage Sieve (actuellement à l'état d'Internet-Draft). Le programme de webmail SquirrelMail, par exemple, dispose d'une interface d'édition de scripts Sieve, qui gère le protocole Manage Sieve.

Voici un exemple de script Sieve tiré du RFC :

             if header :contains "from" "jfc" {
                discard;
             } elsif header :contains ["subject"] ["money"] {
                discard;
             } else {
                fileinto "INBOX";
             }

Sieve lui-même est très limité mais le langage dispose d'un mécanisme d'extensions (qui doivent être déclarées dans le script avec require). Certaines sont définies dès notre RFC (comme fileinto), d'autres sont définies via d'autres RFC, par exemple pour utiliser des tests anti-spam ou antivirus (RFC 3685, désormais RFC 5235), ou bien pour tester sur des sous-adresses (RFC 3598, désormais RFC 5233) (comme le RFC 3028, ces RFC ont depuis été remplacés par d'autres, plus récents.)

Comment combiner le mécanisme de signature DNSSEC (normalisé à l'époque dans le RFC 2535, aujourd'hui dans le RFC 4033) avec les mises à jour dynamiques du DNS par le protocole du RFC 2136 ? Ce RFC détaille les questions que cette combinaison pose et apporte des réponses.

La méthode la plus classique pour signer une zone DNS avec DNSSEC est de le faire sur une zone complète (typiquement un fichier de zone au format décrit par la section 5 du RFC 1035) avec un outil comme dnssec-signzone (dans BIND) ou bien OpenDNSSEC. Mais parfois, la zone est avitaillée (contenu créé, modifié et détruit) par les dynamic updates du RFC 2136. Peut-on encore la signer dans ce cas ? Oui. Ce RFC, successeur du RFC 2137 explique comment (ce RFC a lui-même été légèrement mis à jour par les RFC ultérieurs comme le RFC 4035). Le principe est simple : le client doit s'authentifier, par exemple avec TSIG (RFC 2845) et le serveur doit signer lui-même les données mises à jour (ce qui implique qu'il connaisse la clé secrète DNSSEC, ou bien qu'il aie accès à un dispositif de signature comme un HSM, cf. section 4.3). Un logiciel comme BIND sait aujourd'hui faire cela. L'articulation entre l'authentification de la mise à jour dynamique et celle, ultérieure, faite avec DNSSEC, est expliquée en sections 1.3 et 1.4.

Petit rappel en section 1.1 la mise à jour dynamique se fait en indiquant l'opération d'avitaillement souhaitée (ajout ou suppression, la modification se faisant en combinant les deux, section 2.5 du RFC 2136) et ses valeurs. Avec nsupdate, voici un exemple :

# Génération de la clé
dnssec-keygen -a HMAC-SHA256 -b 256 -n HOST dynamic.test-update

# Configuration de BIND 
key "dynamic.test-update." { 
        algorithm hmac-sha256; 
        secret "TRESSECRET="; 
}; 
zone "dynamic.test" {
       type master;
       file "dynamic.test";
        allow-update {
                key "dynamic.test-update.";
        };
};

# Commande de mise à jour
nsupdate -kKdynamic.test-update.+163+49211 -d <<EOF
server localhost
zone dynamic.test
update add toto$$.dynamic.test 600 A 192.0.2.1
send
EOF

# Le journal de BIND
May 20 08:28:19 golgoth named[836]: client ::1#65379: signer "dynamic.test-update" approved
May 20 08:28:19 golgoth named[836]: client ::1#65379: updating zone 'dynamic.test/IN': adding an RR at 'toto289.dynamic.test' A

L'authentification de la requête (ici, avec la clé contenue dans les fichiers Kdynamic.test-update.+163+49211*) est évidemment impérative. La signature avec DNSSEC ne servirait à rien, si n'importe qui pouvait modifier la zone ! La section 2 détaille cette authentification et explique que, même si les enregistrements DNS transmis sont déjà signés, cela ne doit pas être utilisé pour authentifier la requête de mise à jour, qui doit se faire avec TSIG (comme dans mes exemples) ou SIG(0) (RFC 2931, qui n'est jamais utilisé en pratique).

À noter que la même section (et aussi la 4.1) précise qu'on peut quand même envoyer des enregistrements déjà signés (à condition que la requête soit authentifiée autrement) mais BIND, dans sa version 9.7, ne les accepte pas.

La section 3 rappelle que l'acceptation ou pas d'une mise à jour d'une zone signée dépend de la politique locale. Avec un BIND, voici un exemple :

# Configuration de BIND
options {
        ...
        key-directory "/etc/namedb/keys"; // Les fichiers K* sont mis
	// dans ce répertoire
...
// Pas d'autre changement pour BIND, qui détecte tout seul que la zone
// est signée et qu'il est responsable de la signature de nouveaux
// enregistrements.

# Commande de mise à jour identique : le client n'a rien à faire

# Journal de BIND
May 20 08:43:53 golgoth named[1188]: client ::1#65345: signer "dynamic.test-update" approved
May 20 08:43:53 golgoth named[1188]: client ::1#65345: updating zone 'dynamic.test/IN': adding an RR at 'toto668.dynamic.test' A

# Et le nouvel enregistrement a été signé :
% dig +dnssec @localhost A toto668.dynamic.test 
...
;; ANSWER SECTION:
toto668.dynamic.test.   600     IN      A       192.0.2.1
toto668.dynamic.test.   600     IN      RRSIG   A 5 3 600 20100619064353 20100520054353 39751 dynamic.test. DyUHIRwUVMU2xHeYnNI/W/koF1M9tZHtxo93niWD1Tjp1ysWzZPCN/Js kOKemy4/XOtZlrwlposnrvSGBicl1jaMB57Ejg9GqYK9jV8Tj6+3BcGm...

Notons que BIND ne met pas en œuvre toutes les recommandations de cette section. Par exemple la 3.1 suggère fortement que la politique de modification puisse dépendre du type (A, AAAA, MX, etc) mais cela n'est pas possible avec BIND.

La mise à jour dynamique nécessite des règles spécifiques pour certains types d'enregistrements. On a vu que l'envoi de RRSIG (les signatures, appelées SIG à l'époque de notre RFC 3007) était permis par le protocole (mais pas par BIND). En revanche, la mise à jour des enregistrements de non-existence (les NXT à l'époque, devenus depuis les NSEC et NSEC3) est explicitement interdite (section 3.1.1) car ils doivent être correctement chaînés et seul le serveur connait toute la zone. BIND crée donc tout seul les NSEC et NSEC3 lors de l'ajout ou de la suppression d'un nom.

Enfin, les risques de sécurité entraînés par cette technique (puisque le serveur de noms doit connaître la clé privée, et qu'elle doit donc être « en ligne », d'accès plus facile pour un éventuel attaquant) sont détaillés en section 5.

Pour les détails pratiques de mise en œuvre, voir mon article « Combiner DNSSEC avec les mises à jour dynamiques ».