Mon blog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

% rnv xmlsieve.rnc test2.xml
test2.xml

Parfait, il est bien valide.

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

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

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

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

% xsltproc xml2sieve.xslt test.xml

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

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

Il existe des plans d'URI pour tout. Alors, pourquoi pas pour les SMS ? C'est ce que prévoit notre RFC qui ajoute la possibilité d'avoir des liens hypertexte dont la sélection déclenche l'envoi d'un SMS...

D'abord, avec la section 1 du RFC, révisons : le réseau GSM est un réseau de téléphonie mobile très répandu dans certaines parties du monde (en Europe, par exemple), et fonctionnant sur des fréquences comme 900 Mhz, 1800 Mhz, etc. SMS est un service des réseaux GSM qui permet d'envoyer de courts messages texte. Son succès social a été tel que des réseaux non-GSM comme le RNIS l'ont également adopté, et un service de microblogging comme Identi.ca a emprunté bien des points au SMS, comme la longueur maximale d'un message.

Le SMS a en effet une taille maximale, fixée selon des critères un peu complexes (section 1.2.1 du RFC). La norme dit « 160 caractères » mais, limités à sept bits, ce ne sont pas des caractères Unicode. La vraie limite est en fait de 140 octets. Il existe diverses méthodes (typiquement non-standards) pour stocker dans ces 140 octets de l'UTF-16 ou bien des choses rigolotes comme les émoticons.

La délivrance des SMS se fait via un, et parfois plusieurs, serveur, le SMSC (Short Message Service Center).

La section 1.2.4 explique ensuite l'intérêt de spécifier un plan sms pour le Web. Ce dernier est aujourd'hui l'interface principale d'accès à l'information, notamment grâce à l'invention des URI. Parmi les URI, mailto est devenu très populaire, en permettant d'envoyer un message « depuis » une page Web. L'idée est donc de faire pour les SMS ce que mailto: a permis pour le courrier. (Il existe aussi un tel: pour le téléphone, cf. RFC 3966.)

Le RFC note toutefois que, si la plupart des navigateurs permettent d'associer un programme externe à un contenu de type MIME inconnu (sans toucher au code source du navigateur), cette possibilité n'existe en général pas pour les plans d'URI inconnus. Ceux-ci nécessitent en général de modifier le navigateur, ou bien d'utiliser ses fonctions d'accueil de greffons (c'est le cas de Firefox).

Bref, venons en maintenant à la vraie normalisation ; la section 2 définit ce nouveau plan sms. Il s'appuie sur le RFC 3966 pour la syntaxe des numéros de téléphone (en incluant l'erratum 203). La syntaxe formelle des nouveaux URI figure en section 2.2. Un exemple simple est sms:+15105550101. Un exemple plus complexe est sms:+15105550101?body=hello%20there (d'autres exemples figurent en section 2.5). Ce second exemple illustre l'utilisation de champs (ici, un seul champ, body, qui indique le contenu du message) permettant d'étendre l'URI. Pour que l'ajout de champs ultérieurs soit possible, le RFC impose que les champs inconnus soient ignorés.

Pendant qu'on parle du champ body, la section 2.2 précise également son encodage : de l'UTF-8 avec le surencodage pour-cent, comme l'illustre le %20 ci-dessus.

Un RFC décrivant un plan d'URI n'est pas complet sans le formulaire d'enregistrement formel (RFC 4395, section 5.4), qui figure en section 3. sms: est donc désormais dans le registre IANA.

Et naturellement, le RFC se conclus par la section sur la sécurité (section 4), qui rappelle notamment que, l'envoi d'un SMS étant souvent payant pour l'abonné, le navigateur ne doit pas déclencher cet envoi sur un simple clic, il doit demander confirmation ! D'autre part, cette section attire l'attention des utilisateurs sur le fait que le SMS ne présente aucune confidentialité et aucun mécanisme d'authentification, contrairement au courrier électronique.

Depuis que la technique est utilisée pour rendre la vie plus pénible, il y a des résistances. Telle est, très résumée, la ligne directrice de ce livre de François Jarrige. Si sa sympathie va plutôt à ces résistants, l'intérêt principal de ce court livre est surtout de dresser un tableau complet, quoique très résumé, des principaux épisodes de la résistance au « monstre mécanique ».

Il est facile (et fréquent) de ricaner devant ces opposants, de les disqualifier en les traitant de « luddites » et de faire remarquer que, dans tous les cas, ils n'ont pas arrêté le progrès, qui a fini par écraser (avec toutefois l'aide de la police et de l'armée) toute résistance. Il y aurait beaucoup à dire sur le thème « Avaient-ils raison ou pas ? » Après tout, dans presque tous les cas de révolte « anti-machines », l'introduction des machines permettait effectivement un recul considérable des conditions de vie et de travail des révoltés. Il ne s'agissait nullement de la lutte du progrès contre le conservatisme mais bien de lutte des classes. Mais ce n'est pas l'angle choisi par François Jarrige qui cherche plutôt à montrer que les révoltes sont anciennes, qu'elles ont toujours existé et que l'utilisation des techniques modernes pour accroître l'exploitation a toujours suscité des résistances.

Il part donc de l'antiquité (les Grecs antiques refusaient-ils le progrès technique ?), puis continue avec le Moyen Âge (refus des grands moulins, non pas par pur aveuglément d'ignorants mais parce que ces moulins, centralisés et chers, marquaient surtout une conquête du pouvoir seigneurial ou marchand et une perte d'indépendance pour les familles paysannes).

Mais c'est évidemment la révolution industrielle qui mettra en évidence la « résistance au monstre mécanique ». Ladite révolution provoquera les misères les plus inouïes et aussi les révoltes les plus vives, en général réprimées dans le sang.

Au vingtième siècle, il y a moins d'opposition violente au déploiement de nouvelles techniques mais des inquiétudes nouvelles, par exemple face aux risques du nucléaire, ou des manipulations génétiques. Contrairement à ce que prétend souvent la propagande scientiste, les opposants à ces techniques ne sont pas forcément des abrutis ignorants. Souvent, ils sont eux-mêmes experts dans les techniques dont ils dénoncent les risques. (Une critique au passage : François Jarrige mélange, aux vrais opposants, des cinglés comme Theodore Kaczynski dont le discours pseudo-intellectuel se réduisait à des longs délires. Citer cet assassin dans la longue lignée des résistants au monstre mécanique affaiblit sérieusement le discours.)

À toutes les étapes de cette résistance, les pouvoirs en place, drapés derrière l'argument du progrès, ont utilisé la force et tenté de ridiculiser les opposants en leur opposant l'inévitabilité du progrès. C'est oublier que le progrès n'est pas une entité douée d'autonomie : chaque déploiement d'une technique a été décidé et exécuté par des hommes, qui ont fait le choix d'une certaine direction, en fonction de leurs intérêts. D'autres choix auraient été possibles même si, la plupart du temps, même cette idée de choix est écartée d'un revers de main.

Un serveur réseau connecté à l'Internet doit être robuste car il va voir des tas de paquets mal formés (soit par accident, soit par méchanceté) et ne devra pas planter, encore moins permettre une attaque. Un des outils pour tester facilement la robustesse d'un serveur est Scapy. Voyons son application à des serveurs DNS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Le protocole IPv6 étant très loin d'une connectivité complète dans l'Internet d'aujourd'hui (un très grand nombre d'opérateurs et de fournisseurs d'accès ne sont toujours pas capables de router de l'IPv6, malgré l'épuisement prochain des adresses IPv4), il faut souvent passer par des tunnels pour pouvoir faire de l'IPv6. Ces tunnels peuvent être configurés manuellement mais il peut être plus pratique de disposer d'un protocole qui permet aux serveurs de tunnels d'indiquer aux clients les paramètres de la connexion (comme avec PPP ou DHCP). Cela permet d'avoir des paramètres dynamiques (la section 3 liste les avantages de TSP). C'est un tel protocole que normalise ce RFC. (L'idée de base avait été présentée dans le RFC 3053.)

TSP (Tunnel Setup Protocol) permet donc à un client de demander un tunnel à un serveur et celui-ci, s'il est d'accord, va répondre avec les paramètres du tunnel, comme l'adresse IP.

Comme résumé dans la section 2 de notre RFC, TSP fonctionne au dessus de XML, lui-même au dessus de TCP ou UDP. Les paramètres qu'on peut négocier entre le client et le serveur sont, par exemple :

• l'authentification (certains serveurs peuvent accepter des accès anonymes mais pas tous),
• l'encapsulation, TSP permet de faire un tunnel IPv6-dans-IPv4, le cas le plus courant (RFC 4213), mais aussi IPv4-dans-IPv6 et même IPv6-dans-UDP-dans-IPv4 pour pouvoir contourner les NAT (et leur présence peut être détectée automatiquement, cf. section 2.1).
• les adresses IP utilisées,
• les serveurs DNS, aussi bien le résolveur à utiliser que les serveurs faisant autorité pour ip6.arpa, pour le préfixe délégué par le tunnel.

En toute rigueur, TSP n'implique pas que le serveur TSP soit également l'extrémité du tunnel. C'est le mode le plus simple (figure 2 dans le RFC) mais le serveur TSP peut être aussi un courtier (broker), négociant des paramètres pour le compte du serveur de tunnels (figure 1 dans le RFC et section 4.1 sur la terminologie). Le protocole de signalisation (pour se connecter au courtier) n'est pas forcément le même que le protocole du tunnel.

Le protocole complet est décrit dans la section 4. Le protocole est fort simple, le client TSP se connecte, s'authentifie, envoie sa demande et obtient une réponse. La demande est codée en XML, la réponse est précédée d'un code à trois chiffres résumant le succès ou l'échec (voir annexe B pour une liste de ces codes numériques ).

Le client choisit de se connecter au dessus d'un des protocoles indiqués dans la section 4.4.1. Comme les autres exemples ultérieurs, l'exemple ici est pris sur le fichier de configuration du client TSP gw6 (qu'on obtient en s'inscrivant à leur service) pour Linux. Si on trouve dans gw6c.conf :

tunnel_mode=v6v4

cela indique que le client va se connecter au serveur en TCP (port 3653) avec le protocole IPv4, pour créer un tunnel IPv6. (La liste de toutes les méthodes figure dans le registre IANA, décrit en section 7).

L'authentification figure en section 4.4.2. Elle utilise SASL. Elle se configure, par exemple, ainsi :

userid=mapetiteentreprise
passwd=monsupermotdepasse

Quant à la demande et à la réponse, elles sont décrites en section 4.4.3. Voici un exemple, vu dans le journal du client gw6 :

2009/07/20 08:43:04 I gw6c: Sent:
2009/07/20 08:43:04 I gw6c: Content-length: 217<tunnel action="create" type="v6anyv4" proxy="no"> 
     <client>  <address type="ipv4">208.75.84.80</address>  <keepalive interval="30">    
             <address type="ipv6">::</address>  </keepalive> </client></tunnel>
2009/07/20 08:43:04 I gw6c: Received:
2009/07/20 08:43:04 I gw6c: 200 Success<tunnel action="info" type="v6v4" lifetime="604800">  
       <server>    <address type="ipv4">64.86.88.116</address>    
                   <address type="ipv6">2001:05c0:1000:000b:0000:0000:0000:0218</address>  </server>
       <client>    <address type="ipv4">208.75.84.80</address>    
                   <address type="ipv6">2001:05c0:1000:000b:0000:0000:0000:0219</address>    
                   <address type="dn">bortzmeyer.broker.freenet6.net</address>    
                 <keepalive interval="30">      
                 <address type="ipv6">2001:05c0:1000:000b:0000:0000:0000:0218</address>    
                 </keepalive>  </client>
      </tunnel>

Une fois que la demande est acceptée, le tunnel est typiquement configuré automatiquement par le logiciel client (section 4.5), qui se charge d'exécuter les ifconfig appropriés. On voit alors son tunnel, ici en 2001:5c0:1000:b::219 :

sit1      Link encap:IPv6-in-IPv4  
          inet6 addr: fe80::d04b:5450/64 Scope:Link
          inet6 addr: 2001:5c0:1000:b::219/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1280  Metric:1
          RX packets:5069 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5015 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4526230 (4.3 MiB)  TX bytes:487854 (476.4 KiB)

Les éléments XML échangés sont décrits dans la section 4.7 (et la DTD complète en annexe A). Par exemple, l'élément <server> (section 4.7.3) contient deux éléments, <address> et <router>, qui indiquent les caractéristiques IP de l'extrêmité du tunnel.

Plusieurs exemples de requêtes TSP figurent dans la section 5. Avec tspc, on peut aussi les obtenir en utilisant l'option -vvv :

# /usr/sbin/tspc -vvvvv
Connecting to server with tcp
Using TSP protocol version 2.0.0
Establishing connection with tunnel broker...
Getting capabilities from server
Connection established
Authenticating bortzmeyer
Using authentification mecanism DIGEST-MD5
Authentication success
Asking for a tunnel
sent: Content-length: 252
<tunnel action="create" type="v6v4" proxy="no">
 <client>
  <address type="ipv4">192.134.7.249</address>
<keepalive interval="30"><address type="ipv6">::</address></keepalive <router>
   <prefix length="48"/>
  </router>
 </client>
</tunnel>
...

Aujourd'hui, il existe deux implémentations libre du client, gw6c, déjà cité et tspc. Des exemples plus concrets de configuration peuvent être trouvés dans mon article sur les serveurs de tunnel.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ce RFC a été pendant longtemps la référence pour la description d'informations gérées sur un réseau. Le SMI est le cadre général, dans ce cadre on écrit des MIB, on les interroge avec SNMP (RFC 1157) et voilà la gestion de l'Internet. Aujourd'hui, la dernière norme sur le SMI est la version 2, décrite dans le RFC 2578 mais notre RFC 1155 est toujours en statut standard (numéro 16) et toujours d'actualité puisque toutes les MIB n'ont pas toutes été mises à jour (c'est le cas de la MIB-II, la MIB de base, normalisée dans le RFC 1213, même si elle a connu des évolutions comme celle du RFC 2863).

Notre RFC décrit donc le SMI, le cadre de base de la description d'informations qu'on gère, typiquement avec SNMP (à l'époque où a été fait notre RFC, il était encore obligatoire de citer CMIP, le concurrent ISO qui n'a jamais connu de déploiement significatif). Il y a longtemps que la ligne officielle de l'IAB est que tout protocole Internet soit gérable, et aie donc une MIB, écrite selon les règles du SMI (section 1).

La section 2 donne les principes du SMI : séparation de la description des objets et du protocole d'accès (c'était nécessaire à l'époque, pour les raisons politiciennes qu'explique bien l'un des auteurs du RFC 1155, Marshall Rose, dans son livre The Simple Book), et utilisation d'un sous-ensemble de ASN.1 pour décrire les classes d'objets gérés.

Un autre principe important, est celui de la simplicité. Bien qu'on puisse se demander s'il est vraiment atteint, il faut se rappeler que les propositions concurrentes, à l'époque, étaient bien pires. Le RFC note avec modestie qu'on ne sait pas encore bien maitriser la gestion des réseaux et qu'il faut donc éviter de tout figer par des normes trop strictes (et, effectivement, en 2010, la question est toujours ouverte, comme le montre le RFC 5706). De même, le SMI se veut extensible, car tout ne peut pas être prévu à l'avance

Et, pour ceux qui s'intéressent à l'histoire, outre l'excellent livre de Rose déjà cité, il y a les RFC 1052 et RFC 1109.

Avec la section 3, on en arrive au concret : qu'est-ce qu'une MIB et qu'est-ce qu'on met dedans ? La MIB, écrite en ASN.1, rassemble des objets qui ont tous un nom, plus exactement un OBJECT IDENTIFIER (OID, section 3.1). Ce nom est une suite de chiffres, alloués hiérarchiquement (ce qui garantit l'unicité). Certains de ces chiffres ont aussi parfois une étiquette en lettres. Ainsi, le nœud 1 est étiquetté iso et géré par l'ISO. Tous les objets Internet sont sous le sous-arbre 1.3.6.1 (3 étant alloué par l'ISO à d'autres organisations et 6 étant le DoD qui financait le projet, 1 revenant à l'IAB). En ASN.1, cela se dit :

internet    OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) 1 }

et les objets officiels sont sous le sous-arbre 1.3.6.1.2. La MIB-II du RFC 1213 est ainsi 1.3.6.1.2.1. Pour prendre un exemple d'objet, ifOperStatus, l'état effectif d'une interface réseau (par exemple une carte Ethernet) est { ifEntry 8 }, c'est-à-dire 1.3.6.1.2.1.2.2.1.8 puisque ifEntry était 1.3.6.1.2.1.2.2.1 (il faut se rappeler qu'une MIB est arborescente). Chaque interface réseau recevra ensuite un OBJECT IDENTIFIER à elle, 1.3.6.1.2.1.2.2.1.8.1, 1.3.6.1.2.1.2.2.1.8.1, etc. Voici un exemple vu avec snmpwalk (-O n lui dit d'afficher les OID, pas les étiquettes), sur une machine qui a quatre interfaces réseaux dont deux fonctionnent :

% snmpwalk -v 1  -O n -c tressecret 192.0.2.68 1.3.6.1.2.1.2.2.1.8
.1.3.6.1.2.1.2.2.1.8.1 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.2 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.4 = INTEGER: down(2)

Sans -O n, on aurait eu :

% snmpwalk -v 1   -c tressecret 192.0.2.68 1.3.6.1.2.1.2.2.1.8
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: up(1)
IF-MIB::ifOperStatus.3 = INTEGER: down(2)
IF-MIB::ifOperStatus.4 = INTEGER: down(2)

Si 1.3.6.1.2 désigne les objets « officiels », 1.3.6.1.3 (section 3.1.3 du RFC) est pour les expérimentations et 1.3.6.1.4 pour les objets privés et 1.3.6.1.4.1 pour les objets spécifiques à une entreprise (section 3.1.4 du RFC). Par exemple, si Netaktiv a obtenu le numéro 9319, ses objets seront sous 1.3.6.1.4.1.9319.

L'objet a aussi une syntaxe (section 3., par exemple INTEGER, OCTET STRING, OBJECT IDENTIFIER ou NULL. C'est un sous-ensemble d'ASN.1 qui est utilisé pour bâtir des définitions à partir de ces types primitifs, en les organisant en séquences ou en tables (section 3.2.2). Par exemple, l'état d'une interface réseau, ifOperStatus, déjà cité, est défini par le RFC 1213 comme INTEGER. Voici la définition complète :

          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 }

Notre RFC définit aussi des types à partir de ces types primitifs, types qui pourront être utilisés par toutes les MIB. C'est le cas de :

• IpAddress (section 3.2.3.2), une OCTET STRING de quatre octets (IPv6 n'était pas encore inventé),
• Counter (section 3.2.3.3), un entier positif sur 32 bits, croissant de manière monotone modulu sa valeur maximale. Si 32 bits semblaient à l'époque permettre des valeurs énormes, c'est aujourd'hui bien trop petit. Pour une interface Ethernet 10G, le Counter ifInOctets peut atteindre sa valeur maximale en seulement trois secondes !
• Gauge (section 3.2.3.4) qui, contrairement à Counter, peut monter et descendre.

Un objet a enfin un encodage sur le câble (section 3.3) car ASN.1 ne spécifie pas comment les objets doivent être sérialisés en bits. Le SMI utilise BER.

La section 4 donne les informations qui doivent être indiquées lors de la définition d'une classe d'objets (comme ifOperStatus plus haut) : OID, bien sûr mais aussi accès (lecture seule ou bien aussi écriture), description en langage naturel, etc (la syntaxe formelle est en section 4.3). Cette section est mieux résumée par un exemple, ici tirée d'une expérience avortée, le RFC 1414 :

         identOpSys OBJECT-TYPE
                  SYNTAX  OCTET STRING (SIZE(0..40))
                  ACCESS  read-only
                  STATUS  mandatory
                  DESCRIPTION
                      "Indicates the type of operating system in use.
                      In addition to identifying an operating system,
                      each assignment made for this purpose also
                      (implicitly) identifies the textual format and
                      maximum size of the corresponding identUserid and
                      identMisc objects.

                      The legal values for the `indentOpSys' strings
                      are those listed in the SYSTEM NAMES section of
                      the most recent edition of the ASSIGNED NUMBERS
                      RFC [8]."
                  ::= { identEntry 2 }

Toutes les définitions de ce RFC, en ASN.1, sont rassemblées dans la section 6.

Tiens, Google m'a retrouvé le premier programme significatif que j'avais fait avec SNMP, en 1993 : http://www.cpan.org/scripts/netstuff/addresses.on.the.LAN.info. Ne me demandez pas les sources, ils semblent avoir été perdus.