Les RFC (Request For Comments) sont les documents de référence de l'Internet. Produits par l'IETF pour la plupart, ils spécifient des normes, documentent des expériences, exposent des projets...
Leur gratuité et leur libre distribution ont joué un grand rôle dans le succès de l'Internet, notamment par rapport aux protocoles OSI de l'ISO organisation très fermée et dont les normes coûtent cher.
Je ne tente pas ici de traduire les RFC en français (un projet pour cela existe mais je n'y participe pas, considérant que c'est une mauvaise idée), mais simplement, grâce à une courte introduction en français, de donner envie de lire ces excellents documents.
Le public visé n'est pas le gourou mais l'honnête ingénieur ou l'étudiant.
Date de publication du RFC : Mars 2010
Auteur(s) du RFC : S. Nadas (Ericsson)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF vrrp
Première rédaction de cet article le 11 Mars 2010
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 :
224.0.0.18 et la IPv6 est
FF02:0:0:0:0:0:0:12.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
Date de publication du RFC : Mars 2010
Auteur(s) du RFC : J. Klensin, A. Hoenes (TR-Sys)
Chemin des normes
Première rédaction de cet article le 11 Mars 2010
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 :
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).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.
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 :
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.
Date de publication du RFC : Février 2010
Auteur(s) du RFC : J. Reschke (Greenbytes), J. Kunze (University of California)
Pour information
Première rédaction de cet article le 23 Février 2010
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.
Date de publication du RFC : Mars 2010
Auteur(s) du RFC : N. Freed, S. Vedam (Sun)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF sieve
Première rédaction de cet article le 11 Mars 2010
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.
Date de publication du RFC : Février 2010
Auteur(s) du RFC :
J. Levine (Taughannock)
Pour information
Première rédaction de cet article le 19 Février 2010
Dernière mise à jour le 25 Février 2010
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.
Date de publication du RFC : Février 2010
Auteur(s) du RFC : S. Weiler (Sparta), D. Ward (Cisco Systems), R. Housley (Vigil Security)
Pour information
Première rédaction de cet article le 13 Février 2010
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.
Date de publication du RFC : Février 2010
Auteur(s) du RFC : E. Davies (Policy
consulting), A. Doria (LTU)
Intérêt historique uniquement
Première rédaction de cet article le 19 Février 2010
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 !
Date de publication du RFC : Février 2010
Auteur(s) du RFC : A. Doria (LTU), E. Davies (Folly
consulting), F. Kastenholz
Intérêt historique uniquement
Première rédaction de cet article le 19 Février 2010
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 :
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).
Date de publication du RFC : Février 2010
Auteur(s) du RFC : E. Rescorla (RTFM), M. Ray, S. Dispensa (Phone Factor), N. Oskov (Microsoft)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 13 Février 2010
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 :
secure_renegotiation qui indique
si la nouvelle option est utilisable sur cette connexion TLS,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),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).
Date de publication du RFC : Décembre 2009
Auteur(s) du RFC : R. Braden (ISI), J. Halpern (Ericsson)
Pour information
Première rédaction de cet article le 18 Décembre 2009
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.
Date de publication du RFC : Décembre 2009
Auteur(s) du RFC : H. Alvestrand (Google), R. Housley (Vigil Security)
Première rédaction de cet article le 5 Janvier 2010
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 :
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 :
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.
Date de publication du RFC : Décembre 2009
Auteur(s) du RFC : L. Daigle, O. Kolkman
Pour information
Première rédaction de cet article le 5 Janvier 2010
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é.
Date de publication du RFC : Mars 2010
Auteur(s) du RFC : P. Resnick (Qualcomm), C. Newman (Sun)
Expérimental
Réalisé dans le cadre du groupe de travail IETF eai
Première rédaction de cet article le 4 Mars 2010
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.
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : J. Arkko (Ericsson), M. Cotton (ICANN), L. Vegoda (ICANN)
Pour information
Première rédaction de cet article le 15 Janvier 2010
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.
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : G. Huston (APNIC), M. Cotton (ICANN), Leo Vegoda (ICANN)
Pour information
Première rédaction de cet article le 15 Janvier 2010
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...
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : M. Cotton (ICANN), Leo Vegoda (ICANN)
Première rédaction de cet article le 15 Janvier 2010
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,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.
Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 22 Octobre 2009
Dernière mise à jour le 30 Octobre 2009
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).
Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 14 Octobre 2009
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.
Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 13 Octobre 2009
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).
Date de publication du RFC : Août 2009
Auteur(s) du RFC : S. Hollenbeck (Verisign)
Chemin des normes
Première rédaction de cet article le 14 Décembre 2009
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.