Mon blog

Lorsqu'on configure une machine connectée à l'Internet, on indique le routeur par défaut qu'elle doit utiliser. Que faire s'il tombe en panne ? Utiliser VRRP, le protocole que normalise notre RFC, qui permet à plusieurs routeurs de se surveiller mutuellement, et de se remplacer en cas de défaillance.

Prenons par exemple une machine Unix. Sa table de routage va être :

% netstat -r -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 wlan0
0.0.0.0         10.0.0.1        0.0.0.0         UG        0 0          0 wlan0

Ici, 10.0.0.1 est le routeur par défaut (on utilise parfois l'ancien terme, incorrect, de passerelle par défaut). Que se passe t-il s'il tombe en panne ? La machine n'a plus accès qu'à une petite portion de l'Internet, son réseau local (ici 10.0.0.0/24) et ceux pour lesquels il existe une route via un autre routeur. En IPv6, des mécanismes comme la découverte de voisin (RFC 4861) peuvent aider à trouver un autre routeur, s'il existe, mais les délais sont souvent trop élevés.

C'est évidemment inacceptable lorsqu'on veut pouvoir compter sur son accès Internet. D'où le protocole VRRP, normalisé à l'origine dans le RFC 2338, puis dans le RFC 3768. Cette ancienne version était spécifique à IPv4 et notre RFC 5798 est la première version de VRRP à être commune à IPv4 et IPv6. Elle porte le numéro 3. (Bien à tort, je trouve, le RFC parle de « IPvX » lorsqu'il veut désigner les deux familles, au lieu de simplement dire « IP ».)

La section 1 du RFC commence par introduire le problème et par expliquer quelles sont les solutions possibles, avant VRRP. Ainsi (section 1.2), en IPv4, les méthodes classiques étaient de faire tourner un protocole de routage comme RIP (RFC 2453) en mode « écoute seule », où la machine reçoit les mises à jour de route, pour en déduire les routeurs possibles, mais n'en envoie pas elle même. C'est ainsi que, à une époque lointaine, toutes les machines Unix en réseau faisaient tourner le programme de routage routed. L'utilisation d'un protocole de routage par des machines non-routeuses a entraîné tellement de mauvaise surprises que cette méthode n'est plus recommandée.

Il reste donc la découverte de routeur par le biais de messages ICMP (RFC 1256), jamais réellement déployée, ou bien les routes statiques, mises à la main ou via DHCP. Cette solution a l'inconvénient de l'absence de résistance aux pannes. Si le routeur par défaut s'arrête, il n'y a pas de mécanisme de bascule automatique.

En IPv6 (section 1.3), il y a une possibilité supplémentaire, le protocole de découverte de voisin du RFC 4861 qui permet, via la fonction Neighbor Unreachability Detection (section 7.3 du RFC 4861) de s'apercevoir qu'un routeur est en panne et d'en chercher un autre. Avec les paramètres par défaut de la découverte de voisin, un tel changement prend environ 40 secondes, ce qui est trop pour la plupart des applications.

La section 1.6 décrit le vocabulaire de VRRP. Notons qu'un « routeur VRRP » est un routeur qui parle le protocole VRRP mais qu'un « routeur virtuel » est l'ensemble des routeurs (un maître et plusieurs remplaçants) qui contribuent au fonctionnement continu d'une adresse IP vers laquelle pointent les routes.

La section 2 est un résumé du cahier des charges de VRRP : service continu pour une adresse IP, avec minimisation du temps de bascule vers un autre routeur physique, possibilité d'exprimer une préférence entre les différents routeurs physiques d'un même routeur virtuel, minimiser les bascules inutiles (par exemple lorsqu'un ancien maître redémarre), fonctionnement sur un réseau local coupé par des ponts qui doivent apprendre l'adresse MAC (section 2.4, qui détaille ce problème), etc. VRRP fonctionne sur tout type de réseau local mais, en pratique, est surtout utilisé sur Ethernet (l'annexe A décrit les spécificités des autres protocole comme le Token Ring).

La section 3 donne une vision générale du protocole VRRP. C'est donc un protocole d'élection. Les routeurs physiques communiquent par la diffusion restreinte sur le réseau local. Pour chaque routeur virtuel, identifié par un nombre nomé VRID (virtual router identifier), un maître est élu, et il sera le seul à router. Les routes des machines non-routeuses pointeront vers le routeur virtuel (cf. section 4.1 pour un schéma). Si on veut faire de la répartition de charge, il faut plusieurs routeurs virtuels, avec des VRID différents, cf. section 4.2 pour un bon exemple. Chaque routeur virtuel a une adresse MAC (il n'y a donc pas de problème avec les caches ARP).

Le maître diffuse périodiquement des messages VRRP advertisment. Si le maître n'en envoie plus, un remplaçant le... remplace, avec la même adresse IP (celle du routeur virtuel) et la même adresse MAC.

Le protocole est normalisé en section 5. Le format des paquets est en section 5.1 et 5.2. À noter :

• L'adresse IPv4 de destination des paquets de diffusion est 224.0.0.18 et la IPv6 est FF02:0:0:0:0:0:0:12.
• Le TTL des paquets doit être à 255 (cf . RFC 5082).
• VRRP n'utilise pas un des protocoles de transport classiques comme UDP, il a son propre protocole, numéroté 112.
• Le VRID est sur huit bits et il n'existe pas de mécanisme pour son allocation sur un réseau local, c'est à l'administrateur réseau de s'assurer de son unicité.

La section 6 est consacréee à la machine à états du protocole. Dans l'état d'attente (Backup, section 6.4.2), le routeur VRRP écoute passivement les annonces du maître et ne répond pas aux requêtes ARP ou ND pour l'adresse IP du routeur virtuel, et ignore les paquets envoyés à cette adresse. Si le maître n'envoie plus d'annonces (par défaut, c'est après trois annonces non reçues), le routeur passe dans l'état Maître.

Inversement, le routeur dans l'état Maître (section 6.4.3), répond aux requêtes ARP et ND pour l'adresse IP du routeur virtuel, traite les paquets destinés à cette adresse, route les paquets qu'il reçoit et envoie des annonces périodiques pour manifester qu'il est toujours en service.

La section 7 décrit de manière très détaillée ce que doit faire un routeur VRRP lorsqu'il reçoit ou émet les paquets VRRP. C'est là qu'est spécifié le fait qu'un routeur maître doit utiliser l'adresse MAC du routeur virtuel (et non pas celle du routeur physique) lorsqu'il envoie les annonces de bon fonctionnement. C'est pour permettre aux ponts et commutateurs de trouver le routeur physique. Cette adresse MAC est calculée (sections 7.3 et 12) et vaut 00-00-5E-00-01-{VRID} en IPv4 et 00-00-5E-00-02-{VRID} en IPv6.

Comme souvent sur un réseau, le diable est dans les détails pratiques. Ils font l'objet de la section 8. Ainsi, la section 8.1.2 rappelle que, puisque le maître utilise toujours comme adresse MAC celle du routeur virtuel présentée au paragraphe précédent, le client ne peut pas découvrir qu'un routeur physique en a remplacé un autre.

Parmi ces problèmes opérationnels, celui de la sécurité a droit à une section entière, la 9. En gros, VRRP n'a aucune sécurité. Les versions précédentes avaient tenté de mettre en place quelques mécanismes mais ils n'ont eu aucun succès et notre version 3 de VRRP les supprime. Notons que le problème n'est pas créé par VRRP : sur le réseau local, un méchant a énormément de moyens de perturber bien des protocoles indispensables, à commencer par DHCP et ARP. Par exemple, le méchant peut toujours répondre aux requêtes ARP pour l'adresse IP du routeur et lui voler ainsi le trafic. VRRP, où le méchant peut se faire désigner comme maître, n'aggrave donc pas tellement la situation.

VRRP a toujours souffert d'une polémique récurrente sur un brevet que détient Cisco et qui est apparemment effectivement appliqué (des développeurs VRRP ou bien de protocoles similaires ont, semble t-il, reçu des menaces des avocats de Cisco). L'existence de ce brevet n'est pas en soi contraire à la politique de l'IETF. En effet, celle-ci accepte des protocoles brevetés (il est difficile de faire autrement, compte-tenu du membre, et du caractère ridiculement futile, de la grande majorité des brevets logiciels) et demande juste que les prétentions soient publiques, ce qui est le cas ici. D'innombrables messages, souvent courroucés, ont été échangé sur les listes IETF au sujet de ce brevet. Cette situation a mené les développeurs d'OpenBSD à développer un protocole concurrent, CARP. On peut lire un point de vue (très outrancier) sur cette polémique dans l'interview de Ryan McBride. La réalité est plus complexe : les développeurs d'OpenBSD ont adopté une attitude d'affrontement immédiatement (« comme souvent », disent ceux qui connaissent les gens d'OpenBSD) et la bureaucratie IETF n'a pas fait preuve de bonne volonté et a réagi par un blocage complet. Aujourd'hui, les positions semblent hélas figées, au point que CARP, n'ayant pas eu de numéro de protocole officiel (en raison de leur refus de se plier aux procédures IANA, procédures d'ailleurs incorrectement décrites par McBride), a tout simplement pris celui de VRRP. Sur un réseau local, si on voit des paquets du protocole 112, il peut donc s'agir de CARP ou bien de VRRP.

En raison du brevet Cisco sur HSRP (le précurseur de VRRP), brevet dont la licence n'est apparemment disponible que selon les conditions RAND (bien insuffisantes pour du logiciel libre), il n'est pas évident de faire une mise en œuvre libre de VRRP. Il existe toutefois vrrpd et keepalived (aucun des deux ne semble intégrer IPv6).

La configuration de VRRP sur un routeur Juniper est documentée en Configuring VRRP and VRRP for IPv6 et Configure Basic VRRP Support. Cela donne, par exemple :

address 192.0.2.0/25 {
                    vrrp-group 12 {
                        virtual-address 192.0.2.65;
                        priority 80;
                    }

Notez que vrrp-group est un terme purement Juniper, c'est ce que le RFC appelle VRID (ici 12). Quant au concept de priorité (ici 80, donc moins que la priorité par défaut), il est décrit en section 5.2.4. Avec vrrpd, la même configuration serait :

 ip address 192.0.2.2 255.255.255.128 
 vrrp 12 ip 192.0.2.1
 vrrp 12 priority 80

C'est un très vieux projet qui voit enfin le jour avec ce RFC : documenter les différentes commandes qu'a accumulé le vénérable protocole FTP, après vingt-quatre ans d'existence sous sa forme actuelle (spécifiée par le RFC 959), et d'innombrables extensions ajoutées sans trop de coordination. FTP, qui a commencé en 1971, sous le nom de Data Transfer Protocol (RFC 171), reste très utilisé un peu partout et l'absence d'un registre de ses commandes et extensions pouvait entrainer des problèmes de portabilité.

Certaines des extensions suivaient le cadre du RFC 2389, qui normalisait un mécanisme commun, souvent désigné sous le nom de FEAT (FEATure). Mais ce n'est pas le cas de toutes. Désormais, RFC 2389 ou pas, toutes les commandes et extensions sont dans un registre unique.

Ce registre est décrit en section 2. Nommé FTP Commands and Extensions, il comprend notamment, pour chaque entrée, les informations suivantes :

• Nom de la commande (en MAJUSCULES), s'il y en a une (certaines extensions impliquent plusieurs commandes et, dans ce cas, il n'y a pas de nom de commande). Par exemple, LIST (obtenir la liste des fichiers distants) ou PROT+ (cette dernière étant, comme son nom l'indique, une modification de PROT, qui permet de spécifier le niveau de sécurité requis pour un transfert, voir RFC 4217, section 9).
• Le nom de l'extension, par exemple MDTM (date de modification d'un fichier, cf. RFC 3659) ou hist (fourre-tout pour les vieilles extensions, abandonnées). Si l'extension suit le cadre du RFC 2389, pas de problème, ce nom est celui donné en réponse à la commande FEAT et il est noté en MAJUSCULES. Sinon un nom est inventé et indiqué en minuscules.
• Le caractère obligatoire ou bien facultatif de cette extension. 'm' signifie mandatory (obligatoire), 'o' optional (facultatif) et 'h' historic (abandonné).

Notre RFC 5797 contient en section 3 le registre initial (on peut trouver la version actuelle en ligne). Il contient plusieurs codes « pseudo-FEAT » (qui n'utilisent pas réellement le système FEAT du RFC 2389 et sont donc écrits en minuscules), comme base (commandes obligatoires), secu (extensions de sécurité du RFC 2228), ou nat6 (extensions pour aider avec les NAT ou avec IPv6, dans le RFC 2428).

C'est ainsi que la commande AUTH est enregistrée comme AUTH+ pour tenir compte des extensions TLS qui avaient été normalisées dans le RFC 4217. On trouve aussi, par exemple, une commande LANG, normalisée dans le RFC 2640, et qui permet d'internationaliser FTP, entre autres en demandant des messages dans d'autres langues que l'anglais.

Les sections 2.4 et 2.5 donnent des explications sur la création du registre initial, à partir des commandes de base (RFC 959), toutes obligatoires (comme USER, ou RETR, l'équivalent du GET de HTTP) ou d'essais depuis abandonnés (par exemple par le RFC 1123).

Créer un registre est une chose, mais il faut le faire vivre ensuite : il est prévu que de nouvelles extensions à FTP soient enregistrées. Selon quels critères ? La section 2.3 (et la section 5) les formalise. L'idée est que le registre sert à éviter les conflits dans les codes utilisés. Il ne signifie pas que les extensions qu'il liste sont « approuvées » ou bien qu'elles représentent une « bonne idée ». Les vérifications faites avant l'enregistrement sont :

• Qu'une spécification publique de l'extension existe, par exemple un RFC. Tout RFC convient. Pour les autres documents, l'expert appelé pour vérifier l'enregistrement devra s'assurer que l'autre document a bénéficié d'un examen sérieux.
• Que l'extension a effectivement été mise en œuvre dans un client ou un serveur FTP (dans la tradition du running code de l'IETF).

C'est uniquement si l'extension doit être marquée comme obligatoire qu'il faudra un RFC de statut « Chemin des normes ».

Ces règles sont donc une légère variante des règles « Norme nécessaire » et « Examen par un expert » du RFC 5226.

Un ultra-court RFC pour dire simplement que l'IETF a abandonné tout travail sur la représentation en HTML de la norme de méta-données Dublin Core (cf. RFC 5013).

Cette norme avait connu un RFC, le RFC 2731 mais, depuis, tout le travail d'évolution s'est fait au sein de la Dublin Core Metadata Initiative. C'est donc désormais sur le site Web de celle-ci qu'il faudra aller chercher des informations.

Le langage de filtrage de courrier Sieve, normalisé dans le RFC 5228 a une syntaxe qui lui est propre et qui nécessite le développement d'outils spécifiques pour l'analyser. Or, il existe un format générique pour lequel d'innombrables outils ont été développés, XML. Ce RFC décrit donc un moyen de représenter les scripts Sieve en XML, ainsi que les règles de conversion de et vers le format traditionnel.

La syntaxe officielle de Sieve est celle d'un fichier texte, format simple et facilement traitable par des programmes. Mais la plupart des utilisateurs de Sieve, n'ayant pas d'expertise avec les langages formels, ne lisent et n'écrivent pas le Sieve dans ce format. Ils se servent d'outils spécialisés qui leur présentent le script sous une forme plus claire pour le non-spécialiste.

Le format XML étant très répandu, des facilités existent pour développer de tels outils, si la syntaxe d'entrée est du XML (section 1 du RFC). Comme ce n'est pas le cas de Sieve, notre RFC 5784 normalise une correspondance entre le format classique de Sieve et XML, permettant les conversions dans les deux sens. En outre, ce schéma XML ajoute la possibilité de donner des indications sur la présentation visuelle souhaitée, un point qui manquait dans la syntaxe Sieve classique (et qui était en général remplacé par des commentaires structurés spécifique à un logiciel d'édition).

La section 3 du RFC rappelle les particularités de la grammaire de Sieve : pour permettre les extensions futures, le langage n'a pas de mots réservés. La syntaxe est fixe (les extensions ne peuvent pas la modifier ou l'étendre). Toute extension peut ajouter des mots-clés. Et il existe déjà de très nombreuses extensions.

Un script Sieve est constitué de commandes, qui sont des actions ou des contrôles (mais la syntaxe ne fournit aucun moyen de distinguer les deux, seule la connaissance du mot-clé le permet). La commande est composée d'un mot-clé, suivi d'arguments, d'un test optionnel et d'un bloc de commandes optionnel. Voici quelques exemples :

stop;   /* Un contrôle tout nu, sans argument ou bloc */
require "fileinto"; /* Un contrôle avec un seul argument */
if true {stop;}   /* Un contrôle avec un test et un bloc de
   commandes */
discard;   /* Une action toute nue, sans argument */
fileinto "folder";  /* Une action avec un argument */

La section 4 définit la représentation en XML. Les contrôles sont représentés par l'élement <control> et les actions par l'élément <action>. Les exemples ci-dessus seraient donc, en XML :

   <control name="stop"/>
   <control name="require"><str>fileinto</str></control>
   <control name="if">
     <test name="true"/><control name="stop"/>
   </control>

   <action name="discard"/>
   <action name="fileinto"><str>folder</str></action>

Les directives permettant de contrôler la représentation visuelle du script Sieve sont en section 4.1. Par exemple, l'élement <displayblock> permet de groupe ensemble des commandes Sieve :

     <displayblock name="File filter list mail" order="1"
                   group="FILE_TO_FOLDER" enable="true">
       <control name="if">
         <test name="header">
           <tag>is</tag>
           <str>Sender</str>
           <str>owner-ietf-mta-filters@imc.org</str>
         </test>
         <action name="fileinto">
           <str>filter</str>
         </action>
       </control>
     </displayblock>

et l'élément <displaydata> d'indiquer du texte qui doit être montré à l'utilisateur lors de l'édition.

Pour permettre l'aller-retour dans les traductions de XML en Sieve, la section 4.2 spécifie des commentaires Sieve structurés permettant de garder l'information de présentation lors de la traduction. Ainsi, le code XML ci-dessus serait « sauvegardé » en :

/* [* name="File filter list mail" order="1" group="FILE_TO_FOLDER" enable="true" */
if header :is "Sender" "owner-ietf-mta-filters@imc.org"
...

où [* indique le début d'un displayblock.

Afin de permettre la validation des scripts Sieve en XML, notre RFC propose deux schémas, un en langage W3C Schema (annexe B), l'autre en Relax NG (annexe C). Prenons le schéma en RelaxNG (xmlsieve.rnc) et testons un script :

% rnv xmlsieve.rnc test2.xml
test2.xml

Parfait, il est bien valide.

L'annexe A contient un exemple complet d'un script Sieve (celui de la section 9 du RFC 5228) en XML. Sa version XML est disponible en rfc5228-sec9.xml et sa version sieve en rfc5228-sec9.sieve.

Voici autre un exemple de script Sieve en XML complet. Ce script jette tous les messages qui n'ont pas de champ Date: ou de champ From:, ainsi que les messages dont l'expéditeur est foobar@example.org :

<?xml version="1.0" encoding="utf-8"?>
<sieve xmlns="urn:ietf:params:xml:ns:sieve">
   <control name="if">
     <test name="anyof">
       <test name="not">
         <test name="exists">
           <list><str>From</str><str>Date</str></list>
         </test>
       </test>
       <test name="header">
         <tag>contains</tag>
         <str>from</str>
         <str>foobar@example.org</str>
       </test>
     </test>
     <action name="discard"/>
   </control>
</sieve>

Pour le traduire en script Sieve classique, on peut utiliser le programme XSLT qui figure dans l'annexe D du RFC (et qui est également disponible en xml2sieve.xslt) :

% xsltproc xml2sieve.xslt test.xml

if anyof ( not ( exists [ "From", "Date" ] ), 
   header :contains "from" "foobar@example.org" )
{
  discard;
}

En dehors de ce programme XSLT (qui ne va que dans un seul sens, depuis XML vers Sieve), je ne connais pas encore de mise en œuvre de ce RFC.

Le spam est un tel problème pour le courrier électronique d'aujourd'hui, que de nombreuses techniques ont été développées pour le limiter. Comme toujours en sécurité informatique, il n'y a pas de solution idéale, juste des compromis entre trop de sécurité (et on bloque du courrier légitime) et pas assez (et on est noyés par le spam). Dans cet arsenal de techniques, une des plus courantes et des plus contestées est la liste noire, ou DNSBL (DNS black list). Bien que très largement déployée, elle n'avait jamais fait l'objet d'une documentation formelle, ce qui est désormais le cas, avec ce RFC.

Le principe d'une DNSBL est de distribuer, via le DNS, de l'information sur des machines (identifiées par leur adresse IP) qui ont envoyé du spam, ou bien sont susceptibles de le faire. Le problème n'est pas tant dans la technique utilisée (même si certains déplorent qu'on charge la barque du DNS en lui confiant de plus en plus de missions) que dans la gestion de ces listes. La grande majorité sont gérées de manière opaque, par des gens irresponsables, qui inscrivent ou désinscrivent un peu comme ça leur chante.

Ce RFC a été développé par le groupe de travail IRTF ASRG. L'auteur du RFC, John Levine, est un des porte-paroles les plus fréquents des « éradicateurs », ceux qui sont prêts à faire beaucoup de dégâts collatéraux pour lutter contre le spam. Le RFC a le statut de « pour information », utilisé pour documenter les techniques qui sont utilisées et donc intéressantes à connaître, mais qui ne sont pas forcément approuvées par l'IETF. Il a failli être sur le chemin des normes, à la demande de l'ASRG, mais en a été retiré suite à une virulente discussion sur la liste principale de l'IETF.

Le document commence (section 1) par un peu d'histoire. En 1997, la première liste noire, RBL (Real-time blackhole list) avait été créée par Paul Vixie et Dave Rand. Elle était distribuée avec BGP, le DNS n'est venu qu'après. (Tout le monde a un client DNS, ce qui n'est pas le cas de BGP.) Elle existe toujours sous le nom de MAPS même si elle n'a plus grand'chose à voir avec l'effort du début.

Le terme de RBL étant désormais une marque déposée, le RFC suggère de parler plutôt de DNSBL (DNS Black List) et, pour celles qui sont utilisées pour autoriser plutôt que pour interdire, de DNSWL (DNS White List). Pour parler des deux simultanément, le RFC utilise DNSxL. (Notons que la différence entre les deux est uniquement dans l'usage que le client en fait, cf. section 2.2.)

Ce RFC décrit le fonctionnement technique des DNSxL et le protocole avec lequel elles communiquent leurs résultats. Il ne parle pas des questions de la maintenance de ces listes, ni de leur politique d'inscription/désinscription, qui feront peut-être l'objet d'un autre RFC.

La section 2 attaque la technique : une DNSxL est une zone du DNS, où les noms sont formés à partir de la clé d'accès à la liste. Cette clé est presque toujours une adresse IP (la section 3 traite des listes de noms) et le mécanisme d'encodage est inspiré de celui de in-addr.arpa (section 2.1) : on inverse les octets et on ajoute le nom de la liste. Ainsi, pour chercher si 192.0.2.129 est listé dans la DNSxL list.example.com, on fera une requête DNS pour 129.2.0.192.list.example.com. Si 192.0.2.129 est listé, la zone doit contenir un enregistrement de type A (normalement, « adresse », mais utilisé dans un autre sens par les DNSxL) et peut contenir un enregistrement de type TXT qui stockera un message qu'on pourra afficher à l'utilisateur bloqué. Les données dans une DNBxL sont donc des données DNS ordinaires et on peut donc y accéder par des clients DNS comme dig, ici avec la liste sbl-xbl.spamhaus.org :

% dig A 129.2.0.192.sbl-xbl.spamhaus.org 
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2015
...

Ici, on récupère le code NXDOMAIN (No Such Domain) donc cette adresse IP n'est pas sur la liste. Essayons avec une adresse qui est sur la liste :

% dig 158.2.0.192.sbl-xbl.spamhaus.org
...
;; ANSWER SECTION:
158.2.0.192.sbl-xbl.spamhaus.org. 684 IN A     127.0.0.4

La valeur de l'enregistrement DNS est typiquement 127.0.0.2 mais d'autres sont possibles (section 2.3).

En IPv6, pas de grosses différences, mais notons que, ici, le RFC fait œuvre créative car il n'existe pas encore de DNSxL IPv6 (pour IPv4, le RFC documente un état de fait). La section 2.4 précise les détails.

C'est tout pour le principe. Parmi les détails, la section 5 couvre le cas où une DNSxL arrête de fonctionner correctement et ne contient plus aucun enregistrement (ou au contraire répond systématiquement quelle que soit l'adresse, cas qui s'est déjà produit). La liste doit contenir une entrée pour 127.0.0.2 et ne pas en contenir pour 127.0.0.1. Tester ces deux clés permet de voir si le fonctionnement technique de la liste est correct.

Comment utilise t-on une DNSxl ? La section 6 couvre la configuration des clients. Par exemple, avec le MTA Postfix, la configuration se fait ainsi :

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination,
            reject_rbl_client sbl-xbl.spamhaus.org, ...

et l'examen du journal permet de voir les rejets de certains émetteurs :

Jan 20 21:28:02 lilith postfix/smtpd[7442]: NOQUEUE: reject: RCPT from unknown[192.0.2.158]: 554 5.7.1 Service unavailable; Client host [192.0.2.158] blocked using sbl-xbl.spamhaus.org; http://www.spamhaus.org/query/bl?ip=192.0.2.158; from=<dioxidep@pnc.com.au> to=<info@generic-nic.net> proto=ESMTP helo=<[192.0.2.158]>

La configuration ci-dessus est de tout ou rien. Si l'adresse IP du client SMTP est dans la DNSBL, il est rejeté. Comme le rappelle le RFC, une autre utilisation est de tester plusieurs listes noires et de faire un calcul de pondération entre elles, ne rejetant le message que si l'émetteur se trouve dans plusieurs listes. C'est ce que fait SpamAssassin, par exemple. Cela protège contre les listes excessivement zélées (ou contre les listes mortes, qui peuvent répondre positivement pour toutes les adresses soumises, entraînant des rejets systématiques).

Et comment savoir si on est dans une liste noire ou pas ? Il existe des outils pratiques et j'en recommande deux : rblcheck qui permet d'interroger plusieurs listes noires d'un coup et check-auth@verifier.port25.com, une adresse de courrier à laquelle on peut écrire, et qui vous renvoie automatiquement un rapport détaillé sur votre message et les machines qui l'ont transmis, y compris leur éventuelle présence dans les listes noires. Mais on peut aussi citer (accès Web uniquement) MultiRBL (qui permet de construire des URL REST comme http://multirbl.valli.org/lookup/198.51.100.1.html), Robtex (même remarque sur les URL) ou MXtoolbox.

La section 7, enfin, couvre le problème de sécurité général. Comme le résume bien le RFC, utiliser une liste noire externe à votre organisation, c'est sous-traiter la sécurité à un tiers. Celui-ci peut faire un meilleur travail que vous (la plupart des listes noires maintenues localement sont statiques et jamais mises à jour) ou au contraire un bien pire. Il faut donc être bien conscient de ses responsabilités. Contrairement à ce que prétendent les porte-paroles officiels des gros FAI, les listes noires ne sont pas parfaites : elles comprennent des faux négatifs (spammeurs non listés) et des faux positifs (innocents listés). Tenir à jour ces listes est un gros travail et personne ne peut croire à la vérité des affirmations d'un gros FAI, dont un porte-parole à l'IETF prétend lire et traiter tous les rapports de faux positifs envoyés par ses clients.

Idéalement, l'administrateur système qui configure son serveur de messagerie pour utiliser une liste noire devrait passer du temps à s'informer sur la ou les listes envisagées, étudier leur politique et leur pratique, et surtout suivre son évolution dans le temps puisque les listes changent. Mais très peu le font.

Ne nous faisons pas d'illusion : l'Internet n'est pas un monde de gentils Bisounours où tout le monde coopère pour le bien commun, c'est un espace de concurrence et la polémique à l'IETF reflétait simplement la différence entre d'une part les gros FAI, plutôt éradicateurs, qui connaissent et regardent les autres de haut (la remarque « vous ne gérez pas des millions de boîtes aux lettres, donc taisez-vous » était la plus fréquente lors de la discussion) et d'autre part les petits FAI et les utilisateurs, bien forcés de subir.

Un rapport intéressant, dû à Bruno Rasle et Frédéric Aoun, avait bien montré le manque de sérieux de tant de listes noires : « Blacklists anti-Spam : plus de la moitié des entreprises indexées ». Plus récemment, on peut aussi lire un intéressant article sur la mésaventure survenue à Gandi avec SORBS.

Notons pour terminer que les DNSxL posent d'autres problèmes de sécurité que les faux positifs : comme elles sont consultées à chaque message, le gérant de la DNSxL peut avoir une idée de qui sont vos correspondants, et le DNS n'étant pas très sûr, les DNSxL ne le sont pas non plus (aujourd'hui, aucune n'est signée avec DNSSEC).

Merci à Olivier Fauveaux et Serge Aumont pour leurs remarques et corrections.

Les URI, définis par le RFC 3986, sont des identificateurs qui commencent par le nom d'un plan (scheme). Celui-ci identifie parfois (mais pas toujours) le protocole de communication utilisé. Notre RFC enregistre le plan rsync pour l'application du même nom. Des URI comme rsync://rsync.samba.org/rsyncftp/ seront désormais légaux.

En effet, un URI standard doit avoir un plan enregistré dans le registre IANA, selon les procédures du RFC 4395. Bien que les URI de plan rsync soient très courants, ce plan n'avait jamais été formellement enregistré. La section 2 de notre RFC remédie à ce manque en fournissant le formulaire d'enregistrement. La syntaxe des URI rsync est donc :

rsync://[user@]host[:port]/source

par exemple, rsync://rsync.samba.org/rsyncftp/. Le port par défaut est 873. Contrairement à beaucoup d'autres plans, notamment http, il n'existe qu'une seule application qui utilise ce plan.

Ce RFC est essentiellement un document historique. Écrit il y a pas mal d'années, il est publié aujourd'hui (avec quelques mises à jour et annotations) dans le cadre des efforts de définition d'une future architecture de routage inter-domaine dans l'Internet.

Sur Internet, il existe en effet deux sortes de routage, l'intra-domaine qui concerne les opérations se déroulant à l'intérieur d'un unique système autonome, donc sous une direction commune, et l'inter-domaine, qui traite du routage entre systèmes autonomes (les « domaines »), lorsqu'il faut franchir des frontières administratives, ce qui est bien plus complexe que de simplement pousser des paquets. Aujourd'hui, l'essentiel du routage inter-domaine est fait avec le protocole BGP (RFC 4271, et BGP avait été originellement conçu, en 1989, en réponse aux exigences du RFC 1126) et l'architecture sur laquelle il repose montre des sérieuses limites, notamment en matière de passage à l'échelle : pourrons-nous faire ecnore croître l'Internet, et à un coût raisonnable ? (La section 2 du RFC résume l'état actuel du routage inter-domaine et de ses limites. Elle est complétée sur ce dernier point par la section 5. Le routage intra-domaine est, lui, considéré comme globalement satisfaisant.)

Il existe en ce moment beaucoup d'activité à l'IETF et à l'IRTF autour de ce thème d'une future architecture de routage. Elle porte, par exemple, sur des idées comme la séparation de l'identificateur et du localisateur. Le groupe de l'IRTF concerné est le Routing Research Group et ce groupe travaille à la définition d'un cahier des charges pour la future architecture. Parmi les travaux étudiés à cette occasion, figurent les discussions qui ont eu lieu il y a plusieurs années, à partir du RFC 1126, et qui sont désormais synthétisées dans ce RFC. (Attention, donc, en le lisant, une bonne partie a été écrite au tout début du siècle.)

La section 1 résume la longue genèse de ce document, qui prend sa source dans les travaux d'un groupe informel nommé Babylon en 2001. Le texte original a été préservé, des ajouts indiquent ce qui a pu changer dans l'Internet depuis.

La section 3 du RFC détaille chacune des exigences du RFC 1126, dans l'ordre du RFC original, en expliquant dans quelles mesures elles sont satisfaites aujourd'hui, avec un Internet radicalement différent de ce qu'il était en 1989, où sa taille était minuscule, selon les critères d'aujourd'hui, et où sa connectivité était encore très hiérarchique, avec NSFnet au sommet.

Ainsi, l'exigence indiquée en section 3.1 e) du RFC 1126, Provide paths sensitive to user policies est décrite dans notre RFC 5773 en section 3.1.2.1.5 comme toujours valide (selon le texte écrit en 2001 par Babylon) mais très imparfaitement faite (loose source routing, QoS) et les notes de 2006 à nos jours ajoutent qu'il faut plutôt parler d'échec complet que de déploiement insuffisant.

Mais il y a aussi des succès, le principal étant évidemment que l'Internet marche. Des points qui semblaient primordiaux en 1989 et même encore en 2001 ont sombré dans une relative indifférence (comme la QoS, justement).

Les plus gros problèmes sont peut-être quantitatifs. Le RFC 1126, section 3.4 c) demandait innocemment que le futur (à l'époque) protocole permette 10 000 systèmes autonomes et 100 000 réseaux. Ces nombres ont été largement dépassés mais il n'est pas garanti, loin de là, que cette croissance pourra durer éternellement. En 2001, Babylon s'inquiétait pour l'épuisement de l'espace de numérotation des systèmes autonomes (16 bits à l'époque) et cette inquiétude se retrouve dans notre RFC en section 3.1.2.4.3. Le RFC a finalement une note disant que le déploiement du RFC 4893 est en train de résoudre ce problème mais que ce déploiement prend plus de temps que prévu.

Dans tout exercice d'ingéniérie, le plus dur n'est pas en général de définir les buts (« Que ça marche bien ! Que ça ne soit pas cher ! Que n'importe qui puisse s'en servir ! Que cela fasse le café ! ») mais les « non-buts », ce qu'on renonce à obtenir car cela nous entrainerait trop loin et condamnerait le projet. Il est rare que les non-buts soient explicites, car cela focaliserait la critique. Mais le RFC 1126 avait une telle section, la numéro 4, analysée en section 3.1.3 de notre RFC 5773. Par exemple, le RFC 1126 expliquait que la connectivité de tous n'était pas un but. En effet, elle nécessite la coopération de systèmes autonomes intermédiaires, coopération qui ne peut pas être obtenue par des moyens techniques. Ce simple non-but déclenche une grande discussion dans le RFC 5773 en section 3.1.3.1. N'est-il pas contraire à la mission de connectivité totale de l'Internet ? Le RFC 1126 n'était-il pas excessivement prudent car il avait été écrit dans un monde où IP n'était pas encore le protocole universel qu'il était devenu en 2001 ? (Et qu'il n'est plus depuis que IPv4 et IPv6 coexistent.) Faut-il chercher la connectivité universelle (qu'on n'a pas, même avec IPv4 seul, notamment à cause du NAT) ou le « routage universel » ?

De même, la répartition de charges était considérée par le RFC 1126 comme un nom but, même si la section 3.1.3.3 du RFC 5773 fait observer que le désir de faire passer le trafic d'un domaine par plusieurs fournisseurs est une des causes de la désagrégation des préfixes annoncés, et donc de la croissance de la table de routage.

La section 3 remet les choses dans le contexte de l'époque. En 1989, lorsque le RFC 1126 a été écrit, la famille de protocoles OSI était encore considérée sérieusement par certains (elle sera abandonnée au début des années 1990, sans jamais avoir connu de déploiement significatif). Le développement de BGP s'est donc fait dans un contexte marqué par la présence d'un concurrent, IDRP (alias ISO 10747, section 3.2 de notre RFC). La section revient donc sur l'histoire tourmentée (et parfois contestée) de cette époque, marquée par l'émergence du concept de système autonome et par celle de l'idée de routage non-hiérarchique. Parmi les documents importants cités par le RFC, il y a, par exemple, Internet Architecture Workshop: Future of the Internet System Architecture and TCP/IP Protocols ou bien le chapitre 14 du livre Open Systems Networking. Le RFC considère que, si IDRP n'a jamais été réellement déployé, du moins certaines des idées qu'il contenait ont inspiré les développements dans le monde Internet. (Beaucoup d'autres ont été abandonnées : pensez au chapitre sur les non-buts. Comme tous les protocoles OSI, IDRP ne pouvait pas résister à la conception en comité, où toute fonction demandée était forcément incluse, de peur de fâcher quelqu'un.) D'autres idées d'IDRP, comme l'utilisation de certificats X.509 pour signer les annonces, n'ont pas encore percé, bien qu'elles soient régulièrement évoquées pour BGP.

BGP a donc suivi son bonhomme de chemin, première version dans le RFC 1105 en juin 1989, deuxième dans le RFC 1163, en juin 1990, troisième dans le RFC 1267 publié en octobre 1991 et enfin quatrième dans le RFC 1771 en mars 1995 (BGP-4 est désormais normalisé dans le RFC 4271). IDRP est, lui, bien oublié, il n'a même pas d'article dans Wikipédia .

Parmi les autres efforts pour développer un mécanisme de routage inter-domaine, une place particulière doit être faite à Nimrod (RFC 1753 et RFC 1992, section 3.3 de notre RFC). Le projet Nimrod, de 1994 à 1996, visait à créer une architecture de routage complètement nouvelle. S'il n'a pas débouché, les idées explorées à ce moment ont néanmoins beaucoup influencé les recherches ultérieures. Par exemple, Nimrod, contrairement à pas mal de projets « table rase » qui croient naïvement qu'on les laissera tout détruire et repartir de zéro, mettait explicitement au premier plan la nécessité d'être déployable progressivement, c'est-à-dire de ne pas rester bloqué dans le dilemne de l'œuf et de la poule, où personne n'adopte le nouveau système car il n'y a aucun intérêt à le faire, tant qu'on reste tout seul. Cette exigence de déploiement progressif reste essentielle aujourd'hui : l'Internet n'est plus un jouet de chercheurs, on ne peut plus l'arrêter pour voir, ni imposer un changement d'un seul coup, comme l'avait été l'abandon de NCP.

À noter que l'architecture de Nimrod faisait partie des projets concurrents pour le système « IPng », qui devait prendre la suite d'IPv4. Trop ambitieux, Nimrod avait été rejeté au profit du futur IPv6 qui se limitait au format des paquets IP et ne tentait pas de réformer l'architecture de routage inter-domaine (qui reste donc la même qu'avec IPv4).

Si Nimrod est relativement connu des gens de l'IETF, PNNI, résumé en section 3.4, l'est beaucoup moins. Il venait des travaux de l'ATM forum et n'avait guère eu de succès, peut-être parce que trop lié à une architecture vite dépassée, ATM.

Le travail des chercheurs sur le routage interdomaine ne s'est jamais arrêté. La section 4 est donc consacrée aux travaux récents en ce domaine. Ces recherches sur un objet très mouvant, le gigantesque Internet d'aujourd'hui, doivent s'adapter sans cesse. Ainsi, rappelle notre RFC, la connexion d'un site à plusieurs FAI devient de plus en plus fréquente et il est urgent de trouver un mécanisme qui permette de la faire dans de bonnes conditions.

Parmi les travaux de recherche des dernières années, le RFC cite NewArch (section 4.2). Datant de 2000-2001, financé par une agence gouvernementale états-unienne, NewArch avait, dans son cahier des charges, des préoccupations inquiétantes comme la protection des rapaces détenteurs de « propriété intellectuelle » ou comme la nécessité de développer des systèmes de surveillance plus perfectionnés.

Sans doute trop récents, puisque l'essentiel du RFC 5773 avait été fait avant 2006, les projets comme Clean Slate et GENI qui, pour l'instant, ont surtout produit du vent, ne sont pas mentionnés.

Quel est l'état de la réflexion sur les limites et défauts du modèle actuel de routage inter-domaine ? La section 5 répond à cette question, dans la suite du RFC 3221. Parmi les nombreux problèmes identifiés dans cette section, la propagation mondiale des erreurs locales (section 5.3), magnifiquement illustrée par l'attaque involontaire contre YouTube, l'absence de solution satisfaisante à la forte demande des utilisateurs pour les connexions à plusieurs FAI (section 5.4 et RFC 4116), la question de la sécurité, puisque n'importe quel routeur BGP peut annoncer n'importe quelle route (section 5.11, RFC 4593 pour le cahier des charges des efforts actuels visant à normaliser une solution et certification et, pour un exemple récent d'alerte de sécurité, la faille Kapela & Pilosov.

Comme toutes les listes de problèmes, celle-ci peut donner l'impression que BGP est fichu et on peut se demander, en la lisant, pourquoi l'Internet marche encore. C'est parce que les faiblesses de BGP, notamment la propagation mondiale de n'importe quelle annonce, même fausse, même mensongère, sont aussi ses forces. Elles permettent à tous de détecter le problème et de réagir rapidement. C'est bien à tort que le RFC prétend, dans sa section 5.14, qu'il n'existe pas d'outils de détection en temps réel des changements BGP, il y en a au contraire une pléthore !

Ce RFC qui expose un cahier des charges pour le routage global de l'Internet est essentiellement un document historique. Écrit il y a pas mal d'années, il est publié aujourd'hui (avec quelques mises à jour et annotations) dans le cadre des efforts de définition d'une future architecture de routage. Il accompagne le RFC 5773 qui décrivait l'existant et se focalise sur les deux cahiers des charges qui avaient été redigés par deux groupes de travail en 2001. (Attention, donc, en le lisant, une bonne partie a été écrite au tout début du siècle.)

La section 1 résume la genèse compliquée de ce document. Il est issu d'un travail d'un groupe de l'IRTF qui devait travailler sur le routage « en partant d'une page blanche », c'est-à-dire sans être gêné par la nécessité de rester proche des mécanismes actuels. Un autre groupe, nommé Babylon, travaillait au même moment sur le même sujet, mais avec une perspective différente puisque Babylon se limitait aux solution incrémentales, ne nécessitant pas de tout jeter. Les contributions des deux groupes ont été réunis dans ce RFC 5772 (le « groupe A » est celui de l'IRTF et le « groupe B » est Babylon). Les deux groupes n'ont pas été fusionnés car ils partaient de principes trop différents pour qu'une fusion puisse marcher. La liste des membres des deux groupes figure dans la section 6.

Leurs contributions ont été un peu éditées pour la publication dans ce RFC mais, à part cela, elles reflètent en gros le point de vue du début des années 2000. Dans les deux cas (groupe A et groupe B), il s'agit d'une liste au Père Noël, de tout ce qu'il serait bien d'avoir dans le routage et la section 1 note qu'il n'est pas forcément possible de rééaliser toutes ces exigences (surtout simultanément).

La section 2 est rédigée par le groupe A, celui qui partait d'une feuille blanche. On y trouve tous les bons principes de conception, par exemple qu'une architecture doit être définie et bien documentée, avant de se plonger dans les détails des protocoles (section 2.1.1). Idéalement, les changements des composants de cette architecture devraient pouvoir se faire séparement pour chaque composant. Et, encore plus vœu pieux, l'adressage devrait être séparé de la topologie du réseau (actuellement, sans être complètement liés, les deux sont fortement connectés ; cela explique les bonnes performances de l'Internet, malgré sa taille, mais c'est aussi dans cette forte connexion que se trouvent souvent les conflits, par exemple autour des adresses PI, ces adresses qui ne suivent pas la topologie).

L'architecture vue par le groupe A doit passer à l'échelle, c'est-à-dire accepter des réseaux bien plus grands qu'aujourdhui (« idéalement, pour les vingt prochaines années »), par exemple pour plusieurs dizaines de milliers d'AS, chiffre qu'une note d'un éditeur en 2005 prévient qu'il a déjà été atteint. Une autre prévision est déjà dépassée dans la même section 2.1.3. Le texte de 2001 prenait le risque de pronostiquer que, en raison de certaines limites physiques, les 40 Gb/s d'OC768 seraient difficiles à dépasser alors qu'ils le sont déjà.

La section 2.1.6 demande que l'architecture nouvelle gère proprement le multi-homing. La 2.1.9, encore plus ambitieuse, demande que le nouveau système de routage soit sûr. Par exemple, une des exigences est la possibilité de dissimuler aux regards extérieurs la topologie de son réseau ce qui, pris au pied de la lettre, veut dire qu'il faut pouvoir empêcher traceroute de fonctionner.

Bien que le point de départ originel du projet du groupe A était de partir de zéro, une section, la 2.1.12 est quand même consacrée au déploiement incrémental de la nouvelle architecture, le considérant comme impératif. C'est compréhensible (l'expérience de beaucoup d'autres objets techniques complexes montre la vanité qu'il y a à vouloir faire table rase de l'investissement financier, technique et social) mais cela rend l'ensemble du cahier des charges encore plus... Comment dire ? Ambitieux ? Irréaliste ?

Le caier des charges du groupe A ne s'arrête pas là. Il demande encore une complète portabilité des adresses IP (section 2.1.14), que l'architecture soit simple à comprendre (« en moins d'une heure », dit la section 2.1.17 mais il est vrai que sa simplicité conceptuelle fut une des raisons de la victoire d'IP contre OSI). l'indépendance du système de routage par rapport aux autres composants de l'architecture (comme le DNS cf. section 2.1.20), et bien d'autres choses.

La liste est donc impressionnante. Et pourtant, tout n'a pas été inclus. La section 2.2 liste les non-buts, ce que le groupe A n'a pas considéré comme faisant partie des objectifs. On y trouve l'ingéniérie de trafic (section 2.2.2), terme très flou et trop vaste pour avoir été inclus dans les objectifs. la « sécurité absolue » (section 2.2.6), qui pourrait, en cas de problème, empêcher les opérateurs de faire leur travail, le routage dynamique en fonction de la charge du réseau (section 2.2.7), une vieille idée de l'Arpanet qui s'est toujours avérée très « casse-gueule », et, naturellement, la compatibilité avec l'existant (section 2.2.10) puisque l'idée de départ était une approche « table rase ».

La section 3 donne ensuite la parole au groupe (alias Babylon). Après un résumé du contexte, les exigences commencent en 3.2.3 qui note que tout cahier des charges laisse en général en blanc la question de l'évaluation des résultats : comment savoir qu'on a réussi ?

Parmi les demandes, l'exigence que le routage fournisse suffisamment d'informations pour pouvoir être utilisé par plusieurs services, autres que la délivrance de datagrammes au meilleur effort (section 3.2.3.2), le passage à l'échelle (section 3.2.3.3, où le RFC note que, dans ce secteur, l'échec est bien plus facile à détecter que le succès), etc. La sécurité fait l'objet de la demande 3.2.3.8,qui réclame une protection contre les DoS en notant que, dans l'Internet actuel, le fait de connaître une route sert également d'autorisation à y envoyer un paquet et qu'il faudrait changer cela (les notes récentes du RFC critiquent le groupe B en se demandant si ce ne serait pas une violation de la transparence du réseau).

Le groupe B souhaite également que les erreurs de configuration des routeurs (comme celle d'un routeur Microtik tchèque) ne puissent plus avoir des conséquences poiur l'Internet entier (section 3.2.3.10).

L'Internet n'est pas un objet purement technique. Il nécessite beaucoup de moyens humains et financiers, qui n'arrivent pas tout seuls. La section 3.4 se lance dans l'étude des contraintes extérieures, qui limitent les solutions possibles. Un des exemples le plus simple est celui de la très forte dépendance du soi-disant « cyberespace » vis-à-vis du monde physique (section 3.4.3). Combien d'entreprises ont acheté leur connectivité Internet à deux fournisseurs « pour la redondance » avant de découvrir que leurs câbles passaient dans la même tranchée et pouvaient tous être tranchés par la même pelleteuse ? (Comme ce fut le cas lors de la coupure égyptienne.)

Les exigences détaillées apparaissent ensuite en section 3.6. Groupées en sections, chacune reçoit un numéro, chaque section faisant l'objection d'une discussion groupée. Ainsi, l'exigence R(13) (Requirment 13), « Le routage doit pouvoir gérer différents chemins selon le service demandé » (nécessaire pour la QoS) fait partie de la section 3.6.2.2 sur les annonces de routes.

Il y a en tout 64 de ces exigences. Quelques exemples :

• R(26) ne tranche pas entre les différentes familles d'adresses et demande que le futur système de routage sache gérer IPv4 et IPv6 et également des familles non-IP.
• R(55) demande qu'il ne soit pas nécessaire de prévoir un flag day pour le déploiement du futur système de routage.
• R(62) voudrait que le futur système de routage permette d'authentifier les annonces de route (un problème brûlant aujourd'hui).

La section 3.10 couvre ensuite les questions « contestables », celles où le consensus du groupe B est moins fort. Cela va de questions très vagues (3.10.1 regrette qu'on modélise toujours les réseaux sous forme de graphes et demande qu'on accepte d'autres modèles - sans donner aucune idée de ce qu'ils pourraient être) à des considérations sur des problèmes transversaux comme le général byzantin (section 3.10.10).

Les failles de sécurité font partie du folklore de l'Internet mais la plupart touchent une mise en œuvre particulière, qu'il suffit de corriger par un patch. La faille de renégociation de TLS, révélée en novembre 2009 était au contraire une faille d'un protocole. Il fallait donc modifier celui-ci pour la corriger, ce que vient de faire notre RFC (dont l'un des auteurs, Marsh Ray, est le découvreur de la faille). Ce RFC a été écrit et publié de manière particulièrement rapide, compte-tenu de l'urgence de combler cette faille.

Un petit rappel : le protocole de sécurité TLS, normalisé dans le RFC 5246, contient une phase de négociation pendant laquelle les deux systèmes peuvent décider de choses comme les algorithmes de cryptographie à utiliser. Ils peuvent aussi présenter un certificat X.509 pour s'authentifier. Un point important de TLS est que la négociation ne survient pas uniquement au début de la session. À tout moment, chacune des deux parties peut renégocier (commande R si on utilise openssl s_client). Mais, et c'est le cœur de la faille, il n'existe pas de liaison (binding) entre l'état de la session avant renégociation et après. Un attaquant peut donc commencer une session avec un serveur, envoyer des données, lancer une renégociation, puis laisser la place au vrai client qui va s'authentifier. (Ce problème, et l'attaque qu'il rend possible, sont détaillés dans la section 1 du RFC.) Avec des protocoles utilisant TLS, comme HTTP qui ne fait pas la différence entre avant et après la renégociation, les données envoyées par l'attaquant seront considérées comme authentifiées par le vrai client... Même avec des protocoles comme SMTP et IMAP, où la transition entre état authenfifié et non authentifié est davantage marquée, certaines attaques restaient possibles. Bref, l'absence de toute liaison cryptographique fiable entre l'« ancienne » session et la « nouvelle » fait que le serveur et le client n'avaient aucun moyen de détecter l'attaque.

Qu'est-ce qu'une liaison, à ce sujet ? C'est une preuve cryptographique que deux éléments sont liés, qu'une attaque contre l'un invaliderait l 'autre. C'est un composant essentiel de tout protocole de cryptographie, dont l'oubli ou les défaillances sont à l'origine de plusieurs failles de sécurité. Un exemple de liaison est celle que fait SSH avec le MAC qui est calculé pour les paquets (RFC 4253, section 6.4). Sans ce MAC, l'authentification effectuée au début d'une connexion SSH ne servirait pas à grand'chose puisqu'il n'y aurait pas de liaison entre cette authentification et les paquets : un méchant pourrait laisser l'authentification se faire, puis injecter ses propres paquets. (Sur la question de la liaison cryptographique, on peut lire le RFC 5056 pour plus de détails.)

Bref, TLS manquait d'une liaison entre la session avant et après renégociation. Comment résoudre cette faille ? Le plus simple était de supprimer complètement la renégociation dans la serveur, et c'est ce qu'a fait OpenSSL en urgence. Mais cela ne résoud pas le problème des utilisateurs qui ont besoin de la rénégociation (par exemple pour l'authentification X.509 sur HTTP, si on ne veut pas avoir deux machines, une pour les sessions authentifiées et une pour les autres).

Notre RFC 5746 crée donc une autre solution, qui va nécessiter la mise à jour des mises en œuvre de TLS. Son principe est d'avoir une extension TLS renegotiation_info qui lie cryptographiquement l'ancienne session (avant la rénégociation) et la nouvelle. Elle est décrite plus en détail en section 3. Elle nécessite que chaque pair TLS garde quelques informations supplémentaires :

• Un booléen secure_renegotiation qui indique si la nouvelle option est utilisable sur cette connexion TLS,
• Une valeur client_verify_data qui indiquait les données de vérification envoyées par le client à la dernière négociation (et que le client doit donc connaître, pour authentifier la renégociation),
• Une valeur server_verify_data, l'équivalent pour le serveur.

L'extension elle-même figure en section 3.2. renegotiation_info est définie comme :

      struct {
          opaque renegotiated_connection<0..255>;
      } RenegotiationInfo;

où la valeur renegotiated_connection vaut zéro au début puis, en cas de renégociation, vaut *_verify_data.

Le changement à TLS est donc trivial. Mais il y a quelques détails pénibles. Par exemple, la section 3.3 fait remarquer que, bien qu'une extension inconnue doive être ignorée, certaines mises en œuvre de TLS avortent la connexion dans ce cas. Face à un TLS récent qui tente de leur envoyer une renegotiation_info,il y aura donc un problème. Une astuce a donc été créé : comme TLS permet d'indiquer les algorithmes de chiffrement acceptés, un algorithme bidon a été normalisé, TLS_RENEGO_PROTECTION_REQUEST. L'envoyer dans la liste des algorithmes ne plantera personne (les algorithmes inconnus sont légion et ne perturbent aucune implémentation) et permettra d'indiquer qu'on gère la nouvelle extension. (Oui, c'est un bricolage mais, dans le monde réel, on doit souvent utiliser de tels bricolages pour assurer un déploiement réussi, malgré la présence de logiciels bogués.)

Après ce petit détour sur la compatibilité, le RFC décrit en détail le comportement que doivent adopter clients et serveurs, aussi bien pour la connexion initiale (sections 3.4 et 3.6) que pour une éventuelle renégotiation (sections 3.5 et 3.7). Le client doit envoyer une extension renegotiation_info vide au début, pour indiquer sa volonté de protéger la rénégotiation (ou bien utiliser le truc de l'algorithme de chiffrement bidon). Si cette extension n'est pas dans la réponse, cela peut signifier que le serveur utilise un ancien logiciel, antérieur à notre RFC, ou bien qu'une attaque de l'homme du milieu est en cours. Le client doit donc décider s'il continue en notant juste que secure_renegotiation est faux, ou bien il doit être exigeant et couper la session (après tout, autrement, la nouvelle extension de sécurisation de la renégociation pourrait être rendue inutile par des attaques par repli). Mais la décision est difficile car, au début tout au moins, les clients TLS nouveaux n'auront guère de serveurs « sécurisés » à qui parler. La section 4.1 décrit plus en détail ce problème cornélien.

La situation est plus simple pour le serveur qui peut toujours, s'il rencontre un vieux client, refuser une éventuelle renégociation. La méthode recommandée en section 4.3 (et 4.4 et 5) est donc de n'accepter de renégociation qu'avec un client compatible avec ce RFC 5746.

La renégociation, même sécurisée par une liaison cryptographique avec l'état antérieur de la session, soulève d'amusants problèmes de sécurité, que traite la section 5. Ainsi, beaucoup de logiciels croient qu'en appelant getPeerCertificates(), ils obtiennent une liste de certificats immuable, qui est valide tout le temps de la session. Mais ce n'est pas le cas s'il y a renégociation.

Notre RFC recommande donc aux bibliothèques TLS de fournir un moyen d'autoriser ou d'interdire la renégociation (ce n'était pas le cas d'OpenSSL avant la découverte de la faille de sécurité.) Il y a d'autres recommandations comme celle d'offrir une possibilité de permettre la rénégociation mais sans changement des certificats (d'autant plus que, avec la plupart des bibliothèques existantes, il n'existe aucun moyen de savoir quelles données ont été transmises avant et après la renégociation).

Aujourd'hui, parmi les deux mises en œuvre de TLS en logiciel libre, OpenSSL a intégré le code pour notre RFC 5746 dans sa version 0.9.8m alors que GnuTLS l'a en développement (l'essentiel du code est dans lib/ext_safe_renegotiation.c et est écrit par un des auteurs du RFC).

L'infrastructure juridique des « nouveaux » RFC, désormais répartis en plusieurs voies selon leur source, continue à se mettre en place. Ce RFC 5744 décrit les procédures pour les droits liés aux RFC soumis par la voie « indépendante » (RFC soumis par un individu, ni l'IAB, ni un groupe de travail de l'IETF). Actuellement, il existe des dizaines de documents approuvés techniquement, qui attendent dans la file du RFC Editor car ils ont été soumis par cette voie et son statut n'a pas été clarifié depuis le déploiement des « nouveaux » RFC (RFC 5620). Sans doute vont-ils enfin être publiés mais on ne sait pas encore quand.

C'est que la publication d'un RFC, acte essentiellement technique au début, est devenue une grosse affaire juridico-politique. Des centaines de pages de discussions juridiques ont été noircies sur les problèmes de droits donnés par les auteurs (incoming rights, cf. RFC 5378) et les droits (forcément inférieurs ou égaux) que reçoivent les lecteurs (outgoing rights, cf.RFC 5377). Ces deux derniers RFC ne concernaient que les documents produits par l'IETF et, depuis, les documents produits par des individus languissaient sans statut et ne pouvaient être publiés.

Après tant de débats, il est ironique de constater que la procédure pour les RFC « indépendants » est finalement très proche de celle des RFC « IETF ».

Pour se saisir du contexte, la section 2 de notre RFC 5744 rappelle que le systèmes des voies (streams) a été défini dans les RFC 4844 (et RFC 4846, spécifiquement pour la voie indépendante). Cette dernière est une vieille tradition, et permet de publier des RFC qui sont proposés par des individus isolés, ou bien qui ont rencontré le veto de certaines parties à l'IETF (comme le RFC 4408). Tout RFC n'est donc pas le produit d'un groupe de travail IETF.

Depuis le RFC 5620, qui « éclatait » l'ancienne fonction de RFC Editor, la responsabilité des RFC soumis par voie indépendante revient au Independent Stream Editor, qui, en décembre 2009, n'a pas encore été désigné.

La section 3 pose les buts des nouvelles règles. Reprenant la politique traditionnelle, suivie informellement depuis l'époque de Jon Postel, elle pose comme principe que l'utilisation des RFC doit être la plus libre possible (« Unlimited derivative works »). Toutefois, tous les RFC de la voie indépendante ne sont pas équivalents. Certains sont des republications de documents édités ailleurs (par exemple par d'autres SDO) et les auteurs ont donc la possibilité de demander des restrictions supplémentaires. À noter que ces principes s'appliquent également au code inclus dans les RFC.

Enfin, les règles formelles elle-mêmes, en section 4. La procédure est proche de celle des autres RFC, l'auteur devant donner certains droits pour permettre la publication (par défaut, il donne presque tous les droits, en gardant évidemment l'attribution de son travail). Les termes exacts (le boilerplate) seront fixés par l'IETF Trust.

Le respect de la procédure par l'auteur ne préjuge pas de l'adoption du RFC. L'éditeur de la voie indépendante, l'ISE, reste seul juge de l'intérêt de publier le RFC. Le choix d'un auteur de ne pas permettre la réutilisation du RFC (« no derivative worlks ») peut, par exemple, être motif de rejet.

L'implémentation de cette politique nécessite une action de la part de l'IETF Trust, décrite en section 5. Celui-ci devra accepter la responsabilité de la gestion des droits de propriété intellectuelle pour ces RFC « indépendants » et devra écrire les termes exacts qui seront inclus dans chaque RFC.

Quant aux questions de brevets et de marques déposées, elles sont réglées dans la section 6. Les règles des RFC 2026 et RFC 3979 s'appliquent aux RFC de la voie indépendante comme aux autres : toute prétention de propriété intellectuelle doit être déclarée, de façon à ce que l'ISE puisse décider en toute connaissance de cause (notez bien qu'en pratique, cette règle est parfois violée). Comme d'habitude à l'IETF, il n'y a pas d'a priori sur les conditions de licence des brevets (tout est théoriquement possible) mais notre RFC précise que les termes de licence les plus favorables possibles seront privilégiés, notamment des licenses gratuites, voire implicites.

Les RFC les plus connus sont ceux produits directement par l'IETF. Ils subissent alors tous un examen par l'IESG, garante de leur qualité et de leur cohérence. On l'ignore souvent mais ce n'est pas le cas de tous les RFC. Certains peuvent être soumis directement au RFC editor (Independent stream), d'autres soumis par d'autres organisations (comme l'IRTF). Que doit faire l'IESG avec eux ?

Le RFC 3932 répondait à cette question. Depuis le RFC 4844, qui formalise les différentes voies (streams) de soumission d'un RFC, il fallait le mettre à jour, ce qui a pris beaucoup de temps, entrainant le blocage d'un grand nombre de RFC indépendants, techniquement au point mais ne pouvant pas être publiés car on ignorait comment les gérer administrativement.

Deux des quatre voies sont traitées dans notre RFC 5742 : celle de l'IRTF et la voie indépendante, celle des documents soumis par des individus. Lorsqu'un document n'est pas passé par l'IETF, il n'a pas forcément été examiné sur les points où le protocole décrit peut causer des problèmes : sécurité, contrôle de congestion, mauvaise interaction avec les protocoles existants (section 1). L'IETF n'assume donc aucune responsabilité pour ces RFC indépendants.

Par contre, ils étaient traditionnellement (RFC 2026, section 4.2.3, puis RFC 3710) examinés par l'IESG. C'était un véritable examen, avec discussion des points techniques avec les auteurs, aller-retour, et discussions qui prenaient des ressources à l'IESG et retardaient sérieusement la publication du RFC. L'IESG avait décidé en mars 2004 de passer à une procédure plus légère (RFC 3932) où l'IESG vérifiait surtout qu'il n'y avait pas de conflit avec un travail en cours à l'IETF. Les commentaires de fond étaient envoyés au RFC editor qui les traitait comme n'importe quel autre commentaire. Quant aux documents de l'IRTF, ils étaient traités, soit comme venant de l'IAB, soit comme soumissions individuelles (ils ont maintenant leur propre voie, décrite dans le RFC 5743).

Notre RFC 5742 décrit la procédure qui est désormais suivie lorsque le RFC editor ou l'IRTF demande un examen plus complet à l'IESG (voir aussi le RFC 4846, qui détaille la voie indépendante).

Quels sont les changements par rapport au RFC 3932 ? La section 1.1 les résume :

• Nouvel en-tête pour les RFC, indiquant explicitement la voie empruntée (RFC 5741),
• Mécanisme de résolution de conflits si l'IESG demande l'ajout d'une note au RFC et que cette note soulève des objections. L'insertion de cette note était obligatoire auparavant (RFC 3932, section 4).

Les détails de l'examen par l'IESG sont désormais dans la section 3. Après étude du document, l'IESG peut décider, au choix :

• Qu'il n'y a pas de conflit entre ce document et le travail de l'IETF,
• Qu'il y a une relation avec le travail d'un groupe de l'IETF, sans que cela empêche la publication du document,
• Qu'il y a risque de gêne du travail d'un groupe et que le document ne devrait pas être publié dans l'immédiat,
• Que le document empiète sur un travail réservé à l'IETF (par exemple l'ajout d'un élément à un protocole lorsque la norme de ce protocole prescrit une procédure particulière pour de tels ajouts).

Des exemples concrets de conflits sont fournis dans la section 5. Par exemple, la publication d'un protocole « alternatif » (Photuris, RFC 2522) à celui de l'IETF (IKE, RFC 2409) devrait attendre pour laisser le protocole « officiel » être publié en premier. De tels protocoles alternatifs ne posent pas de problème en soi, le choix est une bonne chose, mais il est important qu'ils soient clairement différenciés du protocole de l'IETF. Un autre exemple est la réutilisation de bits « libres » dans un en-tête de paquet lorsque ces bits ont une autre signification dans la norme.

Et si les auteurs ou le RFC editor sont en désaccord avec la conclusion de l'IESG ? C'est la grande nouveauté de notre RFC 5742, une procédure de résolution des conflits, qui fait l'objet de la section 4. Même l'IETF, suivant la judiciarisation croissante de la société, a ses Dispute Resolution Procedures. En quoi consiste t-elle ici ? Dans l'introduction d'une tierce partie, l'IAB, qui sera chargée d'arbitrer tout conflit entre l'IESG et le RFC Editor, si les six semaines de dialogue obligatoire n'ont pas résolu le problème. L'IAB pourra donner raison à l'un ou l'autre et pourra donc, par exemple, imposer au RFC editor l'inclusion d'une note de l'IESG qu'il ne voulait pas.

Les textes sacrés de l'Internet, les RFC, comprennent un certain nombre d'éléments obligatoires, souvent collectivement appelés boilerplates et comprenant, par exemple, les conditions légales d'utilisation du RFC. Ce RFC 5741 écrit par l'IAB les décrit et les précise.

Les éléments existants comme Category: Experimental ne suffisaient pas à transporter toute l'information nécessaire. Depuis la formalisation des voies dans le RFC 4844, les différents circuits de publication des RFC, il était devenu crucial de déterminer facilement de quelle voie venait un RFC. (Les anciens RFC étaient tous marqués comme provenant d'un mystérieux Network Working Group dont personne ne savait trop ce qu'il recouvrait mais il parait que le RFC 3 en parle.)

Donc, dans sa section 2, notre méta-RFC rappelle que, non seulement tous les RFC ne sont pas des normes (RFC 1796), mais que tous ne sont pas des documents issus de l'IETF, qui n'est qu'une voie parmi d'autres (quoique la plus prolifique). Ainsi, un RFC peut très bien être publié sans que l'IETF n'aie pu donner un avis sur des points comme la sécurité ou le contrôle de congestion, par le biais de procédures comme le IETF Last Call ou l'examen par l'IESG.

La section 3 liste les éléments qui forment la structure d'un RFC. Il y a l'en-tête général (section 3.1) qui, pour notre RFC, est :

Internet Architecture Board (IAB)                         L. Daigle, Ed.
Request for Comments: 5741                               O. Kolkman, Ed.
Updates: 2223, 4844                                          For the IAB
Category: Informational                                    December 2009

indiquant qu'il est issu de la voie IAB, qu'il porte le numéro 5741, qu'il est de la catégorie « Pour information » (les catégories sont décrites dans le RFC 2026), etc. Les autres voies sont IETF, IRTF et « soumission indépendante ».

Après cet en-tête vient un paragraphe (section 3.2.2) qui décrit clairement la voie par laquelle ce RFC est passé. Par exemple, pour une soumission indépendante, le texte (qui est sujet à évolution, en synchronisation avec la définition des voies) actuel est « This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. ».

Je ne reprends pas ici tous les éléments, qui sont décrits dans cette section 3. Notons simplement le copyright, issu des RFC 5378 et RFC 4879, et l'ISSN des RFC, 2070-1721.

Question mise en œuvre, les programmes XSLT de Julian Reschke sont apparemment à jour pour ce RFC (voir l'annonce officielle). Par contre, xml2rfc ne semble pas encore adapté.

Presque toutes les normes produites par l'IETF sont désormais complètement internationalisées. Il reste quelques trous par-ci, par-là, qui sont comblés lentement. Par exemple, notre RFC 5738 normalise le support d'Unicode par le protocole IMAP d'accès aux boîtes aux lettres.

Normalisé dans le RFC 3501, IMAP permet d'accéder à des boîtes aux lettres situées sur un serveur distant. Ces boîtes peuvent désormais avoir des noms en Unicode, les utilisateurs peuvent utiliser Unicode pour se nommer et les adresses gérées peuvent être en Unicode. L'encodage utilisé est UTF-8 (RFC 3629). Ce RFC 5738 fait donc partie de la série de RFC du groupe de travail EAI qui normalise un courrier électronique complètement international. Comme le changement est d'importance, ces RFC sont malheureusement encore étiquetés « expérimentaux ».

Tout commence par la possibilité d'indiquer le support d'UTF-8. Un serveur IMAP, à l'ouverture de la connexion, indique les extensions d'IMAP qu'il gère et notre RFC en crée une nouvelle, UTF8=ACCEPT (section 3). Par le biais de l'extension ENABLE (RFC 5161), le client peut à son tour indiquer qu'il va utiliser UTF-8. La section 3.1 détaille la représentation des chaînes de caractères UTF-8 sur le réseau.

Des commandes IMAP prennent désormais un paramètre UTF8. C'est le cas de SELECT et EXAMINE (section 3.2) qui permettent de manipuler les boîtes aux lettres. L'utilisation de ce paramètre par le client lors de la sélection d'une boîte change la sémantique de certaines commandes. Par exemple, toute commande qui indique la taille de la boîte aux lettres doit désormais compter en caractères Unicode et non plus en octets.

Les nouvelles capacités sont toutes décrites dans la section 10 et enregistrées dans le registre IANA.

On peut désormais imaginer des boîtes aux lettres qui ne puissent être manipulées qu'en UTF-8. Dans ce cas, elles ne doivent pas être indiquées par défaut dans le résultat d'une commande LIST (sauf extensions de celle-ci, cf. RFC 5258), puisqu'elles ne pourraient pas forcément être sélectionnées ensuite. À noter qu'IMAP disposait depuis longtemps d'une astuce pour représenter les boîtes aux lettres dont les noms comportaient des caractères non-ASCII, la IMAP Mailbox International Naming Convention (RFC 3501, section 5.1.3). Elle n'a jamais donné satisfaction et la section 3.3 de notre RFC 5738 recommande de l'abandonner.

Il n'y a bien sûr pas que les boîtes, il y a aussi les noms d'utilisateurs qui peuvent être en Unicode (capacité UTF8=USER), et la section 5 spécifie ce point, en demandant que ces noms soient canonicalisés avec SASLprep (RFC 4013). Le RFC note (annexe A) que le serveur IMAP s'appuie souvent sur un système d'authentification externe (comme /etc/passwd sur Unix) et que, de toute façon, ce système n'est pas forcément UTF-8.

Aujourd'hui, rares sont les serveurs IMAP qui gèrent l'UTF-8. Mais, dans le futur, on peut espérer que l'internationalisation devienne la norme et la limitation à US-ASCII l'exception. Pour cet avenir radieux, la section 7 du RFC prévoit une capacité UTF8=ONLY. Si le serveur l'annonce, cela indique qu'il ne gère plus l'ASCII seul, que tout est en UTF-8 (un tel serveur, en 2010, n'aurait guère de clients...)

Outre les noms des boîtes et ceux des utilisateurs, cette norme IMAP UTF-8 permet à un serveur de stocker et de distribuer des messages dont les en-têtes sont en UTF-8, comme le prévoit le RFC 5335. Si son client ne gère pas UTF-8, le serveur doit alors (section 9) dégrader le messages en ASCII seul, comme expliqué dans le RFC 5504.

Chose relativement rare dans un RFC, l'annexe A contient une discussion détaillée des choix effectués et des raisons de ces choix. Par exemple, le fait que l'accès aux boîtes en UTF-8 se configure boîte par boîte et pas pour tout le serveur, a pour but de permettre aux serveurs existants de ne pas avoir à convertir toutes les boîtes stockées en UTF-8, lors de la mise à jour du logiciel.

Je ne connais pas encore d'implémentation en logiciel libre.

Pendant longtemps, les documentations ou cours sur TCP/IP utilisaient dans les exemples des adresses IP prises un peu au hasard, par exemple sur le réseau de l'auteur. Cela entrainait des problèmes si un lecteur prenait ces exemples trop littéralement et réutilisait ces adresses, rentrant ainsi en conflit avec les adresses existantes. Le RFC 1166 avait donc commencé la bonne tradition de réserver des adresses pour la documentation, tradition que continue notre RFC 5737 (voir aussi le RFC 5735).

Comme le rappelle la section 1, la limite du préfixe 192.0.2.0/24 qui avait été réservé par le RFC 1166 était qu'il était tout seul : un cours sur OSPF ou BGP était assez difficile à faire avec des adresses commençant toutes par 192.0.2. Deux autres préfixes ont donc été ajoutés, 198.51.100.0/24 et 203.0.113.0/24 (section 3). IPv6, lui, a le 2001:db8::/32 du RFC 3849 et les noms de domaine ont les example.org et autres example.net du RFC 2606.

Puisque ces trois préfixes IPv4 sont réservés à la documentation, ils ne devraient jamais apparaitre sur des vrais réseaux, par exemple via BGP (section 4). On peut donc les ajouter aux listes de bogons.

À noter enfin que, contrairement à ce qu'on lit parfois, le préfixe 128.66.0.0/16 n'est pas réservé (section 5) pour la documentation et peut être utilisé pour de vraies allocations.

Le RFC 5735 ayant réservé un préfixe d'adresses IPv4, 192.0.0.0/24 pour des allocations « spéciales », ce RFC 5736 définit les règles que devra suivre l'IANA pour la gestion du registre des allocations dans ce préfixe.

L'utilité principale de ce préfixe réservé est de permettre des allocations d'adresses IP pour certains protocoles qui ont besoin de coder en dur des adresses. (Il existe déjà un tel registre pour les adresses IPv6, registre décrit dans le RFC 4773.) La section 2 du RFC rappelle les généralités sur le rôle de l'IANA, ses relations avec l'IETF et l'accord qui les lie (RFC 2860).

La section 3 décrit le mécanisme d'allocation proprement dit. Prendre une adresse dans le préfixe 192.0.0.0/24 nécessitera une IETF review (le terme est défini dans le RFC 5226 et désigne une procédure relativement lourde, impliquant l'écriture d'un RFC).

Le registre doit indiquer l'adresse IP réservée, le RFC où son usage est documenté, le caractère routable ou non de cette adresse, etc. À noter que, même si le registre dit qu'une adresse est prévue pour être routée mondialement, le RFC précise qu'on ne peut rien garantir à ce sujet, vue la décentralisation des politiques de routage.

Le registre est vide, pour l'instant. Patience...

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.

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. Le premier RFC sur le rôle de l'IANA est le RFC 1174 et la description actuelle du rôle de l'IANA est le RFC 2860.

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, successeur du RFC 3330, é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,
• 169.254.0.0/16, réservé pour les adresses locales au lien (cette réservation a été documentée dans le RFC 3927),
• 192.0.0.0/24, réservé pour les protocoles qui ont besoin d'adresses IP spécifiques. Pour l'instant, aucune affectation dans ce nouveau registre n'a été faite, le RFC 5736 décrit les règles que ces affectations suivront,
• 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24, réservés pour la documentation (par exemple pour rédiger des manuels, sans craindre que les adresses IP d'exemple soient utilisées). Les deux derniers préfixes sont une nouveauté du RFC 5737. Le seul utilisé jusqu'à présent, le 192.0.2.0/24, était trop petit pour certains usages (par exemple, pour un cours BGP, c'était pénible de devoir distinguer 192.0.2.0/25 et,192.0.2.128/25),
• 198.18.0.0/15, réservé pour les mesures, suivant le RFC 2544,
• Et bien d'autres, énumérés dans la section 3 et résumés dans la 4.

Si vous avez une idée géniale qui nécessite de réserver un autre préfixe, la marche à suivre est expliquée dans la section 5. Au minimum, vous aurez à écrire un RFC.

Les fanas de la sécurité noteront la section 7, qui précise les filtrages qui devraient faire les routeurs (par exemple, 169.254.0.0/16 ne devrait jamais être routé), et avertit qu'il ne faut pas forcément compter sur ces filtres : tous les routeurs ne sont pas forcément bien configurés. Donc, si vous recevez un paquet IP avec une adresse source en 169.254.0.0/16, cela ne signifie pas forcément qu'il vienne d'une machine locale.

L'annexe A liste les principaux changements par rapport au RFC précédent, le RFC 3330. En raison de l'extrême pénurie d'adresses IPv4, des préfixes ont été définitivement remis dans le circuit normal d'allocation et n'apparaissent donc plus comme spéciaux (par exemple le 24.0.0.0/8). Et deux nouveaux préfixes apparaissent pour la documentation.

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

Ce court RFC spécifie comment utiliser le protocole d'avitaillement EPP au dessus d'une simple connexion TCP.

EPP, décrit dans le RFC 5730 est à sa base uniquement un format XML pour les requêtes d'avitaillement (création, mise à jour et destruction d'objets) et leurs réponses. Ces éléments XML peuvent être transmis de différence façon (au dessus de HTTP, de BEEP, par courrier électronique, etc), et notre RFC normalise la plus commune aujourd'hui, une simple connexion TCP. Il remplace le RFC 4934, avec uniquement des modifications de détail, portant notamment sur l'utilisation de TLS (section 9).

Le RFC est court car il n'y a pas grand'chose à dire, juste l'utilisation des primitives de TCP (ouverture et fermeture de connexion, section 2 du RFC), l'ordre des messages (section 3), le port utilisé (700, 3121 ayant été abandonné, section 7) et le fait que chaque élément EPP soit précédé d'un entier qui indique sa taille (section 4). Sans cet entier (qui joue le même rôle que l'en-tête Content-Length de HTTP), il faudrait, avec la plupart des implémentations, lire les données octet par octet (sans compter que la plupart des analyseurs XML ne savent pas analyser de manière incrémentale, il leur faut tout l'élément). En outre, sa présence permet de s'assurer que toutes les données ont été reçues (voir l'excellent article The ultimate SO_LINGER page, or: why is my tcp not reliable).

L'entier en question est fixé à 32 bits. Si on programme un client EPP en Python, l'utilisation brutale du module struct ne suffit pas forcément. En effet :

struct.pack("I", length)

force un entier (int) mais pas forcément un entier de 32 bits. Pour forcer la taille, il faut utiliser également, comme précisé dans la documentation, les opérateurs < et >, qui servent aussi à forcer la boutianité (merci à Kim-Minh Kaplan pour son aide sur ce point). Voici une démonstration (un "l" standard fait 4 octets alors que le type long de C peut faire 4 ou 8 octets) :

# Machine 32 bits :

Python 2.4.4 (#2, Apr  5 2007, 20:11:18) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> print struct.calcsize("l")
4
>>> print struct.calcsize(">l")
4

# Machine 64 bits :

Python 2.4.5 (#2, Mar 11 2008, 23:38:15) 
[GCC 4.2.3 (Debian 4.2.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> print struct.calcsize("l")
8
>>> print struct.calcsize(">l")
4

Si on a quand même un doute, on peut tester la taille obtenue mais ce code est probablement inutile (merci à David Douard pour son aide ici) :

# Get the size of C integers. We need 32 bits unsigned.
format_32 = ">I"
if struct.calcsize(format_32) < 4:
    format_32 = ">L"              
    if struct.calcsize(format_32) != 4:
        raise Exception("Cannot find a 32 bits integer")
elif struct.calcsize(format_32) > 4:
    format_32 = ">H"                
    if struct.calcsize(format_32) != 4:
        raise Exception("Cannot find a 32 bits integer")
else:
    pass
...
def int_from_net(data):
    return struct.unpack(format_32, data)[0]

def int_to_net(value):
    return struct.pack(format_32, value)

L'algorithme complet d'envoi est :

epp_as_string = ElementTree.tostring(epp, encoding="UTF-8")
# +4 for the length field itself (section 4 mandates that)
# +2 for the CRLF at the end
length = int_to_net(len(epp_as_string) + 4 + 2)
self._socket.send(length)
self._socket.send(epp_as_string + "\r\n")

et la lecture :

data = self._socket.recv(4) # RFC 5734, section 4, the length 
                            # field is 4 bytes long
length = int_from_net(data) 
data = self._socket.recv(length-4)
epp = ElementTree.fromstring(data)
if epp.tag != "{%s}epp" % EPP.NS:
     raise EPP_Exception("Not an EPP instance: %s" % epp.tag)
xml = epp[0]

Le code Python complet (qui ne met en œuvre qu'une petite partie de EPP, le but était juste de tester ce RFC 5734), utilisant la bibliothèque ElementTree, est disponible en ligne. Le code ci-dessus comporte une grosse faiblesse (mais classique) : rien ne garantit que recv(n) retournera autant d'octets que réclamé. Il en renverra au plus n mais peut-être moins. Pour de la programmation sérieuse, il faut donc le réécrire avec une fonction du genre :

   def safe_recv(s, n):
       data = ''
       while (n > 0):
           tmp = s.recv(n)
           data += tmp
           n -= len(tmp)
       return data

(Merci à Kim-Minh Kaplan pour son aide sur ce point.)

Pour Perl, ce code ressemblerait (merci à Vincent Levigneron), pour envoyer un élément EPP stocké dans la variable $out, à :

print pack('N', length($out) + 4).$out;

et pour lire un élément EPP :

my $length = unpack "N", $buf;
...
$rc = read STDIN, $buf, $length;

Puisque le format N désigne un entier non signé gros boutien (cf. http://perldoc.perl.org/functions/pack.html).

À noter que cette lecture du champ longueur présente un risque de sécurité : si le serveur malloque aveuglément la taille indiquée dans ce champ, comme il fait quatre octets, le serveur naïf risque de consommer quatre giga-octets de mémoire.

La section 8, consacrée à la sécurité, et surtout la nouvelle section 9, consacrée à TLS, détaillent le processus d'authentification du client et du serveur. L'utilisation de TLS (RFC 5246) est obligatoire, ne serait-ce que pour protéger les mots de passe qui circulent en clair dans les éléments EPP. TLS permet également au client d'authentifier le serveur et au serveur d'authentifier le client, par la présentation de certificats X.509. Leur présentation et leur usage sont désormais obligatoires dans EPP. Notons que, comme toujours avec X.509, la difficulté est de déterminer ce qu'on vérifie. La section 9 détaille le cas où on vérifie un nom et celui où on vérifie une adresse IP. Il serait intéressant de savoir quels registres et quels bureaux d'enregistrement effectuent réellement ces validations...

La liste des changements par rapport au RFC 4934 se trouve dans l'annexe A. Le principal changement consiste en une meilleure spécification des règles de vérification du certificat X.509 lorsque TLS est utilisé (cf. la nouvelle section 9).

Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre, consacré aux contacts, c'est-à-dire aux personnes physiques ou morales responsables d'un objet de la base et qui peuvent être contactées à son sujet. (L'objet étant typiquement un nom de domaine ou bien un préfixe IP.)

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 5730, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type, la classe (EPP dit le mapping) pour les contacts. Il remplace le RFC 4933, avec très peu de changement, et marque l'arrivée de cette norme au statut de « norme complète », la dernière étape du chemin des normes de l'IETF.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

Un contact est donc composé d'un identificateur (type clIDType du RFC 5730). Cet identificateur (on l'appelait traditionnellement le handle) est, par exemple, SB68-GANDI (section 2.1).

Les contacts ont également un statut (section 2.2) qui est toujours mis par le client EPP, typiquement le bureau d'enregistrement. Ce mapping ne permet pas aux contacts d'être maîtres de leur propre information et de la changer directement (ce qui est cohérent avec l'approche d'EPP où un intermédiaire, le bureau d'enregistrement, a l'exclusivité des changements).

Les contacts ont aussi évidemment des moyens d'être contactés, via numéro de téléphone, adresse postale, etc. Par exemple, l'adresse de courrier du contact est spécifiée en section 2.6. La syntaxe formelle est celle du RFC 5322, par exemple joe.o'reilly+verisign@example.com. (Mais le schéma XML a une syntaxe plus bien laxiste, presque tout est accepté.)

Les contacts pouvant être des personnes physiques, pour protéger leur vie privée, la section 2.9 du RFC décrit aussi un format pour spécifier si ces informations doivent être publiées ou pas. Insuffisant pour tous les cas, ce format est en général remplacé, chez les registres européens, par un mapping spécifique (par exemple, EPP parameters for .pl ccTLD pour les polonais qui utilisent un élément <individual> pour indiquer si le contact est une personne physique, et a donc droit à la protection des lois européennes sur les données personnelles).

La section 3 normalise ensuite l'usage des commandes standards d'EPP (comme <create>) pour les objets de notre classe « contact ». À titre d'exemple, voici la réponse d'un serveur EPP à une requête <epp:info> (section 3.1.2) pour le contact SB68-GANDI :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <contact:infData
       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>SB68-GANDI</contact:id>
        <contact:roid>SH8013-REP</contact:roid>
        <contact:status s="clientDeleteProhibited"/>
        <contact:postalInfo type="int">
          <contact:name>John Doe</contact:name>
          <contact:org>Exemple SA</contact:org>
          <contact:addr>
            <contact:street>123 rue de l'Exemple</contact:street>
            <contact:city>Trifouillis-les-Oies</contact:city>
            <contact:cc>FR</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice x="1234">+33.7035555555</contact:voice>
        <contact:fax>+33.7035555556</contact:fax>
        <contact:email>jdoe@example.com</contact:email>
        <contact:crDate>1997-04-03T22:00:00.0Z</contact:crDate>
        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
        <contact:authInfo>
          <contact:pw>2fooBAR</contact:pw>
        </contact:authInfo>
        <contact:disclose flag="0">
          <contact:voice/>
          <contact:email/>
        </contact:disclose>
      </contact:infData>
    </resData>
  </response>
</epp>

L'espace de noms XML pour les contacts est urn:ietf:params:xml:ns:contact-1.0.

Comme rappelé par la section 5, EPP utilise XML dont le modèle de caractères est Unicode depuis le début. Logiquement, on devrait donc pouvoir enregistrer des noms et prénoms comportant des accents (comme « Stéphane ») mais je ne suis pas sûr que cela marche avec tous les registres : c'est une chose de transporter la chaîne de caractères Unicode jusqu'au registre et une autre de la stocker dans la base et de la ressortir proprement.

La classe « Contact » permet de représenter certains éléments (comme l'adresse postale) sous deux formes, une en Unicode complet (en indiquant type="loc" et l'autre sous une version restreinte à l'ASCII (en indiquant type="int", notez que ces labels doivent être lus à l'envers, la forme restreinte en labelisée int pour « internationale » et la forme complète loc pour « locale » alors que le contraire aurait été plus logique.)

Ce RFC remplace son prédécesseur, le RFC 4933 mais ce ne sont que des modifications légères, détaillées dans l'annexe A.

La représentation des serveurs de noms (host, dans ce contexte) dans un registre de noms de domaine a toujours été une source de confusion et de désaccords. Le protocole EPP d'avitaillement (provisioning) d'un registre a tranché arbitrairement et décidé que la bonne méthode était d'avoir des objets « serveur de noms » (host) explicitement mis dans le registre. C'est ce que normalise notre RFC, successeur du RFC 4932, qui lui-même succédait au RFC 3732.

Un registre de noms de domaine stocke en effet au moins deux classes d'objets : les domaines, bien sûr, et les contacts, les entités (personnes physiques ou organisations) qui gèrent les domaines. Mais cela laisse ouverte la question des serveurs de noms. Pour pouvoir déléguer un domaine, le registre a besoin de ces serveurs, qui se retrouveront en partie droite des enregistrements de type NS, comme ici, dans le registre de .org :

example.org.      IN     NS    ns1.example.org.
                  IN     NS    galadriel.lothlorien.net. 

Comme souvent lors de l'élaboration d'un schéma de données, on peut se poser la question : objet ou attribut ? Les serveurs de noms doivent-ils être des objets « de première classe », gérés en tant que tels, accessibles via whois ou bien doivent-ils être de simples attributs des objets de la classe domaine ?

Les deux approches sont possibles. .com utilise la première. Un serveur de noms est un objet de première classe, vous pouvez le voir avec whois :

% whois ns.kimsufi.com 
...
   Server Name: NS.KIMSUFI.COM
   IP Address: 213.186.33.199
   Registrar: OVH

D'autres registres ont choisi de faire des serveurs de noms de simples attributs. Quelle approche fallait-il retenir pour le protocole d'avitaillement EPP, normalisé dans le RFC 5730 ? Celui-ci sépare le protocole proprement dit de la définition des classes d'objets (classes nommées, dans EPP, mappings. Il existe une classe (un mapping) pour les domaines (RFC 5731), une pour les contacts (RFC 5733) et notre RFC 5732 pour les serveurs de noms. Toutes sont optionnelles. Un registre n'est pas obligé de mettre en œuvre tous ces mappings et peut donc, s'il ne gère pas les objets hosts, ignorer le RFC 5732.

Si un registre choisit, par contre, de gérer des objets « serveur de noms » comme dans ce RFC, la section 1 décrit les relations entre ces objets et les domaines. Ainsi, tout serveur de noms est subordonné à un domaine (le parent) : ns1.example.org est subordonné à example.org et la relation doit être conservée par EPP (par exemple, l'objet host ne peut être créé que par le client EPP qui gère l'objet domaine parent). À noter que le parent peut être externe au registre (par exemple galadriel.lothlorien.net pour le registre de .org).

La section 2 de ce RFC énumère ensuite les attributs de l'objet « serveur de noms ». Le serveur a un nom (par exemple ns2.example.net), conforme aux règles syntaxiques du RFC 1123. Comme tous les objets manipulés avec EPP, il a un identificateur unique spécifique à EPP, le client identifier (voir le RFC 5730). Il a aussi un état (status), qui peut être une combinaison par exemple ok combiné avec linked (qui indique qu'il est utilisé dans au moins un domaine).

Il a enfin une adresse IP facultative. Le RFC recommande de ne la stocker que si elle est nécessaire pour publier la colle, les enregistrements qui permettent de trouver l'adresse IP d'un serveur de noms qui sert la zone dont il fait lui-même partie par exemple dans :

example.org.      IN     NS    ns1.example.org.
                  IN     NS    galadriel.lothlorien.net.

Ici, ns1.example.org est dans la zone qu'il sert (example.org), il faut donc transmettre au registre son adresse IP, pour qu'il puisse publier la colle :

ns1.example.org.          IN   AAAA    2001:db8:314::1:53

alors que cela n'est pas nécessaire pour galadriel.lothlorien.net. Les RFC 2874 et RFC 3596 contiennent des détails sur cette question. La section 3.2.1 de notre RFC, sur la commande <create> revient également sur ce point en insistant que cette commande n'impose pas de transmettre des adresses IP, bien au contraire.

Le cœur d'EPP est décrit dans le RFC 5730, qui inclus une description des commandes possibles (comme <create> ou <delete>). Toutes ne s'appliquent pas à tous les objets et chaque norme d'un mapping doit donc décrire quelles commandes ont un sens pour lui. C'est ici l'objet de la section 3. Par exemple (section 3.1.3), le passage d'un registrar à un autre (transfer) n'a pas de sens pour un objet « serveur de noms » et n'est donc pas défini. L'espace de noms XML du host mapping, de notre classe « serveur de noms » est urn:ietf:params:xml:ns:host-1.0 (voir section 6).

Les commandes <check> et <info> ont leur sens habituel (section 3.1), celui de récupérer des informations sur un objet, ici en donnant son nom. Voici l'exemple donné par le RFC pour la réponse à une commande <info> pour le serveur ns1.example.com :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <host:infData
       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
        <host:name>ns1.example.com</host:name>
        <host:roid>NS1_EXAMPLE1-REP</host:roid>
        <host:status s="linked"/>
        <host:status s="clientUpdateProhibited"/>
        <host:addr ip="v4">192.0.2.2</host:addr>
        <host:addr ip="v4">192.0.2.29</host:addr>
        <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
        <host:clID>ClientY</host:clID>
        <host:crID>ClientX</host:crID>
        <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
        <host:upID>ClientX</host:upID>
        <host:upDate>1999-12-03T09:00:00.0Z</host:upDate>
        <host:trDate>2000-04-08T09:00:00.0Z</host:trDate>
      </host:infData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

Les informations spécifiques à notre classe sont dans l'espace de noms urn:ietf:params:xml:ns:host-1.0 dont le préfixe est ici host.

La syntaxe formelle complète de cette classe figure dans la section 4, sous la forme d'un schéma W3C.

L'annexe A rassemble les changements depuis le RFC 4932. Les changements, à part la mise à jour des RFC cités en référence, consistent surtout en une nouvelle licence pour le schéma XML et une précision sur le code de retour 2201 (permission refusée).

Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre, consacré aux noms de domaine.

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 5730, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type (EPP dit le mapping, on pourrait aussi l'appeler une classe) pour les noms de domaine.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

On note que ce schéma, se voulant adaptable à de nombreux registres différents, ne colle parfaitement à la politique d'aucun. Par exemple, <infData> est spécifié ainsi :

    <sequence>
      <element name="registrant" type="eppcom:clIDType"
       minOccurs="0"/>
      <element name="contact" type="domain:contactType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="ns" type="domain:nsType"
       minOccurs="0"/>

ce qui veut dire que des « règles métier » très courantes comme « un titulaire et un seul » ou bien « au moins deux serveurs de noms » ne sont pas respectés avec le schéma EPP seul.

Ce RFC remplace son prédécesseur, le RFC 4931 mais ce ne sont que des modifications de détail, résumées en annexe A. Elles vont en général dans le sens d'une plus grande latitude laissée aux implémenteurs.

Voici un exemple d'une réponse à une requête <epp:info> (section 3.1.2) pour le domaine example.com (comme avec whois mais, typiquement, non public) :

<response>
  <result code="1000">
    <msg>Command completed successfully</msg>
  </result>
  <resData>
    <domain:infData
     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
      <domain:name>example.com</domain:name>
      <domain:roid>EXAMPLE1-REP</domain:roid>
      <domain:status s="ok"/>
      <domain:registrant>jd1234</domain:registrant>
      <domain:contact type="admin">sh8013</domain:contact>
      <domain:contact type="tech">sh8013</domain:contact>
      <domain:ns>
        <domain:hostObj>ns1.example.com</domain:hostObj>
        <domain:hostObj>ns1.example.net</domain:hostObj>
      </domain:ns>
      <domain:host>ns1.example.com</domain:host>
      <domain:host>ns2.example.com</domain:host>
      <domain:clID>ClientX</domain:clID>
      <domain:crID>ClientY</domain:crID>
      <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
      <domain:upID>ClientX</domain:upID>
      <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
      <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
      <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
      <domain:authInfo>
        <domain:pw>2fooBAR</domain:pw>
      </domain:authInfo>
    </domain:infData>
  </resData>
...

On y voit les serveurs de noms du domaine, ns1.example.com et ns1.example.net, son titulaire, identifié par un code, ici jd1234, sa date de création, le 3 avril 1999, etc.

De même, pour créer un domaine, on appele <epp:create> (section 3.2.1) avec des éléments de l'espace de nom urn:ietf:params:xml:ns:domain-1.0, par exemple :

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">2</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.example.com</domain:hostObj>
          <domain:hostObj>ns1.example.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>jd1234</domain:registrant>
...

La liste complète des commandes EPP utilisables pour ce type « domaine » figure dans la section 3.

La syntaxe utilisable pour un nom de domaine est celle du RFC 1123, bien plus restrictive que celle utilisée dans le DNS (section 2.1). Ce type « domaine » ne peut donc pas être utilisé pour tout nom de domaine légal.

Chaque domaine a un « statut », ceux mis par le client (typiquement un registrar) étant préfixés par client (section 2.3). Par exemple, clientHold indique que, à la demande du registrar, ce nom, quoique enregistré, ne doit pas être publié dans le DNS.