Mon blog

Un court et simple RFC, pour normaliser un nouvel en-tête dans les messages du courrier électronique, en-tête qui donne l'URI où on peut trouver une version archivée de ce message.

Pourquoi un tel en-tête ? Si on a le message, on n'a pas besoin de l'URI de référence, non ? Mais en fait, on a souvent besoin de passer, non pas le message mais une référence au message, par exemple parce qu'on a repéré une discussion intéressante sur une liste et qu'on veut donner une référence stable à cette discussion (la section 3.3 détaille ce besoin).

Voici un exemple de cet en-tête, pour le message qui annonce l'approbation de cette norme par l'IESG :

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'The Archived-At Message Header Field'   to Proposed Standard
Date: Mon, 10 Sep 2007 19:20:22 -0400
Archived-At: <http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg04069.html>

L'un des principaux utilisateurs de ce RFC devrait être l'IETF elle-même, qui accorde une grande importance à la disponibilité en ligne des archives de toutes ses listes de diffusion, afin qu'on puisse voir pourquoi tel choix a été fait dans une norme et qui l'a défendu. On va donc guetter les premières mises en œuvre de ce côté.

Les protocoles modernes comme SIP (qui sert surtout pour la téléphonie sur Internet mais aussi pour la messagerie instantanée) permettent d'obtenir bien des informations sensibles comme la localisation exacte de l'interlocuteur. Celui-ci n'a pas forcément envie de tenir le reste du monde au courant de ses activités. Notre RFC s'attaque donc à ce problème en décrivant un format de document exprimant des préférences en matière de protection de la vie privée.

Par exemple, une extension de SIP (RFC 3856, voir aussi le RFC 2778) permet d'être informé de la présence ou de l'absence d'une personne donnée. Ce n'est pas une information qu'on donne forcément à tout le monde ! D'une manière générale, la diminution considérable de la vie privée, consécutive au rôle grandissant de l'informatique, inquiète, à juste titre, de plus en plus de gens.

S'il est nécessaire que certains usages soient tout simplement interdits, comme le fait, par exemple, la loi française informatique & Libertés, pour d'autres, on peut envisager de négocier et d'arbitrer entre l'intimité et le caractère pratique de la diffusion d'informations. À condition qu'on puisse choisir et que ces choix soient respectés. L'IETF ne peut pas garantir ce respect mais elle peut au moins définir un format pour que les choix soient transmis de manière non ambigüe et c'est ce que fait ce RFC.

Il est l'héritier d'autres formats dont le plus connu est le P3P du W3C, qui permet aux serveurs Web de signaler leurs pratiques en matière de respect de la vie privée. P3P n'a eu aucun succès, sans doute en partie car les sites Web qui ont l'habitude de déclarer leurs politiques en vingt pages d'anglais légal incompréhensible ne voulaient pas les traduire dans un langage simple et non ambigü. Le W3C continue son travail sur ces « langages de politique » via l'activité Pling.

Notre RFC définit donc un format assez général pour couvrir d'autres besoins que ceux de SIP. La définition du format commence avec la section 4, qui détaille les principes de base. Notamment, ce format ne permet d'exprimer que des permissions, pas des interdictions. Tout est interdit par défaut et l'auteur du document doit lister les permissions. En effet, comme le sait toute personne qui a rédigé des ACL pour un routeur, on se trompe facilement, dans le sens d'une trop grande sécurité ou au contraire dans celui d'un laxisme involontaire. (La même section explique qu'il vaut mieux forcer l'utilisateur à exprimer clairement ses autorisations plutôt que de le laisser croire à tort qu'il est protégé.) Si une règle autorise 192.168.1.0/24 à faire une certaine action et qu'une autre interdit cette action à 192.168.1.0/26, il n'est pas immédiatement évident de savoir si 192.168.1.62 est autorisé...

La solution radicale adoptée par notre RFC rend l'écriture des règles plus simple, et notamment indépendante de l'ordre dans lequel elles sont exprimées (un piège classique avec les ACL). Pour les mêmes raisons de simplicité, la section 5 explique pourquoi des fonctions intéressantes comme les expressions rationnelles ont été omises.

La section 7 est le gros morceau du RFC. Elle détaille les conditions qui décident si une règle s'applique ou pas. Pour l'instant (mais des extensions ultérieures pourraient changer cela), il y a trois conditions possibles. La première est l'identité, décrite en section 7.1. Elle fonctionne en comparant une identité stockée dans la règle avec celle obtenue de l'autre utilisateur (l'authentification de cette seconde identité n'est pas couverte dans le RFC). Ainsi, on pourra dire « si l'appelant est +33 1 38 30 83 46, alors ... ». Voici un exemple inspiré du RFC (l'élément <identity> correspond si au moins un des éléments <one> correspond) :

              <identity>
                   <one id="sip:alice@example.org"/>
                   <one id="tel:+1-212-555-1234" />
                   <one id="mailto:bob@example.net" />
               </identity>

Dans un autre exemple, on voit la possibilité d'autoriser tout le monde sauf quelques uns :

               <identity>
                   <many>
                       <except domain="example.com"/>
                       <except id="sip:alice@bad.example.net"/>
                       <except id="sip:bob@good.example.net"/>
                       <except id="tel:+1-212-555-1234" />
                       <except id="sip:alice@example.com"/>
                   </many>
               </identity>

Une autre condition possible est la sphère (section 7.3). Une sphère n'est pas une identité mais une situation dans laquelle on se trouve (par exemple « au travail », « en train de manger » ou « endormi »). Le RFC n'essaie pas de définir une ontologie de ces situations, chacun est libre du vocabulaire utilisé. Enfin, la troisième espère de condition, la validité permet d'ajouter des contraintes temporelles. Voici un exemple (lorsqu'il y a plusieurs conditions, elles doivent toutes être vraies pour que le total soit vrai) :

<conditions>
   <sphere value="work"/>
   <identity>
          <one id="sip:boss@example.com"/>
   </identity>
   <validity>
                   <from>1900-01-01T08:00:00+01:00</from>
                   <until>2010-12-31T18:00:00+01:00</until>
   </validity>
</condition>

Une fois qu'on dispose de conditions, on peut exprimer des actions, qui font l'objet de la section 8 et des transformations (section 9). Notre RFC ne définit aucune action, cela sera laissé à des RFC ultérieurs.

Enfin, la section 13 est consacrée au schéma formel du langage, écrit en W3C Schema. Les actions et les transformations, non décrites dans ce RFC, sont marquées comme extensibles en les dérivant de xsd:anyType.

Pour rendre plus facilement analysables les innombrables rapports d'incidents de sécurité qui circulent sur Internet tous les jours, ce RFC spécifie un format standard XML, nommé IODEF, pour décrire ces incidents. Ce RFC décrivait la version 1, une version 2, plus étendue, a ensuite été publiée dans le RFC 7970.

Tous les jours, des organisations comme les CERT envoient et reçoivent des rapports détaillés concernant une attaque sur un réseau informatique ou un serveur. Ces rapports sont longs et détaillés mais, la plupart du temps, ce n'est pas une attaque isolée qui est intéressante, c'est l'image qui apparait lorsqu'on synthétise tous les rapports, et qu'on voit alors les tendances, par exemple l'arrivée d'un nouveau ver ou bien une attaque concertée contre un pays donné. D'où l'importance de pouvoir analyser automatiquement ces rapports, ce qui impose un modèle de données et un format standard, ce que fournit ce RFC.

Le modèle de données est proche des modèles objet, par exemple dans la descriptions des classes d'objets manipulés (comme la classe Incident en section 3.2, avec la cardinalité des attributs). Ces classes sont composés avec des données élémentaires (booléens, entiers, dates) décrits dans la section 2. Le schéma XML complet, écrit en W3C Schema, figure dans la section 8.

Une première tentative de normaliser un tel format avait été faite avec IDMEF, dans le RFC 4765 mais n'avait pas rencontré de consensus. Notre RFC représente désormais la solution standard.

Voici un exemple d'un rapport d'incident, tiré du RFC et qui décrit une reconnaissance menée par un agresseur potentiel :

   <?xml version="1.0" encoding="UTF-8" ?>
   <!-- This example describes reconnaissance activity: one-to-one and
        one-to-many scanning -->
   <IODEF-Document version="1.00" lang="en"
     xmlns="urn:ietf:params:xml:ns:iodef-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
     <Incident purpose="reporting">
       <IncidentID name="csirt.example.com">59334</IncidentID>
       <ReportTime>2006-08-02T05:54:02-05:00</ReportTime>
       <Assessment>
         <Impact type="recon" completion="succeeded" />
       </Assessment>
       <Method>
         <!-- Reference to the scanning tool "nmap" -->
         <Reference>
           <ReferenceName>nmap</ReferenceName>
           <URL>http://nmap.toolsite.example.com</URL>
         </Reference>
       </Method>
       <!-- Organizational contact and that for staff in that
            organization -->
       <Contact role="creator" type="organization">
         <ContactName>CSIRT for example.com</ContactName>
         <Email>contact@csirt.example.com</Email>
         <Telephone>+1 412 555 12345</Telephone>
         <!-- Since this <Contact> is nested, Joe Smith is part of the
             CSIRT for example.com -->
         <Contact role="tech" type="person" restriction="need-to-know">
           <ContactName>Joe Smith</ContactName>
           <Email>smith@csirt.example.com</Email>
         </Contact>
       </Contact>
       <EventData>
         <!-- Scanning activity as follows:
           192.0.2.1:60524 >> 192.0.2.3:137
                  192.0.2.1:60526 >> 192.0.2.3:138
                  192.0.2.1:60527 >> 192.0.2.3:139
                  192.0.2.1:60531 >> 192.0.2.3:445
         -->
         <Flow>
           <System category="source">
             <Node>
               <Address category="ipv4-addr">192.0.2.200</Address>
             </Node>
             <Service ip_protocol="6">
               <Portlist>60524,60526,60527,60531</Portlist>
             </Service>
           </System>
           <System category="target">
             <Node>
               <Address category="ipv4-addr">192.0.2.201</Address>
             </Node>
             <Service ip_protocol="6">
               <Portlist>137-139,445</Portlist>
             </Service>
           </System>
         </Flow>
         <!-- Scanning activity as follows:
               192.0.2.2 >> 192.0.2.3/28:445 -->
         <Flow>
           <System category="source">
             <Node>
               <Address category="ipv4-addr">192.0.2.240</Address>
             </Node>
           </System>
           <System category="target">
             <Node>
               <Address category="ipv4-net">192.0.2.64/28</Address>
             </Node>
             <Service ip_protocol="6">
               <Port>445</Port>
             </Service>
           </System>
         </Flow>
       </EventData>
     </Incident>
   </IODEF-Document>

Quelques informations sur le rythme de publication de ce blog, faites avec gnuplot...

Un très court RFC qui normalise la représentation des étiquettes de langue dans les MIB.

Plusieurs MIB, les structures de données utilisées notamment pour SNMP, utilisaient leurs propres conventions pour représenter des identificateurs formels comme les URI ou les étiquettes de langue du RFC 4646. Petit à petit, ces conventions migrent dans des RFC spécialisés. Celui-ci décrit simplement en une page les conventions à utiliser pour mettre une étiquette de langue dans une MIB, comme celles du RFC 5132.

Le principal choix est de les mettre entièrement en minuscules, puis de limiter leur longueur à 64 caractères.

Ce RFC est l'adaptation à IPv6 du protocole décrit dans le RFC 1191, protocole qui permet de découvrir la MTU du chemin entre deux machines reliées par Internet. Il a depuis été remplacé par le RFC 8201.x

Avec IPv4, déterminer la MTU maximale du chemin est très utile pour optimiser les performances. Mais elle devient presque indispensable en IPv6, où les routeurs n'ont pas le droit de fragmenter les paquets trop gros (toute fragmentation doit être faite dans la machine de départ). PMTU fait donc quasi-obligatoirement partie d'IPv6 (une alternative est de n'envoyer que des paquets suffisamment petits pour passer partout).

L'algorithme est le même qu'en v4, envoyer des paquets, et voir si on reçoit des paquets ICMP Packet too big qui contiennent en général la MTU maximale du lien suivant. (Pas de bit DF - Don't fragment - en IPv6 puisque la fragmentation n'est possible qu'à la source. L'annexe A détaille les différences avec l'algorithme IPv4 décrit dans le RFC 1191.)

Comme avec IPv4, l'algorithme PMTU marche mal en pratique car beaucoup de sites filtrent stupidement tous les paquets ICMP et la machine qui tente de faire de la Path MTU discovery n'aura jamais de réponse. IPv6, comme IPv4, devra donc sans doute utiliser la nouvelle technique du RFC 4821

(Un excellent article très complet sur la question est A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation.)

Le protocole PPP sert à bien d'autres choses qu'aux liaisons modem. Par exemple, il est un des plus utilisés pour les connexions ADSL, dans sa variante PPPoE, que décrit notre RFC.

Comme la plupart des technologies d'accès aujourd'hui, une connexion ADSL typique fournit un accès en Ethernet et PPP (RFC 1661) n'avait été conçu que pour le point-à-point où il n'y a que deux machines sur le réseau. L'essentiel de notre RFC est donc consacré au protocole de découverte (section 5) par lequel une machine PPPoE va pouvoir trouver son concentrateur d'accès, en demandant à la cantonade.

La section 3 décrit le principe du protocole. Le client PPPoE (PPP est pair-à-pair, pas client-serveur mais le protocole de découverte, lui, est client-serveur) émet un paquet PADI de recherche du concentrateur, celui-ci répond avec un paquet PADO (qui contient des étiquettes, décrites dans l'annexe A, pour donner des informations supplémentaires) et lui indique un numéro de session (0x2041 dans les exemples ci-dessous) qui permet de séparer les différentes sessions PPP qui coexistent sur le même Ethernet.

Ensuite, c'est LCP qui prend le relais et on fait du PPP classique (la section 7 donne quelques détails, notamment sur les problèmes de MTU mais attention, le RFC 4638 l'a mise à jour).

Voici, sur une machine Debian, un extrait du fichier de configuration /etc/ppp/peers/nerim pour se connecter au FAI Nerim. Le « modem » ADSL est configuré en simple pont pour que la machine Debian puisse joindre le concentrateur d'accès en Ethernet :

# Nerim via LDcom degroupe
pty "pppoe -I eth1 -T 80 -m 1412"
linkname nerim
# wait for PADO (3s)
connect-delay 3000
# Le reste n'est pas spécifique à PPPoE...

Pour créer le pseudo-terminal (pty) où PPP va se connecter, on lance le démon pppoe.

Voici la découverte du concentrateur d'accès avec la commande Unix pppoe :

# pppoe -A -I eth1
Access-Concentrator: SE800-CBV3-1
       Service-Name: ldcom
AC-Ethernet-Address: 00:30:88:10:3c:b9

et voici son résultat, vu avec tcpdump (sections 5.1 et 5.2 du RFC) :

% tcpdump -n -e -I eth1
22:25:39.424864 00:0c:76:1f:12:7b > ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 24: PPPoE PADI
22:25:39.469939 00:30:88:10:3c:b9 > 00:0c:76:1f:12:7b, ethertype PPPoE D (0x8863), length 60: PPPoE PADO [AC-Name "SE800-CBV3-1"] [Service-Name "ldcom"] [EOL]

Si, au lieu de regarder avec tcpdump l'interface Ethernet (ici eth1), on regarde l'interface PPP (ici ppp0), on voit passer des paquets IP classiques. Pour voir l'encapsulation PPP, il faut regarder l'interface Ethernet et le trafic ressemble à :

% tcpdump -n -e -I eth1
22:28:16.129173 00:0c:76:1f:12:7b > 00:30:88:10:3c:b9, ethertype PPPoE S (0x8864), length 62: PPPoE  [ses 0x2041] PPP-IP (0x0021), length 42: IP 213.41.181.9.35156 > 204.13.160.129.80: F 212:212(0) ack 875 win 6984
22:28:16.323916 00:30:88:10:3c:b9 > 00:0c:76:1f:12:7b, ethertype PPPoE S (0x8864), length 62: PPPoE  [ses 0x2041] PPP-IP (0x0021), length 42: IP 204.13.160.129.80 > 213.41.181.9.35156: . ack 213 win 8189

Notez que le type Ethernet a changé, passant de 0x8863 pour la découverte à 0x8864 pour la session (section 4 du RFC).

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

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

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

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

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

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

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

Ce RFC décrit l'architecture d'adressage d'IPv6, ainsi que des points comme la représentation textuelle des adresses.

IPv6 a beaucoup changé depuis dix ans, le manque de déploiements opérationnels laissant davantage de liberté aux auteurs de protocole. Moins de base installée égale moins de stabilité des normes, jusqu'à la dissolution récente du groupe de travail IPv6 de l'IETF. Ce RFC sera donc probablement le dernier sur ce sujet. Il succède au RFC 3513, avec des changements peu importants, le principal étant l'abandon des adresses locales au site.

Il n'y a rien d'extraordinaire dans l'adressage IPv6, par rapport à son prédécesseur IPv4 depuis que celui-ci a abandonné les anciennes classes d'adresses. Les mêmes concepts sont à l'œuvre, notamment la notion de préfixe d'une adresse (les N premiers bits, où N dépend de l'architecture du réseau).

Une importante exception à cette règle, qui n'a pas d'équivalent en IPv4, est que les 64 derniers bits sont réservés à l'identificateur d'interface (interface identifier ou IID). On ne peut donc pas, contrairement à IPv4, utiliser des préfixes de longueur quelconque (la section 2.5.1 indique toutefois des cas où on peut utiliser des préfixes de plus de 64 bits).

Cet interface identifier était souvent dérivé de l'adresse MAC (l'algorithme est décrit dans l'annexe A) mais il peut être généré autrement (méthode recommandée par le RFC 8064), attribué arbitrairement, ou encore fabriqué par l'algorithme décrit dans le RFC 8981. L'abondance des adresses en IPv6 permet des fantaisies nouvelles, par exemple le serveur racine F a pour adresse 2001:500::1035 en l'honneur du RFC 1035, qui normalise le DNS. De même, le serveur racine B a comme adresse 2001:478:65::53, 53 étant le port utilisé par le DNS.

Les premiers bits de l'adresse IPv6 indiquent son type. C'est ainsi que le préfixe FE80::/10 identifie les adresses locales au lien (link-local). De même, les adresses de diffusion (peu utilisées à l'heure actuelle) sont couvertes par le préfixe FF00::/8. Attention, les adresses locales au site ont été abandonnées dans le RFC 3879, remplacées par les ULA du RFC 4193.

La section 2.2 décrit la forme textuelle des adresses, avec les nombres codés en hexadécimal et avec le deux-points comme séparateur, par exemple 2001:DB8:42::1954:2:1. Deux deux-points successifs identifient une suite de zéros. L'adresse ci-dessus aurait donc pu s'écrire 2001:DB8:42:0:0:1954:2:1.

On notera qu'il n'a jamais existé de représentation textuelle normalisée des adresses IPv4 (la forme avec quatre octets en décimal séparés par des points est la plus courante mais pas la seule, essayez telnet 651667656 si vous ne me croyez pas et regardez à quelle machine il tente de se connecter).

Deuxième RFC (après le RFC 606) à avoir proposé de mettre la liste de toutes les machines d'Arpanet en ligne, à une époque où le DNS était encore très loin dans le futur.

Avant le DNS, le RFC 606 suggérait de résoudre le problème lancinant de la mise à jour des fichiers hosts (carnets d'adresses de machines) en mettant en ligne, accessible à tous, un fichier de toutes les machines connues sur Arpanet, avec leurs adresses (c'était avant IPv4 et les adresses tenaient sur un octet). Notre RFC était l'acceptation officielle de ce projet par le NIC, projet qui allait devenir HOSTS.TXT, le fichier de référence d'Arpanet.

HOSTS.TXT durera de nombreuses années, recopié plus ou moins régulièrement par les machines d'Arpanet. Au bout d'un moment, sa taille croissante et la charge qu'impliquait son transfert, la difficulté de maintenir un fichier central de toutes les machines, et le fait que les copies locales n'étaient jamais à jour a mené au développement d'un système décentralisé et dynamique, le DNS, qui a fait disparaitre HOSTS.TXT. (Sur l'histoire du DNS, voir mon article « Quelques éléments d'histoire... ».)

Retrouver des versions anciennes de ce fichier a été un travail amusant. En commençant par les plus récentes, Geoffroy Rivat me signale qu'on peut récupérer une version de 1994, soit bien après que le DNS aie tout remplacé (et qu'on soit passé à IPv4). Noel Chiappa, lui, m'a indiqué une version encore plus ancienne, mais toujours en IPv4.

Il signale aussi une curieuse curieuse archive au format ITS, qu'on peut assez bien lire avec un éditeur normal et qui contient apparemment une copie du HOSTS.TXT de 1983 ! En voici un extrait :

HOST MIT-LISPM-9,	CHAOS 3074,USER,LISPM,LISPM,[CADR-9,CADR9,LM9]
HOST MIT-LISPM-TEST,	CHAOS 3024,USER,LISPM,LISPM,[CADR-TEST,LMTEST,TEST]
HOST MIT-MACEWAN,	LCS 12/120,SERVER,UNIX,VAX,[MACEWAN]
HOST MIT-MARIE,		CHAOS 7500,SERVER,VMS,VAX,[MARIE,MIT-LNS]
HOST MIT-MC,		[3/44,CHAOS 1440],SERVER,ITS,PDP10,[MC,MITMC]

Une autre copie des fichiers de cette époque se trouve en http://saildart.org/prog/NET/index.html. Voir par exemple un HOSTS.TXT de 1983 en http://saildart.org/prog/NET/HST_NET/.html/000071?70,37120.

Enfin, la version la plus ancienne a été extraite par Elizabeth Feinler, directrice du NIC à l'époque, et que je remercie beaucoup pour ses efforts. Une fois retrouvée une copie papier de 1974 (apparemment incomplète), Liz Borchardt et Dana Chrisler, du Computer History Musem, ont numérisé ce document. Les adresses étaient encore codées sur un seul octet... Une copie plus récente (1982, à l'époque du RFC 810, qu'elle avait écrit) montre des adresses IPv4, sur quatre octets.

On notera avec amusement dans ce RFC que le NIC utilisait à l'époque un programme pour transformer sa base de données en fichier HOSTS.TXT. Aujourd'hui, vingt-trois ans après, l'IANA n'a pas encore rattrapé cette étape et maintient toujours ses registres dans des fichiers texte, « à la main », avec les inévitables erreurs que ce processus archaïque entraine.

Heureuse époque où un RFC pouvait tenir sur une seule page. Celui-ci normalise le protocole echo, utile surtout pour le débogage.

echo sert à déboguer des serveurs réseaux. Son principe est de renvoyer les données transmises par le client en TCP ou en UDP. Les requêtes ICMP du même nom ne suffisent pas car, sur une machine Unix, elles sont typiquement traitées par le noyau et une machine peut donc répondre à ping et être néanmoins incapable de faire fonctionner des applications, par exemple parce qu'elle swappe trop. Un protocole de test de la couche 7 était donc nécessaire.

Du côté du serveur, echo est typiquement mis en œuvre par inetd mais on peut aussi en trouver une curieuse implémentation dans Emacs ou bien mon implémentation en Python, pour ceux qui veulent voir un exemple d'utilisation de la bibliothèque SocketServer. Une autre implémentation, en Go, illustrant bien les possibilités de ce langage, est NoNewContent.

Comme echo est un protocole très simple, les programmes de test réseau l'utilisent souvent. Par exemple, GnuTLS affiche un sample TLS 1.0 echo server dans sa documentation.

Du côté du client, echo se retrouve par exemple dans echoping, à qui il doit son nom (echo était le premier protocole utilisé par echoping).

Le protocole echo est en général désactivé depuis une alerte de sécurité. Il est à noter que echo n'est dangereux qu'en UDP (et encore, il ne permet pas d'amplification de l'attaque) ou bien combiné avec d'autres protocoles comme chargen (RFC 864). Mais le résultat de cette alerte a été la désactivation quasi-systématique de cet utile protocole (à une époque, il était activé par défaut sur toute machine Unix et sur les routeurs Cisco).

Un livre à grand succès, que tout le monde cite, pas forcément correctement. Collapse (Effondrement, dans l'édition française) raconte le sort de plusieurs civilisations qui ont disparues ou quasiment disparues, parce qu'elles n'ont pas su réagir et qu'elles ont tenu à continuer dans une mauvaise voie.

Jared Diamond est un biogéographe très connu, déjà auteur d'autres livres largement diffusés. Collapse est un gros livre mais raconté avec tellement de verve et d'érudition qu'on ne voit pas le temps passer en le lisant. Plusieurs civilisations disparues sont successivement étudiées, des Vikings du Groenland aux Mayas d'Amérique Centrale en passant par l'île de Pâques. Sans oublier des civilisations qui se sont sorties de crises écologiques graves, comme les papous de Nouvelle-Guinée ou qui s'en tireront peut-être comme les États-Unis d'ajourd'hui (Diamond étudie en détail le Montana et, de manière plus rapide, la région de Los Angeles).

À chaque fois, l'auteur nous décrit une civilisation brillante, sûre d'elle, et qui fonce avec obstination vers l'abîme, situé en général juste après le moment de plus grand rayonnement.

Un des points importants de Diamond est que ces civilisations disparues n'étaient pas forcément plus stupides ou plus ignorantes que la nôtre. Les erreurs qu'ils ont commises, l'aveuglément dont ils faisaient preuve, étaient dus à des facteurs qui existent aussi dans nos civilisations modernes. Si nous avons des avantages sur eux (nous savons davantage de choses), nous avons aussi des faiblesses plus graves (Diamond rappelle que les habitants de l'île de Pâques ont réussi à anéantir leur forêt avec seulement des haches de pierre et s'inquiète de ce que nous pourrions « réussir » à faire avec nos outils modernes).

Beaucoup de compte-rendus de Collapse ont insisté sur le côté pittoresque et ridicule de certaines décisions qu'avaient prises nos prédécesseurs (comme les Vikings du Groenland s'obstinant à construire d'immenses églises, dans un pays où le bois est plus rare que l'or, ou encore refusant de manger du poisson, alors que leurs bateaux naviguaient dans des eaux parmi les plus poissonneuses du monde). Mais Diamond s'oppose tout à fait à cette vision simpliste et rassurante, qui nous permettrait à nous, occidentaux d'aujourd'hui, de nous moquer des sauvages stupides des siècles passés. Il affirme que nos décisions ou non-décisions d'aujourd'hui, par exemple en ce qui concerne la lutte contre le réchauffement planétaire, apparaitront tout aussi ridicules dans le futur. Et qu'aucun effondrement ne peut être imputé à une cause unique. Le fanatisme religieux des Vikings du Groenland a certainement joué un rôle dans leur disparition (par exemple, en leur faisant refuser d'apprendre quoi que ce soit des Inuits, dont les compétences étaient ignorées car ils étaient païens). Mais leur civilisation, rappelle Diamond, a duré plus longtemps que le peuplement anglo-saxon en Amérique du Nord. Et c'est peut-être justement ce fanatisme religieux qui les a aidé à tenir si longtemps.

Diamond passe donc du temps à étudier les facteurs qui peuvent aider à comprendre la disparition ou le maintien de certaines civilisations. Son propos est nettement volontariste, comme le résume le sous-titre du livre : les civilisations choisissent leur sort. Là encore, Diamond voit beaucoup de solutions possibles, qu'il organise en deux catégories. Les méthodes de bas en haut, comme l'extrême démocratie pratiquée par les papous, exaspérante pour un occidental, mais qui leur a permis de prendre les décisions radicales exigées par la déforestation de leur île. Et les méthodes de haut en bas comme celles, très autoritaires, utilisées par le shogun au Japon pour sauver les derniers arbres de l'archipel, avec succès.

Diamond mentionne notamment, parmi les facteurs aggravant, l'inégalité. Chez les papous, les « grands hommes » (des sortes de sages respectés) cultivent un lopin de terre identique à celui des autres. Ils comprennent bien que leur sort est lié au sort commun. Au contraire, dans des sociétés ultra-hiérarchisées comme celle des Vikings ou des Mayas, les chefs pouvaient développer l'illusion qu'ils échapperaient à l'effondrement final et n'avaient donc aucune motivation pour tenter d'arrêter la catastrophe.

Un long article du Monde Diplomatique en décembre 2007, s'attaque à ce livre en le présentant comme l'inspirateur de la politique écologique de Sarkozy. C'est mettre les choses à l'envers. Sarkozy cite Diamond (qu'il n'a peut-être jamais lu) parce que c'est un auteur à la mode et parce que tout homme politique français se doit d'avoir une vision planétaire et d'avoir lu de gros livres. Mais rien n'indique que Sarkozy, l'ami des milliardaires, soit prêt à prendre les mesures radicales que réclame Diamond, surtout si elles s'attaquent aux intérêts du patronat.

(Le même article accuse aussi Diamond d'être un partisan caché d'un génocide, simplement parce qu'il fait remarquer les risques de la surpopulation.)

À une époque, il semblait encore possible de résumer dans un RFC tout ce que devait savoir le développeur de services réseaux. Ce n'est évidemment plus le cas, néanmoins, ce RFC, qui synthétise les règles que doivent respecter les machines non-routeuses reste utile, certaines des règles qu'il pose étant toujours d'actualité.

Un problème classique de l'implémenteur est le nombre de RFC à lire, et le risque de ne plus pouvoir distinguer les choses importantes des détails, au milieu de toutes ces normes. D'où l'idée de résumer les « choses importantes » dans des RFC de synthèse comme le RFC 1812 pour les routeurs ou comme deux RFC, le RFC 1122 et le nôtre, qui couvrent les machines non-routeuses (host en anglais, parfois traduit par terminal, qui est un terme que je trouve trop marqué par l'époque des mainframes et du Minitel). Le RFC 1122 couvre les couches basses et le 1123 les couches hautes. C'est un des plus vieux RFC encore en service. À l'époque (1989), les médias et les experts officiels n'avaient pas encore découvert l'Internet mais celui-ci était déjà suffisamment complexe pour que la section 1.2.1 s'inquiète de l'« énorme croissance de l'Internet » et des problèmes qu'elle pose.

Comme le note la section 1, de tels RFC de synthèse sont normalement inutiles. « Une mise en œuvre de bonne foi, faite en lisant soigneusement les RFC, ainsi qu'en suivant les activités de la communauté technique et des bons principes d'ingéniérie, ne devrait se différencier des demandes de ce RFC que de manière mineure. » Mais la pratique ne suivant pas toujours la théorie, et des mises en œuvre des protocoles Internet s'étant avérées très boguées, la réalisation d'un RFC de rappel a semblé une bonne idée. En revanche, la mise à jour régulière de ce RFC, promise en section 1, ne s'est jamais concrétisée, même s'il y a eu des mises à jour partielles, comme les RFC 1349 ou RFC 2181.

La partie la plus souvent citée de notre RFC est certainement la section 2.1 Host names and numbers, qui normalise la syntaxe pour les noms de machines sur Internet. Cette syntaxe est limitée à LDH (Letters - Digits - Hyphen) c'est-à-dire un sous-ensemble d'ASCII limité aux lettres de A à Z, aux chiffres et au tiret. Contrairement à ce qu'on lit souvent sous la plume d'ignorants, cette limite n'a rien à voir avec le DNS, qui était une invention récente à l'époque de notre RFC. Cette limite plonge au contraire ses racines dans des normes plus anciennes, comme le RFC 952 qui était même encore plus strict (le nom ne pouvait pas commencer par un chiffre). Ainsi, les règles pour les noms de machines ne sont pas les mêmes que pour un nom de domaine. C'est pour cela qu'il a fallu développer IDN (RFC 3490), pas à cause d'une soi-disant limite du DNS.

La section 1.2.2 rappelle un de ces « bons principes d'ingéniérie », la fameuse phrase « Soyez prudents dans ce que vous envoyez et ouverts dans ce que vous recevez » (« Be liberal in what you accept, and conservative in what you send », déjà présente dans le RFC 791).

Voyons maintenant les autres parties, moins célèbres, de ce RFC.

Sur certains points, les changements dans l'Internet ont été positifs. C'est ainsi que la section 1.2.4 déplorait que l'auto-configuration des machines connectés était toujours aussi utopique, alors que depuis, notamment grâce à DHCP (RFC 2131), elle est devenue une réalité.

Par contre, d'autres fonctions, sur lesquelles on fondait beaucoup d'espoirs, n'ont jamais vraiment pris. Ainsi, la section 2.4 mentionne les TOS d'IPv4, que peu d'applications utilisent et que beaucoup de routeurs ou de coupe-feux bloquent. (Petite publicité personnelle : echoping permet de définir ces valeurs TOS, avec l'option -P.)

La section 3 est consacrée au protocole telnet, qui devrait logiquement être abandonné aujourd'hui, remplacé par SSH.

La section 4 concerne le transfert de fichiers, qui à l'époque se faisait uniquement avec FTP. Il est toujours utilisé aujourd'hui, mais HTTP (RFC 2616) et SCP ont diminué son importance.

La section 5 parle du courrier électronique mais on ne recommande pas sa lecture, les normes et, encore plus, la réalité ayant beaucoup évolué depuis (les textes à jour sont les RFC 2821 et RFC 2822).

La section 6.1 détaille les interactions avec les systèmes de résolution de noms. Elle n'est pas limitée au DNS, loin de là, la section 6.1.3.8 expliquant la possibilité d'utiliser également un fichier local (/etc/hosts sur Unix) et de configurer quel mécanisme de résolution est utilisé (/etc/host.conf sur Unix).

La 6.1.4, elle, mentionne les listes de domaines dans lesquels chercher un nom (fonction mise en œuvre avec la directive search dans le /etc/resolv.conf des machines Unix). La publication du RFC en 1989 n'a pas empêché Verisign de déposer un brevet en 2003 (6,560,634) sur cette fonction. Et l'office états-unien des brevets l'a accepté (les offices des brevets acceptent tout et n'importe quoi ; ils n'ont ni la compétence, ni l'envie de chercher des précédents, puisque leurs revenus dépendent des dépôts).

La section 6.2 concerne la gestion des machines, à une époque où le protocole SNMP était très récent.

Il n'y a pas que des normes qui réussissent, à l'IETF. Il y a aussi des échecs, comme cette amélioration du protocole TCP, T/TCP, qui portait de nombreux espoirs à une époque et est pourtant aujourd'hui abandonnée.

T/TCP, normalisé dans ce RFC, visait à résoudre un problème de TCP : le temps d'établissement de la connexion est souvent supérieur au temps passé à transmettre des données, dès que les données sont peu nombreuses. C'est le cas des protocoles de type requête/réponse comme HTTP (beaucoup de pages Web font moins d'un ou un et demi kilo-octet, soit moins qu'un seul paquet IP) mais aussi du DNS ou de SNMP, que notre RFC cite dans sa section 1. Pour ces protocoles, on souhaiterait typiquement n'envoyer que deux paquets, un pour la question et un pour la réponse, laissant le mécanisme normal de TCP aux transferts de gros fichiers, pour lesquels le temps d'établissement de la connexion est négligeable. Le DNS ou SNMP ont choisi d'utiliser UDP et, comme celui-ci n'offre aucune fiabilité, doivent donc gérer les paquets perdus, les retransmissions, etc. HTTP a choisi d'utiliser TCP, ce qui simplifie la tâche des développeurs d'applications Web mais augmente nettement la durée d'une requête Web typique.

Pourquoi ? À cause d'une fonction essentielle de TCP, le 3-way handshake. TCP ne peut pas envoyer ne serait-ce qu'un octet de données avant d'avoir terminé l'ouverture de la connexion et cette ouverture nécessite trois paquets, le paquet de demande d'ouverture d'une connexion, SYN, le paquet d'acceptation et d'accusé de réception, SYN+ACK et le paquet d'accusé de réception ACK. Si le RTT du réseau est important (par exemple sur les liaisons satellite), la durée du 3-way handshake pourra être l'essentiel de la durée de la requête. On peut voir cet effet avec echoping, sur un site Web (http://www.kame.net/) dont la page d'accueil est très légère :

% echoping -v -h / www.kame.net

This is echoping, version 5.2.0.

Trying to connect to internet address 2001:200:0:8002:203:47ff:fea5:3085 80 to transmit 88 bytes...
Trying to send 256 bytes to internet address 2001:200:0:8002:203:47ff:fea5:3085...
Connected...
TCP Latency: 0.331326 seconds
Sent (88 bytes)...
Application Latency: 0.357898 seconds
3241 bytes read from server.
Elapsed time: 0.711559 seconds

Le temps d'établissement de la connexion (TCP latency) est la moitié du temps total. Voici le 3-way handshake correspondant, vu avec tcpdump (le grand S après les adresses IP indique un paquet SYN) :

21:43:15.110842 2001:7a8:7509::1.35261 > 2001:200:0:8002:203:47ff:fea5:3085.80: S 845465777:845465777(0) win 5728 <mss 1432,sackOK,timestamp 10604938 0,nop,wscale 0>

21:43:15.425956 2001:200:0:8002:203:47ff:fea5:3085.80 > 2001:7a8:7509::1.35261: S 3136927327:3136927327(0) ack 845465778 win 65535 <mss 1440,nop,wscale 1,nop,nop,timestamp 476839171 10604938,[|tcp]> [class 0x3] [flowlabel 0x71d12]

21:43:15.426014 2001:7a8:7509::1.35261 > 2001:200:0:8002:203:47ff:fea5:3085.80: . ack 1 win 5728 <nop,nop,timestamp 10605253 476839171>

À la fin de cette échange d'un tiers de seconde, aucune donnée « utile » n'a encore été envoyée.

(Un autre problème de TCP pour ce genre de liens est le délai d'attente à la fin d'une connexion, où chaque machine doit garder un état pour pouvoir traiter correctement les paquets arrivant en retard. Pour un serveur très chargé, gérant beaucoup de requêtes, c'est une vraie contrainte.)

L'idée de base de T/TCP est de transporter dès le premier paquet les données, de façon à ce que l'acceptation de la connexion puisse également porter la réponse. Cela se fait en utilisant une option de TCP, CC (Connection Count) qui indique la présence de données dans le paquet SYN. Le Connection Count sert également de cookie pour garantir qu'on parle bien à la même machine. Un certain nombre de détails doivent être pris en compte pour que cela marche, en conservant la fiabilité de TCP, même si des paquets sont perdus. Ce qui explique que le protocole soit plus complexe que résumé ici (les sections 2 et 3 le détaillent).

Par exemple, comme la connexion ne dure pas longtemps, la mesure du RTT que fait normalement TCP pour optimiser l'utilisation du réseau ne peut avoir lieu. La section 4.3 demande donc qu'une machine T/TCP garde un cache des RTT des différentes machines à laquelle elle parle, pour obtenir approximativement le même effet.

L'idée était donc très tentante et a été promue par plusieurs experts comme W. Richard Stevens, qui s'en est fait l'ardent défenseur. Mais peu de systèmes d'exploitation l'ont implémenté (FreeBSD est la principale exception mais Linux a eu aussi sa version), peu de machines l'ont activé et peu de logiciels s'en servaient (echoping avait une option -r pour T/TCP mais elle a été retirée pour les raisons exposées plus loin, cf. bogue #1350714).

Outre la simple inertie face à la nouveauté, T/TCP a en effet été rapidement victime d'une sécurité plus faible que celle de TCP. Il n'y a pas de miracle : si on va plus vite, on vérifie moins. Alors que les adresses IP d'une connexion TCP sont relativement authentifiées (car le numéro de séquence TCP doit être renvoyé, ce qui impose de donner sa vraie adresse IP pour recevoir les messages), T/TCP n'est guère plus fiable qu'UDP face à l'usurpation d'adresses IP. Comme les réponses sont souvent plus grandes que les requêtes, cela permet en outre une amplification de l'attaque.

Ces failles ont été documentées dans plusieurs articles :

• VU#464113: TCP/IP implementations handle unusual flag combinations inconsistently
• Security Problems Associated With T/TCP en 1996,
• Example of RFC-1644 attack sur Bugtraq en 1998,
• Enhanced Transaction TCP - Design and Implementation qui proposait une amélioration du protocole, qui ne semble pas avoir eu de suite.

Sur une machine FreeBSD, T/TCP semble coupé par défaut, désormais (sysctl -a | grep -E 'rfc1644|dropsyn' pour voir les variables pertinentes).

Finalement, c'est le RFC 4614 qui a marqué l'abandon officiel de T/TCP. Le RFC 6247 entérinera cet abandon en reclassifiant notre RFC 1644 comme « intérêt historique seulement ».

Pour le chef de projet, pour les développeurs, ou pour les simples curieux, il peut être intéressant d'afficher un graphe des commits dans un dépôt Subversion. C'est ce que fait le programme présenté ici, qui utilise Gnuplot pour créer une jolie image montrant un des aspects de l'activité des développeurs.

Un des RFC les plus anciens encore en service, la normalisation de la célèbre MIB-II, la base des données qui peuvent être récoltées avec le protocole de gestion de réseaux SNMP.

La MIB-II est la plus connue et la base de toutes les autres MIB (elle succède à la MIB-I, décrite dans le RFC 1156). Elle décrit un modèle de données, pas un protocole. Ces données sont accessibles par les différentes versions du protocole SNMP, elle donne accès à sept groupes d'informations, comme System ou IP. Ce RFC est donc surtout composé d'une longue liste de variables (objets), selon les principes communs à toutes les MIB, décrits dans le RFC 1155.

Physiquement, une MIB est (section 4) une description en langage ASN.1 des données présentes, avec leur syntaxe, une indication de leur identificateur (l'OID), une description en langue naturelle, etc. Les commandes comme snmpget affichent par défaut les noms des variables mais on peut afficher les OID avec l'option -On. Les OID de MIB-II démarrent à 1.3.6.1.2.1. Par exemple, la définition de la variable ifNumber (nombre d'interfaces réseaux de la machine) est :

          ifNumber OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of network interfaces (regardless of
                      their current state) present on this system."
              ::= { interfaces 1 }

Son OID étant { interfaces 1 } et celui de interfaces, défini un peu plus haut, étant { mib-2 2 }, on voit que l'OID de ifNumber est 1.3.6.1.2.1.2.1.0 (le zéro final est une valeur nécessaire pour les scalaires, avec SNMP). snmpget peut donc la récupérer :

% snmpget [options] myrouter 1.3.6.1.2.1.2.1.0
IF-MIB::ifNumber.0 = INTEGER: 2

Si la variable est un tableau, c'est un peu plus compliqué, il faut ajouter à l'OID un index. Par exemple, les interfaces ont une variable ifOperStatus qui indique si elles fonctionnent ou pas (ifAdminStatus indique l'état désiré de l'interface, ifOperStatus son état réel ; la comparaison des deux est donc un bon moyen de savoir si toutes les interfaces fonctionnent comme prévu). Cete variable est définie dans notre RFC ainsi :

          ifOperStatus OBJECT-TYPE
              SYNTAX  INTEGER {
                          up(1),       -- ready to pass packets
                          down(2),
                          testing(3)   -- in some test mode
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The current operational state of the interface.
                      The testing(3) state indicates that no operational
                      packets can be passed."
              ::= { ifEntry 8 }

% snmpget [options] myrouter 1.3.6.1.2.1.2.2.1.8.1
IF-MIB::ifOperStatus.1 = INTEGER: up(1)                                      

Voici enfin, affichée par snmpwalk, une partie de la MIB-II d'un commutateur réseau de bas de gamme. D'abord, le groupe System (section 3.4), qui décrit l'engin lui-même, par exemple sa description :

SNMPv2-MIB::sysDescr.0 = STRING: 24-Port Managed 10/100 Switch w/WebView
SNMPv2-MIB::sysLocation.0 = STRING: UVA
...

puis le groupe Interfaces qui décrit les interfaces de l'engin :

IF-MIB::ifNumber.0 = INTEGER: 37
...
IF-MIB::ifDescr.1 = STRING: Ethernet Interface
...
IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
...
IF-MIB::ifMtu.1 = INTEGER: 1500
...
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
...
IF-MIB::ifInOctets.1 = Counter32: 188864

Ce dernier compteur, ifInOctets est un exemple des variables que récoltent les programmes de surveillance de réseau comme le célèbre MRTG ou comme le plus récent Munin.

Les groupes ultérieurs comme IP, ou TCP sont moins pertinents pour un commutateur, car ils ne comptent que les paquets qui lui sont directement adressés.

Le logiciel PGP est synonyme de cryptographie pour beaucoup de gens. Un des plus anciens et des plus utilisés pour les fonctions de confidentialité mais aussi d'authentification, PGP est très célèbre mais on sait peu que ses messages sont normalisés, dans ce RFC (depuis remplacé par le RFC 9580).

PGP a vu son format de données normalisé pour la première fois en août 1996, dans le RFC 1991. Cette norme a été révisée par la suite, dans le RFC 2440 et notre RFC est l'avant-dernière version, la dernière étant le RFC 9580.

Cette normalisation permet à diverses mises en œuvre de PGP d'interopérer. La plus connue aujourd'hui est la seule libre, GNU Privacy Guard (qui n'existait pas encore au moment de la publication du premier RFC). Il ne faut donc plus confondre le logiciel PGP, écrit à l'origine par Phil Zimmermann, et qui est non-libre, avec le format PGP que décrit notre RFC et que des logiciels autres que PGP peuvent lire ét écrire.

Le principe du chiffrement avec PGP est simple. Une clé de session (le terme est impropre puisqu'il n'y a pas de session au sens de TLS mais c'est celui utilisé par le RFC) est créée pour chaque destinataire, elle sert à chiffrer le message et cette clé est chiffrée avec la clé publique du destinataire (section 2.1 du RFC).

Pour l'authentification, c'est aussi simple conceptuellement. Le message est résumé et le résumé est chiffré avec la clé privée de l'émetteur (section 2.2 du RFC).

Le format PGP permet également la compression (qui améliore la sécurité en supprimant les redondances) et l'encodage en Base64 (RFC 4648), baptisé ASCII armor, pour passer à travers des logiciels qui n'aiment pas le binaire (la section 6 détaille cet encodage).

La section 3 explique les éléments de base utilisés par le format PGP. L'un des plus importants est le concept d'entier de grande précision (MPI pour Multi-Precision Integers), qui permet de représenter des entiers de très grande taille, indispensables à la cryptographie, sous forme d'un doublet longueur + valeur.

Enfin les sections 4 et 5 expliquent le format lui-même. Un message PGP est constitué de paquets (rien à voir avec les paquets réseau). Chaque paquet a un type, une longueur et un contenu. Par exemple, un paquet de type 1 est une clé de session chiffrée, un paquet de type 2 une signature, un paquet de type 9 du contenu chiffré, etc.

La section 7 du RFC décrit un type de message un peu particulier, qui n'obéit pas à la syntaxe ci-dessus, les messages en clair mais signés. Ces messages ont l'avantage de pouvoir être lus sans avoir de logiciel PGP. Ils nécessitent donc des règles spéciales.

On notera que gpg permet d'afficher les paquets présents dans un message PGP, ce qui est pratique pour l'apprentissage ou le débogage. Voyons un exemple avec un fichier test.txt de 35 octets, signé mais non chiffré :

% gpg --list-packets test.gpg 
:compressed packet: algo=1
:onepass_sig packet: keyid 4136479797D6D246
        version 3, sigclass 00, digest 2, pubkey 17, last=1
:literal data packet:
        mode b (62), created 1191502517, name="test.txt",
        raw data: 35 bytes
:signature packet: algo 17, keyid 4136479797D6D246
        version 3, created 1191502517, md5len 5, sigclass 00
        digest algo 2, begin of digest 0d e4
        data: [159 bits]
        data: [158 bits]

Malheuresement, gpg n'affiche pas les valeurs numériques des types, telles que listées par le RFC. Mais les noms qu'il utilise sont les mêmes que dans le RFC, on peut donc facilement trouver la section qui explique ce qu'est un "onepass_sig packet".

Avec un message chiffré, on obtient :

% gpg --list-packets test.txt.gpg
:pubkey enc packet: version 3, algo 16, keyid F3A0253D6C2A95F9
        data: [1022 bits]
        data: [1023 bits]
:pubkey enc packet: version 3, algo 16, keyid C0FE90B0F08F74D7
        data: [2044 bits]
        data: [2048 bits]

You need a passphrase to unlock the secret key for
user: "Stephane Bortzmeyer (Personl address) <stephane@bortzmeyer.org>"
2048-bit ELG-E key, ID F08F74D7, created 2000-03-31 (main key ID 97D6D246)

:encrypted data packet:
        length: 102
        mdc_method: 2
gpg: encrypted with 1024-bit ELG-E key, ID 6C2A95F9, created 2005-02-18
      "Kim Minh Kaplan <kaplan@kim-minh.com>"
gpg: encrypted with 2048-bit ELG-E key, ID F08F74D7, created 2000-03-31
      "Stephane Bortzmeyer (Personl address) <stephane@bortzmeyer.org>"
:compressed packet: algo=2
:literal data packet:
        mode b (62), created 1191502765, name="test.txt",
        raw data: 35 bytes

On notera que c'est après l'affichage des premiers paquets que gpg demande la phrase de passe pour lire la clé privée. En effet, les premiers paquets ne sont pas chiffrés, puisqu'ils indiquent la clé à utiliser pour déchiffrer le reste (PGP a une option pour masquer ces paquets, cf. section 5.1).

Malheureusement, notre RFC n'indique pas clairement les changements par rapport à la version précédente, le RFC 2440. Mais les changements ne sont pas radicaux, la version reste la même. Les principaux ajouts sont les suivants :

• Le précédent RFC contenait une note de l'IESG expliquant qu'il n'y avait pas de mécanisme d'extension, par exemple pour ajouter de nouveaux types ou sous-types de paquets. Ce n'est plus le cas et la section 10 détaille comment demander à l'IANA d'ajouter de nouveaux paramètres.
• Il y a moins de support des vieilles versions de PGP (l'obligation de les accepter est passée de MUST à SHOULD, cf. RFC 2119.)
• Il y a de nouveaux types de paquet comme le paquet User Attributes, plus riche que le paquet User ID, avec notamment la possibilité d'ajouter des images.
• Un nouveau format de compression est ajouté, bzip2.
• La section 14 (analyse de sécurité) est bien plus détaillée, avec description des attaques possibles.
• Parmi les nouvelles options, les signatures peuvent désormais être marquées comme confirmées par un tiers de confiance, via les Third-Party Confirmation signature.

Première incarnation du travail sur les réseaux à forte latence (RFC 4838), voici le protocole « Bundle », pour communiquer avec un vaisseau spatial en route pour Jupiter... (Une version plus élaborée l'a depuis remplacé, cf. RFC 9171.)

Conçu pour des réseaux difficiles, à très forte latence, avec des connectivités très intermittentes, Bundle ne doit pas grand'chose à TCP/IP et ressemble davantage à UUCP. Un bundle (avec un petit b) est un paquet de notre protocole (il a par exemple l'équivalent d'un en-tête, décrit dans la section 4.2). Il est transmis de machine en machine, chaque machine en acceptant la garde et le stockant pour un temps indéterminé, avant de le passer à la machine suivante. (Les bundles sont composés de plusieurs blocs et ce sont en fait les blocs qui sont transmis, mais c'est un détail.)

La transmission se fait avec des protocoles des couches inférieures comme le LTP présenté dans le RFC 5325.

Ce concept de garde (custody) est essentiel dans Bundle et évoque le courrier électronique où, avant l'explosion du spam, un serveur de messagerie avait pour principe de ne jamais jeter un message dont il avait accepté la garde : « distribuer ou signaler (la non-distribution) ».

Bundle fonctionne au niveau Applications. À l'intérieur de chaque réseau (le RFC dit « internet » avec un petit i, mais je trouve le risque de confusion avec l'Internet trop grand), Bundle utilise les protocoles de transport et de routage de ce réseau (la section 7 détaille les propriétés que doit avoir la mince couche logicielle qui connecte Bundle à ces protocoles).

Le format des bundles est décrit dans la section 4 (il sera ensuite normalisé de manière plus rigoureuse dans le RFC 6256). Il ressemble au BER d'ASN.1. Les valeurs ne sont pas étiquetées avec leur longueur, leur fin est détectée lorsque le bit de plus fort poids devient zéro.

La section 5 décrit le traitement des bundles, par exemple leur expiration lorsqu'ils n'ont pas pu être transmis dans le délai imparti.

La section 6 est consacrée aux messages « administratifs », l'équivalent d'ICMP dans le monde IP. Transmis par le même protocole Bundle, ils permettent de signaler qu'un bundle a été transmis, qu'il a été déposé à sa destination finale, etc.

Une première mise en œuvre du protocole Bundle a été developpée et se trouve en http://masaka.cs.ohiou.edu/ocp/bundling.html. Une autre est ION, accessible en http://www.dtnrg.org/wiki/Code.

Le protocole TLS, permettant de chiffrer et d'authentifier des communications sur Internet n'a toujours utilisé qu'un seul type de certificats, ceux à la norme X.509. Désormais, on peut aussi se servir de clés PGP. (Ce RFC a depuis été mis à jour dans le RFC 6091.)

Pour authentifier l'autre partie, lors d'une communication TLS (utilisée par exemple avec HTTP ou bien avec SMTP), on doit signer ses messages avec sa clé privée. Le correspondant doit connaitre la clé publique pour vérifier cette signature. Avec l'ancien protocole SSL et avec son successeur TLS (normalisé dans le RFC 5246), cela se faisait en présentant un certificat X.509. X.509 a plusieurs limites, notamment le fait qu'il dépende d'une autorité de certification. Tout le monde n'a pas envie de payer une telle autorité, pour un gain de sécurité contestable. Il était donc important d'avoir une alternative.

Même si celle-ci n'a pas été tout de suite standardisée par l'IETF (ce RFC n'a que le statut « expérimental », c'est son successeur, le RFC 6091 qui aura fait évoluer le statut), elle est déjà mise en œuvre dans GnuTLS (pour l'instant, le seul logiciel à le faire).

Techniquement, notre RFC dépend du mécanisme d'extension TLS spécifié dans le RFC 5246. Ces extensions permettent d'annoncer le type de certificat utilisé, et donc de choisir X.509 ou bien PGP (PGP est normalisé dans le RFC 4880). Le RFC précise que ces extensions ne doivent pas être utilisées si on ne gère que des certificats X.509, pour interopérer plus facilement avec les vieilles implémentations.

La clé PGP est envoyée encodée en binaire, ou bien peut être récupérée sur le réseau, si celui qui veut s'authentifier indique uniquement l'empreinte de la clé (de la même façon qu'un certificat X.509 peut être récupéré sur le réseau, si celui qui veut s'authentifier indique l'URL de son certificat).

Ce RFC semble être le premier à avoir parlé du NAT et à avoir tenté de le définir, de lister ses propriétés, et de proposer un vocabulaire standard.

Le déploiement du NAT, à partir de la fin des années 1990, était largement dû à l'épuisement des adresses IPv4 et à la difficulté d'en obtenir suffisamment. Mais ce déploiement s'est fait en dehors de l'IETF, sans standardisation, sans description rigoureuse des fonctions effectuées par le routeur NAT. Plusieurs protocoles IETF ne pouvant pas passer certains NAT (cf. RFC 3027), plusieurs RFC ont été écrits pour proposer des solutions, et, avant tout, pour bien définir le problème.

Il existe deux grandes terminologies (qui se recouvrent partiellement) : celle de STUN (RFC 3489) bâtie sur la notion de cône (le NAT fait correspondre un large pool d'adresses vers un pool plus petit, d'où l'image du cône), et une terminologie qui semble s'être imposée, celle de notre RFC, qui a été ultérieurement reprise et étendue par le groupe Behave, par exemple dans le RFC 4787.

C'est donc notre RFC qui définit, dans sa section 4, des termes comme :

• Basic NAT qui ne travaille que sur les adresses IP,
• NAPT, qui travaille aussi sur les numéros de port,
• etc.

Je recommande, si on veut une bonne introduction aux problèmes posés par le NAT, l'excellent article Peer-to-Peer Communication Across Network Address Translators.

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

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

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

DLV (DNSSEC Lookaside Validation) était une technique apparemment simple, qui résout élégamment un nœud gordien, mais qui a suscité de très chauds débats, pour des raisons politiques. DLV vise en effet à résoudre un problème de fond de DNSSEC, la signature de la racine. Elle est désormais abandonnée (cf. RFC 8749.)

En effet, avec DNSSEC tel qu'il est spécifié dans le RFC 4033, le résolveur qui tente de vérifier un domaine doit partir de la racine, si elle est signée, ou bien connaitre un ensemble de points de départ, les trust anchors, qui sont les clés publiques des registres qui signent certaines zones. En l'absence d'une racine signée, c'est cette seconde solution que j'ai utilisée pour mes tests du résolveur Unbound.

Signer la racine est trivial techniquement (l'IANA l'a déjà fait) mais très compliqué politiquement. Il faut trouver un signataire légitime (et des sommets internationaux entiers ont été consacrés au problème d'une autorité légitime pour la racine) et il faut que ce signataire soit prêt à s'engager sérieusement puisque qu'une fois que les résolveurs testent la signature, on ne peut plus revenir en arrière.

DLV résout donc le problème en permettant aux racines de signature (comme celle de l'ISC) d'être distinctes de la racine du DNS. Ainsi, pour vérifier la signature de parano.example, un résolveur DNSSEC avec support DLV, pourra allez chercher les signatures dans, par exemple, parano.example.dlv.isc.org. DLV utilise les enregistrements DNS de type DLV, décrits dans le RFC 4431.

La section 7 du RFC est consacrée à un problème difficile. Avec DLV, contrairement au DNSSEC classique, plusieurs « racines » peuvent signer un même domaine. On peut avoir par exemple une racine DLV qui signe .org et une autre qui signe example.org. Laquelle utiliser dans le cas de tels recouvrements ? La solution choisie est de ne pas choisir : le résolveur DLV peut utiliser l'algorithme qu'il veut, le plus simple étant décrit comme « choisir la racine la plus spécifique » (celle de example.org dans notre exemple). La section 7 décrit d'autres algorithmes et recommande que le résolveur propose un choix à l'utilisateur.

DLV fournit donc désormais une alternative à la longue attente d'une signature officielle de la racine. Cette alternative a semblé trop simple à certains et beaucoup d'objections ont été levées contre DLV, accusé notamment de retarder la « vraie », la « bonne » solution de signer la racine. Pour citer Paul Vixie, un grand défenseur de DLV, on peut dire que ces objections reviennent à empêcher des adultes consentants d'expérimenter une idée intéressante et qui ne fait de mal à personne. À noter que l'IAB a publié un communiqué qui, après pas mal de détours, accepte l'idée de DLV.

L'ISC a une note technique, 2006-01 sur le sujet de DLV. DLV est implémenté dans le résolveur de BIND depuis plusieurs versions. Il se configure ainsi (une documentation détaillée est en https://secure.isc.org/index.pl?/ops/dlv/) :

// À l'intérieur du bloc "options"
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside . trust-anchor dlv.isc.org.; 

À partir de là, on peut valider un domaine qui est enregistré dans le registre DLV de l'ISC, même si on n'a pas de trust anchor. Prenons par exemple sources.org :

% dig +dnssec MX sources.org.               

; <<>> DiG 9.5.0-P2 <<>> +dnssec MX sources.org.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15559
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
                   ^^
>>>>               Authentic Data, donc validées par DNSSEC

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;sources.org.                   IN      MX

;; ANSWER SECTION:
sources.org.            86400   IN      MX      10 uucp.bortzmeyer.org.
...

Autre solution pour tester si son résolveur utilise bien le registre DLV de l'ISC : https://www.dns-oarc.net/oarc/services/dlvtest. Par exemple :

% dig +dnssec a.nsec.dlvtest.dns-oarc.net txt


; <<>> DiG 9.5.1-P3 <<>> +dnssec a.nsec.dlvtest.dns-oarc.net txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56042
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...

Cet essai a bien fonctionné, on a bien le 'ad'.

Le service DLV de l'ISC a été arrêté depuis et cette technique transitoire n'est désormais plus d'actualité.

Le protocole DKIM de signature des courriers électroniques a une limite. Tant que tout le monde ne signe pas, on ne peut pas savoir si l'absence de signature est volontaire ou bien est la conséquence d'une fraude. Le protocole SSP (Signing Practices Protocol) doit permettre de résoudre ce problème.

DKIM, normalisé dans le RFC 6376, normalise un mécanisme pour insérer des signatures cryptographiques dans un courrier électronique, de façon à en prouver l'authenticité. Mais le déploiement de DKIM ne sera pas instantané et n'atteindra peut-être jamais 100 % des serveurs de messagerie. Si un message arrive sans signature, est-ce normal car ce domaine ne signe pas, ou bien est-ce une fraude ? Impossible de le savoir sans connaitre les pratiques de signature du domaine. Par exemple cisco.com signe tous ses messages. Mais on ne peut pas connaitre les pratiques de tous les domaines de l'Internet. Il faut donc un protocole pour récupérer cette information, SSP, dont ce RFC donne le cahier des charges.

Le principe de SSP est de fournir un moyen permettant à un MTA de décider, lorsque le message n'est pas signé, si cela est suspect ou non. Si SSP indique que example.net signe toujours et qu'un message prétendant venir de dupont@example.net n'est pas signé, le récepteur pourra donc légitimement le traiter avec une extrême suspicion.

La section 3 du RFC donne divers scénarios d'usage, et la section 4 se penche sur les problèmes de déploiement, un problème difficile pour toutes les nouvelles technologies. Ainsi, la section 4.2 rappelle que le gérant d'un domaine peut avoir envie de couvrir également les sous-domaines (autrement, le méchant qui veut faire croire que son domaine est example.net n'aurait qu'à envoyer depuis staff.example.net), la section 4.5 insiste sur les questions de performance, etc..

La section 5 attaque les exigences proprement dites. Je ne vais pas les énumérer ici, mais seulement donner quelques exemples :

• 5.1 (4) reprend le scénario d'une attaque sur un sous-domaine et demande que SSP permette de couvrir les sous-domaines (on note que cela permettrait au gérant de .com de définir une politique pour example.com...).
• 5.2 (3) exige que la charge entrainée par les requêtes SSP soit bornée (SPF, normalisé dans le RFC 4408, avait été critiqué car son langage, très puissant, permettait d'exprimer des politiques complètes qui auraient pu mener à une avalanche de requêtes DNS à chaque message reçu).
• 5.3 (5) veut que la syntaxe des messages soit compréhensible par un humain et dit, par exemple, que p=unknown est préférable à p=? (là encore, SPF est sans doute visé, ses enregistrements étant parfois cryptiques).
• 5.3 (9) exige que l'appel à SSP soit facultatif, si la signature DKIM est présente et correcte.

SSP a finalement été spécifié dans le RFC 5617, qui utilise le DNS pour récupérer des politiques ressemblant, pour un domaine qui signe tout et garantit que ces signatures ne sont pas invalidés en cours de route, à dkim=discardable.

Un court RFC qui s'inscrit dans le contexte de la lutte contre le spam et qui donne quelques règles sur les pratiques à suivre lors de la soumission originale du message.

Ce RFC est un exemple de la capacité de l'IETF à gérer les mauvaises idées. Il a commencé comme un Internet-Draft très virulent, reflétant largement les idées d'AOL sur la nécessité de réduire le marché des FAI à un cartel de gros opérateurs, réglant les questions de spam entre eux. Peu à peu vidé de sa substance au fur et à mesure des itérations, il ne reste qu'un court RFC qui se limite à des bonnes pratiques de soumission du courrier, laissant de côté le devenir ultérieur du message. Des idées très contestables, mais cohérentes avec la vision AOL d'un Internet séparant nettement les opérateurs et les simples consommateurs, ont été écartées, par exemple le blocage du port SMTP en sortie, qui n'est plus mentionné qu'en passant.

La seule vraie règle (déjà présente dans le RFC 4409) est la forte recommandation qu'un MSA authentifie les soumissions de courrier, par exemple via TLS ou bien via SASL (cf. RFC 4954).

Un article détaille comment configurer Postfix pour une telle authentification et donc respecter ces bonnes pratiques.

Voici un méta-RFC, ne spécifiant aucun protocole, mais donnant des consignes sur la rédaction des autres RFC. Il spécifie les termes à utiliser pour exprimer des règles normatives comme « Le client doit faire ceci... » ou bien « Le serveur doit répondre cela... » de façon à permettre à l'implémenteur d'un protocole de bien discerner ce qui est obligatoire de ce qui ne l'est pas.

Dans ce domaine comme dans beaucoup d'autres, l'IETF est parti d'une situation où tout était informel pour arriver à une situation d'extrême normativité. Les RFC sont écrits en langue naturelle (il n'y a jamais eu de tentative de trouver ou de développer un langage formel pour les spécifications) et cette langue naturelle est souvent bien floue. En l'absence de règles portant sur le langage, les premiers RFC utilisaient parfois des verbes comme must (doit) ou may (peut) de manière imprécise, menant les implémenteurs à des disputes sur le droit à ne pas implémenter tel ou tel aspect de la norme.

D'où ce RFC, qui donne un sens rigoureux à certains mots, et qui les écrit EN MAJUSCULES pour qu'on ne les confonde pas avec leur usage « flou ». Sont ainsi rigoureusement spécifiés :

• MUST : l'implémentation DOIT agir ainsi,
• SHOULD : l'implémentation DEVRAIT agir ainsi, sauf raison explicite et bien comprise (SHOULD peut se résumer par « Dans le doute, faites-le »),
• MAY : l'implémentation PEUT faire ainsi si ça lui chante.

De même, leurs négations comme MUST NOT ou des variantes comme RECOMMENDED sont également définies.

Et voici pourquoi les RFC sont désormais truffés de mots en majuscules. Par exemple, le RFC 2616 contient : The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs.

Voici aussi pourquoi les groupes de travail de l'IETF passent souvent beaucoup de temps à discuter pour savoir si telle fonction doit être précédée d'un MUST ou d'un SHOULD. En gros, le MUST permet une meilleure interopérabilité (puisque toute mise en œuvre d'un protocole sait exactement à quoi s'attendre) mais contraint davantage, et peut-être excessivement.

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

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

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

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

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

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

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

Depuis longtemps, le manque d'adresses IPv4 se fait sentir. Pour obtenir ces précieuses adresses, il faut remplir de longs documents à envoyer au RIR, ou bien payer son FAI pour une offre « pro » ou n'importe quel autre qualificatif indiquant que, entre autres, on aura d'avantage d'adresses, peut-être un /29 au lieu d'un simple /32 (pour les politiques d'allocation, voir le RFC 7020). D'où la demande pour un stock d'adresses IPv4 privées, non annoncées sur l'Internet et non uniques globalement, mais dans lequel on pourrait piocher à loisir. C'est ce que propose ce RFC, certainement un des plus cités, le "1918" étant devenu synonyme de ressource privée.

Ce RFC est court et pourrait se contenter de lister (section 3) les trois préfixes privés réservés :

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16, certainement le plus utilisé des trois.

Et les bases des RIR, accessibles via whois, reflètent bien cette réservation à l'IANA :

% whois  10.42.0.1                 

OrgName:    Internet Assigned Numbers Authority 
OrgID:      IANA
Address:    4676 Admiralty Way, Suite 330
City:       Marina del Rey
StateProv:  CA
PostalCode: 90292-6695
Country:    US

NetRange:   10.0.0.0 - 10.255.255.255 
CIDR:       10.0.0.0/8 
NetName:    RESERVED-10
NetHandle:  NET-10-0-0-0-1
Parent:     
NetType:    IANA Special Use
NameServer: BLACKHOLE-1.IANA.ORG
NameServer: BLACKHOLE-2.IANA.ORG
Comment:    This block is reserved for special purposes.
Comment:    Please see RFC 1918 for additional information.
Comment:    
RegDate:    
Updated:    2002-09-12
...

Mais l'idée même d'adresses IP privées ne s'est pas imposée sans mal. Un des principes d'architecture de l'Internet est en effet la connectivité de bout en bout. Toute machine peut parler directement à toute autre. C'est l'une des grandes innovations de l'Internet, tous les réseaux concurrents à l'époque (années 1970 et 80) n'envisageaient que des réseaux isolés. Or, s'il existe des adresses privées, elles ne sont pas globalement uniques. Deux machines sur des sites différents peuvent avoir la même adresses 192.168.1.1. Cela remet donc en cause le modèle de base et le prédécesseur de notre RFC, le RFC 1597 avait été fortement critiqué, notamment dans le RFC 1627, intitulé Network 10 Considered Harmful.

Notre RFC détaille donc aussi, dans ses sections 2 et 4, les motivations de ces adresses privées et explique pourquoi on ne peut pas s'en passer.

Si la poussière soulevée par le débat est bien retombée par la suite, c'est parce qu'on envisageait un déploiement rapide d'IPv6 qui règlerait le problème, grâce à son abondance d'adresses. Ce déploiement ne s'étant pas (encore ?) produit, notre RFC et ses adresses privées continuent à bénéficier d'un grand succès.

Ce succès s'étend même à des domaines non prévus, comme la documentation, qui devrait normalement utiliser 192.0.2.0/24 (cf. RFC 5737).

Pourquoi ces trois préfixes-là et pas d'autres ? Pour 10.0.0.0/8 la raison semble connue mais pas pour les autres.

Parfois, ces adresses privées « sortent » même, par accident, du réseau local où elles auraient dû rester confinées, malgré la section 5 du RFC qui explique qu'il ne faut pas le faire. On doit donc prendre soin de les filtrer. Les règles d'ACL d'un coupe-feu commencent souvent par quelque chose du genre (ici, des règles de Netfilter dans le noyau Linux) :

Chain norfc1918 (2 references)
target     prot opt source               destination
rfc1918    all  --  172.16.0.0/12        0.0.0.0/0
rfc1918    all  --  192.168.0.0/16       0.0.0.0/0
rfc1918    all  --  10.0.0.0/8           0.0.0.0/0
...
Chain rfc1918 (6 references)
target     prot opt source               destination
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 6 prefix `Shorewall:rfc1918:DROP:'
DROP       all  --  0.0.0.0/0            0.0.0.0/0

(Dans le cas ci-dessus, les règles sont ajoutées automatiquement par Shorewall.)

De même, un routeur BGP refuse en général de ses pairs des annonces pour ces préfixes (ici, la syntaxe d'IOS) :

! http://www.cymru.com/Bogons/index.html
! Deny any packets from the RFC 1918 netblocks to block
! attacks from commonly spoofed IP addresses.
access-list 2010 remark Anti-bogon ACL
! Bogons
access-list 2010 deny ip 10.0.0.0 0.255.255.255 any log-input
access-list 2010 deny ip 172.16.0.0 0.15.255.255 any log-input
access-list 2010 deny ip 192.168.0.0 0.0.255.255 any log-input

Et le nombre de serveurs DNS faisant des requêtes de type PTR pour ces adresses, et fatiguant ainsi pour rien les serveurs de in-addr.arpa, a nécessité le déploiement d'un système dédié pour les absorber, l'AS112.

Aujourd'hui, le petit réseau local typique a donc presque toujours des adresses tirées du RFC 1918, un routeur NAT et/ou des relais applicatifs et une seule adresse IP publique, attribuée par le FAI.

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

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

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

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

GTSM avait à l'origine été spécifié comme protocole « expérimental » dans le RFC 3682. Notre RFC marque l'entrée de ce protocole sur le chemin des normes officielles de l'IETF, met à jour son précédesseur, corrigeant un certain nombre de bogues et simplifiant le protocole (par exemple, il ne peut plus être utilisé entre des machines non-adjacentes, multi-hop scenario).

Un RFC de synthèse, qui rassemble tout ce que le fabricant d'un routeur IP doit savoir, parmi tous les RFC dispersés. L'idée était bonne mais, n'ayant jamais été mis à jour, ce RFC contient également pas mal de choses dépassées.

Créer un nouveau routeur IP est un gros travail, en partie parce qu'il faut lire des dizaines de RFC différents, sans avoir de vision d'ensemble et sans toujours pouvoir déterminer facilement ce qu'on doit faire et ce qui est facultatif. D'où l'idée de RFC de synthèse, comme celui-ci pour les routeurs (il succède au RFC 1716) ou comme le RFC 1123 pour les machines « terminales ». Mais, si le principe est bon, l'actualisation d'un tel document s'est révélée difficile. L'IETF travaillant sur la base du volontariat et la mise à jour de grosses synthèses étant moins intéressante que la création de nouveaux protocoles, le RFC a pris sérieusement la poussière. Officiellement, seul le RFC 2644 le modifie mais, en pratique, d'autres points de notre RFC semblent bien dépassés aujourd'hui. Par exemple, rares sont encore les équipements qui utilisent les paquets ICMP de répression de la source (Source Quench, section 4.3.3.3) car ces paquets facilitent trop les DoS (le RFC 6633 a officialisé l'abandon de ces paquets). Même chose pour le routage dirigé par la source (source routing).

Ce RFC fait 175 pages et est donc un gros morceau à lire (mais on ne crée pas un nouveau routeur tous les jours). C'est néanmoins une excellente source d'information pour quiconque s'intéresse au fonctionnement réel des réseaux informatiques.

Il commence par rappeler quelques principes généraux (sections 1 et 2), notamment le fait que ce RFC ne remplace pas les RFC standardisant tel ou tel protocole ou comme le principe de robustesse, Be conservative in what you do, be liberal in what you accept from others ou, dit autrement, « Ne faites pas le malin, essayez de coopérer avec les autres, pas de leur prouver qu'ils ont tort ». La section 2, sur l'architecture de l'Internet, est une bonne source sur ce sujet, recommandée à ceux qui apprennent comment fonctionne Internet. Puis chaque section est consacrée à une couche particulière, la section 3 à la couche 2, deux sections, 4 et 5, à la couche 3 (la section 5 s'occupant spécifiquement des cas où le paquet est transmis - forwarding), etc. La section 7, qui concerne la couche application s'occupe notamment des protocoles de routage.

Ainsi, pour citer quelques exemples des règles que pose ce RFC :

• La section 3 sur la couche de liaison précise que le routeur IPv4 qui met en œuvre ARP (RFC 826) ne devrait pas abandonner les paquets tout de suite s'il manque provisoirement une entrée dans la table ARP (ce conseil n'est plus du tout suivi aujourd'hui où, pour éviter l'encombrement des files d'attentes et les DoS, les routeurs du cœur de l'Internet jettent immédiatement les paquets qui ne peuvent pas être transmis pour cette raison).
• La section 4 n'impose pas de respecter les options IP comme Timestamp ou Record route qui n'ont jamais été réellement déployées (et ont disparu en IPv6).
• La section 4 rappelle que le routeur doit être capable de fragmenter les paquets trop gros (cela a disparu en IPv6 et, même en IPv4, c'est peu utilisé, au profit des techniques décrites dans les RFC 1191 et RFC 4821).
• La section 4 parle aussi d'ICMP et note que, pour éviter les avalanches, un paquet ICMP d'erreur ne doit jamais être envoyé en réponse à un autre paquet ICMP d'erreur.

Comme noté au début, le RFC n'a jamais été mis à jour donc il ne faut pas espérer y trouver d'informations sur les techniques apparues depuis, comme le NAT ou IPv6.

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

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

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

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

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

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

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

Voici le premier livre chez O'Reilly à propos d'Unicode. C'est un gros pavé de 700 pages et il ne couvre pourtant pas tout.

Le monde des écritures humaines est très riche et très compliqué et donc, logiquement, Unicode est compliqué. La norme est bien écrite, certes, mais rien ne peut rendre simple une réalité aussi complexe. N'attendons donc pas de ce livre des miracles, il explique déjà très bien beaucoup de choses.

L'orientation générale est plutôt vers l'auteur de documents. Le programmeur sera frustré, seul un chapitre lui est consacré, et une bonne partie est occupée par des langages de balisage comme HTML, qui ne sont pas de la programmation.

En revanche, Jukka Korpela explique avec beaucoup de détails (chapitres 4 à 6) la structure de la norme Unicode, les différents termes utilisés par celle-ci, les encodages et les innombrables informations qu'on peut trouver dans la base de données Unicode. Plus original, on trouve un excellent chapitre 2 consacré aux techniques permettant de saisir des caractères Unicode. Bien qu'il soit nettement trop orienté Windows à mon goût, ce chapitre réussit très bien à décrire les différentes méthodes.

Pour renforcer le côté « livre conçu pour les auteurs de textes, pas pour les programmeurs », je signale l'excellent chapitre 8, sur les usages des caractères, où on apprend plein de choses, même sur l'humble signe +. Beaucoup de caractères ont en effet plusieurs usages (la lettre grecque oméga - U+03A9 ou Ω - sert également à noter l'ohm, l'astérisque des énumérations en anglais sert également aux programmeurs à noter la multiplication, etc).

Le chapitre 11, consacré à la programmation est, on l'a dit, un peu limité, et il vaut sans doute mieux (re)lire Unicode demystified, de Richard Gillam.

Le chapitre 10 (sur les protocoles Internet) couvre également le problème intéressant d'écrire des textes en Unicode pour les publier sur Internet. L'auteur fait justement remarquer que, si on écrit en Unicode (par exemple en UTF-8), on sera tenté d'utiliser beaucoup plus de caractères, peut-être au détriment de la lisibilité du texte par les destinataires. Si on a donc relativement peu de caractères non-latins, il suggère de taper le texte en ASCII ou en ISO 8859 et d'utiliser les échappements comme ا (alif, ا). Curieusement, c'est justement ce que fait aujourd'hui l'auteur de ce blog, qui, en raison de problèmes avec UTF-8 rédige en Latin-1 et met les caractères non-latins avec des entités numériques XML.

Le style est très bon et les explications claires. La qualité générale de ce livre est celle des autres publications de cet éditeur et ce livre est donc à recommander aux non-programmeurs qui veulent comprendre les détails d'Unicode (ceux qui parlent français préféreront peut-être le livre d'Andries).

Plusieurs protocoles, notamment IMAP, ont besoin de trier des chaînes de caractères. Il existe plusieurs règles de tri, plus ou moins faciles à mettre en œuvre et plus ou moins « correctes » pour l'utilisateur et ce RFC spécifie une règle qui respecte mieux les chaînes Unicode, sans pour autant être parfaite du point de vue des règles des langues vivantes.

Pour éviter à chaque application de réinventer la roue, il existe un registre IANA des règles de tri, que les protocoles n'ont qu'à référencer. Ce registre, initialement créé par le RFC 4790, se remplit petit à petit. Les premières règles étaient triviales à implémenter (comme i;octet, qui travaille uniquement au niveau binaire, sans comprendre les caractères), mais très éloignées de ce qu'un utilisateur humain appelerait un tri. Notre RFC normalise une nouvelle règle, i;unicode-casemap qui fournit un tri indépendant de la casse pour les chaînes Unicode.

La règle est assez simple à exprimer (et le RFC est très court) :

• Convertir les caractères dans leur version capitalisée (attention, contrairement à ASCII, on ne peut pas le faire algorithmiquement, il faut une table),
• Décomposer chaque caractère (pratiquement la normalisation Unicode NFKD).

Notre RFC donne l'exemple du caractère « LATIN CAPITAL LETTER DZ WITH CARON » (U+01C4 en Unicode, soit DŽ. Il est capitalisé en « LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON (U+01C5, soit Dž). Il est ensuite décomposé en « LATIN CAPITAL LETTER D » (un grand D ordinaire) et « LATIN SMALL LETTER Z WITH CARON » (U+017E soit ž). Ce dernier est à son tour décomposé et le résultat final est Dž (trois caractères Unicode, le dernier étant le caron combinant, U+030C, dites-moi si vous voyez tout correctement sur votre navigateur). On peut alors trier.

Utilisant la base de données Unicode, on peut programmer cet algorithme (ici un programme écrit en Python) facilement. Voici les résultats, avec successivement le « e accent aigü », le « grand dz avec caron », et la ligature arabe « Djalladjalalouhou » :

 % ./decompose.py --rfc5051 -n U+00E9
U+000045 U+000301 
% ./decompose.py --rfc5051 -n U+1C4 
U+000044 U+00007A U+00030C 
% ./decompose.py --rfc5051 -n U+FDFB
U+00062C U+000644 U+000020 U+00062C U+000644 U+000627 U+000644 U+000647

Le programme n'est pas 100 % parfait (il ne gère pas le cas où la capitalisation d'une lettre est une chaîne et pas une lettre unique) mais presque.

Notons enfin une très intéressante section 3 sur la sécurité, qui explique comment deux implémentations correctes de cet algorithme peuvent quand même donner des résultats différents (un problème fréquent avec Unicode).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ce RFC met à jour un protocole qui a souvent été présenté comme un des gros avantages d'IPv6, la possibilité d'acquérir une adresse globale par autoconfiguration.

Le principe de SLAAC (StateLess Address AutoConfiguration) est simple : la machine IPv6 écoute sur le réseau et détecte les RA (Router Advertisement) envoyés par le routeur (notre RFC ne s'applique en effet qu'aux machines « terminales », pas aux routeurs). Ces RA l'informent de la valeur du préfixe réseau utilisé. La machine concatène ce préfixe à un identificateur d'interface, obtenant ainsi une adresse (section 5 du RFC, notamment 5.5).

L'identificateur d'interface est décrit dans le RFC 4291, qui indique comment les fabriquer à partir d'éléments comme les adresses MAC. (Notez que la méthode recommandée est désormais de ne plus utiliser l'adresse MAC, cf. RFC 8064.)

Voici, vu par tcpdump, un de ces RA :

17:49:23.935654 IP6 fe80::20c:6eff:fe6e:e5d4 > ff02::1: ICMP6, router advertisement, length 56

Si le préfixe annoncé est 2001:660:f108::/64 et que le RA est reçu par la machine dont l'identificateur d'interface est 20c:6eff:fe6e:e73a, l'adresse IPv6 fabriquée sera 2001:660:f108:0:20c:6eff:fe6e:e73a.

Si IPv4 a désormais une possibilité analogue grâce au RFC 3927, IPv6 garde un gros avantage, la notion de préfixe publié, qui fait que ces adresses autoconfigurées sont globales, elles peuvent être utilisées sur tout l'Internet.

Cette méthode d'autoconfiguration, dite sans état, est concurrente de DHCP (RFC 8415).

Notons qu'on n'est pas obligé d'attendre le Router Advertisement du routeur, on peut le solliciter avec un Router Solicitation.

La section 5.4 de notre RFC décrit la procédure DAD (Duplicate Address Detection), qui permet de s'assurer que l'adresse obtenue est bien unique en envoyant un Neighbor Solicitation (RFC 4861).

Toujours vue avec tcpdump, voici toute la procédure, envoi d'un RS, réception du RA et DAD :

18:13:32.046584 IP6 fe80::20c:6eff:fe6e:e73a > ff02::2: ICMP6, router solicitation, length 16
18:13:32.046861 IP6 fe80::20c:6eff:fe6e:e5d4 > ff02::1: ICMP6, router advertisement, length 56
18:13:32.578592 IP6 :: > ff02::1:ff6e:e73a: ICMP6, neighbor solicitation, who has 2001:660:f108:0:20c:6eff:fe6e:e73a, length 24

tcpdump n'affiche pas tous les détails, il ne montre pas le préfixe, ni la durée du bail (l'annonce RA est valable pour un certain bail, de durée limitée).

Parmi les limites du protocole, la section 6 du RFC note qu'il n'offre aucune sécurité. Une machine peut envoyer des faux RA, peut répondre aux DAD qui ne sont pas pour elle, etc.

Notre RFC remplace le RFC 2462. Il s'agit de changements mineurs, qui ne devraient pas toucher l'interopérabilité (mais qui peuvent affecter les implémentations, comme l'obligation d'un délai aléatoire avant de tester la duplication d'adresse).

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

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

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

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

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

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

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

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

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

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

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

La question de savoir qui doit diriger l'Internet n'a pas cessé de poser depuis que ce réseau de réseaux a cessé d'être un jouet ultra-subventionné, pour devenir un espace public, soumis à toutes les règles de la politique et du droit. Ce livre nous donne un point de vue très états-unien sur la question.

En effet, dans des discussions comme à l'ICANN ou bien à l'IGF, on parle le langage diplomatique. On ne dit pas franchement ce que l'on veut, encore moins ce que l'on fait. Dans ce livre, par contre, son éditeur, l'Institut Cato, un centre de réflexion sur la politique, très marqué à droite, l'Institut Cato, donc, ne prend pas de gants.

Ainsi, l'article de Christopher Cox, « Establishing global Internet freedom » est un point de vue impérialiste classique, appelant à établir les mêmes règles qu'aux États-Unis, partout dans le monde, par la force si nécessaire.

Tous les auteurs ne sont pas forcément sur la même longueur d'onde pour tout. Ainsi, le livre contient une discussion lancée par Jack Goldsmith, qui s'oppose fortement à ce qu'il nomme la « cyber-anarchie », c'est-à-dire l'idée comme qui l'Internet serait un espace radicalement nouveau, où les lois et autres règles humaines traditionnelles ne pourraient ou ne devraient pas s'appliquer. Goldsmith s'oppose vigoureusement à ce point de vue et estime au contraire qu'il n'y a pas de changement de fond dans la politique et le droit, malgré Internet.

Dans le même livre, David Post s'oppose à cette théorie. Post est un tenant de la thèse « exceptionnaliste » qui dit que l'Internet est un espace radicalement nouveau et qu'on ne peut pas espérer y faire appliquer la loi de la même façon.

Il est amusant de constater que certains problèmes juridiques posés par le caractère international d'Internet étaient déjà connue par les états-uniens longtemps avant que le réseau ne sorte de leur pays. En effet, dans ce pays fédéral, les états ont souvent des législations divergentes et cette divergence nourrit une vaste jurisprudence depuis longtemps. Les articles de Michael Geist et de Dan Burk expliquent en détail ce problème, pendant que celui de Bruce Kobayashi et Larry Ribstein défend fermement un point de vue ultra-libéral en affirmant que les lois de protection du consommateur (comme celles qui existent en Californie) ne doivent pas s'appliquer sur le réseau, de façon à laisser les entreprises s'installer dans les « paradis légaux » comme le Delaware et en tirer tous les bénéfices souhaités.

Voici une nouvelle version, légèrement remaniée, du protocole Label Distribution Protocol pour MPLS.

Le protocole MPLS, normalisé dans le RFC 3031 repose sur la notion de label, un court identificateur de taille fixe, qui sert d'index dans une table de commutation des paquets. Le RFC 3031 ne spécifie pas comment les labels sont distribués, parce qu'il existe plusieurs méthodes. Notre RFC en normalise une, le protocole LDP, Label Distribution Protocol. LDP n'est pas comparable aux protocoles de routage comme BGP. Il ne sert pas à distribuer de l'information brute permettant de calculer une route, il sert juste à indiquer quels labels doivent être utilisés pour chaque classe (FEC pour Forwarding Equivalence Class). Actuellement, le seul type de classe connu de LDP est celle basée sur le préfixe de l'adresse IP (son encodage est décrit dans la section 3.4.1).

Le protocole est donc relativement simple, deux routeurs MPLS (on dit LSR pour Label Switching Router) se découvrent par des paquets LDP de type Hello, envoyés sur UDP et s'échangent ensuite de l'information au dessus de TCP. Mais le RFC est très long car beaucoup de détails doivent être spécifiés.

Les données sont transportées de l'aval vers l'amont. C'est le routeur aval qui indique à son prédécesseur quel label utiliser pour chaque classe, chaque préfixe de réseau.

Les données transportées par LDP sont, pour la plupart, encodées en TLV ce qui rend le protocole très souple et capable d'évolution. Deux bits dans le paquet indiquent ce que doit faire le LSR qui ne comprend pas un type : doit-il l'ignorer ou bien refuser le message et, s'il l'ignore, doit-il le transmettre à d'autres LSR ? Ce mécanisme contribue également à la robustesse du protocole puisqu'il permet d'introduire de nouveaux types de données sans craindre que les vieux équipements ne réagissent bizarrement.

LDP avait originellement été spécifié dans le RFC 3036 et ce RFC n'apporte que de petits changements.

Ce RFC spécifie un format pour signer, sur le très long terme, des enregistrements. L'exigence de durée est un gros problème pour la cryptographie car les algorithmes de signature peuvent être cassés avec le temps.

Conçu dans le cadre du groupe de travail IETF ltans, ce RFC propose une méthode simple. Chaque signature est accompagnée d'une date et les dates sont elles-même signées (et resignées si un algorithme s'avère à l'usage trop simple, donc une application peut avoir à suivre une chaîne de signatures, ce que décrit la section 5). Le RFC 4810 qui donnait le cahier des charges du groupe de travail précisait déjà la nécessité de prouver l'intégrité d'un document après des dizaines d'années, malgré les progrès qu'avait fait la cryptographie pendant ce temps.

Notre RFC spécifie également d'autres techniques pour résister au passage du temps, comme le fait de mettre autant que possible au moins deux signatures, avec des algorithmes différents, pour augmenter les chances qu'un d'eux résiste (section 7).

Le format est spécifié en utilisant le langage ASN.1.

Ce RFC documente les problèmes de sécurité connus pour le protocole de transport SCTP. Ces problèmes, présents dans la première version de la norme, le RFC 2960, documentés une première fois dans le RFC 4460, sont traités dans la dernière version de la norme, le RFC 4960.

SCTP est très peu utilisé par rapport à son grand concurrent TCP. S'il règle certaines failles de sécurité de celles-ci (par exemple en intégrant un mécanisme d'authentification des adresses IP plus robuste pour l'établissement de la connexion), ses nouvelles possibilités pour le multihoming ouvrent des nouvelles failles.

Celles-ci, d'abord discutées dans le RFC 4460, sont désormais documentées dans le RFC 4960, qui change légèrement le protocole et donne plusieurs conseils aux implémenteurs. Bien que SCTP ne se place pas réellement dans la catégorie des protocoles à séparation de l'identificateur et du localisateur, ces faiblesses sont quand même proches de celles trouvées dans ces protocoles : l'ajout d'un niveau d'indirection supplémentaire permet de nouvelles usurpations. Avec SCTP, le fond du problème est qu'un attaquant peut dire la vérité sur l'adresse IP principale, celle qui sert à établir la connexion (SCTP dit l'association), mais mentir sur les adresses IP supplémentaires.

Par exemple, la première attaque documentée (section 2), le camping, consiste pour un attaquant à se connecter à un serveur en annonçant des adresses IP supplémentaires, qui ne sont pas à lui, et, en « campant » ainsi dessus, il peut empêcher leur légitime titulaire d'établir une association avec le même serveur.

La solution proposée par le RFC est de tester ces adresses (ce qui était déjà prévu par le mécanisme de battement de cœur dans le RFC 2960 mais sans l'utiliser pour la sécurité). On notera que ce test empêche d'utiliser ces adresses IP supplémentaires si elles ne sont pas joignables immédiatement par la machine associée. C'est conforme au cahier des charges de SCTP, qui vise le multihoming, pas la mobilité (un RFC séparé, le RFC 5061 fournit des pistes pour mieux gérer la mobilité).

Une autre attaque documentée (section 5) est le bombardement, qui permet des DoS. L'attaquant prétend contrôler une adresse IP (en fait, celle de sa victime), établit l'association en indiquant cette adresse IP comme supplémentaire et demande un gros transfert de données, qui frappera sa victime. Si celle-ci n'a pas SCTP, elle ne pourra pas signaler l'erreur. Là encore, la solution est de tester toute adresse IP avant de lui envoyer des données.

Le nouveau protocole APP permet la publication et la mise à jour de documents Atom. Il vise à faciliter la publication sur le Web, notamment pour les blogs.

APP est clairement issu du monde des blogs. Si on veut mettre à jour un blog automatiquement, il existe plusieurs protocoles avec XML-RPC mais rien de normalisé. Ce rôle est celui principalement visé par APP. Mais APP permettra aussi beaucoup d'autres choses sur le Web, concurrençant aussi des protocoles comme WebDAV (RFC 4918).

APP est un protocole de la famille REST, bâti au dessus de HTTP (RFC 7230).

APP repose sur les concepts de ressources et de collections (section 3). Une ressource est une information accessible par le Web. Dans APP, elle est fréquemment au format Atom (RFC 4287) et est alors nommée une entry resource. Les ressources non-Atom sont nommées des media resource. Elles sont en général « pointées » par une entry resource qui contient les métadonnées les concernant et un lien vers la media resource.

Les sections 7 et 8 du RFC spécifient également deux nouveaux formats XML, pour des documents décrivant les catégories (un mécanisme de classification des ressources) et les collections.

Ces ressources et ces collections sont identifiées par des URI (plus exactement par des IRI, RFC 3987). APP agit sur les collections et les ressources par l'intermédiaires de méthodes HTTP qui sont classiques pour les programmeurs REST (section 4.3 du RFC et des détails de protocole en section 5) :

• GET récupère une ressource ou une collection,
• PUT met à jour une ressource,
• POST modifie une collection, par exemple en créant une ressource,
• et DELETE, évidemment, détruit.

Le RFC précise bien que les serveurs APP jouissent d'une grande liberté d'action et que le client doit être prêt à tout, notamment si on utilise des méthodes HTTP dont l'action n'est pas définie par le RFC. Par exemple, DELETE sur une collection n'est pas spécifié mais peut être accepté par certains serveurs. Même chose pour le PUT sur une ressource pas encore existante, mentionné plus loin.

Voyons maintenant un exemple, tiré de la section 9 du RFC, montrant la création d'une ressource, obtenue par un POST sur l'URL d'une collection (ici, /edit/) :

[Envoyé par le client]
       POST /edit/ HTTP/1.1
       Host: example.org
       User-Agent: Thingio/1.0
       Authorization: Basic ZGFmZnk6c2VjZXJldA==
       Content-Type: application/atom+xml;type=entry
       Content-Length: 343
       Slug: First Post

       <?xml version="1.0"?>
       <entry xmlns="http://www.w3.org/2005/Atom">
         <title>Atom-Powered Robots Run Amok</title>
         <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
         <updated>2003-12-13T18:30:02Z</updated>
         <author><name>John Doe</name></author>
         <content>Some text.</content>
       </entry>

[Répondu par le serveur]
       HTTP/1.1 201 Created
       Date: Fri, 7 Oct 2005 17:17:11 GMT
       Content-Length: 430
       Content-Type: application/atom+xml;type=entry;charset="utf-8"
       Location: http://example.org/edit/first-post.atom
       ETag: "c180de84f991g8"

       <?xml version="1.0"?>
       <entry xmlns="http://www.w3.org/2005/Atom">
         <title>Atom-Powered Robots Run Amok</title>
         <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
         <updated>2007-08-01T16:46:18Z</updated>
         <author><name>John Doe</name></author>
         <content>Some text.</content>
         <link rel="edit"
             href="http://example.org/edit/first-post.atom"/>
       </entry>

Le serveur renvoie le document Atom car il est libre de modifier ce qu'a envoyé le client (ici, la date a changé dans l'élément <updated>, peut-être parce que le serveur a davantage confiance dans sa propre horloge). C'est un des points importants d'APP.

Parmi les questions brûlantes d'APP figurait celle du lost update, la mise à jour perdue lorsque deux clients font presque en même temps un GET d'une ressource suivi d'un PUT avec la ressource modifiée. (L'excellent document du W3C indiqué plus haut, Editing the Web: Detecting the lost update problem using unreserved checkout explique très bien l'ensemble du problème et les solutions possibles.)

HTTP n'ayant pas d'état, et APP n'ayant pas d'option de verrouillage (contrairement à une autre extension de HTTP, WebDAV), la solution recommandée par notre RFC est celle du « PUT conditionnel » (section 9.5 du RFC) en utilisant la date ou bien l'etag et les en-têtes HTTP If-Modified-Since: ou If-None-Match:.

Techniquement, c'est donc une solution assez simple mais la blogosphère a frémi sous les polémiques à ce sujet.

Parmi les verbes REST, on notera que PUT n'est utilisé que pour les mises à jour, pas les créations (le RFC 7231 autorise pourtant cet usage dans sa section 4.3.4). La question du « PUT pour créer » est toujours une question délicate dans le monde REST (voir http://bitworking.org/news/141/REST-Tips-Prefer-following-links-over-URI-construction ou bien http://www.megginson.com/blogs/quoderat/2005/04/03/post-in-rest-create-update-or-action/). Dans APP, comme l'espace de nommage est contrôlé par le serveur, il n'est pas prévu que le client puisse créer une ressource autrement qu'en passant par une collection (avec POST) et en laissant le serveur choisir un nom (le client peut toujours le guider avec le nouvel en-tête Slug:, décrit dans la section 9.7).

APP connait déjà des extensions, la plus connue étant Gdata.

Parmi les mises en œuvres existantes d'APP, on notera, pour les serveurs :

• mod_atom, un module Apache,
• amplee.

et pour les clients :

• GData Python Client Library est le client de référence de Google pour leur protocole Gdata, une extension d'APP,
• APP Test Client.

Pour en apprendre plus sur APP, on peut consulter l'excellent article Getting to know the Atom Publishing Protocol.

Le logiciel PGP est synonyme de cryptographie pour beaucoup de gens. Un des plus anciens et des plus utilisés pour les fonctions de confidentialité mais aussi d'authentification, PGP est très célèbre mais on sait peu que ses messages sont normalisés, dans ce RFC.

PGP a vu son format de données normalisé pour la première fois en août 1996, dans le RFC 1991. Cette norme a été révisée par la suite et notre RFC n'est pas le dernier (le RFC 4880 est la version actuelle).

Cette normalisation permet à diverses mises en œuvre de PGP d'interopérer. La plus connue aujourd'hui est la seule libre, GNU Privacy Guard (qui n'existait pas encore au moment de la publication du RFC). Il ne faut donc plus confondre le logiciel PGP, écrit à l'origine par Phil Zimmermann, et qui est non-libre, avec le format PGP que décrit notre RFC et que des logiciels autres que PGP peuvent lire ét écrire.

Le principe du chiffrement avec PGP est simple. Une clé de session (le terme est impropre puisqu'il n'y a pas de session au sens de TLS mais c'est celui utilisé par le RFC) est créée pour chaque destinataire, elle sert à chiffrer le message et cette clé est chiffrée avec la clé publique du destinataire (section 2.1 du RFC).

Pour l'authentification, c'est aussi simple conceptuellement. Le message est résumé et le résumé est chiffré avec la clé privée de l'émetteur (section 2.2 du RFC).

Le format PGP permet également la compression (qui améliore la sécurité en supprimant les redondances) et l'encodage en Base64, baptisé ASCII armor, pour passer à travers des logiciels qui n'aiment pas le binaire (la section 6 détaille cet encodage).

La section 3 explique les éléments de base utilisés par le format PGP. L'un des plus importants est le concept d'entier de grande précision (MPI pour Multi-Precision Integers), qui permet de représenter des entiers de très grande taille, indispensables à la cryptographie, sous forme d'un doublet longueur + valeur.

Enfin les sections 4 et 5 expliquent le format lui-même. Un message PGP est constitué de paquets (rien à voir avec les paquets réseau). Chaque paquet a un type, une longueur et un contenu. Par exemple, un paquet de type 1 est une clé de session chiffrée, un paquet de type 2 une signature, un paquet de type 9 du contenu chiffré, etc.

La section 7 du RFC décrit un type de message un peu particulier, qui n'obéit pas à la syntaxe ci-dessus, les messages en clair mais signés. Ces messages ont l'avantage de pouvoir être lus sans avoir de logiciel PGP. Ils nécessitent donc des règles spéciales.

On notera que gpg permet d'afficher les paquets présents dans un message PGP, ce qui est pratique pour l'apprentissage ou le débogage. Voyons un exemple avec un fichier test.txt de 35 octets, signé mais non chiffré :

% gpg --list-packets test.gpg 
:compressed packet: algo=1
:onepass_sig packet: keyid 4136479797D6D246
        version 3, sigclass 00, digest 2, pubkey 17, last=1
:literal data packet:
        mode b (62), created 1191502517, name="test.txt",
        raw data: 35 bytes
:signature packet: algo 17, keyid 4136479797D6D246
        version 3, created 1191502517, md5len 5, sigclass 00
        digest algo 2, begin of digest 0d e4
        data: [159 bits]
        data: [158 bits]

Malheuresement, gpg n'affiche pas les valeurs numériques des types, telles que listées par le RFC. Mais les noms qu'il utilise sont les mêmes que dans le RFC, on peut donc facilement trouver la section qui explique ce qu'est un "onepass_sig packet".

Avec un message chiffré, on obtient :

% gpg --list-packets test.txt.gpg
:pubkey enc packet: version 3, algo 16, keyid F3A0253D6C2A95F9
        data: [1022 bits]
        data: [1023 bits]
:pubkey enc packet: version 3, algo 16, keyid C0FE90B0F08F74D7
        data: [2044 bits]
        data: [2048 bits]

You need a passphrase to unlock the secret key for
user: "Stephane Bortzmeyer (Personl address) <stephane@bortzmeyer.org>"
2048-bit ELG-E key, ID F08F74D7, created 2000-03-31 (main key ID 97D6D246)

:encrypted data packet:
        length: 102
        mdc_method: 2
gpg: encrypted with 1024-bit ELG-E key, ID 6C2A95F9, created 2005-02-18
      "Kim Minh Kaplan <kaplan@kim-minh.com>"
gpg: encrypted with 2048-bit ELG-E key, ID F08F74D7, created 2000-03-31
      "Stephane Bortzmeyer (Personl address) <stephane@bortzmeyer.org>"
:compressed packet: algo=2
:literal data packet:
        mode b (62), created 1191502765, name="test.txt",
        raw data: 35 bytes

On notera que c'est après l'affichage des premiers paquets que gpg demande la phrase de passe pour lire la clé privée. En effet, les premiers paquets ne sont pas chiffrés, puisqu'ils indiquent la clé à utiliser pour déchiffrer le reste (PGP a une option pour masquer ces paquets, cf. section 5.1).

Un ancien RFC, qui représentait une des premières incursions de l'IETF dans le monde complexe des jeux de caractères.

Ce RFC tentait d'énumérer tous les jeux de caractères en usage à l'époque (la bibliographie cite le manuel de VMS, pour le jeu de caractères de ce système !). Les préoccupations d'internationalisation sont anciennes à l'IETF et ce RFC reflète une époque très reculée, où la version 1.0 d'Unicode venait tout juste d'être publié.

Ce RFC est donc essentiellement constitué d'un format pour décrire un jeu de caractères et d'une longue liste de jeux de caractères utilisés à l'époque, en utilisant les noms d'une version préliminaire d'ISO 10646. C'était donc un concurrent direct de la norme Unicode. Cette démarche n'a pas eu un succès fracassant et MIME, par exemple, se contentera d'attribuer un identificateur unique à chaque jeu, sans essayer de le décrire complètement (mais en citant notre RFC). Comparons par exemple l'entrée de notre RFC pour US-ASCII :

  &charset ANSI_X3.4-1968
  &rem source: ECMA registry
  &alias iso-ir-6
  &alias ANSI_X3.4-1986
  &alias ISO_646.irv:1991
  &g0esc x2842 &g1esc x2942 &g2esc x2a42 &g3esc x2b42
  &alias ASCII
  &alias ISO646-US
  &alias US-ASCII
  &alias us
  &alias IBM367
  &alias cp367
  &code 0
  NU SH SX EX ET EQ AK BL BS HT LF VT FF CR SO SI
  DL D1 D2 D3 D4 NK SY EB CN EM SB EC FS GS RS US
  SP ! " Nb DO % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
  At A B C D E F G H I J K L M N O P Q R S T U V W X Y Z <( // )> '> _
  '! a b c d e f g h i j k l m n o p q r s t u v w x y z (! !! !) '? DT

avec celle d'aujourd'hui, tirée du registre IANA, géré selon le RFC 2978 :

Name: ANSI_X3.4-1968                                   [RFC1345,KXS2]
MIBenum: 3
Source: ECMA registry
Alias: iso-ir-6
Alias: ANSI_X3.4-1986
Alias: ISO_646.irv:1991
Alias: ASCII
Alias: ISO646-US
Alias: US-ASCII (preferred MIME name)
Alias: us
Alias: IBM367
Alias: cp367
Alias: csASCII

On notera que, pour faire rentrer les jeux de caractères dans un RFC écrit en ASCII, ce RFC développe un codage se voulant « intuitif » (la section 2.3 dit The two characters are chosen so the graphical appearance in the reference set resembles as much as possible (within the possibilities available) the graphical appearance of the character.). C'est ainsi que le é, le « e accent aigü » s'écrit e' et le è, l'« e accent grave » e!. Voici la seconde moitié de la table ISO 8859-1, ainsi exprimée :

  A! A' A> A? A: AA AE C, E! E' E> E: I! I' I> I:
  D- N? O! O' O> O? O: *X O/ U! U' U> U: Y' TH ss
  a! a' a> a? a: aa ae c, e! e' e> e: i! i' i> i:
  d- n? o! o' o> o? o: -: o/ u! u' u> u: y' th y:

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

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

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

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

En octobre 2006, l'IAB a tenu un séminaire à Amsterdam, consacré aux questions fondamentales de routage et d'adressage sur Internet. Ce RFC est le compte-rendu de ce séminaire.

Cela fait très longtemps que l'avenir du routage et de l'adressage, les deux bases de la sécurité et de la stabilité de l'Internet, suscitent des inquiétudes. Par exemple, la rapide consommation d'adresses IPv4 a mené au début des années 90 à la création d'IPv6. Mais le problème n'a pas cessé, l'inquiétude principale portant désormais sur le routage. Les routeurs de la DFZ (Default-Free Zone, l'ensemble des routeurs qui n'ont pas de route par défaut et doivent donc avoir une entrée dans leur table de routage pour chaque réseau indépendant) consomment de plus en plus de mémoire et d'autres ressources, pour stocker les (aujourd'hui) 230 000 routes de l'Internet. Est-ce que la croissance actuelle pourra se poursuivre ?

Le séminaire a donc étudié le problème actuel et les capacités des routeurs à supporter encore quelques années (cinq ? dix ?) de croissance (la passionnante section 4 décrit en détail les problèmes de matériel des routeurs, prenant en compte jusqu'à la question du refroidissement). Il s'est aussi penché sur les phénomènes à l'origine de cette croissance. Bien sûr, il y a le nombre de personnes connectées à l'Internet. Mais il y a aussi des causes nouvelles, comme la montée de la mobilité, ou comme les demandes des utilisateurs pour le multihoming, c'est-à-dire être connecté par plusieurs FAI.

Le problème est très difficile à résoudre car, à son cœur, se trouve une contradiction entre les demandes des opérateurs, qui préféreraient des adresses fortement agrégées en gros préfixes (de façon à limiter le nombre de ces derniers) et les utilisateurs qui préféreraient pouvoir router à volonté « leurs » adresses. Une des pistes pour trancher ce nœud gordien est la séparation de l'identificateur et du localisateur, actuellement fusionnés dans l'adresse IP. Ce point est détaillé dans les sections 2.2, 6 et 7.2 de notre RFC.

Le RFC se termine par un ensemble d'exigences que devra satisfaire la solution proposée et par des recommandations que le problème, bien que non immédiat, soit traité sérieusement. Conscient de la contradiction entre les intérêts des différentes parties prenantes, l'IAB recommande également que les futurs séminaires ou forums ne comprennent pas que des fabricants de routeurs et des opérateurs...

La publication du RFC, bien tardive, a été retardée par des désaccords sur certains des conclusions. Alors que le RFC aurait dû être un compte-rendu factuel de ce qui s'était dit à Amsterdam, il a failli être compris comme un plan d'action stratégique, devant donc faire l'objet d'un relatif consensus. La discussion lancée par ce séminaire se poursuit aujourd'hui sur la liste RAM.

Voici une nouvelle version du protocole ND (Neighbor Discovery) qui permet à une machine IPv6 de trouver l'adresse MAC d'une autre machine qui se trouve sur le même réseau local.

Lorsqu'une machine veut écrire à une autre machine située sur le même lien et qu'elle ne connait que son adresse IP, son adresse de couche 3, comment fait-elle pour avoir l'adresse MAC, l'adresse de couche 2 qu'il faut mettre, par exemple, dans l'en-tête de la trame Ethernet ?

IPv4 utilisait ARP, spécifié dans le RFC 826. Ce protocole avait plusieurs limites, notamment le fait qu'il n'utilisait pas IP, requérant des machines qu'elles mettent donc en œuvre un autre protocole. IPv6 a donc un mécanisme assez différent, ND, qui fonctionne au dessus d'ICMP v6 et donc d'IP.

ND permet aux machines de trouver les routeurs, aux routeurs de s'annoncer, et aux machines de trouver leurs voisines. Voici quelques paquets vus avec tcpdump -n ip6. D'abord, un routeur se signale en écrivant à l'adresse multicast ff02::1:, « toutes les machines » :

15:20:02.032894 fe80::201:96ff:fe96:dc60 > ff02::1: icmp6: router advertisement           [class 0xe0]

(Cette fonction de ND n'était pas en IPv4 gérée par ARP mais par Router Discovery, RFC 1256.) Maintenant, on a le même routeur qui cherche à joindre 2001:660:3003:3::1:3 et qui diffuse donc une demande de voisin (neighbor solicitation) :

15:19:37.981830 fe80::201:96ff:fe96:dc60 > ff02::1:ff01:3: icmp6: neighbor solicitation:  who has 2001:660:3003:3::1:3 [class 0xe0]

Ici, la machine n'avait jamais répondu. Ici, un cas où la machine sollicitée, 2001:660:3003:3::1:1, répond :

15:30:44.416346 fe80::211:43ff:fee7:bcde > 2001:660:3003:3::1: icmp6: neighbor sol: who has 2001:660:3003:3::1
15:30:44.417438 2001:660:3003:3::1 > fe80::211:43ff:fee7:bcde: icmp6: neighbor adv: tgt is 2001:660:3003:3::1 [class 0xe0]

On note que le solliciteur écrit toujours depuis son adresse « lien local » (link-local).

Naturellement, les résultats d'une découverte du voisin sont gardés dans un cache, qu'on peut afficher. Sur Linux :

% ip neigh show                         
fe80::210:dbff:feb8:e5ed dev eth0 lladdr 00:10:db:b8:e5:ed router REACHABLE
2001:660:3003:3::1 dev eth0 lladdr 00:10:db:b8:e5:ed router REACHABLE
fe80::219:b9ff:fee4:2987 dev eth0 lladdr 00:19:b9:e4:29:87 router REACHABLE

Sur FreeBSD :

% ndp -na
Neighbor                             Linklayer Address  Netif Expire    S Flags
2001:470:1f15:121:223:12ff:fe56:b34d 0:23:12:56:b3:4d    sis1 20h24m25s S
...

La section 6.2.1 du RFC précise qu'un routeur doit fournir un moyen de configurer les paramètres qui sont utilisés dans la découverte de voisin qu'il effectue et dans les annonces du RFC 4862. Avec le logiciel radvd, cela se fait dans /etc/radvd.conf qui peut ressembler à (radvd utilise pour ses options exactement les noms suggérés par le RFC) :

...
   prefix 2001:DB8:49::/64
   { 
     AdvOnLink on; 
     AdvPreferredLifetime 1800;

Et on voit alors avec un tcpdump -vvv le paramètre « durée de vie » (ltime pour life time) :

18:25:59.264392 fe80::204:75ff:fece:efbe > ff02::1: icmp6: router advertisement(chlim=64, pref=medium, router_ltime=1800, reachable_time=0, retrans_time=0)[ndp opt] (len 64, hlim 255)

Peu de changements par rapport au RFC 2461 et ils portent essentiellement sur la sécurité. L'ancien RFC ne la mentionnait guère, sauf pour expliquer que le protocole était peu sûr (les risques sont détaillés dans les RFC 3756 et RFC 6104). Désormais, la section Sécurité est plus détaillée et cite des solutions possibles comme le protocole SEND, spécifié dans le RFC 3971. Depuis, une autre est apparue, les gardes, dans le RFC 6105.

Notre RFC spécifie comment faire fonctionner IPv6 au dessus de PPP.

Rien de très nouveau dans ce RFC, successeur du RFC 2472. Les changements sont peu nombreux. En quelques pages, il explique comment faire passer le protocole IPv6 au dessus de PPP. Je l'utilise par exemple chez moi pour une liaison PPPoE. Ajouter l'option ipv6 , dans le fichier de configuration suffit (il faut évidemment aussi que le pair en face accepte ce protocole).

Notre RFC définit un nouvau LCP (Link Control Protocol), IPV6CP et on peut voir ici dans le journal de pppd la négociation de ce protocole :

Jun  5 08:13:23 ludwigVI pppd[3046]: sent [IPV6CP ConfReq id=0x1 <addr fe80::35cd:efc1:e399:3aa9>]
Jun  5 08:13:23 ludwigVI pppd[3046]: rcvd [IPV6CP ConfReq id=0x1 <addr fe80::020f:90ff:fe92:bd00>]
Jun  5 08:13:23 ludwigVI pppd[3046]: sent [IPV6CP ConfAck id=0x1 <addr fe80::020f:90ff:fe92:bd00>]
Jun  5 08:13:23 ludwigVI pppd[3046]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::35cd:efc1:e399:3aa9>]

Et on peut ainsi vérifier le bon fonctionnement du lien :

% ping6 -I ppp0 fe80::0205:00ff:fe77:0000
PING fe80::0205:00ff:fe77:0000(fe80::205:ff:fe77:0) from fe80::a103:545b:b99a:3493 ppp0: 56 data bytes
64 bytes from fe80::205:ff:fe77:0: icmp_seq=1 ttl=64 time=46.4 ms
64 bytes from fe80::205:ff:fe77:0: icmp_seq=2 ttl=64 time=43.3 ms

On notera que, contrairement à IPv4 sur PPP (RFC 1661), on ne peut pas choisir les adresses IP du lien, elles sont forcément de type « locales au lien » :

Aug 25 23:35:17 ludwigV pppd[32050]: local  LL address fe80::79f7:f73b:d7b0:5de3
Aug 25 23:35:17 ludwigV pppd[32050]: remote LL address fe80::0205:00ff:fe77:0000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comment configurer les serveurs de noms sur toutes les machines du réseau qu'on administre ? DHCP fournit une solution, ce RFC en normalise une autre, fondée sur les RA (Router Advertisements).

Si on gère un gros réseau, avec de nombreuses machines dont certaines, portables, vont et viennent, s'assurer que toutes ces machines ont les adresses IP des serveurs de noms à utiliser n'est pas trivial. On ne peut évidemment pas utiliser le DNS, cela serait tenter de voler en tirant sur les lacets de ses chaussures. Et configurer à la main les adresses sur chaque machine (par exemple, sur Unix, en les écrivant dans le fichier /etc/hosts) est bien trop difficile à maintenir.

La solution la plus populaire actuellement est DHCP (RFC 2136 et RFC 3315). Son principal inconvénient est qu'elle est à état : le serveur DHCP doit se souvenir des baux qu'il a attribué. Sur un gros réseau local, le nombre de requêtes à traiter, chacune nécessitant une écriture dans une base de données, peut devenir très lourd.

Une autre solution est sans état et repose sur une nouveauté d'IPv6, les RA (Router Advertisements), décrits dans le RFC 4862. Ce sont des messages envoyés à intervalles réguliers par les routeurs et qui informent les machines non-routeuses des caractéristiques essentielles du réseau, comme le préfixe utilisé (par exemple 2001:DB8:BEEF:42::/64). Le routeur diffuse ses messages et n'a pas besoin d'écrire quoi que ce soit sur son disque, ni de faire des traitements compliqués lors d'une sollicitation, il répond toujours par le même message RA.

Ces RA peuvent diffuser diverses informations, par le biais d'un système d'options. Le principe de notre RFC est donc d'utiliser ces RA pour transporter l'information sur les serveurs de noms récursifs utilisables sur le réseau local, via la nouvelle option nommée RDNSS (le numéro 25 a été affecté par l'IANA).

Initialement prévu pour le chemin des normes, ce RFC a finalement été publié comme « expérimental », suite à des désaccords sur la « bonne » méthode de configuration des serveurs de noms. Notre RFC commence donc, en section 1.1, par un avertissement que le protocole « officiel » reste DHCP. Le RFC 4339 contient une discussion plus détaillée de ce problème du choix d'une méthode de configuration des serveurs de noms (notons qu'il existe d'autres méthodes comme l'anycast avec une adresse « bien connue »). Le successeur de notre RFC, le RFC 6106 a été, lui, publié sur le chemin des normes et la publication de réglages DNS par le Router Advertisement est donc désormais standard.

Sur Linux, le démon rdnssd permet de recevoir ces RA et de modifier la configuration DNS. Pour FreeBSD, on peut consulter une discussion sur leur liste. Les CPE de Free, les Freebox, émettent de telles options dans leurs RA. Voici ce qu'affiche Wireshark :

...
Ethernet II, Src: FreeboxS_c3:83:23 (00:07:cb:c3:83:23), 
             Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01)
...
Internet Control Message Protocol v6
    Type: 134 (Router advertisement)
...
    ICMPv6 Option (Recursive DNS Server)
        Type: Recursive DNS Server (25)
        Length: 40
        Reserved
        Lifetime: 600
        Recursive DNS Servers: 2a01:e00::2 (2a01:e00::2)
        Recursive DNS Servers: 2a01:e00::1 (2a01:e00::1)

et les serveurs DNS annoncés répondent correctement. (Vous pouvez récupérer le paquet entier sur pcapr.net.)

Une des particularités du protocole IP est que vous avez plusieurs protocoles de transport disponibles. TCP et UDP sont les plus connus mais SCTP, normalisé dans notre RFC, est également intéressant. (Il a depuis été remplacé par le RFC 9260.)

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

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

Cette dernière possibilité le rapproche des protocoles qui séparent l'identificateur et le localisateur et lui permet de gérer proprement le multihoming.

Cela se fait en indiquant, au début du contact, toutes les adresses IP (et même les noms de domaines, cf. la section 3.3.2.1) de la machine.

SCTP tient également compte de l'expérience acquise avec TCP. par exemple, l'établissement d'une connexion (que SCTP nomme association) se fait avec un échange de quatre paquets (et non pas trois comme avec TCP), pour offrir une meilleure protection contre les dénis de service. Les SYN cookies, un ajout plus ou moins bancal en TCP, sont ici partie intégrante du protocole.

SCTP est surtout issu des demandes du monde de la téléphonie sur IP, qui avait besoin d'un tel protocole pour la signalisation mais il peut être aussi utilisé dans d'autres domaines.

Le premier RFC à avoir normalisé SCTP était le RFC 2960. Les changements qu'introduit ce nouveau RFC ne modifient pas en profondeur le protocole mais corrigent les nombreux problèmes survenus pendant ses premières années d'utilisation. Le RFC 4460 donne la liste complète des problèmes corrigés. Depuis, le RFC 9260 a également légèrement révisé la norme.

Un bon tutoriel existe, SCTP for beginners et un excellent article du Linux Journal.

SCTP est depuis longtemps mis en œuvre dans Linux et, depuis peu également dans FreeBSD. De même, des programmes de débogage comme Wireshark sont capables de décoder et d'afficher le SCTP. Le support de SCTP est parfois limité, voici un exemple de ce que racontait tcpdump, lors d'une ouverture de connexion, sur une machine Ubuntu de 2007 :

09:06:07.896605 IP 192.0.2.33.32769 > 192.0.2.34.7: sctp[|sctp]

et ce qu'il indique, pour la même activité en TCP. C'est bien plus détaillé :

09:06:58.441737 IP 192.0.2.33.49874 > 192.0.2.34.7: S 2577209510:2577209510(0) win 32792 >mss 16396,sackOK,timestamp 243393 0,nop,wscale 7<

Ceci dit, avec une Ubuntu plus récente, en 2010, on a enfin l'association SCTP complète :

 
14:25:18.931093 IP 192.168.2.1.6666 > 192.168.2.25.8888: sctp (1) [INIT] [init tag: 4133424833] [rwnd: 55808] [OS: 10] [MIS: 65535] [init TSN: 1604754740] 
14:25:18.931236 IP 192.168.2.25.8888 > 192.168.2.1.6666: sctp[|sctp]
14:25:18.937771 IP 192.168.2.1.6666 > 192.168.2.25.8888: sctp[|sctp]
14:25:18.937882 IP 192.168.2.25.8888 > 192.168.2.1.6666: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 1604754740] [a_rwnd 56314] [#gap acks 0] [#dup tsns 0] 

Des exemples de programmes de tests SCTP se trouvent dans mon article sur le RFC 3286.

On pourra consulter une étude comparée des différents protocoles de transport concurrents de TCP dans l'article A Survey of Transport Protocols other than Standard TCP.

Il n'est pas sûr que les coupe-feux laissent passer SCTP de si tôt... L'Internet s'ossifiant de plus en plus, il devient très difficile de déployer un nouveau protocole de transport.

Un bon résumé de l'histoire et des avantages de SCTP se trouve dans Why is SCTP needed given TCP and UDP are widely available?.

Les techniques pair-à-pair ont une place de plus en plus importantes sur Internet aujourd'hui mais aucune ne semble formellement normalisée. Ce RFC est donc le premier RFC à parler du pair-à-pair, via une étude de la littérature existante.

S'il n'existe pas de RFC, ni d'ailleurs d'autres texte normatifs, sur aucun des fameux protocoles de pair-à-pair, il y a en revanche une abondante littérature scientifique sur ce sujet. Tellement abondante qu'il est parfois difficile de s'y retrouver. Notre RFC entreprend donc un tour général de cette littérature, et s'appuie sur une bibliographie d'une taille très inhabituelle pour un RFC, avec plus de 380 références.

Le résultat est utile, mais pas forcément très digeste. Et il souligne l'absence de l'IETF dans le champ des techniques pair-à-pair, bien qu'elles représentent aujourd'hui probablement la majorité du trafic de l'Internet.

Notre RFC décrit donc les différents types d'index, du centralisé de Napster au distribué de Freenet, puis les index « sans sémantique », c'est-à-dire où l'identificateur d'une ressource est complètement opaque (et qui se prêtent donc bien à une mise en œuvre via des DHT comme Pastry ou Chord) et enfin les index « à sémantique », plus faciles pour la recherche floue, lorsqu'on ne sait pas bien ce qu'on veut, mais moins efficaces.

Peut-être les changements sont-ils encore trop rapides, dans cette technique assez jeune ? Ou peut-être la diabolisation du pair-à-pair pratiquée par certains gros intérêts financiers effraie t-elle les SDO ? En tout cas, le pair-à-pair reste pour l'instant complètement hors du champ de la normalisation.

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

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

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

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

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

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

Un court RFC pour ajouter un nouveau transport au protocole IRIS. Désormais, IRIS peut utiliser UDP, un peu comme le DNS.

IRIS, spécifié dans le RFC 3981, est un protocole d'interrogation de registres Internet. Il fonctionne typiquement au dessus de TCP mais il existe une demande pour un transport plus léger, purement requête/réponse, avec un seul paquet pour chacune. Ce transport, LWZ (Lightweight using Compression aujourd'hui mais il avait une autre signification, sans que le sigle ait changé), est normalisé dans ce RFC.

LWZ est simple : la question est un élément XML IRIS classique, précédé de quelques octets (section 3 du RFC) indiquant notamment l'identificateur de la transaction (afin de permettre de mettre en correspondance les questions et les réponses) et la longueur maximale de réponse acceptable. Même chose pour le paquet de réponse.

Il n'existe à ma connaissance que deux implémentations, dans les logiciels Irisserv et FlowerBed de Verisign. Ces deux logiciels sont peu maintenus, mais ont un support de LWZ (surtout sur Flowerbed).

À ma connaissance, il n'existe pas de serveurs IRIS publics, que ce soit avec LWZ ou pas.

La sécurité de LWZ est très faible et, notamment, il présente les mêmes failles que le DNS : identificateur de transaction trop petit, donc vulnérable aux tentatives d'usurpation, taille du paquet réponse très supérieure à la taille du paquet question, donc risque que les serveurs IRIS servent à des attaques avec amplification, etc. La section 8, sur la sécurité, semble bien faible par rapport à ces risques.

Le courrier électronique, tel que spécifié à l'origine, reposait entièrement sur la confiance aveugle des acteurs entre eux. N'importe quel serveur de messagerie pouvait demander n'importe quoi à n'importe quel autre et les expéditeurs de courrier pouvaient indiquer ce qu'ils voulaient dans le courrier. Aujourd'hui, les demandes de sécurité sont plus fortes, d'où ce RFC.

Il y a deux questions importantes, la sécurité du message (s'assurer qu'un message est authentique, quelles que soient les étapes traversées) et la sécurité du canal (s'assurer que le serveur à l'autre bout est le bon). Si cette dernière ne permet pas, à elle seule, d'authentifier un message (il faut pour cela utiliser des techniques comme PGP, spécifié dans le RFC 4880), elle est toutefois intéressante lorsqu'un serveur de messagerie veut n'autoriser certaines fonctions qu'à certains partenaires, dûment authentifiés.

Un exemple typique est le fait de relayer du courrier. On parle de « relais » lorsqu'un MTA transmet à un autre MTA un courrier dont le serveur destinataire n'est pas le destinataire final. Il devra donc relayer ce courrier. Autrefois, tous les serveurs relayaient. La montée du spam a mis fin à ces relais ouverts et, aujourd'hui, un serveur bien géré ne relaie que pour des clients autorisés et authentifiés.

Cette extension d'authentification utilise le cadre SASL, spécifié dans le RFC 4422. À l'intérieur de ce cadre sont spécifiées plusieurs méthodes d'authentification comme un mot de passe transmis en clair (RFC 4616).

Le serveur capable d'authentifier annonce cette possibilité en réponse à la requête EHLO :

% telnet mail.bortzmeyer.org smtp 
...
220 mail.bortzmeyer.org ESMTP Postfix (Debian/GNU)
EHLO mail.example.org
250-mail.bortzmeyer.org
...
250-AUTH DIGEST-MD5 CRAM-MD5

Ici, le serveur SMTP annonce, entre autres choses, sa capacité à gérer l'authentification.

Cette extension est mise en œuvre, par exemple, dans le serveur de messagerie Postfix.

Bien sûr, transmettre un mot de passe en clair sur Internet est le plus sûr moyen de se faire sniffer. Alors, notre RFC impose, pour tout mécanisme d'authentification à mot de passe en clair, d'utiliser TLS, spécifié dans le RFC 3207 et également disponible dans Postfix.

Ce RFC met à jour le RFC 2554, qui avait introduit cette extension. Il n'apporte pas de changements fondamentaux. Notons par exemple l'arrivée de SASLprep (RFC 4013, pour gérer des noms d'utilisateurs en Unicode).

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

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

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

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

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

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

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

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

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

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

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

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

La sécurité sur Internet est un problème très fréquemment mentionné. Rien d'étonnant donc à ce que l'IAB, organisme chargé entre autres de superviser les développements de l'architecture de l'Internet, aie décidé de réunir un certain nombre d'experts pour un séminaire sur « le trafic Internet non désiré ». Ce RFC est le compte-rendu de ce séminaire.

Le séminaire s'est tenu à Marina del Rey en mars 2006 et on peut déplorer l'extrême lenteur que met toujours l'IAB à publier les compte-rendus de ses intéressants séminaires.

De quoi a t-on parlé pendant ce séminaire ? D'abord, la définition de « trafic non désiré » s'est concentrée sur deux phénomènes spécifiques, le spam et les DoS. Ensuite l'IAB note qu'un des messages les plus importants à faire passer est que le trafic non désiré n'est pas seulement produit par quelques adolescents perturbés mais est majoritairement l'œuvre d'entreprises criminelles bien organisées au sein de ce que l'IAB appelle (section 2 et notamment 2.1 du RFC) l'économie souterraine. (Je prends mes distances face à ce terme car je ne suis pas sûr qu'elle soit si souterraine que cela, ni si distincte de l'économie légale. L'utilisation de paradis fiscaux ou de la fraude fiscale n'est pas spécifique à la Mafia. Mais revenons à la sécurité de l'Internet.)

Bref, au revoir l'image du boutonneux qui s'attaque aux serveurs du Pentagone pour impressionner ses copains. Place aux professionnels, qui agissent pour l'argent.

Cette économie souterraine fait que des ressources humaines, financières et techniques importantes sont dédiées aux utilisations illégales de l'Internet. Dans un réseau ouvert, ces utilisations peuvent faire beaucoup de dégâts, d'autant plus que beaucoup d'utilisateurs ne sont pas conscients de l'ampleur des dangers que courent leurs machines. Outre son caractère ouverte et l'absence de traçabilité construite dans le réseau lui-même, l'Internet doit une partie de sa vulnérabilité à son caractère international. On ne peut pas compter sur la police russe pour traquer ceux qui ont attaqué les réseaux informatiques en Estonie puisque ces attaquants agissaient sous la bienveillance de leur propre gouvernement.

Quelles sont les machines participant aux attaques ? Aujourd'hui, ce ne sont que rarement celles appartenant à l'attaquant (section 2.3). Celui-ci se sert plutôt de zombies, des machines piratées et asservies. Le RFC note que la grande majorité des machines connectées à Internet est vulnérable. En partie à cause des faiblesses de Microsoft Windows (que l'IAB minimise par souci du « politiquement correct ») mais aussi parce que ces machines ne sont pas gérées par des professionnels responsables. Même prévenu, il est rare que l'utilisateur d'une machine zombie la nettoie. Les problèmes sont pour les autres, pas pour lui et l'absence de responsabilité crée un terrain favorable pour les recruteurs de zombies.

Notons que le séminaire n'avait pas pour but de trouver une solution magique mais d'étudier le problème. Le compte-rendu est donc souvent balancé, car il n'y a pas de solution parfaite, uniquement des compromis. C'est ainsi que la section 2.4 rappelle que, si on change le réseau pour augmenter la traçabilité, ces nouvelles possibilités de surveillance vont certainement attirer des gens peu recommandables, qui seraient ravis d'utiliser ces nouvelles possibilités pour surveiller les citoyens.

La section 3 est ensuite consacrée à une étude de l'ampleur du problème, pour les différents acteurs, et aux stratégies qu'ils utilisent pour se défendre. C'est là par exemple que l'IAB rappelle que le RFC 2827 (alias BCP 38), qui permettrait de sérieusement limiter l'usurpation d'adresse IP, n'est pratiquement pas déployé aujourd'hui, par suite du manque d'intérêt financier à le faire (la section 4.2.1 détaille également ce problème, où le marché est incapable de déployer une solution qui bénéficierait à tous mais coûterait un peu à chacun).

La section 3.4 concerne les fournisseurs de services DNS. Sa principale recommandation est le déploiement rapide de l'anycast sur les serveurs importants. Notre RFC étant consacré aux trafic non désiré et notamment aux DoS, il n'est pas étonnant que les conseils qu'il donne n'aille pas dans le même sens que ceux des RFC qui se penchent surtout sur l'intégrité des données. Ainsi, DNSSEC est présenté comme un risque plutôt que comme une solution (la section 4.3.2 exprime également une certaine méfiance par rapport à la cryptographie).

La section 4 commence à s'attaquer aux solutions. On notera que plusieurs participants au séminaire ont estimé qu'on avait déjà toutes les solutions techniques nécessaires, le défi était de les déployer. Si le déploiement doit se faire sur les réseaux des grands opérateurs commerciaux, il est freiné par l'absence de retour sur investissement. Si le déploiement doit se faire sur les machines des utilisateurs, il est freiné par la difficulté d'éducation.

Compte-tenu de l'ampleur du problème, ne faut-il pas adopter des mesures drastiques, qui changeraient radicalement le modèle de l'Internet ? C'est par exemple ce que propose le projet « table rase » de l'université de Stanford, qui se propose de refaire complètement l'Internet, autour d'un modèle bien plus fermé où tout devrait être autorisé préalablement. Les sections 4.3.4 et surtout 5.1 sont consacrées à l'examen de telles solutions, qui évoquent le médecin assassinant le malade pour le guérir...

Les présentations faites lors du séminaire sont en partie en ligne, à l'exception de celles qui sont trop sensibles. Un compte-rendu du séminaire, plus court et plus vivant que le RFC, a été fait dans le numéro 70 de l'IETF Journal.

L'Internet ne continue à fonctionner que parce que chaque machine qui y est connectée « fait attention », entre autre parce que les logiciels qui y sont installés essaient d'éviter de congestionner le réseau. Sur quels principes repose ce contrôle de la congestion ?

D'abord, ce contrôle de congestion n'est pas fait par IP (et donc pas par les routeurs) mais dans les protocoles au dessus, TCP étant le plus utilisé. Le contrôle de congestion est donc de bout en bout entre deux machines qui communiquent et n'est pas du ressort du réseau lui-même. Cela le rend très souple et très adapté à l'innovation mais cela met une lourde responsabilité sur chaque machine de l'Internet. Comme discuté dans la section 3.2 du RFC, une machine incivile qui voudrait s'allouer le maximum de bande passante peut le faire. Et, pour l'instant, il n'existe pas de protocoles IETF pour détecter ce comportement (certains travaux de recherche ont eu lieu sur ce sujet).

Le plus gros risque si le contrôle de congestion défaillait, risque décrit dans la section 3.1, ainsi que dans la section 5, est celui d'effondrement : dans un effondrement dû à la congestion, le débit diminue si on augmente le nombre de paquets. Le réseau passe alors tout son temps à tenter de transmettre des paquets qui seront finalement perdus, retransmis, le tout sans bénéfice pour personne. L'Internet est passé plusieurs fois près de l'effondrement (cf. RFC 896, qui était également le premier à pointer le danger des machines inciviles ou boguées, qui ne réagissent pas en cas de congestion) et seule l'amélioration continue des protocoles de transport a permis de continuer la croissance du trafic.

En effet, à partir de 1986, TCP a commencé, notamment sous l'impulsion de Van Jacobson, à prêter sérieusement attention à la congestion (voir le RFC 2001 pour une description a posteriori de cet effort), notamment via le mécanisme de retraite, où l'émetteur cherche s'il y a congestion et ralentit son débit si c'est le cas.

Aujourd'hui, tout flot de données (un flot n'a pas de définition unique et rigoureuse, disons que c'est un ensemble de paquets appartenant au même échange de données, et gérés ensemble, pour ce qui concerne la congestion) doit mettre en œuvre des techniques de détection et de réponse à la congestion. Pour une application utilisant TCP, c'est fait automatiquement dans ce protocole mais une application utilisant UDP doit s'en charger elle-même. (D'autres RFC sont sortis depuis comme le RFC 5681 pour TCP.)

Outre l'effondrement, l'absence de contrôle de congestion présente un autre risque, qui fait l'objet de la section 3.2, le risque d'injustice. Si plusieurs flots se battent pour une bande passante limitée, le risque est que le mauvais citoyen, qui ne diminue pas son débit en cas de congestion, emporte une plus grosse part du gâteau que les autres. Une implémentation de TCP qui se comporterait ainsi pourrait même permettre à son vendeur de prétendre qu'il a un « TCP accéléré ». C'est une méthode analogue, mais au niveau applicatif, qu'avait utilisé le navigateur Web Netscape 1, en ouvrant plusieurs connexions TCP simultanées vers le même serveur HTTP.

La section 6 de notre RFC est ensuite dédiée aux démarches à adopter : avoir un contrôle de congestion est la principale. La section 9, en annexe, décrit plus spécifiquement les responsabilités de TCP. De nombreux RFC (par exemple le RFC 4907), référencent ce document, auquel tous les nouveaux protocoles doivent se conformer. Mais, en 2011, la question du contrôle de la congestion restait toujours largement ouverte, comme le montre le RFC 6077.

Dans la désormais longue série des RFC autour du format Atom, celui-ci spécifie un moyen de récupérer une partie d'un flux de syndication et comment itérer pour avoir le reste du flux.

Atom, normalisé dans le RFC 4287, permet de décrire un flux de syndication, comprenant un certain nombre d'entrées, par exemple des articles d'un blog. Avant ce nouveau RFC, Atom ne permettait pas de récupérer le flux en plusieurs étapes. La plupart des sites Web ne publiaient que les N derniers articles et sans fournir de moyen d'obtenir les autres. Notre RFC change cela : il permet de récupérer des flux par étapes successives (pages feeds) et aussi de récupérer un flux en plusieurs étapes en ayant la garantie que cette récupération inclus toutes les entrées (archived feeds).

Un paged feed est simplement un flux qui contient des liens vers le groupe suivant d'entrées. Par exemple :

   <feed xmlns="http://www.w3.org/2005/Atom">
    <title>Mon flux à moi</title>
    <link href="http://example.org/"/>
    <link rel="self" href="http://example.org/index.atom"/>
    <link rel="next" href="http://example.org/index.atom?page=2"/>
 ...

où ce document, index.atom, contient un lien de type next qui mène au document suivant du flux, index.atom?page=2.

Ce type next, ainsi que d'autres types décrits dans ce RFC comme prev sont enregistrés dans le registre IANA des relations.

Un paged feed n'offre pas de garantie de cohérence. Entre la requête à index.atom et une requête ultérieure à index.atom?page=2, des entrées ont pu être ajoutées et des entrées figurant dans le premier document ont pu « migrer » vers le second. Itérer sur les next peut donc ne donner qu'une partie de la collection d'entrées.

Pour avoir un flux cohérent, il faut utiliser les archived feeds avec les relations next-archive et prev-archive :

   <feed xmlns="http://www.w3.org/2005/Atom"
    xmlns:fh="http://purl.org/syndication/history/1.0">
    <!-- L'espace de noms http://purl.org/syndication/history/1.0 est
    défini dans ce RFC -->
    <title>Mon flux à moi</title>
    <link rel="current" href="http://example.org/index.atom"/>
    <link rel="self" href="http://example.org/2003/11/index.atom"/>
    <fh:archive/>
    <link rel="prev-archive"
     href="http://example.org/2003/10/index.atom"/>
...

Itérer sur prev-archive et next-archive, si ces relations sont présentes, est sûr et garantit de ne perdre aucune entrée.

Notre RFC définit également un troisième type de flux, les complete feeds où la présence de l'élément <fh:complete/> garantit que le flux contient toutes les entrées de la collection.

Désolé, mais ce blog ne met pas encore en œuvre ce RFC et ne fournir donc qu'un flux limité, réduit aux N derniers articles.

Unicode est une norme de classification des caractères utilisés pour écrire des textes. L'imagination des humains dans ce domaine étant sans limites, Unicode est une norme de taille importante, et compliquée. Le cœur de la norme Unicode étant une liste de tous les caractères, pour toutes les écritures du monde, mettre cette liste dans une base de données relationnelle simplifie son accès, grâce au langage SQL.

Mise à jour, voici la liste des éléments qui forment le fameux Dublin Core, un ensemble d'éléments pour créer des métadonnées, notamment sur les ressources Web.

Dublin Core, qui doit son nom à la ville de Dublin, où s'est tenue la réunion fondatrice, est un jeu de quinze éléments, qui permettent d'attribuer des métadonnées à une ressource, typiquement un fichier accessible via le Web.

Ces quinze éléments comprennent, entre autres :

• title, le titre de la ressource,
• identifier, un identificateur unique pour la ressource,
• date, la date de publication de la ressource,
• language, la langue de la ressource,
• etc.

On notera que Dublin Core ne spécifie pas de sémantique rigoureuse pour ces éléments. C'est volontaire, afin de donner le maximum de liberté à ceux qui définissent ces métadonnées. Le RFC se contente de donner des conseils, comme d'utiliser un « système d'identificateurs formels » pour l'élément identifier.

De même, la syntaxe n'est pas spécifiée, uniquement conseillée. Ainsi, le RFC suggère d'utiliser les étiquettes de langue du RFC 4646 pour language ou bien ISO 8601 pour les dates.

De même, la façon dont se représentent les éléments Dublin Core dans la ressource n'est pas précisée dans ce RFC. Elle dépend en effet du format de cette dernière. On peut trouver une liste de techniques en http://dublincore.org/resources/expressions/ et un exemple pour HTML en http://dublincore.org/documents/2008/08/04/dc-html/.

Dublin Core avait été à l'origine normalisé dans le RFC 2413, auquel notre RFC succède. Il n'y a pas de changement radical entre les deux RFC. Il existe aussi une norme ISO sur Dublin Core, la 15836 mais, comme elle n'est pas publique, le RFC est une meilleure source.

Très peu de pages Web publient du Dublin Core aujourd'hui. Sur ce blog, par exemple, vous n'en trouverez pas dans les pages HTML mais il y en a dans le flux de syndication Atom. En voici un extrait :

<feed xml:lang="fr" xmlns="http://www.w3.org/2005/Atom" 
                    xmlns:html="http://www.w3.org/1999/xhtml"
                    xmlns:dublincore="http://purl.org/dc/elements/1.1/">
<!-- See for discussions about the relationship between Atom and Dublin Core 
     and why Atom does not use Dublin Core:
  http://internetalchemy.org/2004/03/theNucleusOfAtom 
  http://www.imc.org/atom-syntax/mail-archive/msg03170.html
  http://www.imc.org/atom-syntax/mail-archive/msg04474.html
  http://bitworking.org/news/Not_Invented_Here
-->
...
<dublincore:title>Blog de Stéphane Bortzmeyer</dublincore:title>
<dublincore:language>fr</dublincore:language> 
<dublincore:identifier>tag:bortzmeyer.org,2006-02:Blog/</dublincore:identifier>
<dublincore:date>2007-07-05T16:35:00Z</dublincore:date>
...

Autre exemple, le logiciel libre de dessin Inkscape permet d'associer des métadonnées Dublin Core à un document. Comme son format natif de stockage est SVG, Inkscape, logiquement, les exprime en XML dans l'espace de nommage Dublin Core (notons aussi l'utilisation des schémas de Creative Commons) :

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://web.resource.org/cc/"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
...
  <metadata>
    <rdf:RDF>
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title>Forces Architecture</dc:title>
        <dc:date>2007-09-21</dc:date>
        <dc:creator>
          <cc:Agent>
            <dc:title>Stéphane Bortzmeyer</dc:title>
          </cc:Agent>
        </dc:creator>
        <dc:rights>
          <cc:Agent>
            <dc:title>GFDL</dc:title>
          </cc:Agent>
        </dc:rights>
        <dc:language>fr</dc:language>
        <cc:license
           rdf:resource="gfdl" />
      </cc:Work>
    </rdf:RDF>
  </metadata>

Voici quelques autres exemples d'utilisation aujourd'hui :

• L'Open Archive Initiative, protocole d'échanges de métadonnées entre des réservoirs d'articles scientifique en libre accès utilise entre autres le Dublin Core.
• TEF (Thèses Electroniques Françaises) pour la description des thèses.
• L'excellent projet revues.org d'édition électronique en sciences sociales.
• L'École des chartes.

C'est mince par rapport aux ambitions anciennes des systèmes de métadonnées.

De même, je ne connais pas de logiciel public (par exemple de moteur de recherche) qui puisse utiliser le Dublin Core. Les seuls cas existants sont dans des mondes plus fermés comme celui d'In-extenso, un moteur de recherche spécialisé en sciences humaines et sociales.

En dépit de gros efforts de sensibilisation, les métadonnées restent les grandes absentes du Web. Pour quelles raisons ? Outre les raisons spécifiques à Dublin Core, comme le fait que beaucoup d'éléments Dublin Core font double emploi avec des éléments existants (<title> ou l'attribut lang en HTML, les mêmes plus <published> ou <author> en Atom), je vois deux raisons communes à toutes les métadonnées.

L'une est que les moteurs de recherche ont appris à se méfier des informations mises par l'auteur de la page Web. Soit il est peu soigneux, soit il triche en mettant des mots-clés susceptibles de lui attirer du trafic.

L'autre est un problème d'œuf et de poule classique. Les moteurs de recherche n'utilisent pas les métadonnées, donc les auteurs n'en mettent pas, donc les moteurs ne les utilisent pas...

Merci à Gautier Poupeau pour ses nombreuses informations.

Curieusement, malgré le nombre d'attaques ayant visé le protocole TCP, aucun RFC n'avait documenté lesdites attaques et les solutions couramment utilisées comme les SYN cookies.

TCP (RFC 793) est de très loin le plus utilisé des protocoles de transport sur Internet. Même les applications qui font passer l'essentiel de leur trafic en UDP comme la téléphonie, dépendent de TCP pour l'établissement et la coupure de la liaison. Une attaque sur TCP a donc typiquement des effets dévastateurs et la première à avoir été largement médiatisée, l'attaque par SYN flooding contre Panix en 1996, a provoqué une prise de conscience. De nombreuses défenses contre les différentes attaques ont été développées dans les années qui ont suivi et ce RFC est le premier à les documenter.

La section 2 de notre RFC décrit en détail le SYN flooding qui consiste à envoyer des paquets de demande d'ouverture de connexion (des paquets SYN) sans jamais répondre aux accusés de réception (packets ACK). Les mises en œuvre typiques de TCP ont un tableau de taille fixe pour leurs connexions TCP et le seul paquet SYN suffit à réserver une case de ce tableau, jusqu'à l'expiration d'un délai qui est typiquement de plusieurs minutes.

Sans avoir besoin de révéler son adresse IP, avec un trafic relativement faible, un attaquant peut donc empêcher la machine cible d'accepter des nouvelles connexions TCP, empêchant ainsi tout service.

Un outil comme hping permet d'automatiser cette attaque, sans que l'attaquant aie même à savoir programmer (non, je ne donnerai pas les détails gratuitement).

La section 3 du RFC s'attaque ensuite aux mesures de défense comme les SYN cookies, qui consiste à ne pas allouer du tout d'état à la réception du paquet SYN, mais à encoder les informations contenues dans ce paquet dans le numéro de séquence TCP initial. La réception du paquet ACK, le deuxième paquet envoyé par le client, permettra de vérifier qu'un SYN avait bien été envoyé et que l'ACK du serveur avait bien été reçu. Cette idée, mise au point par Dan Bernstein, est conforme au principe « ne pas allouer d'état sans authentification » posé dans la section 4.1.1 du RFC 4732.

Les SYN cookies posent quelques problèmes à TCP (décrits dans la section 3.6 du RFC ou, par exemple, dans le manuel sur FreeBSD). C'est pour cela qu'ils ne sont typiquement pas activés par défaut. Par exemple, sur une Debian, il faut les configurer à yes dans le fichier /etc/network/options (qui indique au script de démarrage qu'il doit mettre à jour la variable Linux /proc/sys/net/ipv4/tcp_syncookies).

Aussi, d'autres solutions existent comme le SYN cache, qui alloue un état, mais de petite taille ou comme l'abandon, lorsque la table des connexions en cours est pleine, des connexions non actives les plus anciennes.

Cette nouvelle option du DNS permet d'identifier le serveur de noms physique auquel on parle, dans le cas où plusieurs machines servent sous la même adresse IP. Elle a vocation à remplacer l'ancien hostname.bind.

En application du cahier des charges du RFC 4892, ce très court RFC normalise une nouvelle utilisation d'EDNS pour transporter une chaîne de bits qui identifie une instance particulière d'un serveur de noms.

Aujourd'hui, en effet, comme l'explique le RFC 4892, il est fréquent qu'un même serveur de noms (par exemple F.root-servers.net, serveur de la racine) soit mis en œuvre par plusieurs machines physiques (des dizaines dans le cas de F.root-servers.net). En cas de défaillance d'une seule de ces machines, il est préférable de pouvoir détecter quelle machine était en cause (voir par exemple la panne de C-root). Cela se faisait autrefois avec le nom spécial hostname.bind (un id.server a été proposé pour être moins lié à BIND). Cette méthode ayant plusieurs inconvénients (là encore, voir le RFC 4892), une nouvelle méthode était nécessaire.

NSID est simplement une option EDNS. Lorsqu'elle est présente dans la requête, le serveur mettra son identité dans la réponse.

En quoi consistera cette identité ? Ce fut le grand et vif débat au sein du groupe de travail dnsext de l'IETF. Certains operateurs de serveurs de noms ne souhaitaient pas en révéler trop, certains souhaitaient mettre de l'Unicode dans la réponse, etc. Le compromis a finalement été de décider que la chaîne de bits mise dans la réponse n'a aucune signification standard. Elle dépend entièrement de l'opérateur. Il pourra mettre un nom de machine (comme on le fait souvent aujourd'hui avec hostname.bind), un identificateur opaque, ou même une valeur différente à chaque fois (la section 3.1 détaille ces possibilités).

Voici une configuration de cette option sur un BIND 9.7 :

options {
    ...
    server-id "My super X-server";
};

et son résultat, lorsque le serveur est interrogé par dig :

% dig +nsid @ns1.example.org SOA example.org
...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; NSID: 4d 79 20 73 75 70 65 72 20 58 2d 73 65 72 76 65 72  \
           (M) (y) ( ) (s) (u) (p) (e) (r) ( ) (X) (-) (s) (e) (r) (v) (e) (r)
;; QUESTION SECTION:
...

Comme le contenu du NSID peut être absolument quelconque, dig affiche les valeurs des différents octets (et, pour être sympa, le caractère correspondant à ce code ASCII). Si on met une valeur en UTF-8 :

   server-id "Café-crème";

dig, n'affichera que les caractères ASCII :

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 43 61 66 c3 a9 2d 63 72 c3 a8 6d 65  \
          (C) (a) (f) (.) (.) (-) (c) (r) (.) (.) (m) (e)

Avec nsd (depuis la version 3.2.5), la configuration est en hexadécimal (NSD 4 permet de mettre des chaînes ASCII). J'utilise ce petit programme en Python pour faire la traduction. Mais on peut aussi, toujours en Python, faire simplement python -c 'import sys;print sys.stdin.read().encode("hex")' (merci à @alexpigne) ou bien en classique shell Unix, utiliser hexdump avec hexdump -v -e '/1 "%02X"' (merci à @guguscat). Si vous le faites en une ligne de shell, n'oubliez pas le -n en argument à echo. En tout cas, voici un exemple :

% echo -n "ns1.example.net" | hexdump -v -e '/1 "%02X"'      
6E73312E6578616D706C652E6E6574

# nsd.conf
nsid: 6E73312E6578616D706C652E6E6574

Si vous cherchez un exemple réel, les serveurs de l'AFNIC ont NSID :

% dig +nsid @c.nic.fr. SOA fr
...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 64 6e 73 2e 74 68 32 2e 6e 69 63 2e 66 72  (d) (n) (s) (.) (t) (h) (2) (.) (n) (i) (c) (.) (f) (r)

Ici, c'était une machine installée au Telehouse 2 (th2) à Paris. Mais c'est évidemment plus drôle avec une « machine » anycast, essayez depuis plusieurs endroits du réseau avec d.nic.fr. Une telle étude a été faite et publiée. Autre exemple d'utilisation importante de NSID, sur le serveur L-root, décrit dans le RFC 7108.

Si vous voulez avoir une idée de ce qu'implique une mise en œuvre de ce RFC, vous pouvez regarder le « commit » 4cd33c... de GRONG. Voici son utilisation :

% grong-server -servername="ns1.local.bortzmeyer.org"
...
% dig +nsid @::1 nimportequoi
...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 6e 73 31 2e 6c 6f 63 61 6c 2e 62 6f 72 74 7a 6d 65 79 65 72 2e 6f 72 67  \
      (n) (s) (1) (.) (l) (o) (c) (a) (l) (.) (b) (o) (r) (t) (z) (m) (e) (y) (e) (r) (.) (o) (r) (g)
...

Le logiciel check-soa a une option -nsid qui peut servir simplement à voir les NSID des serveurs d'une zone :

 % check-soa -nsid tf 
d.ext.nic.fr.
	192.5.4.2: OK: 2222247941
	2001:500:2e::2: OK: 2222247941
d.nic.fr.
	194.0.9.1: OK: 2222247941 (NSID dns.ix1.nic.fr)
	2001:678:c::1: OK: 2222247941 (NSID dns.ix1.nic.fr)
e.ext.nic.fr.
	193.176.144.22: OK: 2222247941 (NSID ns-ext1a.sidn.nl)
	2a00:d78:0:102:193:176:144:22: OK: 2222247941 (NSID ns-ext1a.sidn.nl)
f.ext.nic.fr.
	194.146.106.46: OK: 2222247941 (NSID s2.par)
	2001:67c:1010:11::53: OK: 2222247941 (NSID s2.sth)
g.ext.nic.fr.
	194.0.36.1: OK: 2222247941 (NSID 1.lys.pch)
	2001:678:4c::1: OK: 2222247941 (NSID 1.lys.pch)

Si vous voulez voir les requêtes NSID en Go, voici le commit.

Le logiciel Blaeu de création et d'analyse de mesures des sondes RIPE Atlas peut également demander et afficher les NSID :

% blaeu-resolve --nsid --nameserver d.nic.fr yt
Nameserver d.nic.fr
[NSID: b'dns.lon.nic.fr'] : 1 occurrences 
[NSID: b'dns.lyn.nic.fr'] : 1 occurrences 
[NSID: b'dns.bru.nic.fr'] : 1 occurrences 
[NSID: b'dns.fra.nic.fr'] : 1 occurrences 
[NSID: b'dns.ix1.nic.fr'] : 1 occurrences 
Test #12181106 done at 2018-04-16T13:48:38Z
  

L'analyse avec dnspython est à cet endroit.

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

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

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

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

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

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

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

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

Un court RFC pour expliquer comment une pile IP peut tirer parti des indications envoyées par la couche 2 pour déterminer si un changement de réseau physique vient d'avoir lieu.

Il est fréquent qu'une machine puisse changer de réseau physique sans redémarrer : cela peut arriver en Wi-Fi, bien sûr, mais aussi avec les technologies issues de la téléphonie mobile comme 3GPP et même avec Ethernet lorsqu'on débranche et rebranche un câble.

Les paramètres de la connexion IP dépendent souvent du réseau physique sous-jacent. IP doit donc être prêt à changer ces paramètres lorsque la machine change de réseau. Il reste à détecter automatiquement ce changement et notre RFC explique, pour chaque technique de couche 2, les méthodes possibles et leurs problèmes éventuels.

Pour 3GPP/GPRS par exemple, notre RFC explique dans sa section 3.1 que c'est l'établissement du contexte PDP (Packet Data Protocol) qui signale que IP est disponible et qui doit donc être utilisé comme évenement déclencheur de la (re)configuration IP.

Pour Ethernet, c'est plus compliqué. La présence de ponts exécutant le protocole spanning tree fait que la connexion physique au lien ne signifie pas que les trames passent déjà. Et rien n'indique aux stations connectées que le protocole a terminé et que les trames peuvent désormais passer. Le RFC expose ce problème mais ne propose pas de solution simple.

Un RFC de nature opérationnelle, pour rappeler à quel point l'idée de mettre des adresses IP en dur dans la configuration des équipements réseaux est une mauvaise idée.

L'auteur parle d'expérience : son université, University of Wisconsin a été sérieusement perturbée lorsque des routeurs fabriqués par Netgear ont, par milliers, tenté de se connecter à son serveur NTP. Sans vergogne, les fabricants du routeur avaient mis l'adresse IP dudit serveur dans la configuration par défaut du routeur !

Une mésaventure identique était survenue à un ingénieur danois connu, dont le serveur NTP avait été surchargé par des routeurs D-link, produits par des gens peu scrupuleux.

Notre RFC s'appuie donc sur ces exemples pour demander que les adresses IP ne soient pas mises en dur dans la configuration de machines, surtout si celles-ci, comme la plupart des petits équipements réseaux, ne seront jamais mises à jour après leur livraison au client, et jamais administrées professionnellement. Même si le fabricant est bien titulaire de l'adresse IP du serveur, il ne peut pas garantir qu'il le restera. Comme le notent le RFC 2101 et le RFC 7020, les adresses IP ne sont pas éternelles.

On trouve de telles adresses IP dans les documentations (alors qu'il faudrait utiliser les adresses spéciales décrites dans les RFC 5737 et RFC 3849) et dans les configurations (pour que la machine fonctionne immédiatement, sans configuration manuelle, ce qui peut être plus pratique pour le client mais est très dangereux pour l'Internet, comme dans les cas ci-dessus).

Notre RFC décrit aussi dans sa section 3 les alternatives, comme d'utiliser des noms de domaine, plus stables que les adresses IP et surtout permettant des techniques de répartition de charge ou bien d'indirection, par exemple avec les enregistrements SRV (RFC 2782).

Une autre alternative est de compter sur des annonces faites localement, par exemple par DHCP, pour trouver les serveurs utiles.

I installed the operating system Ubuntu on a Dell Latitude D430 laptop machine. This article is to share the information that I obtained during the process.

While the basic functions are OK, there are problems. As often with laptops, especially very recent machines, a lot of things do not work, or do not work out of the box.

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 4930, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type (EPP dit le mapping) pour les contacts. Il n'est plus d'actualité, ayant été remplacé par le RFC 5733.

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 4930). Cet identificateur (on l'appelait traditionnellement le handle) est, par exemple, SB68-GANDI.

Les contacts ont aussi évidemment des moyens d'être contactés, via numéro de téléphone, adresse postale, etc.

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

À titre d'exemple, voici la réponse d'un serveur EPP à une requête <epp:info> 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>

Ce RFC remplace son prédécesseur, le RFC 3733 mais ce ne sont que des modifications de détail. Lui-même a ensuite été remplacé par le RFC 5733, avec, là encore, peu de modifications.

Ce RFC documente une simple extension à ICMP pour distribuer de l'information spécifique à MPLS.

De nombreux outils existent pour traiter les informations envoyées par le protocole de signalement ICMP, notamment le fameux traceroute. Notre RFC spécifie donc un moyen de permettre à un routeur MPLS de mettre des informations spécifiques à MPLS dans le paquet ICMP émis en cas de problème.

Depuis le RFC 4884, ICMP peut inclure des messages structurés, comme MIME le permet pour le courrier électronique. C'est cette possibilité qu'utilise notre RFC pour transmettre un message MPLS Label Stack qui inclue les valeurs des labels MPLS utilisés.

Si les LSR, les routeurs MPLS sont configurés pour signaler ces labels (tous les opérateurs ne le font pas), un programme comme traceroute pourra les afficher. Un patch est par exemple intégré dans Gentoo ou dans le traceroute de NANOG. Voici le résultat :

...
 5  p5-2-0-2.rar2.chicago-il.us.xo.net (65.106.6.161)  6.771 ms  15.769 ms  6.651 ms
 6  p1-0.IR1.Chicago2-IL.us.xo.net (65.106.6.138)  8.008 ms  6.910 ms  7.489 ms
 7  206.111.2.54.ptr.us.xo.net (206.111.2.54)  8.812 ms  7.224 ms  7.022 ms
 8  if-1-0.core2.CT8-Chicago.teleglobe.net (66.110.14.177)  6.955 ms  8.744 ms  7.288 ms
     MPLS Label=391 CoS=0 TTL=0 S=1
 9  if-0-1-0.core2.NTO-NewYork.teleglobe.net (66.110.14.22)  33.647 ms  33.673 ms  33.791 ms
     MPLS Label=106 CoS=0 TTL=0 S=1
10  if-4-0.core1.PG1-Paris.teleglobe.net (80.231.72.113)  104.626 ms  104.966 ms  107.155 ms
     MPLS Label=96 CoS=0 TTL=0 S=1
11  if-0-0.core2.PG1-Paris.teleglobe.net (80.231.72.34)  104.865 ms 111.197 ms  104.696 ms

Ce RFC nommé « Réflexions sur la neutralité de l'Internet » est essentiellement consacré à un rappel de l'importance qu'il y a à ne pas préjuger des usages et des applications. L'Internet doit rester transparent c'est-à-dire traiter de la même façon tous les paquets IP, sans privilégier certaines applications. C'est cette transparence qui a permis le développement spectaculaire de nouvelles applications et qui est aujourd'hui menacée.

Aujourd'hui, cette transparence est sérieusement menacée. Par exemples, certains opérateurs voudraient traiter de manière privilégiée certaines applications, ou au contraire contrarier certaines, comme la téléphonie sur IP, qui s'attaque à leur marché le plus rentable. C'est contre cette tendance que s'est développé le courant qui défend la neutralité du réseau.

Mais il y a d'autres menaces, par exemple, le déploiement de plus en plus fréquent de mécanismes qui empêchent la connexion de bout en bout, que ce soit :

• le NAT pour pallier le manque d'adresses IPv4,
• les coupe-feux mis au nom de la sécurité,
• ou, pire, certains FAI qui redirigent discrètement les paquets, bloquent certains ports comme le 25 (SMTP) ou modifient les réponses DNS dans les récurseurs qu'ils offrent à leurs clients.

Notre RFC est donc consacré à l'analyse de ces problèmes et à un rappel de leur caractère négatif. En effet, le fait que l'Internet soit un réseau neutre, un oblivious transport (terme utilisé dans le rapport New Arch, que cite notre RFC), un simple transporteur de paquets, qui ne se permet pas de les examiner ou de les modifier, est l'un des points les plus importants de l'architecture de ce réseau. C'est ce point qui permet le développement d'applications nouvelles et non planifiées dès l'origine. L'exemple archétypal est bien sûr le Web, non prévu à l'origine de l'Internet et qui a pu être déployé progressivement ; sur un réseau transparent, il suffit que deux machines soit d'accord et elles peuvent tout de suite commencer à utiliser le nouveau protocole.

À l'opposé des réseaux transparents se trouvent des réseaux ossifiés comme les réseaux des opérateurs téléphoniques, liés à une seule application et ne permettant donc pas l'innovation, puisque tout changement doit être approuvé et mis en œuvre par l'opérateur.

L'Internet, traditionnellement transparent, devient de plus en plus ossifié. C'est ainsi que les routeurs NAT et les coupe-feux qui examinent le contenu des paquets ne laissent guère de chance à des nouveaux protocoles de transport comme SCTP (RFC 3286) d'être déployés. De même, les nouvelles applications sont souvent obligées de « tricher » en passant au dessus de HTTP, de façon à franchir les coupe-feux.

Il est temps de réagir. Ce RFC n'est pas le premier document sur la question, le pionnier avait été le RFC 2775 et notre nouveau RFC se consacre surtout aux nouveautés. Il décrit les facteurs qui s'opposent à la transparence comme le filtrage (section 2.1), d'autant plus problématique que très rares sont les FAI qui publient leur règle de filtrage, malgré le RFC 4084, certaines utilisations de la QoS (section 2.2), les passerelles applicatives (ALG, section 2.3), puisqu'elles doivent être mises à jour pour tout changement du protocole applicatif, mais aussi la manipulation des réponses DNS (section 2.5.2).

Certains FAI (apparemment, aujourd'hui, en France, Noos, Club-Internet et Tiscali) modifient les réponses DNS reçues par les serveurs faisant autorité. Typiquement, ils remplacent les réponses NXDOMAIN (No Such Domain, ce nom de domaine n'existe pas) par une adresse IP prédéterminée où un serveur Web leur propose moteur de recherche et publicités. Le RFC note que, outre leur incompatibilité avec DNSSEC, ces manipulations cassent le modèle de référence du DNS (qui est que le gérant d'une zone est l'autorité suprême sur le contenu de la zone).

La sécurité, c'est toujours un problème difficile. Parmi les sous-problèmes à résoudre pour rendre un système informatique sûr, la sécurité du générateur de nombres aléatoires occupe une bonne place, mais qui est souvent méconnu. Ce RFC fait donc le point sur le problème et sur les mesures à adopter lors de la mise en œuvre des protocoles IETF.

L'alerte de sécurité CVE-2007-2926 sur le générateur aléatoire de BIND est venue nous le rappeler : beaucoup de mécanismes de sécurité informatique reposent sur la génération « sûre » de nombres aléatoires. « Sûre » voulant dire ici « Difficile à prévoir par l'adversaire ». Comme tout serveur récursif DNS, BIND doit placer dans les requêtes sortantes une query ID que le serveur faisant autorité mettra dans sa réponse, permettant ainsi de s'assurer de la validité de la réponse (la query ID sert donc de cookie). Si les query ID sont prévisibles par un méchant, il peut facilement fabriquer de fausses réponses qui ont l'air vraies et ainsi empoisonner le cache du serveur récursif.

Cette faille est très classique : nombreux sont les logiciels qui utilisent, sans bien s'en rendre compte, un générateur aléatoire prédictif. Notre RFC donne une explication partielle pour cet aveuglement : les textes classiques sur les générateurs aléatoires ne les jugent que par des considérations statistiques, pas en prenant le point de vue d'un adversaire qui chercherait à trouver le nombre suivant. Notre RFC cite l'exemple d'un générateur qui, devant fabriquer des nombres de 128 bits aléatoires, produirait en moyenne 50 % de nombres égaux à zéro et 50 % de nombres aléatoires. Statistiquement, il y aurait toujours 64 bits d'entropie, ce qui peut sembler suffisant. Mais un attaquant n'aurait qu'à essayer un nombre nul pour réussir la moitié du temps et l'entropie réelle serait donc de un bit...

Ce RFC, qui succède au RFC 1750, est donc consacré à l'exposé des bonnes pratiques en matière de générateur aléatoire. Depuis le RFC 1750, le monde des protocoles Internet a été bouleversé puisque presque tous dépendent désormais plus ou moins de la cryptographie, qui elle-même dépend souvent de générateurs aléatoires sûrs, par exemple pour fabriquer les clés de session.

Les bonnes pratiques peuvent se regrouper en deux catégories, utiliser le hasard présent dans la matériel, et utiliser des générateurs cryptographiquement forts.

Le matériel d'un système informatique est en effet source de nombreux bruits très aléatoires. Le bruit de fond du micro (section 3.2.1) ou les interruptions envoyées par le disque dur (section 3.2.2) sont deux bons exemples. Presque tous les ordinateurs ayant un tel matériel, il est recommandé de l'utiliser comme source d'entropie. (Les cartes réseaux ne sont mentionnées qu'en passant, car leurs interruptions peuvent être influencées par un tiers, surtout s'il est sur le même réseau.) Idéalement, il faudrait utiliser des dispositifs quantiques comme un ensemble d'atomes radioactifs dont on mesure la désintégration mais les PC ont plus souvent un micro qu'un compteur Geiger... (À défaut d'un tel compteur, on peut utiliser un générateur de bruit blanc comme l'Alea.)

Le RFC détaille aussi des mauvaises idées, par exemple le programmeur qui doit initialiser un générateur aléatoire avec une graine (seed) utilise souvent l'horloge de la machine (par exemple en Python, quelque chose comme generator = random.Random (time.time()) ou bien en C, initstate(time(NULL), state, NUMSTATES);). C'est en général très peu sûr, car les horloges ont typiquement une résolution très faible : si l'attaquant sait à quelle heure approximative le système a démarré, il peut trouver la graine et en déduire les nombres générés (section 3.4 du RFC). La section 6.1 détaille d'autres mauvaises idées, notamment celle de croire que, si on fait des manipulations très complexes des données, on est davantage en sécurité (en fait, c'est souvent le contraire).

Il y a beaucoup d'autres détails à prendre en compte (le RFC note que le problème est « étonnamment difficile ») comme le fait qu'une machine qui démarre a accumulé peu d'entropie et est donc particulièrement vulnérable (sauf si on sauvegarde le dernier résultat du générateur lors de l'arrêt, pour l'utiliser comme graine au démarrage suivant).

Pour le programmeur qui trouve cela bien difficile, notons que le RFC, dans le traditionnel esprit IETF de se soucier des problèmes pratiques, pas juste de la théorie, a prévu une section 7 qui détaille les fonctions déjà écrites et qu'il n'y a plus qu'à utiliser comme /dev/random sur beaucoup de systèmes Unix. /dev/random est un pseudo-fichier rempli par le noyau du système en utilisant diverses sources d'entropie, dont celles fournies par le matériel. Sur Linux, il existe aussi un /dev/urandom, sans doute moins sûr (car utilisant également un générateur pseudo-aléatoire) mais non bloquant (la lecture de /dev/random peut durer longtemps, car le noyau n'y écrit rien tant qu'il n'a pas assez récolté d'entropie). Voici un exemple d'utilisation de /dev/urandom pour obtenir 512 octets aléatoires dans un fichier :

dd bs=512 count=1 if=/dev/urandom > /tmp/random_data

Ceux qui aiment lire le code source noteront que, dans les noyaux Linux 2.6, ce mécanisme est programmé dans drivers/char/random.c et que les commentaires très détaillés de ce fichier sont instructifs.

Les personnes allergiques aux mathématiques sont prévenues que ce RFC est un des rares documents de l'IETF à comporter des formules mathématiques (qui n'ont pas été faciles à publier en texte seul).

Ce RFC décrit un langage formel pour spécifier les en-têtes d'un paquet et, surtout, pour indiquer le mécanisme de compression utilisé.

Tous les réseaux ne disposent pas d'un excès de bande passante. Même aujourd'hui, les vieux modems restent en service (y compris dans un pays riche, mais étendu, comme les États-Unis) et certaines technologies récentes offrent une bande passante limitée (par exemple sur les téléphones mobiles). Il est donc utile de pouvoir comprimer les données et aussi les en-têtes des paquets émis, qui sont souvent très redondants, ouvrant ainsi de bonnes perspectives pour la compression. Le premier grand travail dans ce domaine avait été la compression des en-têtes TCP par Van Jacobson en 1990 (RFC 1144). Par la suite, plusieurs mécanismes de compression ont été inventés et le projet ROHC (Robust Header Compression) a été créé pour mettre de l'ordre dans ces mécanismes, en développant un cadre commun, spécifié dans le RFC 3095 et dans plusieurs autres (ROHC est désormais normalisé dans le RFC 5795).

Il manquait à tous ces RFC un langage formel, toutes les descriptions étant en langue naturelle. C'est désormais fait avec notre RFC et ce langage, ROHC-FN, rejoint donc ABNF (RFC 5234) et MIB (RFC 2578) comme langage formel pour aider à la normalisation. La première utilisation de ROHC-FN a été dans le RFC 5225.

On notera que ROHC-FN permet également la description formelle des en-têtes des paquets, description qui était traditionnellement faite dans les RFC par des ASCII box. Voici un en-tête (imaginaire) en ASCII box :

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |version| type  |    flow_id    |
   +---+---+---+---+---+---+---+---+
   |  sequence_no  |   flag_bits   |
   +---+---+---+---+---+---+---+---+

et le même décrit en ROHC-FN :

     eg_header
     {
       UNCOMPRESSED {
         version_no   [ 2 ];
         type         [ 2 ];
         flow_id      [ 4 ];
         sequence_no  [ 4 ];
         flag_bits    [ 4 ];
       }

Si on intègre la compression, ce qui est le but principal de ROHC-FN, on peut avoir :

       COMPRESSED obvious {
         version_no    =:= uncompressed_value(2, 1);
         type          =:= irregular(2);
         flow_id       =:= static;
         sequence_no   =:= lsb(0, -3);
         abc_flag_bits =:= irregular(3);
         reserved_flag =:= uncompressed_value(1, 0);
       }

ce qui exprime le fait que version_no a toujours la même valeur (1), que type n'est pas comprimable, ou que sequence_no ne l'est pas dans un paquet mais qu'une compression inter-paquets est possible (le numéro de séquence s'incrémentant légèrement à chaque paquet).

Ces différentes méthodes (uncompressed_value, lsb, etc) sont décrites dans la section 4.11 de notre RFC.

On notera qu'il existe d'autres langages pour la description de structures binaires comme les en-têtes mais qu'apparemment aucun ne convenait pour l'IETF.

Je décris ici une application Web qui ne sert à rien mais qui montre l'usage de plusieurs techniques qui sont apparemment souvent demandées : SQL, REST, Unicode, etc, le tout en Python.

Voici un RFC expérimental (et dont mon pronostic est qu'il le restera) sur l'encodage de schémas ASN.1 en XML.

ASN.1 est un langage très utilisé dans les RFC pour décrire les données échangées entre deux systèmes. Il est notamment à la base du langage de description des MIB, les bases de données des agents SNMP. ASN.1 est probablement le langage formel le plus courant dans les RFC, même devant ABNF.

Ce n'est pas en raison de ses qualités propres, pourtant. Normalisé par l'ISO, il hérite les défauts habituels des normes ISO : diffusion payante et restreinte, documents très complexes et abstraits, écrits sans aucun souci pour les problèmes des implémenteurs.

C'est un de ces problème que traite ce RFC : ASN.1 est difficile à analyser en raison des multiples ambiguïtés de sa grammaire (section 1 du RFC). Changer la grammaire actuelle pour XML, en gardant la sémantique semble donc une idée tentante.

Le résultat est un RFC de 165 pages, un des plus longs car il a fallu reprendre toute la sémantique d'ASN.1. ASN.X est en effet décrit sous la forme d'une transformation d'une grammaire en ASN.1 en XML.

Par exemple, en appliquant ces règles de transformation, l'ASN.1 suivant :

SEQUENCE {
          one    INTEGER,
          two    BOOLEAN OPTIONAL,
          three   PrintableString DEFAULT "third"
      }

deviendra en XML :

<type>
       <sequence>
        <element name="one" type="asnx:INTEGER"/>
        <optional>
         <attribute name="two" type="asnx:BOOLEAN"/>
        </optional>
        <optional>
         <element name="three" type="asnx:PrintableString"/>
         <default literalValue="third"/>
        </optional>
       </sequence>
</type>

Le résultat semble aussi complexe que l'original et ne résout qu'un seul problème, celui de la syntaxe. Je ne lui prédis donc pas beaucoup d'avenir.

Ce RFC décrit la voie "indépendante" pour soumettre un RFC au RFC editor sans passer par l'IETF.

On l'oublie souvent mais tous les RFC n'ont pas été développés à l'IETF. Certains ont emprunté la "voie indépendante" qui fait l'objet de notre RFC. Compagnon du RFC 4844, ce RFC décrit cette voie.

A l'origine, tous les RFC étaient de tels "indépendants" puisque les RFC existaient bien avant l'IETF. Aujourd'hui que les normes techniques de l'Internet sont dévelopées à l'IETF et publiés comme RFC après leur approbation par l'IESG, la voie indépendante sert pour :

• Documenter des protocoles privés,
• Proposer des protocoles alternatifs à ceux approuvés par l'IETF,
• Publier des normes qui n'ont pas réussi sur la voie normale e à qui la voie indépendante offre un rattrapage.

Ces futurs RFC sont donc soumis directement au RFC editor. Si celui-ci vérifie avec l'IESG la possibilité d'un conflit avec une norme IETF (section 5 du RFC), le RFC editor n'en est pas moins le seul décideur pour leur publication ou non. (Depuis la parution de ce RFC, un nouvel acteur a été ajouté, l'ISE - Independent Submission Editor, cf. RFC 8730 - et d'autres changements ont eu lieu, par exemple dans le RFC 8726.)

Parmi les protocoles utilisés sur Internet, presque tous sont internationalisés depuis longtemps. Le dernier gros manque concernait les adresses de courrier électronique, obligées de s'en tenir à stephane@internet-en-cooperation.fr alors qu'on voudrait pouvoir écrire à stéphane@internet-en-coopération.fr. Désormais, nous avons une solution, Internationalized Email Addresses. Expérimentale à l'époque de la parution de ce RFC, cette solution est devenue une norme complète par la suite avec le RFC 6530, qui a remplacé ce RFC.

Bien sûr, pour l'exemple ci-dessus, le gain n'est pas évident. Mais il l'est beaucoup plus si vous voulez écrire votre adresse avec l'écriture arabe ou chinoise.

Le contenu des courriers était internationalisé depuis longtemps, au moins depuis MIME (RFC 1341 à l'origine, en juin 1992). Mais les adresses ne l'étaient pas encore. Notre RFC décrit le cadre général de l'internationalisation des adresses de courrier.

Il y a deux parties à l'adresse (décrites dans le RFC 2822) : la partie locale, à gauche du @ et le nom de domaine à droite. Si ce nom de domaine, depuis la sortie du RFC 3490, en mars 2003, peut s'écrire en Unicode (norme IDN), le courrier exigeait toujours un nom de domaine en ASCII donc un message de non-délivrance, par exemple, allait affichait la forme Punycode du nom. Ce n'était pas une vraie internationalisation.

Le cadre d'internationalisation du courrier couvre plusieurs aspects, couverts chacun par un RFC. Ce premier RFC expose l'architecture générale.

SMTP est modifié pour permettre une nouvelle extension, indiquant le support du courrier internationalisé (RFC 5336).

Le format des messages (RFC 2822) est modifié pour permettre d'inclure de l'Unicode, encodé en UTF-8, directement dans les en-têtes, comme le champ To: (RFC 5335).

Un mécanisme de repli (downgrading) était prévu pour le cas où un émetteur internationalisé rencontrerait un récepteur qui ne l'est pas, nécessitant une modification des adresses en ASCII (RFC 5504). En effet, contrairement à HTTP, le courrier ne fonctionne pas de bout en bout et le message est relayé par plusieurs serveurs, qu'on ne connait pas forcément a priori. Ce mécanisme s'est révélé bien compliqué pour pas grand'chose et a finalement été abandonné avec le RFC 6530.

De même, les protocoles POP et IMAP doivent être modifiés pour que le courrier ainsi internationalisé puisse être récupéré... et lu.

Le repli est certainement la partie la plus complexe et fera l'objet d'un RFC propre : modifier un message est toujours une opération délicate, notamment en présence de signatures cryptographiques, que le repli ne doit pas invalider !

Notons (section 6.3 du RFC) que les adresses de courrier sont utilisés en de nombreux endroits, par exemple comme identificateurs sur certains sites Web de commerce électronique, comme Amazon et que ces utilisateurs vont également devoir s'adapter. Quant on voit le nombre de sites, supposés professionnels, qui continuent à interdire des adresses de courrier légales, on mesure l'ampleur du travail. La sortie en février 2012 de la norme RFC 6530, qui remplace notre RFC, accélérera-t-elle les choses ?

Les RFC, qui incluent notamment les normes techniques de l'Internet, sont en général réalisés par l'IETF mais sont publiés par un organisme séparé, le RFC editor dont le rôle n'avait pas encore été mis par écrit, ce que fait notre RFC, qui a depuis été remplacé par le RFC 8729.

Comme pour beaucoup de choses dans l'Internet, la définition exacte des rôles des différents acteurs n'avait pas été formalisée car personne n'en ressentait le besoin. Au fur et à mesure que l'Internet devient une infrastructure essentielle, cette absence de formalisation est mal ressentie et la tendance, depuis plusieurs années, est de mettre par écrit tout ce qui était implicite auparavant.

C'est le cas du rôle du RFC editor. Autrefois le titre d'une seule personne, Jon Postel, ce nom désigne désormais une petite structure, choisie et financée par l'ISOC, hébergée à l'ISI, qui assure le travail d'éditeur. Relire les RFC avant publication, leur donner un numéro et assurer leur distribution, tels sont les principaux rôles du RFC editor.

Notre RFC décrit en détail le rôle de cet éditeur, sa place dans le processus de publication et les fonctions qu'il doit assurer (le cahier des charges de l'IETF avait été publié dans le RFC 4714).

Il faut noter (section 5 du RFC) que le RFC editor reçoit des textes candidats par plusieurs voies. Si la plus connue est celle de l'IETF, il peut aussi publier des RFC d'autres origines notamment ceux ici des soumissions indépendantes (RFC 4846).

Le RFC editor a une mission difficile puisqu'il doit agir avec prudence, voire avec conservatisme, pour assurer la qualité et la disponibilité des RFC pendant de très longues périodes.

Il remplit cette mission sans faire d'excès de zèle. Ce n'est pas chez le RFC editor qu'il faudrait chercher les derniers gadgets comme un flux de syndication. Les erreurs signalées mettent fort longtemps à être publiées, les RFC ne sont pas signés (malgré la section 6 du RFC qui demande que des mesures soient prises pour assurer l'intégrité des documents), et le manque de poids politique du RFC editor fait qu'il n'a jamais été possible d'adopter un autre format de publication que le texte brut...

Voici le cahier des charges du groupe de travail IETF NEMO qui vise à normaliser les techniques permettant la mobilité d'un réseau entier, pas seulement d'une machine.

La mobilité est un domaine riche et complexe et il est préférable de lire d'abord les RFC de terminologie comme le RFC 3753 et RFC 4885. Les principaux termes utilisés dans notre RFC sont MR (Mobile Router) pour le routeur du réseau mobile, MNN (Mobile Network Nodes) pour les machines ordinaires du réseau mobile et CN (Correspondent Node) pour la machine (par exemple, un serveur Web) avec laquelle le MNN veut communiquer.

La section 2 décrit les scénarios d'usage, du cadre survolté moderne bardé de gadgets électroniques, comme un soldat US en Irak, et qui est un réseau mobile à lui tout seul, tous ses gadgets communiquant entre eux par Bluetooth, à un groupe d'étudiants qui travaillent sur leurs ordinateurs portables dans le train et qui ont besoin de connectivité entre eux aussi bien qu'avec l'Internet.

La section 3 du RFC expose ensuite les buts de NEMO : permettre aux MNN d'ignorer qu'ils sont mobiles, ne pas charger la table de routage globale en vain (section 3.12), permettre de protéger la vie privée des MNN (le CN ne doit pas savoir où se trouve son client), etc.

Le groupe de travail NEMO a bien avancé. Ce RFC de cahier des charges est publié deux ans (!) après la première spécification, le RFC 3963 et en même temps que plusieurs autres normes comme les RFC 4887 et RFC 4889.

J'ai commencé cet article dans un avion et je note que NEMO n'est pas encore déployé partout, nous n'avions pas de connectivité Internet (même si des essais ont été tentés).

Cette extension au format de syndication Atom permet de spécifier la licence utilisée par l'auteur et autorise donc les lecteurs / agrégateurs / transformateurs de flux de syndication à prendre des décisions en toute connaissance de cause.

Atom, normalisé dans le RFC 4287 est un format de syndication bâti sur XML. L'un des buts de la syndication est de permettre à des logiciels de traiter automatiquement ces flux, pour les agréger avec d'autres, sélectionner certaines entrées, etc. Mais est-ce légal ? Cela dépend de la licence sous laquelle l'auteur des flux les distribue. La norme Atom fournissait déjà un élément <atom:rights> pour indiquer cette licence mais son contenu était prévu pour être lu par des humains, pas par des logiciels.

Atom est extensible, mais il n'a pas été nécssaire d'utiliser le mécanisme d'extension, cette fois. Notre RFC comble la faille en utilisant l'élément <atom:link>. Celui-ci sert à référencer toutes sortes de ressources, la nature de cette référence étant donnée par son attribut rel qui prend une valeur choisie dans le registre des relations.

Par exemple, ce blog, qui est distribué sous licence GFDL contient désormais dans son flux de syndication :

<link rel="license" type="text/html" title="GFDL in HTML format" href="http://www.gnu.org/copyleft/fdl.html"/>
<!--  draft-walsh-app-docbook-xml, not yet registered -->
<link rel="license" type="application/docbook+xml" title="GFDL in Docbook format" href="http://www.gnu.org/licenses/fdl.xml"/>
<link rel="license" type="text/plain" title="GFDL in plain text" href="http://www.gnu.org/licenses/fdl.txt"/>

ce qui permet à un lecteur de flux Atom de retrouver facilement la licence utilisée.

Cela ne veut pas dire qu'il saura a traiter, le RFC ne va pas jusqu'à spécifier un langage formel pour exprimer les licences, comme l'avait tenté (avec peu de succès) P3P.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Voici un exemple de script Sieve tiré du RFC :

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

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

Ce RFC décrit une expérience (apparemment sans suite) d'utilisation du DNS pour aider au routage IP. Cette expérience éclaire certains débats actuels sur la séparation de l'identificateur et du localisateur.

Notre RFC s'attaque à un problème récurrent de l'Internet : la croissance des tables de routage, due notamment au multihoming. Si les chiffres donnés dans le RFC font sourire aujourd'hui (« there are already more than 5000 networks announced in the NSFNET routing tables », alors qu'ils sont plus de 200 000 désormais), la question reste la même. Si un site, pour des bonnes raisons, veut se connecter à plusieurs FAI (être multihomé), il doit annoncer une route dans la table de routage globale et celle-ci croît, aux frais des opérateurs Internet.

La solution proposée par Christian Huitema dans ce RFC est de ne pas annoncer la route vers le réseau du site multihomé mais de compter sur le DNS pour la trouver. Le principe est le suivant : le site multihomé utilise le préfixe réseau 192.0.2.0/24. Le site ne fait pas de BGP et ne l'annonce pas dans la table de routage globale. Il est connecté par deux fournisseurs, dont les routeurs ont les adresses IP 10.123.6.1 et 172.18.1.3, qui ne sont pas dans ce préfixe et sont, elles, annoncées en BGP. Le site publie des enregistrements DNS de type RX qui pointent vers les routeurs des FAI :

2.0.192.in-addr.arpa.     IN    RX   10.123.6.1
                          IN    RX   172.18.1.3

Le premier routeur qui veut parler à une adresse en 192.0.2.0/24 peut alors utiliser le DNS pour trouver le routeur de bord de site.

On a donc une vraie séparation de l'identificateur et du localisateur, l'adresse non-BGPisée (192.0.2.0/24) étant un identificateur et l'adresse des routeurs de bord de site étant un localisateur.

Les enregistrements RX ont été nommés par analogie aux MX. En fait, en raison de la difficulté à déployer de nouveaux types d'enregistrement, notre RFC a utilisé des enregistrements de type TXT.

La première idée est de faire faire ce travail de client DNS à chaque routeur du trajet. Mais cela imposerait des délais et un gros trafic DNS. Le RFC spécifie donc en fait que seul le premier routeur fera une requête DNS, puis utiliser la source routing pour que les routeurs suivants n'aient pas ce travail. (On notera que le source routing ne fonctionne plus sur l'Internet d'aujourd'hui, pour des raisons de sécurité.)

L'expérience ne semble pas avoir connu de suite.

Un des aspects les moins connus du protocole HTTP est la possibilité de négociation de contenus par laquelle le client HTTP informe le serveur de ses préférences, en matière de format de données, ou bien de langue.

Tout le monde écrit un blog aujourd'hui. L'interface Web des moteurs de blogs autorise une mise à jour simple, même par des personnes non informaticiennes. Mais une mise à jour par un programme est-elle possible ? Aujourd'hui, la plupart des moteurs de blogs le permettent, en général avec XML-RPC.

Ce RFC spécifie une nouvelle version du protocole WebDAV (Web Distributed Authoring and Versioning), initialement décrit dans le RFC 2518. Les changements sont peu nombreux.

WebDAV étend le protocole HTTP pour faciliter le travail en groupe sur les ressources distribuées via le Web. HTTP offrait déjà des moyens de modifier une ressource (une ressource est en général un document) par les commandes PUT et DELETE, en plus des commandes permettant d'y accéder (GET), mais elles étaient peu utilisées en dehors de certaines applications REST. WebDAV étend les possibilités de ces commandes, notamment par le concept de collection (un groupe de ressources) et par celui de versions, décrit dans le RFC 3253, dit Delta-V. En outre, il ajoute des nouvelles commandes comme :

• PROPFIND pour récupérer la liste des propriétés (métadonnées) d'une ressource,
• LOCK et UNLOCK pour mettre et retirer des verrous sur les ressources, afin d'éviter qu'un auteur ne marche sur les pieds d'un autre.

Les réponses à ces nouvelles commandes sont formulées en XML et, comme dans la plupart des RFC récents, notre RFC recommande dans l'appendice A.2 d'être très prudent avec le traditionnel principe Be liberal in what you accept and conservative in what you send, principe qui, sur le Web, a fait plus de mal que de bien.

WebDAV est un protocole complexe (notre RFC est plutôt gros et il faut déjà connaitre HTTP pour le lire) et qui n'est qu'un succès mitigé. En pratique, il semble que la plupart des gens qui maintiennent un site Web chargent leur fichier en FTP ou bien directement en TTW, Through The Web, c'est-à-dire via leur navigateur et un formulaire, comme on peut le faire avec la plupart des CMS.

L'un des utilisateurs le plus connus de WebDAV est Subversion dont c'est le principal protocole d'accès au dépôt. Un serveur Subversion est donc un serveur WebDAV étendu (car WebDAV ne suffisait pas, tout gros qu'il soit), en général un Apache avec les modules dav et dav_svn. Voici par exemple une configuration typique d'Apache pour Subversion :

LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so

<VirtualHost *:443>
        ServerAdmin webmaster@example.net
        ServerName svn.example.net

        SSLEngine on 
        SSLCertificateFile /etc/apache2/apache.pem

        <Location />
              DAV svn
             
              SVNPath /home/Subversion-Repository

             AuthType Basic
             AuthName "Subversion Repository"
             require valid-user
        </Location>

</VirtualHost>

On voit alors dans le journal du serveur les requêtes spécifiques à WebDAV, ici un PROPFIND lors d'un svn update :

192.0.2.69 - bortzmeyer [29/Mar/2007:12:05:35 +0200] "PROPFIND / HTTP/1.1" 207 629 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net

Et ici la séquence d'ajout d'un nouveau fichier (par svn commit) qui se fait en déposant un fichier temporaire avec PUT, puis en le déplaçant avec MERGE - commande qui vient du RFC 3253 - avant de détruire le fichier temporaire avec DELETE :

192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "PUT /!svn/wrk/9c36d042-47ac-41d6-a455-b8a6091f6a3c/README HTTP/1.1" 201 225 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net
192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "MERGE / HTTP/1.1" 200 933 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net
192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "DELETE /!svn/act/9c36d042-47ac-41d6-a455-b8a6091f6a3c HTTP/1.1" 204 - "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net

Il semble y avoir peu de logiciels qui gèrent WebDAV, le principal sur Unix étant cadaver. Voici un exemple d'utilisation de cadaver pour envoyer des fichiers sur un serveur DAV :

% cadaver http://tmp.example.org:9701/tests_perf
Authentication required for Tests de performance on server `tmp.example.org':
Username: tester
Password: 

dav:/tests_perf/>   mput *
[Matching... 4 matches.]
Uploading AFNIC-2-Renater-Paris.pcap.gz to `/tests_perf/AFNIC-2-Renater-Paris.pcap.gz':
Progress: [=============================>] 100.0% of 289 bytes succeeded.
Uploading AFNIC-2-INRIA-Montbonnot.pcap.gz to `/tests_perf/AFNIC-2-INRIA-Montbonnot.pcap.gz':
Progress: [=============================>] 100.0% of 292 bytes succeeded.
Uploading Nerim-2-Renater-Paris.pcap.gz to `/tests_perf/Nerim-2-Renater-Paris.pcap.gz':
Progress: [=============================>] 100.0% of 289 bytes succeeded.
Uploading Nerim-2-INRIA-Montbonnot.pcap.gz to `/tests_perf/Nerim-2-INRIA-Montbonnot.pcap.gz':
Progress: [=============================>] 100.0% of 292 bytes succeeded.

dav:/tests_perf/> quit
Connection to `tmp.example.org' closed.

Mais on trouve du WebDAV en plusieurs endroits, par exemple comme protocole d'accès pour des serveurs de fichiers.

Le groupe de travail WebDAV de l'IETF a eu un parcours assez difficile et vient seulement d'être dissous, après dix ans d'existence, ce qui est extrêmement long pour l'IETF. Finalement, cette mise à jour du RFC 2518 n'apporte que des changements de détails, qui sont décrits dans l'appendice F.

La protection de la vie privée sur Internet suscite de plus en plus d'intérêt à l'IETF, d'autant plus que certaines techniques comme la mobilité peuvent aggraver la diffusion d'informations confidentielles. Notre RFC explique le problème.

Lorsqu'une machine A correspond avec une machine B, celle-ci apprend l'adresse IP de A, c'est inévitable. B apprend aussi beaucoup d'autres choses (par exemple via les cookies Web) qui, mises ensemble, peuvent représenter une sérieuse menace pour la vie privée. Dès qu'on cherche un peu, on est étonné du nombre de moyens qu'il existe pour détecter des choses que le correspondant voulait cacher. Par exemple, l'analyse du temps de réponse du correspondant peut donner une idée de la distance, et donc permettre de savoir quand un portable a quitté son « port d'attache ».

En effet, dans le cas de la mobilité IP, de nouvelles vulnérabilités apparaissent. La mobilité « traditionnelle » où la machine en déplacement (on parle de MN pour Mobile Node) acquiert une nouvelle adresse IP à chaque réseau visité, typiquement par DHCP, avait déjà ses propres dangers. Si le correspondant du MN, le CN (Corresponding Node), peut découvrir un invariant du MN (par exemple un cookie Web envoyé ou, de manière plus sophistiquée, une signature du comportement de l'horloge de la machine, le CN peut littéralement suivre à la trace le MN et déterminer sa position approximative, comme si votre téléphone GSM révélait à vos correspondants votre position !

La mobilité IPv6, décrite dans le RFC 3775, a deux modes de fonctionnement, le mode « normal » (reverse tunneling) où tout le trafic passe par un routeur sur le réseau principal du MN (et où le CN ne voit donc pas l'actuelle adresse IP du MN, la « care-of address ») et un mode « optimisé » où le passage par le routeur « de la maison » (Home Agent) n'est plus obligatoire et qui retrouve donc le même inconvénient qu'avec DHCP pur. Chacun de ses deux modes a ses propres défauts pour la protection de la vie privée et notre RFC les détaille. La section 4 est particulièrement vivante dans son exposé des risques qui guettent le malheureux utilisateur d'un PC portable.

Notre RFC ne propose pas de solution, il explique les problèmes à résoudre et donne une idée des compromis qu'il faudra sans doute faire.

Les liens Internet dont la MTU est plus faible que les traditionnels 1500 octets rencontrent souvent de nombreux problèmes, qui frappent particulièrement les transferts TCP. Quelles sont les solutions pratiques ?

Un RFC de l'IAB pour décrire l'usage que peuvent faire les protocoles Internet des indications envoyées par la couche Liaison (couche 2) du réseau.

Dans le traditionnel modèle en couches, que notre RFC rappelle dans sa jolie figure 1, la couche 2 ou couche de liaison (Link layer) peut donner aux couches supérieurs des indications utiles, par exemple que le lien fonctionne (Link Up) ou bien justement qu'il ne fonctionne pas (Link Down). Mais la réalité est bien plus complexe et ce RFC la détaille.

Ces indications sont typiquement transitoires (un lien, surtout les liens radio, qui sont le principal exemple donné dans le RFC, tombe en panne, remarche, etc). La section 1.4 est toute entière consacrée aux nombreuses méthodes existantes pour utiliser les indications de la couche 2. Il y en a beaucoup car aucune n'est idéale. Par exemple, sur un Ethernet 100base-T, il peut être tentant d'utiliser les indications données par le commutateur pour déterminer si le lien fonctionne ou pas. Mais un commutateur défaillant peut établir le signal, sans pour autant commuter les paquets. L'information de lien doit donc être utilisée avec prudence, les protocoles doivent toujours faire leurs propres tests (par exemple, OSPF (RFC 2328) ne se fie qu'à ses paquets Hello). Et c'est pire pour les liens radio, où la qualité du signal peut varier énormément. Bref, une machine qui se fierait aveuglément aux indications de la couche 2 pourrait avoir des faux positifs (le lien semble marcher mais les paquets ne passent pas) et des faux négatifs (le lien est tombé mais c'est transitoire, il ne faut pas interrompre les sessions TCP pour si peu). Ces problèmes sont également décrits dans le RFC 4436 qui propose une méthode pour savoir si la liaison réseau fonctionne, sans compter sur la couche 2 pour le dire.

La section 2 du RFC décrit en détail les règles qui doivent suivre les protocoles qui veulent utiliser les indications de la couche liaison. Par exemple, ceux-ci doivent résister à des indications erronnées de la couche 2.

La section 4 est consacrée aux questions de sécurité car les messages de la couche liaison sont en général non authentifiés et un atatquant peut donc relativement facilement simuler des évenements comme Link Down.

Enfin, une longue et détaillée annexe A passe en revue l'abondante littérature sur le sujet, notamment sur les protocoles sans fil, littérature qui montre que l'état d'un lien n'est pas aussi binaire (Up/Down) qu'on pourrait le penser.

Une nouvelle pierre dans la construction d'une éventuelle future architecture Internet séparant identificateur et localisateur, depuis remplacée par le RFC 7343.

Les ORCHID sont des identificateurs dont la forme est celle d'une adresse IPv6 (afin de pouvoir être utilisés dans les API qui attendent des adresses IP). Ils sont typiquement utilisés dans le cadre de protocoles comme HIP (RFC 9063). Pour les distinguer, notre RFC réservait le préfixe 2001:10::/28 (rendu depuis, suite au RFC 7343). Si vous voyez une telle « adresse IP », ne vous attendez pas à pouvoir la « pinguer », elle n'a pas vocation à être routable, c'est un pur identificateur.

Comme les adresses CGA (RFC 3972), les ORCHID sont signées cryptographiquement, la section 2 de notre RFC détaillant le mécanisme de construction d'une ORCHID.

Autrefois, tout était plus simple, les serveurs de noms DNS étaient simplement identifiables par leur adresse IP et on savait donc toujours à quel serveur on s'adressait. Mais un certain nombre d'innovations techniques assez récentes comme l'anycast ont rendu le débogage plus difficile. D'où l'importance d'un nouveau mécanisme pour trouver à quel serveur on parle.

A priori, si je pose une question à 192.93.0.4, une et une seule machine peut répondre à la question posée, non ? Eh bien non, en raison de l'anycast (voir le RFC 4786) et des répartiteurs de charge. Plusieurs machines peuvent désormais se « cacher » derrière une même adresse. Normalement, on ne s'en aperçoit même pas mais, s'il y a un problème, par exemple si elles se désynchronisent, il est nécessaire de pouvoir déterminer à quelle machine physique on parle.

La méthode traditionnelle, popularisée par le logiciel BIND était d'utiliser une requête de la classe CH (pour CHAOS), classe inutilisée et donc disponible. Essayons sur f.root-servers.net, qui est anycasté :

% dig @f.root-servers.net CH TXT hostname.bind   
...
;; ANSWER SECTION:
hostname.bind.          0       CH      TXT     "cdg1b.f.root-servers.org"

On voit qu'on est tombé sur l'instance parisienne de cette machine (l'ISC identifiant ses machines par le code à trois lettres de l'aéroport international le plus proche, ici Roissy / CDG).

Mais cette méthode, qui n'avait jamais été normalisée ou documentée a ses limites, que décrit notre RFC :

• Elle est spécifique, y compris dans son nom, à BIND (mais son concurrent NSD la met également en œuvre, vous pouvez tester avec k.root-servers.net, également anycasté et utilisant NSD).
• Et, surtout, elle nécessite une requête séparée, qui n'arrivera pas forcément au même serveur de noms que la requête originale (le routage ayant pu changer pendant ce temps).

Notre RFC pose donc le cahier des charges pour un remplaçant. Celui-ci devra :

• Garder une excellente propriété de la solution actuelle, le fait qu'elle fonctionne sur le DNS et ne nécessite donc pas d'ouvrir un nouveau port dans le coupe-feu ou d'installer un logiciel supplémentaire,
• Mais faire en sorte que l'identification du serveur passe désormais dans la même session.

Un projet existe déjà pour ce nouveau système, utilisant EDNS (RFC 6891). Adopté par l'IESG, il n'est pas encore publié en RFC.

Le protocole BGP distribue aujourd'hui des centaines de milliers de routes dans tout l'Internet. Spécifié uniquement pour IPv4 à l'origine, BGP peut aussi servir à d'autres protocoles, comme IPv6.

BGP est le seul protocole de routage utilisé aujourd'hui sur l'Internet pour échanger des routes entre opérateurs. Ce protocole, normalisé dans le RFC 4271, n'était à l'origine prévu que pour IPv4. L'Internet d'aujourd'hui compte de plus en plus de routes IPv6 et il était donc nécessaire de pouvoir également les distribuer. Même chose pour les labels MPLS (RFC 3107). BGP est donc devenu multi-protocoles avec le RFC 2283 puis avec le RFC 2858, dont notre RFC est le successeur.

À spécifier, cela va vite et le RFC est très court. Deux nouveaux attributs BGP, MP_REACH_NLRI et MP_UNREACH_NLRI apparaissent donc pour porter des routes indépendamment du protocole. Chaque route est marqué avec le type d'adresse (AFI, pour Address Family Identifier) utilisé, par exemple 2 pour IPv6, et les adresses sont donc de longueur variable, dépendant du type. Un marqueur supplémentaire, SAFI (Subsequent Address Family Identifier), indique le type de routage considéré (par exemple unicast). Les valeurs possibles du SAFI sont dans un registre IANA.

Les changements par rapport au prédécesseur, le RFC 2858 ne sont que de détail, par exemple la suppression d'une option pour un routage combiné de l'unicast et du multicast, option qui n'a jamais été réellement déployée.

Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre (remplacé depuis par le RFC 5731), 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 4930, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type (EPP dit le mapping) 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 3731 mais ce ne sont que des modifications de détail. Lui-même a ensuite été remplacé par le RFC 5731.

Voici un exemple d'une réponse à une requête <epp:info> pour le domaine example.com :

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

Les registres, par exemple les registres de noms de domaine fonctionnent parfois sur un modèle registry/registrar c'est-à-dire, où le client final doit passer par un intermédiaire, le registrar pour enregistrer son nom de domaine. Le registrar souhaite en général avoir un protocole de communication avec le registre afin d'automatiser ses opérations, dans son langage de programmation favori. EPP, décrit dans ce RFC, est un de ces protocoles d'avitaillement (provisioning, et merci à Olivier Perret pour la traduction). (EPP n'emploie pas le terme de registrar mais celui de sponsoring client, plus neutre. EPP peut donc en théorie être utilisé en cas de vente directe.)

Notre RFC remplace le premier RFC sur EPP, le RFC 3730, mais les changements sont mineurs, essentiellement des bogues qui se produisent assez rarement dans la pratique, même si le registre du .eu a réussi à violer la norme XML en câblant en dur le préfixe d'espace de noms epp dans leur code, ce qui a nécessité une modification dans la section 2 de notre RFC pour rappeler que c'était interdit.

À son tour, notre RFC 4930 a été remplacé, par le RFC 5730, là encore avec peu de modifications.

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

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

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

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

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

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

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

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