Mon blog

Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.

RFC 4719: Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)

Date de publication du RFC : Novembre 2006
Auteur(s) du RFC : R. Aggarwal (Juniper), M. Townsley (Cisco), M. Dos Santos (Cisco)
Chemin des normes
Première rédaction de cet article le 28 décembre 2006

Le protocole L2TP était historiquement surtout conçu pour transporter du PPP. La version 3, définie dans le RFC 3931 permettant un plus grand choix de protocoles transportés, voici le moyen de transporter de l'Ethernet au dessus d'un réseau IP comme l'Internet.

Notre RFC est fort simple : une fois qu'une session L2TP est établie, on transmet simplement l'intégralité du paquet Ethernet sur ce lien L2TP. Ce protocole permet de traiter de l'Ethernet tagué (pour les VLAN) ou non.

Téléchargez le RFC 4719


L'article seul

RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Date de publication du RFC : Mars 2005
Auteur(s) du RFC : J. Lau (Cisco), M. Townsley (Cisco), I. Goyret (Lucent)
Chemin des normes
Première rédaction de cet article le 28 décembre 2006

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

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

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

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

Téléchargez le RFC 3931


L'article seul

Liste de diffusion pour le langage Cosmogol

Première rédaction de cet article le 27 décembre 2006

Étape suivante de l'évaluation du langage Cosmogol par l'IETF, une liste de diffusion a été créée à la demande de l'Area Director pour pouvoir évaluer l'intérêt porté à ce projet d'un langage de spécification de machines à états.

La liste est cosmogol@ietf.org et on peut s'inscrire ou se renseigner en https://www1.ietf.org/mailman/listinfo/cosmogol.


L'article seul

RFC 4786: Operation of Anycast Services

Date de publication du RFC : Décembre 2006
Auteur(s) du RFC : J. Abley (Afilias), K. Lindqvist (Netnod)
Première rédaction de cet article le 26 décembre 2006
Dernière mise à jour le 28 décembre 2006

L'anycast : un terme complètement inconnu il y a trois ans, qui est maintenant très souvent prononcé. Cette technique de distribution de serveurs a largement fait ses preuves et est maintenu reconnu comme « bonne pratique ».

Notons que le terme d'anycast est officiellement traduit (Journal Officiel de la République Française, 28 décembre 2006, Commissions générale de terminologie et de néologie, « Vocabulaire des télécommunications ») par « envoi à la cantonade ».

Le premier RFC a avoir parlé de l'anycast est le RFC 1546, il y a plus de dix ans. Mais la technique n'a vraiment décollé qu'à partir de la grande attaque d'octobre 2002 qui a mis en évidence la vulnérabilité des indispensables serveurs de la racine du DNS. Quelques mois après, les premiers serveurs racine anycastés voyaient le jour, nouvel hommage à la réactivité de l'Internet. La première documentation moderne était l'excellente note technique de l'ISC : Hierarchical Anycast for Global Service Distribution de Joe Abley, un des auteurs de notre RFC. Ce succès (l'attaque d'octobre 2002 ne s'est jamais reproduite) est largement dû aux efforts de l'ISC.

Le but principal de l'anycast est donc la sécurité, notamment la résistance aux attaques DoS. Cette résistance accrue est due au plus grand nombre de serveurs qui peut être déployé, grâce à l'anycast, et à la concentration des attaques dans un lieu proche des attaquants, ce qui permet de les détecter plus facilement.

En quoi consiste l'anycast ? Le principe est de disposer plusieurs serveurs, tous aptes à rendre le même service, et de permettre au client de choisir automatiquement le « meilleur ». Contrairement à la technique des miroirs, l'anycast se fait sans intervention du client. Contrairement aux systèmes de répartition de charge, la requête du client ne passe par aucune machine qui déciderait du serveur choisi. Le service de loin le plus anycasté est le DNS et la méthode la plus courante repose sur le protocole de routage BGP : le même préfixe (par exemple 192.5.5.0/24 pour F.root-servers.net) est annoncé par les routeurs de chaque site où se trouve une instance de F.root-servers.net. Le traditionnel algorithme de sélection des routes par BGP choisira l'instance anycast qui servira la requête. En général, les dites instances sont situées sur des points d'échange et l'instance anycast sert les opérateurs connectés à ce point.

Notre RFC n'explique pas comment on construit un service anycast (on trouve des informations utiles dans A Software Approach to Distributing Requests for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD ou bien sur le serveur du projet AS112). Il explique les bonnes pratiques, pour être sûr que les avantages de l'anycast l'emportent sur ses inconvénients.

Notre RFC commence donc par étudier les protocoles qui bénéficient le plus de l'anycast : le DNS, étant typiquement sans état (chaque requête est indépendante des autres) est le plus adapté et ce n'est pas un hasard s'il est le plus anycasté aujourd'hui. Les protocoles où les sessions peuvent être longues (SSH, par exemple) sont difficiles à anycaster : un changement des tables de routage et les paquets arrivent à une autre instance, qui ne sait pas comment reprendre la session.

Ensuite, le RFC examine des questions comme le placement des nœuds (instances) anycast.

Un gros morceau commence ensuite, dans les sections 4.3 et 4.4 : le routage. L'anycast peut fonctionner avec un protocole de routage externe comme BGP mais aussi avec un protocole de routage interne comme OSPF. Dans les deux cas, il faut coupler étroitement le routeur et le serveur, de façon à ce qu'un arrêt du serveur, entraine l'arrêt de l'annonce de la route. Le RFC détaille ensuite le cas de certains mécanismes comme PPLB ou comme RPF (décrit dans le RFC 3704) qui, dans certains cas très rares sur Internet, peuvent interférer avec l'anycast.

Le RFC détaille ensuite, notamment dans sa section 5, des considérations plus pratiques d'administration système : surveillance d'un service anycast (il faut surveiller chaque instance individuellement), débogage (anycast est conçu pour que les instances soient indistinguables par les clients, ce qui peut compliquer la recherche sur un problème), etc.

La sécurité étant une des principales motivations de l'anycast, on ne s'étonnera pas que le RFC se termine par une longue section sur ce sujet, qui insiste entre autres sur les risques nouveaux liés à l'anycast ; par exemple, une annonce BGP pirate (RFC 4272) sera moins facilement détectée qu'avec un service traditionnel.

Notons pour terminer que le site Web http://www.root-servers.org/ présente une liste des serveurs racines actuellement anycastés et la localisation de leurs instances.

Téléchargez le RFC 4786


L'article seul

Transformer du XML en CSV

Première rédaction de cet article le 22 décembre 2006
Dernière mise à jour le 23 janvier 2007

Issues d'une question posée sur la liste XML-fr, voici trois façons possibles de traduire un fichier du format XML vers le format CSV. Une précision, tout d'abord, puisque cet article reçoit beaucoup de visites d'utilisateur d'un moteur de recherche qui ont simplement tapé « convertir du xml en csv » dans ce dernier ; toutes ces méthodes impliquent de programmer. Il n'est pas possible de trouver un programme tout fait qui convertisse n'importe quel fichier XML en CSV, car les modèles de données sont trop différents.

Notons d'abord que le format CSV, décrit dans le RFC 4180, n'est pas structuré : on ne peut pas mettre des tuples dans d'autres tuples, contrairement à ce que permettent des formats hiérarchiques comme XML ou JSON. D'une manière générale, si un élément XML peut apparaitre plusieurs fois, la traduction en CSV va être problématique.

Prenons par exemple de fichier XML des langues parlées au Sénégal (j'ai utilisé les informations publiées par SIL). : 


<!-- http://www.ethnologue.com/ and ISO 639-2. Le nombre de locuteurs
(très approximatif) est en milliers. -->
<languages>
 <language>
  <code>wo</code>
  <name>Wolof</name>
  <name>Ouolof</name>
  <speakers>3568</speakers>
 </language>
 <language>
  <speakers>607</speakers>
  <name>Manding</name>
  <name>Mandinka</name>
  <code>man</code>
 </language>
 <language>
  <code>dyo</code>
  <speakers>293</speakers>
  <name>Jola-Fonyi</name>
 </language>
 <language>
  <code>snk</code><name>Soninke</name><speakers>194</speakers>
 </language>
</languages>

Si on veut le traduire en CSV, on devra choisir comment placer les différents noms, chaque langue pouvant en avoir plusieurs. Une solution courante est de les mettre dans une seule case, séparé par un autre séparateur (par exemple un point-virgule si le séparateur principal est une virgule).

Ici, nous allons simplifier le problème en ne mettant qu'un nom par langue : 


<!-- http://www.ethnologue.com/ and ISO 639-2. Le nombre de locuteurs
(très approximatif) est en milliers. -->
<languages>
  <language>
    <code>wo</code>
    <name>Wolof</name>
    <speakers>3568</speakers>
  </language>
  <language>
    <speakers>607</speakers>
    <name>Manding</name>
    <code>man</code>
  </language>
  <language>
    <code>dyo</code>
    <speakers>293</speakers>
    <name>Jola-Fonyi</name>
  </language>
  <language>
    <code>snk</code><name>Soninke</name><speakers>194</speakers>
  </language>
</languages>

La première technique employée sera XSLT, un langage déclaratif. Notre script sera : 


<!DOCTYPE stylesheet [
<!ENTITY newln "&#xA;">
]>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
  version='1.0'>
  
  <xsl:output method="text" encoding="utf-8"/>
  
  <xsl:template match="languages">
    <xsl:apply-templates/>
  </xsl:template>

  <xsl:template match="language">
    <xsl:apply-templates select="code"/>
    <xsl:text>,</xsl:text>
    <xsl:apply-templates select="name"/>
    <xsl:text>,</xsl:text>
    <xsl:apply-templates select="speakers"/>
    <xsl:text>&newln;</xsl:text>
  </xsl:template>

  <xsl:template match="name">
    <xsl:value-of select="text()"/>
  </xsl:template>

  <xsl:template match="speakers">
    <xsl:value-of select="text()"/>
  </xsl:template>

  <xsl:template match="code">
    <xsl:value-of select="text()"/>
  </xsl:template>

  <xsl:template match="text()">
    <!-- Ignore everything else -->
  </xsl:template>

</xsl:stylesheet>

Et son utilisation, ici avec xsltproc : 

% xsltproc -o langues.csv langues2csv.xslt langues.xml

produira : 

wo,Wolof,3568
man,Manding,607
dyo,Jola-Fonyi,293
snk,Soninke,194

Tout le monde n'aime pas XSLT. La deuxième méthode va donc utiliser un langage impératif, Python, avec le module ElementTree : 


#!/usr/bin/python

import cElementTree
import sys

if len(sys.argv) <= 1:
    raise Exception("Usage: %s xml-file" % sys.argv[0])

filename = sys.argv[1]
tree = cElementTree.fromstring(open(filename).read())
lang_elements = tree.getiterator("language")
for lang in lang_elements:
    for characteristic in lang:
        if characteristic.tag == "code":
            code = characteristic.text
        elif characteristic.tag == "name":
            name = characteristic.text
        elif characteristic.tag == "speakers":
            speakers = int(characteristic.text) * 1000
    print "%s,%s,%i" % (code, name, speakers)

Et il donnera quasiment le même fichier CSV (à part qu'on a traduit les milliers en unités).

Et si on préfère les langages fonctionnels, voici un exemple en Haskell, en utilisant la bibliothèque HaXml : 


import Text.XML.HaXml
import System
import IO

rootOf :: Document -> Element
rootOf (Document _ _ r _) = r

nameOf :: Element -> Name
nameOf (Elem n _ _) = n

contentsOf :: Element -> [Content]
contentsOf (Elem _ _ cs) = cs

textOf :: Element -> String
textOf (Elem _ _ cs) = concat (map show cs)

instance Show Content where 
   show (CString _ value) = value 
   show (CElem e) = nameOf e
   show _ = "Undefined"

showVal :: Content -> String
showVal (CElem e)= textOf e

firstChild :: Name -> Content -> Content
firstChild tagname item = head (concat (map (tag tagname) (children item)))

formatCSV :: Content -> String
formatCSV l = 
    let code = firstChild "code" l in
    let name = firstChild "name" l in
    let speakers = firstChild "speakers" l in
    showVal code ++ "," ++ showVal name ++ "," ++ showVal speakers

main = do
  myargs <- getArgs
  if (length myargs) == 0 then
     error "Usage: lang2csv xml-file"
   else
     putStr ""
  let filename = head myargs 
  f <- IO.openFile (filename) IO.ReadMode
  input <- IO.hGetContents f
  let xmltree = rootOf (xmlParse filename input)
  let languages = concat (map (tag "language") (contentsOf xmltree))
  mapM putStrLn (map formatCSV languages)

Si le fichier XML contient des caractères ennuyeux comme des vraies virgules ou comme des sauts de ligne, il faut prendre davantage de précautions.

Pour les virgules, Alain Couthures conseille :

  • D'utiliser le point-virgule comme séparateur, moins fréquent dans les données et que beaucoup de logiciels (comme Excel) acceptent.
  • D'échapper les vraies virgules. Il n'existe pas de norme pour cela mais encadrer les virgules par des guillemets semble fonctionner avec ledit Excel.
  • Sinon, de remplacer les virgules, par exemple par des points (Excel, encore lui, accepte en entrée un chiffre avec un point décimal, même dans sa version française). En XSLT, un test avec contains() permet de détecter la présence du séparateur dans la donnée et un appel à translate() permet de changer des caractères en autres, comme par exemple tous les "," en ".".

Pour les autres, le mieux est d'avoir des données en XML normalisées, conformes à un schéma strict qui interdit les espaces, les sauts de ligne, etc. C'est plus facile à dire qu'à faire : si on utilise W3C Schema ou bien RelaxNG avec la bibliothèques de types de ces W3C Schemas, on se heurte à une limite (décrite en http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#rf-whiteSpace). Ces types sont normalisés avant les tests des motifs et il n'y a donc pas moyen d'éliminer les espaces de début et de fin. Un seul type échappe à cette règle, string et le schéma RelaxNG ci-dessous l'utilise avec succès : 


# XML files that follow this schema do not create problems when
# converting to CSV
start = element languages {lang+}

lang = element language {code & name+ & speakers}

code = element code {xsd:string  { minLength = "2" maxLength = "3" 
                                    pattern = "[a-z]+"} }

name = element name {xsd:string { pattern="\S.*\S"}}

# You have to use xsd:string and not xsd:integer because integer is
# normalized so the conditions always succeed.
speakers = element speakers {xsd:string {pattern="[0-9]+"}}

Un test avec rnv détecte les problèmes facilement. Ici, ligne 8, j'ai écrit : 


  <name>
Wolof</name>

et rnv le détecte : 

% rnv schema.rnc languages.xml
languages.xml
languages.xml:8:5: error: invalid data or text not allowed
required:
        data http://www.w3.org/2001/XMLSchema-datatypes^string

Merci à Eric van der Vlist pour son aide inestimable sur ce dernier point.

On ne peut pas toujours forcer les fichiers qu'on veut convertir à être conforme à un schéma. Souvent, ces fichiers arrivent comme ils sont et on n'a pas la possibilité de réclamer. Dans ce cas, c'est le programme de conversion qui doit se charger d'éliminer ces espaces et sauts de ligne gênants. En XSLT, la fonction normalize-space est très pratique. Si je change mes templates XSLT ainsi : 


  <xsl:template match="name">                                                   
    <xsl:value-of select="normalize-space(text())"/>                            
  </xsl:template>

plus de problèmes, même si le fichier XML contient des espaces ou des sauts de ligne.


L'article seul

NCP, premier brouillon d'un nouveau protocole

Première rédaction de cet article le 20 décembre 2006

La première publication du brouillon (Internet draft) d'un nouveau protocole est toujours émouvante. Voici donc le futur cahier des charges du Nameserver Communication Protocol, un protocole d'échange de configurations entre serveurs DNS.

La version texte est sur le serveur de l'IETF et voici une version HTML.

Le cahier des charges ne sera finalisé qu'en mai 2011, avec la publication du RFC 6168.


L'article seul

RFC 4741: NETCONF Configuration Protocol

Date de publication du RFC : Décembre 2006
Auteur(s) du RFC : R. Enns, editor (Juniper)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF netconf
Première rédaction de cet article le 20 décembre 2006

Netconf est un protocole de configuration de matériel réseau (typiquement des routeurs ou des commutateurs). Ce RFC est le premier publié par le groupe de travail IETF sur Netconf. Il a depuis été remplacé par le RFC 6241.

Si on doit gérer un seul routeur, le faire à la main est raisonnable. Mais, si on doit en gérer des dizaines ou des centaines, cela devient impossible sans automatisation. Il existe depuis longtemps de nombreux outils pour gérer un grand nombre d'équipements réseaux, Rancid étant le plus connu. (L'excellent article de Joe Abley, Managing IP Networks with Free Software en donne un bon aperçu. Le RFC 3535 rend compte d'un atelier de l'IAB qui a discuté de ces questions en 2002.) Netconf vise à rendre l'écriture de ces outils plus simple.

Netconf spécifie donc un protocole de RPC permettant à un gérant (manager) de modifier la configuration de l'équipement (device) en lui envoyant du XML.

Le contenu exact de ce document XML n'est pas entièrement spécifié par Netconf car il dépend de l'équipement configuré (la section 1.1 de notre RFC explique ce point). Un langage de description des modèles, Yang (RFC 6020), existe pour décrire les possibilités.

Extrait du RFC, voici un exemple (hypothétique) où on fixe à 1500 octets la MTU de l'interface réseau eth0 : 


    <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>eth0</name>
               <mtu>1500</mtu>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

Il est difficile de ne pas penser à l'acronyme NIH en lisant ce RFC. Netconf définit un protocole de RPC alors qu'il existe déjà SOAP et XML-RPC, Netconf définit en section 6, un mécanisme d'extraction de sous-arbres XML alors que XPath existe déjà...

Il existe plusieurs mises en œuvres de Netconf en logiciel libre, voir la liste en http://www.ops.ietf.org/netconf/. Parmi d'autres, les routeurs Juniper peuvent déjà être configurés avec Netconf.

Téléchargez le RFC 4741


L'article seul

RFC 3490: Internationalizing Domain Names in Applications (IDNA)

Date de publication du RFC : Mars 2003
Auteur(s) du RFC : P. Faltstrom (Cisco), P. Hoffman (IMC), A. Costello (UC Berkeley)
Chemin des normes
Première rédaction de cet article le 18 décembre 2006

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

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

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

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

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

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

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

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

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

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

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

Téléchargez le RFC 3490


L'article seul

RFC 4693: IETF Operational Notes

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : H. Alvestrand (Google)
Intérêt historique uniquement
Première rédaction de cet article le 18 décembre 2006
Dernière mise à jour le 10 avril 2008

Ce RFC décrivait un moyen de ne pas écrire de RFC : il introduisait une nouvelle expérience, les ION, une série de documents qui aurait pu partiellement remplacer les RFC mais qui a finalement été abandonnée.

C'est une vieille blague au sein de l'IETF que de faire remarquer qu'il y aura bientôt plus de RFC consacrés aux procédures que de RFC consacrés aux protocoles. D'où l'idée d'une nouvelle série de documents, les ION (IETF Operational Notes).

En outre, le processus de publication des RFC est très lourd, et impose un passage par un organisme extérieur, le RFC editor. Les ION devaient donc être plus légers, plus faciles à publier, accessibles dans d'autres formats que le texte brut...

Mais ils seraient néanmoins plus stables qu'un Internet-draft et feraient plus autorité qu'une page Web quelconque. Chaque ION indiquait clairement quel organisme l'a approuvé (par exemple l'IESG) et quel était son numéro de version (les RFC ne sont pas versionnés, si on veut en changer un, il faut faire un nouveau RFC).

Une dizaine d'ION ont été publiés, les deux premiers ayant été : ion-ion-format sur leur format (étaient proposés le texte seul et le HTML) et ion-ion-store sur le dépôt des ION, son mécanisme d'accès (un accès Subversion était possible), ses URL, etc. L'IESG maintenait une page générale sur les IONs.

Le 11 mars 2008, l'IESG a annoncé la fin négative de l'expérience. Les IONs n'ont pas accroché et le projet a donc été abandonné, et ce RFC reclassé comme « Intérêt historique » par le RFC 6393. Les IONs existants ont été republiés sous d'autres formes.

Téléchargez le RFC 4693


L'article seul

Récupérer une zone DNS

Première rédaction de cet article le 17 décembre 2006
Dernière mise à jour le 16 décembre 2008

Il est fréquent que l'on souhaite étudier le contenu d'une zone DNS. Il existe un mécanisme standard pour les transférer (cf. RFC 5936) mais la plupart des serveurs de noms refusent désormais ce transfert. Il est donc préférable d'automatiser les essais.

Le contenu d'une zone DNS permet de savoir le nombre d'enregistrements dans la zone (par exemple, on voit que le domaine de l'ex-Yougoslavie, .yu, que l'IANA, voudrait supprimer contient encore des dizaines de milliers de domaines), permet de les étudier en détail, peut permettre de détecter des bogues. Par exemple, il y a peu, http://louvre.museum/ était inaccessible une fois sur deux car la vraie adresse IP du serveur Web avait été mise dans le fichier de zone de .museum en même temps que l'adresse IP « attrape-tout » de .museum, celle qui sert à récupérer les fautes de frappe. En récupérant le fichier de la zone .museum, le diagnostic a été bien plus facile à faire.

Mais cela peut être jugé très indiscret : on comprend que de nombreux gestionnaires de zone refusent tout accès à cette zone (c'est le cas de presque tous les registres européens). Ou qu'ils le fassent payer (c'est le cas des gros TLD commerciaux). Pour cette raison et aussi pour des raisons plus pratiques (un transfert de zone peut prendre pas mal de ressources, notamment si la zone est grosse), le transfert de zone est en général désactivé sur la plupart des serveurs de noms.

Lorsqu'on cherche à obtenir une zone, il est donc pénible d'essayer les serveurs un par un. Pour la racine du DNS, par exemple, seuls deux serveurs sur les treize acceptent aujourd'hui le transfert. D'où l'idée d'une simple automatisation, avec ce petit script shell qui s'utilise ainsi : 

% try-get-zone fr
No willing nameservers from which to transfer fr

% try-get-zone museum
Got museum from ns1.getty.edu.

Ici, je n'ai pu obtenir .fr, protégé, mais .museum est accessible.

Voici le script : try-get-zone.sh

Attention en interprétant les résultats : certains TLD comme .uk ou .jp n'enregistrent qu'au troisième niveau (co.uk ou or.uk pour les britanniques). Même si on réussit à transférer le fichier de zone du TLD, le nombre d'enregistrements n'est donc pas forcément le bon (merci à Elisabeth Porteneuve pour avoir noté ce problème dans un test précédent).

Une autre question est à garder en mémoire : s'il ne fait aucun doute que certaines zones sont transférables délibérement, dans d'autres cas, c'est simplement le responsable technique qui a fait une erreur, rendant la zone accessible sans s'en rendre compte. Il est normal dans ce cas de le prévenir...

Une autre solution, mais qui est assez « limite » est, pour les zones signées avec DNSSEC, d'utiliser le parcours de zone (zone walking). Cette technique utilise le fait que DNSSEC permet, lorsqu'un nom de domaine n'existe pas dans la zone, de récupérer le nom du domaine suivant qui existe. De proche en proche, on peut ainsi dérouler toute la zone. Cette technique peut être mise en œuvre par un script comme celui de Kim-Minh Kaplan : 


#!/bin/sh
# $Id: dnssec-walk.sh,v 1.6 2008/12/16 17:20:02 kaplan Exp $
if test $# -lt 1 -o $# -gt 2
then
    echo "usage: $0 <zone> [<resolver>]" >&2
    exit 1                                  
fi
zone=${1%.}.
resolver=
if test $# -eq 2
then
    resolver=@${2#@}
fi

pred=$zone
step=$pred
set -- `dig +short +dnssec $resolver $step NSEC`
while test "$1" != "$zone"
do
    if test -z "$1"             # Walk next if NSEC not served
    then
        label=${step%.$zone}
        step=$label-.$zone
        set -- `dig +dnssec $resolver $step NSEC | grep ^$pred.*NSEC`
        if test "$1" == "$pred"
        then
            shift
            shift
            shift
            shift
        else
            echo $1 !!!
        fi
    else  
        pred=$1
        step=$1
        echo $pred
        set -- `dig +short +dnssec $resolver $pred NSEC`
    fi                                                  
done

Elle est également implémentée dans le logiciel DNSSEC walker et aussi comme exemple ldns.

Attention, cette façon de récupérer la zone n'est probablement pas conforme aux conditions d'accès du registre. En outre, certains registres mettent en œuvre des restrictions qui empêchent le walker de fonctionner.

Un bon article sur les risques de sécurité associés au transfert de zone, avec une jolie zone ouverte pour la démonstration, est « ZoneTransfer.me ».


L'article seul

RFC 4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)

Date de publication du RFC : Novembre 2006
Auteur(s) du RFC : M. Johnston (Intel), S. Venaas (UNINETT)
Pour information
Première rédaction de cet article le 17 décembre 2006

DHCP est une technique très utilisée pour distribuer à des postes clients, non seulement une adresse IP, mais également beaucoup d'autres informations. Ce RFC précise comment utiliser les options DHCP pour transmettre l'identité PXE.

DHCP est un immense succès, très répandu aujourd'hui dans de nombreux environnements. Un simple poste client, non géré comme un serveur, reçoit presque toujours son adresse IP, l'adresse de ses serveurs de noms ou de ses serveurs de temps par DHCP. Ce protocole, spécifié dans le RFC 2131 permet de passer des options supplémentaires (RFC 2132) telles que celles listées ci-dessus.

Notre RFC spécifie une nouvelle option, qui permet aux clients de passer trois nouvelles options, liées au système PXE. Par exemple, l'option Client Machine Identifier permet au client d'indiquer son nom (s'il est configuré dans un support fiable comme une mémoire Flash), de manière plus fiable et plus pérenne que la méthode classique d'examen de l'adresse MAC.

Téléchargez le RFC 4578


L'article seul

FRnOG discute de la surréservation

Première rédaction de cet article le 14 décembre 2006

Le groupe FRnOG a eu récemment une longue et très intéressante discussion sur la surréservation, c'est-à-dire le fait pour un prestataire Internet de vendre plus que ce qu'il n'a.

Commencé comme une discussion sur la possibilité d'un CDN en France, le débat a vite tourné autour des problèmes entraînés par la surréservation. En effet, tous les prestataires Internet (FAI ou FHI) vendent plus de ressources que ce qu'ils peuvent écouler. Si chaque client tente d'utiliser ce à quoi il a normalement droit, le réseau s'écroule sous la charge.

Avant de crier au scandale, il faut bien voir qu'une telle surréservation est inévitable. Si un FAI vend une offre 10 Mb/s à 100 000 abonnés, il lui faudrait 1 Tb/s pour tout écouler, ce qui serait physiquement impossible (et financièrement impossible si on songe qu'une telle offre coûte actuellement 20 à 30 € par mois en France).

Les banques ne font pas autrement : les fonds de réserve imposés par les régulateurs sont certes plus élevés que ce que la banque garderait spontanément mais ils ne permettraient pas à celle-ci de se couvrir si tous les clients voulaient retirer leur argent en même temps.

Comme la banque, le prestataire Internet compte sur le comportement moyen de l'utilisateur. Tous ne se serviront pas de leurs 10 Mb/s au même moment. Rani Assaf, directeur technique du FAI Free, préfère parler de mutualisation ; c'est plus joli mais le principe est le même. Il explique notamment que la mutualisation se fait à plusieurs niveaux : à chaque étape de la connexion, les ressources totales sont inférieures à ce qui permettrait de servir tous les abonnés simultanément.

D'autres facteurs viennent limiter les risques : par exemple, une partie des communications sont internes au FAI et passent donc sur l'épine dorsale de son réseau, probablement plus grosse que les liens externes. Mais ce modèle a ses limites. Si les clients ne jouent pas le jeu et consomment ce à quoi ils ont droit, le réseau est saturé. Octave Klaba, directeur technique du FHI OVH argumente en ce sens : pour que ça marche, il faut que les clients se comportent comme prévu. Au nom de cet argument, il refuse qu'un gros diffuseur de vidéo s'installe chez OVH comme client ordinaire (« YouTube doit payer »).

Le même fil de discussion a également abordé d'autres sujets proches comme la « neutralité du réseau », la politique de peering ou bien la façon de faire payer les fournisseurs de contenu comme Wikipédia : doivent-ils payer pour être transportés sur les réseaux des gros FAI devenus oligopolistiques ? Donc, plein de choses à lire pour ceux qui s'intéressent à l'économie des réseaux.


L'article seul

RFC 1796: Not All RFCs are Standards

Date de publication du RFC : Avril 1995
Auteur(s) du RFC : Christian Huitema (INRIA, Sophia-Antipolis), Jon Postel (USC/Information Sciences Institute), Steve Crocker (CyberCash, Inc.)
Pour information
Première rédaction de cet article le 14 décembre 2006

Un RFC pour rappeler une règle simple : tous les RFC ne sont pas des normes.

En effet, chaque RFC a un statut, disponible en ligne ou dans le fichier texte en ftp://ftp.rfc-editor.org/in-notes/rfc-index.txt. Il peut être (liste non limitative) :

  • Standards track (sur le chemin des normes, qui compte trois étapes, Proposed standard, Draft standard et Full standard, également appelé Standard tout court), leur liste est en http://www.rfc-editor.org/rfcxx00.html,
  • Informational (pour information seulement),
  • Experimental (à utiliser avec prudence).

Le RFC 791, sur IP est évidemment Full standard (un statut très rare), comme le RFC 1034 sur le DNS ou le RFC 5234 sur ABNF. Le RFC 2821 sur SMTP n'est que proposed standard (probablement parce que personne n'a passé son temps à argumenter pour son avancement). Et notre RFC 1796 lui-même n'est que informational.

Téléchargez le RFC 1796


L'article seul

RFC 4593: Generic Threats to Routing Protocols

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : A. Barbir (Nortel), S. Murphy (Sparta), Y. Yang (Cisco)
Pour information
Première rédaction de cet article le 8 décembre 2006

Parmi tous les risques de sécurité qui touchent Internet, notre RFC s'attache à décrire ceux qui visent les protocoles de routage.

Il n'y a pas d'analyse spécifique de chaque protocole. Celle pour BGP est déà fournie par le RFC 4272. Notre RFC, au contraire, décrit des attaques génériques, avec l'espoir que des solutions génériques puissent être développées.

Comme dans toute bonne analyse de sécurité, notre RFC commence par une analyse des attaquants, de leurs motivations et de leurs capacités. Puis il décrit les conséquences possibles des différentes attaques (du DoS jusqu'au détournement de trafic vers une machine qui pourra alors s'insérer dans une communication qui ne lui était pas destinée). Enfin, la section 4 en arrive aux actions du méchant : par exemple, la falsification des données de routage, pour annoncer des routes qu'il ne gère normalement pas.

Téléchargez le RFC 4593


L'article seul

RFC 4716: The Secure Shell (SSH) Public Key File Format

Date de publication du RFC : Novembre 2006
Auteur(s) du RFC : J. Galbraith (VanDyke), R. Thayer (Canola & Jones)
Pour information
Première rédaction de cet article le 2 décembre 2006

Le protocole SSH, mis au point il y a de nombreuses années, est normalisé depuis quelque mois (RFC 4253) mais il manquait la spécification du format de fichier pour l'échange des clés. Chaque serveur SSH utilisait une forme différente.

Désormais, c'est fait et notre RFC spécifie donc comment représenter les clés publiques des serveurs SSH, afin de pouvoir les transmettre d'une mise en œuvre de SSH à une autre.

C'est un simple format bâti sur ASCII, pas bien méchant, mais qui n'est pas exactement le même que celui utilisé actuellement par OpenSSH et qui va donc nécessiter quelques adaptations. Mais Putty, lui, sait déjà utiliser ce format (ainsi que celui d'OpenSSH.)

Téléchargez le RFC 4716


L'article seul

RFC 3917: Requirements for IP Flow Information Export (IPFIX)

Date de publication du RFC : Octobre 2004
Auteur(s) du RFC : J. Quittek (NEC), T. Zseby (Fraunhofer), B. Claise (Cisco), S. Zander (Swinburne University)
Pour information
Réalisé dans le cadre du groupe de travail IETF ipfix
Première rédaction de cet article le 2 décembre 2006
Dernière mise à jour le 1 février 2008

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

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

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

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

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

Téléchargez le RFC 3917


L'article seul

Qui écrira l'épopée des immigrants d'aujourd'hui ?

Première rédaction de cet article le 1 décembre 2006

Chaque jour, des candidats à l'immigration vers les pays riches accomplissent des exploits inouïs, surmontent des épreuves terribles, se heurtent à mille obstacles, risquent dix fois leur vie et, non seulement ils ne sont pas considérés comme des héros, mais ils sont méprisés et insultés.

Avec des voyages bien moins difficiles, Ulysse ou Xénophon sont devenus immortels. Pourtant, comme le fait remarquer Jean-François Deniau dans son excellent roman, « La mer est ronde », Ulysse a mis dix ans à faire le voyage de Troie à Ithaque, voyage qui prend dix jours à un plaisancier amateur. Et Xénophon était un mercenaire vaincu, qui a su transformer par son talent de conteur, un engagement douteux et une retraite devant l'ennemi, en un exploit inoubliable.

Pourquoi personne n'a t-il encore écrit l'Odyssée ou l'Anabase des immigrés qui tentent la traversée du Sahara, puis celle de la Méditerrannée ou de l'Atlantique ? Ce n'est pas par manque d'épreuves, de tempêtes, de méchants brutaux recontrés sur le chemin. Est-ce simplement parce que les protagonistes de ces voyages ne sont pas des Européens mâles et morts ?

[À propos de littérature, notez un excellent roman sur ce sujet, « Eldorado » de Laurent Gaudé.]


L'article seul

Sécuriser le DNS, les deux approches

Première rédaction de cet article le 28 novembre 2006
Dernière mise à jour le 5 juin 2009

Presque toutes les applications de l'Internet dépendent du DNS. Pourtant, ce protocole n'est absolument pas sécurisé et il est relativement facile d'y injecter de fausses données. Il existe deux approches (pas forcément concurrentes) pour sécuriser le DNS : signer cryptographiquement les données et s'assurer que la réponse vient bien du serveur interrogé.

Les failles du DNS, en matière de sécurité, sont bien décrites dans le RFC 3833.

La seule manière fiable de sécuriser la distribution des données DNS est clairement la signature cryptographique, qui fournit une authentification forte des données. La norme pour cela se nomme DNSSEC (RFC 4033 et suivants). DNSSEC résout complètement le problème de l'injection de fausses données dans le DNS, et ceci indépendamment du serveur qui a répondu à la requête. Cela permet même d'abandonner le traditionnel système des serveurs « faisant autorité » au profit de systèmes de résolution peer to peer comme CoDoNS (CoDoNS impose d'utiliser DNSSEC).

Mais, en pratique, DNSSEC est très peu déployé (certains TLD sont signés mais quasiment aucun serveur récursif ne valide avec DNSSEC). C'est en partie dû au fait que, si le protocole est stable et correct, les problèmes pratiques ont été peu étudiés :

  • Comment remonter l'information aux applications (getaddrinfo ne le permet pas actuellement) ? Le résolveur DNS doit-il prendre des décisions et prétendre qu'un domaine n'existe pas si la vérification de la signature a échoué ? (Ce que font BIND ou Unbound par défaut.)
  • Qui a la légitimité politique et technique pour signer la racine ? (D'où le système DLV, dans le RFC 4431.)
  • Qui va assurer le support utilisateurs avec tous les problèmes que crée en général le déploiement d'un nouveau système de sécurité (clés perdues, clés qui expirent, comme cela s'est produit plusieurs fois sur les bancs de test où ne participaient pourtant que des experts, bogues logicielles, domaines parfaitement légaux qui deviennent « invalides » par suite d'un problème de signature), etc.

D'où l'intérêt de ne pas laisser tomber l'autre approche : vérifier que l'information vient bien du serveur « officiel ». C'est une authentification faible mais, en pratique, elle résoudrait bien des problèmes. En termes techniques (voir par exemple le RFC 3552), il s'agit de protéger le canal, DNSSEC protégeant le message. Bien sûr, protéger le canal ne sert pas à grand'chose si l'un des serveurs intermédiaires ment (c'est le cas des serveurs récursifs de beaucoup de FAI). Mais cette sécurité, complémentaire de celle qu'offre DNSSEC, est typiquement plus simple à déployer.

Il y a très longtemps, la plupart des serveurs de noms acceptaient n'importe quelle réponse, même « martienne » (une réponse martienne est une réponse à une question qu'on n'a pas posée). Il était donc facile de les tromper. Peu à peu, les implémentations du DNS sont devenues plus paranoïaques, en partie sous l'influence de Daniel Bernstein, dont l'épouvantable caractère et l'impossibilité à travailler avec les autres ne doivent pas faire oublier le rôle positif dans la compréhension des problèmes de sécurité du DNS (utilisez avec précaution ce que vous trouvez sur son site Web : il y a beaucoup d'énormités). C'est par exemple Bernstein qui a conceptualisé l'importance de ne pas accepter les données hors-bailliage, c'est à dire servies par un serveur qui n'a pas autorité pour la zone : par exemple, la réponse d'un serveur de .fr incluant des adresses IP d'une machine en .net. Ces principes ont été mis en œuvre dans beaucoup de logiciels, comme BIND.

Il est donc plus difficile aujourd'hui de tricher (spoofing) mais les résolveurs DNS ne mettent pas encore tous en œuvre toutes les recommandations qui figurent dans le RFC 5452. S'ils le faisaient, en pratique, nous aurions moins besoin de DNSSEC, et moins rapidement.


L'article seul

Le format sitemap

Première rédaction de cet article le 22 novembre 2006

Il y avait traditionnellement plusieurs formats pour indiquer aux moteurs de recherche les informations à indexer et à quel rythme. Désormais, Yahoo, Google et MSN ont annoncé qu'ils s'étaient mis d'accord sur un format commun, « sitemap » (http://www.sitemaps.org/).

Je ne sais pas si c'est vraiment utile (et il y a d'autres sceptiques mais, bon, ça ne coûte pas cher donc j'ai désormais installé un http://www.bortzmeyer.org/sitemap.xml, produit et validé automatiquement et donc le contenu aujourd'hui est : 


<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
      <loc>http://www.bortzmeyer.org/</loc>
      <lastmod>2006-11-22T21:58:00Z</lastmod>
      <changefreq>weekly</changefreq>
   </url>
</urlset>

L'article seul

RFC 3286: An Introduction to the Stream Control Transmission Protocol (SCTP)

Date de publication du RFC : Mai 2002
Auteur(s) du RFC : L. Ong (Ciena), J. Yoakum (Nortel)
Pour information
Première rédaction de cet article le 22 novembre 2006
Dernière mise à jour le 23 septembre 2010

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

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

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

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

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

# Bon
% checksctp                        
SCTP supported

# Mauvais
% checksctp
checksctp: Protocol not supported

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

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

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

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

Le serveur a bien reçu le message : 

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

Téléchargez le RFC 3286


L'article seul

RFC 4698: IRIS: An Address Registry (areg) Type for the Internet Registry Information Service

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : E. Gunduz (RIPE-NCC), A. Newton (Verisign), S. Kerr (RIPE-NCC)
Chemin des normes
Première rédaction de cet article le 22 novembre 2006

Le protocole IRIS, qui prétend remplacer le vénérable whois, se décline en plusieurs variantes, selon le schéma de données utilisé (et selon les requêtes spécifiques à ce schéma). Voici donc « areg », le schéma pour les registres d'adresses IP, comme le RIPE-NCC, qui a beaucoup contribué à ce RFC.

Contrairement à l'antédiluvien whois (spécifié dans le RFC 3912), IRIS permet de spécifier un schéma de données formel (spécifié en W3C Schema), garantissant ainsi qu'on pourra analyser les données sans se tromper sur leur signification. IRIS a été normalisé dans le RFC 3981 et le premier schéma de données était « dreg », pour les registres de noms de domaine, spécifié dans le RFC 3982. Les RIR sont également des gros utilisateurs de whois et il n'est donc pas étonnant qu'ils aient voulu un schéma IRIS pour leur activité.

« areg » permet donc de chercher les contacts associés à une adresse IP, ou à un système autonome, éventuellement en indiquant si on souhaite également les réseaux plus ou moins spécifiques que celui indiqué.

Téléchargez le RFC 4698


L'article seul

Fiche de lecture : Mondialisation et technologies de la communication en Afrique

Auteur(s) du livre : (sous la direction de) Annie Chéneau-Loquay
Éditeur : Karthala - MSHA
2-84586-547-3

Première rédaction de cet article le 21 novembre 2006
Dernière mise à jour le 22 novembre 2006

Annie Chéneau-Loquay avait déjà dirigé « Enjeux des technologies de la communication en Afrique » et continue à rassembler les contributions des meilleurs spécialistes du développement des NTIC en Afrique, via le programme de recherche Africanti (auquel succède le programme Net Suds).

Les contributions rassemblées dans ce livre couvrent de très nombreux aspects des NTIC. Elles sont très détaillées, parfois touffues : voici un livre dont on ne dira pas qu'il se lit « comme un roman ». Mais certaines contributions sont fascinantes comme celle Camille Lancri sur la région de Sikasso au Mali ou celle de Caroline Dulau et Annie Chéneau-Loquay sur les commerçants de Kayes au Mali ou, moins exotique pour un français (encore que...), celle de Claire Scopsi qui a étudié le monde étonnant des cyberboutiques du quartier du Chateau Rouge à Paris.

Loin des grands discours comme ceux tenus dans les réunions de l'IGF ou de NEPAD, un ouvrage qui permet de mesurer le dynamisme des africains, les difficultés recontrées et les progrès réalisés.

Le livre semble aujourd'hui être épuisé chez l'éditeur mais peut être commandé à la MSHA. Sinon, il sera sans doute bientôt en ligne.


L'article seul

RFC 4714: Requirements for IETF Technical Publication Service

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : A. Mankin, S. Hayes (Ericsson)
Pour information
Première rédaction de cet article le 18 novembre 2006

Comme le RFC 4228, ce RFC appartient au groupe des « méta-RFC » qui normalisent le processus de production des normes IETF. Ici, il décrit le rôle de l'éditeur des RFC, une fonction qui est traditionnelement distincte de celle de l'IETF.

Ce n'est pas l'IETF qui publie les RFC mais, pour des raisons historiques, une entité séparée, le RFC editor, actuellement l'ISI (et qui vient d'être récemment confirmé dans cette fonction par l'ISOC).

L'IETF n'a pas de prise directe sur cette fonction, tout au plus peut-elle en normaliser les tâches. C'est ce que fait notre RFC.

Le travail d'un éditeur de normes est à la fois le travail d'un éditeur classique (relire, corriger les fautes, publier) et un travail très spécial. Des normes comme les RFC, dont la durée de vie active se compte en dizaines d'années (comme le RFC 791) posent des défis particuliers. Il faut être conservateur dans les formats (pas question de publier les RFC dans un format lié à un éditeur de logiciels particulier, qui aura changé dix fois ce format dans les prochaines années), et très prudent à chaque étape du processus (par exemple pour vérifier le texte légal, inclus dans chaque RFC, et qui fixe les conditions d'utilisation). Lorsqu'une erreur grave survient, comme dans le RFC 4676, la seule solution est de publier en urgence un autre RFC (ici le RFC 4776).

Notre RFC décrit donc successivement toutes ces responsabilités, par exemple :

  • Relire soigneusement le texte,
  • Valider les parties qui sont écrites dans des langages formels comme ABNF,
  • Attribuer un identificateur unique à chaque RFC (c'est parfois fait avec humour, comme le RFC 1984 qui parle de l'espionnage des communications par les autorités),
  • Maintenir la liste des RFC,
  • Publier (sur http://www.rfc-editor.org/) et annoncer sur la liste adaptée,
  • Publier la liste des errata (pour les erreurs les moins graves, qui ne justifient pas la publication d'un nouveau RFC) ; on notera que c'est un point sur lequel l'actuel RFC editor est défaillant beaucoup d'errata signalés ne sont jamais publiés,
  • etc.

Téléchargez le RFC 4714


L'article seul

RFC 4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : P. Arberg (Redback), D. Kourkouzelis (Redback), M. Duckett (Bell South), T. Anschutz (Bell South), J. Moisand (Juniper)
Pour information
Première rédaction de cet article le 18 novembre 2006

Beaucoup d'utilisateurs ADSL souffrent de la limite de MTU que leur impose le protocole PPPoE. Voici une solution possible.

La plupart des utilisateurs ADSL utilisent le protocole PPPoE, décrit dans le RFC 2516, entre leur routeur et celui du FAI. Ce protocole, qui consiste à utiliser PPP au dessus d'Ethernet a un gros défaut : les 8 octets de l'en-tête PPP sont soustraits des 1500 octets maximums d'Ethernet et la MTU est donc de seulement 1492 octets. Si les machines du réseau local gardent leur MTU Ethernet par défaut, les paquets seront fragmentés et le débit chutera. Ce problème est très bien expliqué dans l'article MTU, MSS etc..., de Christian Caleca.

Il existe plusieurs solutions à ce problème. Par exemple, abaisser de force la MTU sur toutes les machines (sur Unix, cela se fait typiquement avec la commande ifconfig). Ou bien utiliser le MSS clamping qui consiste à réduire la taille des segments TCP pour qu'elle tienne dans la MTU minimum du réseau (sur Linux, cela se fait typiquement en mettant dans /etc/ppp/peers/FAI, l'option -m à pppoe, par exemple pty "pppoe -I eth1 -T 80 -m 1412").

Mais notre RFC suggère une autre approche : la plupart des équipements Ethernet acceptent en fait des paquets plus grands que les 1500 octets normalisés. Ignorons donc la norme et créons des paquets PPPoE de 1500 octets (1508 avec l'en-tête). Si l'IESG a quand même glissé un avertissement dans le RFC pour cette violation formelle de la norme Ethernet de l'IEEE, cela fonctionne et permet de résoudre le problème.

Téléchargez le RFC 4638


L'article seul

Médiane et moyenne

Première rédaction de cet article le 14 novembre 2006
Dernière mise à jour le 12 septembre 2008

Beaucoup de logiciels de test des réseaux, comme le célèbre ping, permettent de répéter le test et affichent la moyenne des résultats obtenus. C'est presque toujours une mauvaise idée, la médiane devrait être utilisée à la place. La médiane est la valeur telle qu'une moitié des mesures est située en-dessous.

Un excellent article de Stanislav Shalunov (un expert de la mesure des réseaux et un des piliers du groupe de travail IPPM de l'IETF) explique fort bien pourquoi : la moyenne a plusieurs défauts et, notamment, elle n'est pas robuste. Une seule mesure franchement hors des limites suffit à la changer beaucoup. Or, de telles mesures sont fréquentes sur Internet. Par exemple, si je mesure le RTT d'un serveur, je peux obtenir un tableau comme (3, 3, 4, 3, 198, 3, 4) (RTT en millisecondes). Sa médiane sera de 3 ms (reflétant le cas de loin le plus courant) mais sa moyenne sera complètement « faussée » par la valeur exceptionnelle de 198 ms (la moyenne vaudra 31 ms).

Si on tient à utiliser la moyenne, il faut au moins l'accompagner de son indispensable auxiliaire, l'écart-type (merci à Stéphane Bunel pour ce rappel et pour son excellente page sur la question). Une autre technique est d'éliminer du calcul de la moyenne les outliers, les valeurs qui s'éloignent « trop » de la moyenne, par exemple de plus de deux écarts-types.

Si je peux me permettre un peu de publicité, le programme echoping est un des rares programmes de mesure réseaux à afficher la médiane des valeurs mesurées (et à afficher systématiquement l'écart-type à coté de la moyenne ; quant à l'élimination des outliers, elle a fait l'objet d'un patch d'Andy Juniper, intégré depuis la version 6). Voici un exemple des résultats affichés par echoping (notez la différence entre la médiane et la moyenne, pour un site dont le temps de réponse varie considérablement) : 

Minimum time: 0.993819 seconds (258 bytes per sec.)
Maximum time: 7.264942 seconds (35 bytes per sec.)
Average time: 2.677578 seconds (96 bytes per sec.)
Standard deviation: 2.059113
Median time: 1.860476 seconds (138 bytes per sec.)

Avec la dernière version d'echoping (qui inclus le patch outlier) et l'option -N 1, cela donnerait : 

Minimum time: 0.858710 seconds (298 bytes per sec.)
Maximum time: 24.057933 seconds (11 bytes per sec.)
Average time: 4.521010 seconds (57 bytes per sec.)
Standard deviation: 6.765369
Median time: 1.488127 seconds (172 bytes per sec.)
Average of values within 1 standard deviations: 2.350241

D'autres exemples d'un tel programme sont thrulay de Stanislav Shalunov ou bien le owamp d'Internet2.

Malheureusement, les experts en réseaux ont en général une connaissance très limitée des statistiques. Pour arranger cela, une excellente source est Basic Statistics, un texte de statistiques expliquées aux ingénieurs non-mathématiciens. Pour plus de réflexions sur le manque gênant de culture statistique chez les programmeurs, j'invite à lire l'excellent article de Zed Shaw, avec plein d'exemples écrits en R.

Et pour implémenter un calcul de médiane ? echoping, écrit en C, appelle simplement qsort avant de choisir l'élément du milieu du tableau ainsi trié. Cet algorithme est en O(n*log(n)) mais d'autres algorithmes sont en O(n) (par exemple le median of medians).

Pour PostgreSQL, Sébastien Dinot a écrit une jolie implémentation, qui est utilisée pour mon système de statistiques.

Pour SQLite, j'ai trouvé la description d'une solution utilisant une extension.

L'utilisation abusive de la moyenne à la place de la médiane ne se rencontre pas uniquement dans les réseaux informatiques. On la trouve aussi souvent en politique. Par exemple, lorsqu'il faut gommer un peu les inégalités salariales, on annonce un salaire moyen car il est nettement plus élevé que le salaire médian qui est pourtant bien plus représentatif du vécu de la majorité. L'écart entre les deux nombres est d'autant plus élevé que les inégalités sont accentuées.

C'est ainsi que l'INSEE nous apprend qu'en France en 2004, le salaire moyen annuel net était de 22 193 € alors que le salaire médian (celui qui sépare les salariés en deux parties égales, ceux qui gagnent plus et ceux qui gagnent moins) était de seulement 17 802 €. Paradoxe intéressant, la grande majorité des habitants de la France vivent donc avec moins de la moyenne... C'est logique du point de vue mathématique, mais contraire à l'intuition habituelle de ce que signifie « moyen ».


L'article seul

RFC 3454: Preparation of Internationalized Strings ("stringprep")

Date de publication du RFC : Décembre 2002
Auteur(s) du RFC : P. Hoffman (IMC), M. Blanchet (Viagenie)
Chemin des normes
Première rédaction de cet article le 13 novembre 2006

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

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

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

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

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

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

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

Téléchargez le RFC 3454


L'article seul

Les formats de données structurés

Première rédaction de cet article le 9 novembre 2006
Dernière mise à jour le 28 avril 2007

Il existe une pléthore de langages pour décrire des données structurées (c'est-à-dire facilement analysables par un programme). XML est le plus connu mais il y en a d'autres.

Tout le monde a besoin d'échanger des données. L'intérêt d'un format normalisé est évident. La question est de savoir quel format. Plusieurs sont aujourd'hui répandus. La concurrence entre ces langages s'exerce sur leur popularité (XML est de loin le plus connu), sur leur expansivité (XML est sans doute celui qui nécessite le plus d'octets), sur leurs choix techniques (XML, YAML ou JSON sont tous les trois représentés en texte mais d'autres sont stockés en binaire) sur la disponibilité de bibliothèques pour les principaux langages de programmation, sur l'existence ou non d'une norme formelle, etc. Tous ceux cités ici permettent de stocker des structures de données hiérarchiques (ce que ne permettent pas les langages plus primitifs comme CSV (décrit dans le RFC 4180) ou INI, qui sont à plat).

Les principaux langages sont :

Il y a aussi des langages moins normalisés comme les S-expressions ou comme Serialized PHP, utilisé par exemple par Yahoo.

Pour illustrer les différences, prenons les mêmes données (le nombre de cafés distribués par les différentes machines de la boîte) dans les différents formats.

En XML : 


<consommations>
 <machine name="Publique">
      <expresso>4</expresso>
      <long>11</long>
      <capuccino>6</capuccino>
 </machine>
 <machine name="Recherche">
      <gratuite/>
      <expresso>25</expresso>
      <long>18</long>
      <capuccino>19</capuccino>
 </machine>
</consommations>

En JSON : 

[
  {"name": "Publique",
   "gratuite": false,
   {
      "expresso": 4,
      "long": 11,
      "capuccino": 6
   }
  }
  {"name": "Recherche",
   "gratuite": true,
   {
      "expresso": 25,
      "long": 18,
      "capuccino": 19
   }
  }
]

Notons qu'il existe des constructions XML qui ne peuvent pas se représenter en JSON. Par exemple, comme l'ordre des paires nom/valeur n'est pas significatif en JSON, cet élément XML : 


<équipe>
<employé>Paul</employé>
<employé>Amadou</employé>
</équipe>

n'est pas représentable tel quel en JSON (en XML, l'ordre est important et une traduction bête en JSON ferait perdre l'ordre entre Paul et Amadou).

En YAML (il existe de nombreuses façons de représenter ces données en YAML, le choix fait ici est donc un peu arbitraire) : 

- 
  name: Publique
  gratuite: false
  (expresso: 4, long: 11, capuccino: 6)  
- 
  name: Recherche
  gratuite: true
  (expresso: 25, long: 18, capuccino: 19)

En S-expressions : 

(
  (
    ("name" "Publique")
    ("gratuite" "false") 
    (("expresso" 4) ("long" 11) ("capuccino" 6))
  )
  (
    ("name" "Recherche")
    ("gratuite" "true") 
    (("expresso" 25) ("long" 18) ("capuccino" 19))
  )
)

Enfin, on peut noter qu'il y a en fait deux parties dans la norme XML : le modèle de données, l'infoset et la syntaxe. Certaines personnes, mécontentes de la syntaxe (par exemple parce qu'on répète le nom de l'élément dans la balise fermante) ont proposé des syntaxes novatrices pour représenter le modèle de données de XML. Aucune n'a connu de succès. Citons :

L'exemple ci-dessus ressemblerait, en SXML, à : 

(consommations
   (machine (@ (name "Publique"))
        (expresso 4)
        (long 11)
        (capuccino 6))
   (machine (@ (name "Recherche"))
        (gratuite)
        (expresso 25)
        (long 18)
        (capuccino 19)))

L'article seul

RFC 4713: Registration and Administration Recommendations for Chinese Domain Names

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : X. Lee (CNNIC), W. Mao (CNNIC), E. Chen (TWNIC), N. Hsu (TWNIC), J. Klensin
Pour information
Première rédaction de cet article le 9 novembre 2006

Les IDN, noms de domaine en Unicode soulèvent des questions particulières pour les langues chinoises. Notre RFC décrit la solution actuelle.

La norme des IDN, le RFC 3490 s'arrête aux considérations techniques. Elle ne traite pas les questions politiques comme « Faut-il que le titulaire du nom de domaine café.fr soit forcément le même que celui de cafe.fr ? » On peut estimer que ces deux noms devraient être regroupées en un lot, qui soit attribué à un seul titulaire (c'est l'approche du RFC 4290).

Ces questions sont traitées par chaque registre et le mieux est que les registres d'une même aire linguistique s'entendent. C'est ce qu'on fait les registres chinois (.CN) et taïwanais (.TW) dans ce RFC, qui décrit la méthode choisie, suivant le schéma qui avait été défini dans le RFC 3743 pour les langues asiatiques.

Notamment, il faut noter qu'il existe deux écritures des langues chinoises : la traditionnelle, surtout utilisée à Taïwan et la simplifiée, surtout utilisée sur le continent. L'Internet étant international, les auteurs du RFC ont choisi de considérer les deux écritures comme équivalentes, pour ce qui concerne les noms de domaines.

Téléchargez le RFC 4713


L'article seul

Un moteur de recherche pour mon blog

Première rédaction de cet article le 7 novembre 2006
Dernière mise à jour le 2 avril 2009

C'est évidemment très bien qu'il y aie un moteur de recherche sur ce blog. Pour cela, il y a deux solutions et j'explore ici celle d'un moteur hébergé à l'extérieur, que je n'ai finalement pas retenue.


L'article complet

RFC 4707: Netnews Administration System (NAS)

Date de publication du RFC : Octobre 2006
Auteur(s) du RFC : P. Grau, V. Heinau, H. Schlichting, R. Schuettler (Freie Universitaet Berlin)
Expérimental
Première rédaction de cet article le 3 novembre 2006

Les News ou Net News, et le réseau qui les transporte, Usenet, sont parmi les outils de communication entre humains les plus anciens sur les réseaux informatiques (y compris avant Internet). Traditionnellement, les News sont gérées de manière assez anarchique, en tout cas sans règles strictes, contrairement au DNS. Résultat, il est courant que deux serveurs de News ne soient même pas d'accord sur la question de savoir si un groupe existe. Ce RFC spécifie un mécanisme par lequel des serveurs de News peuvent communiquer la liste des groupes qu'ils gèrent.

Les News sont structurées en groupes et le schéma de nommage ressemble assez à celui du DNS, sauf que le label le plus significatif est à gauche. Par exemple fr.reseaux.internet.hebergement est un groupe de News francophone sur les fournisseurs d'hébergement Internet. Mais la grosse différence avec le DNS est qu'il n'existe pas d'autorité de gestion de la racine et que chaque serveur est libre de créer ou pas des groupes, voire des hiérarchies complètes (comme lorsqu'avait été créé la hiérarchie fr, suite à des débats forts vivants dans la communauté francophone, et malgré l'opposition d'un fournisseur, le dominant à l'époque).

Si cette souplesse présente de nombreux avantages, surtout lorsqu'on compare avec la gestion très bureaucratique du DNS par l'ICANN, elle a aussi des inconvénients. Par exemple, un groupe a pu être créé sur certains serveurs et d'autres serveurs, soit ont refusé délibèrement de le créer soit ont oublié (la création de groupes implique souvent une action manuelle). Les clients de ce serveur ne verront pas le groupe.

Notre RFC s'attaque au côté technique du problème : il spécifie un nouvau protocole, NAS (Netnews Administration System), qui permet à deux serveurs de News de s'échanger des informations sur les groupes qu'ils gèrent, ce qui leur donne une chance de pouvoir se synchroniser. On peut dire que NAS est le protocole pour transporter les métadonnées, les données, structurées selon le format indiqué dans le RFC 5536, étant transportées par d'autres moyens.

Dans ses concepts et sa syntaxe, ce protocole ressemble beaucoup à d'autres protocoles texte de l'Internet comme SMTP ou bien sûr NNTP, le protocole le plus utilisé aujourd'hui pour le transport des News.

Ainsi, notre RFC donne un exemple de la commande GETP qui permet de récupérer la description d'une hiérarchie, ici humanities pour les sciences humaines : 

GETP 0 0 0 humanities
615 data follow
...
Name: humanities
Status: Complete
Serial: 20020821094529
Description: ...

Téléchargez le RFC 4707


L'article seul

RFC 4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record

Date de publication du RFC : Février 2006
Auteur(s) du RFC : M. Andrews (ISC), S. Weiler (SPARTA)
Intérêt historique uniquement
Première rédaction de cet article le 3 novembre 2006
Dernière mise à jour le 14 novembre 2007

L'une des faiblesses les plus souvent citées du DNS est son manque de sécurité. Pour authentifier les données servies, le protocole DNSSEC a été développé, dans les RFC 4033 et suivants. Notre RFC vient d'ajouter un nouveau type de données, pour indiquer une racine de signature différente de la "vraie" racine. (Notez que ce RFC a ensuite été ramené à la catégorie « Intérêt historique seulement », en novembre 2019, et que DLV est donc abandonné depuis, voir le RFC 8749.)

DNSSEC calque sa structure sur celle du DNS : hiérarchique, avec une racine, gérée par le gouvernement des États-Unis, via l'IANA. Normalement, la racine est signée par l'IANA, qui signe les délégations des TLD qui à leur tour signent les délégations des titulaires de noms de domaine. (Ces délégations apparaissent dans les enregistrements de type DS - Delegation Signer.)

Mais cette hiérarchie pose des problèmes : que faire si l'IANA, par exemple parce que l'ICANN est bloquée par des problèmes politiciens, ne veut ou ne peut pas signer la racine ? (Aujourd'hui, la seule racine du DNS signée l'est en PGP et par Verisign, l'opérateur à qui le gouvernement états-unien a délégué la gestion technique de la racine. Elle est accessible en ftp://rs.internic.net/domain/root.zone.gz, la signature étant dans le même répertoire.)

D'ou l'idée de base de DLV (DNSSEC Lookaside Validation) : dissocier la racine du DNS et la racine de signature DNSSEC. Avec DLV, on peut créer une racine de signature en, par exemple, dlv.isc.org et la peupler d'enregistrements DLV. Si les résolveurs DNS sont configurés pour les chercher là, DNSSEC marchera bien et on aura contourné le problème policitien.

Les enregistrements DS sont donc remplacés par des DLV, spécifiés dans notre RFC, et qui ont exactement le même format. BIND les met en œuvre depuis la version 9.3.2 et 9.4.0. Voici un exemple de récupération de DLV avec dig : 


% dig DLV sources.org.dlv.isc.org.  

; <<>> DiG 9.5.0-P2 <<>> DLV sources.org.dlv.isc.org.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30687
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sources.org.dlv.isc.org.       IN      DLV

;; ANSWER SECTION:
sources.org.dlv.isc.org. 3600   IN      DLV     22107 5 2 AF12A23DFBCDB5609DCEC2C2FBD3CD65AEEFE49CBE0751C65C71C983 986B7DE5
sources.org.dlv.isc.org. 3600   IN      DLV     14347 3 2 0D5D5B209264BBA5EDAEC9B95843901073BF27F01702B144FFC1389D 747DAB7F
...

À noter que notre RFC normalise un format de données, pas la façon de l'utiliser. C'est l'objet du RFC 5074 qui, entre autres, décrit ce qui se passe si deux racines DLV coexistent, peut-être pour des parties différentes du DNS.

Téléchargez le RFC 4431


L'article seul

Eustathius, a program to generate texts from formal grammars

First publication of this article on 26 October 2006

Eustathius is a set of programs to test ABNF grammars by parsing them and generating texts which obey the grammar.

You can use it to test ABNF in documents like the RFC or to test a parser that you have written.

Eustathius can be downloaded. It will require an Haskell compiler to build.

You are free to use it, accoding to the GPL.

Here is a sample grammar (you can find many others, typically extracted from the RFCs in the tests/ directory of the distribution) of a Lisp-like programming language: 

program = expr

expr = spaces "(" spaces *(expr / term ) spaces ")" spaces

term = 1*ALPHA

spaces = *WSP

And here is the result of parsing with abnf-parse, a program of Eustathius: 

% ./abnf-parse tests/minilisp.abnf
program : expr
expr : Seq[spaces ( spaces 0*10Choice[expr term] spaces ) spaces]
term : 1*10ALPHA
spaces : 0*10WSP
...
All the rules:
expr:  (UNsafe)
term:  (Safe)
...

(Safe are the rules for which there is at least a terminal in the next N steps.)

After that, you can use Eustathius to generate sample programs, for instance to give them to your parser: 

% ./abnf-generate -s program tests/minilisp.abnf
(        (      eWbejp   (  )(   kwMRMhvamEcGMLTDWGhTlooAXHQmzmwYiqEMn
)       erDZ)LXfhB ()ZtkatUFlSZ         (yrKg    (daaLeuAxXFGZq)
) (ObMi(y       )  CoqZBW(qET  )                )               )

Remember that the ABNF grammar (specified in RFC 5234) only describes the syntax. Some semantic rules are not, or cannot be expressed in the grammar and therefore, Eustathius can produce texts which are not legal. For instance, in RFC 3339, you find a grammar to generate dates and it does not protect against months > 12, so Eustathius can do: 

 % ./abnf-generate -s date tests/date.abnf
2679-73-08

Similar or useful programs:

  • abnfgen is very similar to Eustathius. Written in C, it has interesting options which Eustathius currently does not have.
  • bnfparser (untested by me).
  • Other tools can be found at the IETF tools page.
  • Another ABNF tool in Haskell, which I did not notice before writing Eusthathius is included in hsemail.

Thanks to Kim-Minh Kaplan for his help and the discussions.


L'article seul

RFC 4186: Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : H. Haverinen (Nokia), J. Salowey (Cisco)
Pour information
Première rédaction de cet article le 24 octobre 2006

L'IETF a normalisé un cadre de définition des protocoles d'authentification, EAP (RFC 3748). Ce profil d'EAP est appliqué aux réseaux GSM (les réseaux comme UMTS ont un autre protocole).

Comme le sait tout possesseur d'un téléphone portable, l'information sur l'utilisateur n'est pas contenue dans le téléphone mais dans la carte SIM, démontable. D'où le nom de ce protocole, EAP-SIM. Défini au sein du cadre EAP, il permet d'authentifier le possesseur de la carte, via un NAI (RFC 7542).

EAI-SIM est fort complexe (le RFC fait presque cent pages) car la sécurité est un domaine délicat. Le RFC est plein de sigles issus du monde des télécoms.

EAP-SIM prévoit également l'anonymat (section 4.2.1.2) en générant un pseudonyme pour l'utilisateur.

On notera que, comme beaucoup d'autres RFC, il ne spécifie pas une norme Internet, n'ayant été publié que "pour information", après avoir été écrit par le forum 3GPP.

Téléchargez le RFC 4186


L'article seul

RFC 229: Standard host names

Date de publication du RFC : Septembre 1971
Auteur(s) du RFC : Jon Postel (University California Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC))
Statut inconnu, probablement trop ancien
Première rédaction de cet article le 24 octobre 2006

Un des tous premiers RFC à tenter d'organiser le nommage sur Arpanet, trente-cinq ans avant le SMSI.

Le premier a apparemment été le RFC 226. Mais notre RFC a deux avantages : il a été écrit par Jon Postel et il est le premier à avoir nommé une machine "SEX", des dizaines d'années avant le fiasco de .xxx, retiré sur pression des bigots (bon, je plaisante un peu, ce "SEX" faisait référence au Sigma EXperimental operating system).

Autrement, la liste est très proche de celle du RFC 226, mais plus détaillée. À l'époque, c'était le seul moyen dont disposait Arpanet, le futur Internet, pour permettre d'adresser une machine par son nom. Le DNS était encore très loin.

Téléchargez le RFC 229


L'article seul

RFC 3972: Cryptographically Generated Addresses (CGA)

Date de publication du RFC : Mars 2005
Auteur(s) du RFC : T. Aura (Microsoft)
Chemin des normes
Première rédaction de cet article le 24 octobre 2006

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

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

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

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

Téléchargez le RFC 3972


L'article seul

RFC 3779: X.509 Extensions for IP Addresses and AS Identifiers

Date de publication du RFC : Juin 2004
Auteur(s) du RFC : C. Lynn (BBN), S. Kent (BBN), K. Seo (BBN)
Chemin des normes
Première rédaction de cet article le 22 octobre 2006

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

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

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

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

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

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

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

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

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

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

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

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

Téléchargez le RFC 3779


L'article seul

Comparaison des performances XPath avec plusieurs langages

Première rédaction de cet article le 17 octobre 2006
Dernière mise à jour le 18 octobre 2006

J'ai un programme qui tourne beaucoup trop lentement. Il semble qu'une des tâches essentielles qu'il accomplit soit d'extraire des valeurs d'un document XML en utilisant XPath. Comment accélerer cette extraction ?

En matière de performances des systèmes informatiques, il ne sert à rien de spéculer, rares sont les informaticiens qui peuvent trouver, sans se tromper, quel est le goulet d'étranglement d'un programme. Il faut mesurer. L'informatique est une science expérimentale.

J'écris donc le même programme dans trois langages. Le programme va extraire le texte d'un fichier XML, en prenant en paramètre une expression XPath, ici //date/text() (le texte d'un élément XML <date>).

Le premier programme est écrit (par moi) en Python : 

% time  python xpath.py '//date/text()'  fichier.xml
2006-03-23
python xpath.py '//date/text()' fichier.xml  0.55s user 0.04s system 98% cpu 0.597 total

Son exécution complète (initialisation de Python, chargement du programme, puis du fichier XML, recherche XPath, etc) a pris plus d'une demi-seconde ! (Le temps total écoulé est affiché à la fin du résultat de time.) Ce temps a été presque entièrement consommé en temps utilisateur, donc à dérouler du code Python (le fichier XML fait 10 ko, donc peu d'entrées/sorties sont nécessaires).

Le second programme est écrit (il est distribué avec le module XML::XPath) en Perl : 

% time perl ./xpath.pl -e '//date/text()'  fichier.xml
Found 1 nodes in fichier.xml:
-- NODE --
2006-03-23
perl ./xpath.pl -e '//date/text()' fichier.xml  0.20s user 0.02s system 97% cpu 0.220 total

Il ne prend que la moitié du temps consommé par son prédécesseur.

Le troisième programme est écrit (par Aleksey Sanin, et il est distribué avec libxml2, mais je l'ai modifié) en C : 

% gcc -o xpath `xml2-config --cflags` `xml2-config --libs` xpath.c
% time ./xpath  fichier.xml '//date/text()'
2006-03-23
./xpath fichier.xml '//date/text()'  0.00s user 0.00s system 91% cpu 0.004 total

Cette fois, le temps d'éxécution est à peine visible.

Comme tous les benchmarks, celui-ci est très contestable : dans les langages comme Perl ou Python, le temps de chargement de l'interpréteur et éventuellement le temps de compilation du programme peuvent être importants et un programme qui ne fait qu'une seule recherche XPath est donc probablement peu efficace. Si on avait plusieurs recherches successives, l'écart se resserrerait sans doute. D'autre part, les performances du programme C ne doivent pas faire oublier sa longueur (cinq fois plus long que le programme Python et probablement bien plus de cinq fois plus difficile à maintenir).

D'autre part, on n'est pas obligé de faire du tout-C ou du tout-Python. Par exemple, dans ce cas, comme dans beaucoup d'autres, on peut appeler du C depuis Python (l'interface entre une bibliothèque C et un programme Python est très facile à réaliser, bien plus qu'en Perl). C'est ce que fait notre quatrième programme qui utilise les bindings Python de libxml2 : 

%  time  python xpath-libxml2.py '//date/text()' fichier.xml
2002-03-23
python xpath-libxml2.py '//date/text()' fichier.xml  0.04s user 0.00s system 96% cpu 0.041 total

On le voit, il est bien plus rapide que le programme en Python pur (mais reste plus lent que le programme en C). Si on souhaite, ce qui est mon cas, réaliser la structure principale du programme en Python, cette bibliothèque permet d'accélerer les parties les plus lentes, tout en évitant de programmer soi-même dans un langage difficile comme C.

Une autre solution très courante aux problèmes de performance, lorsque la même donnée est demandée régulièrement, est l'utilisation d'un cache. Celui-ci stocke le résultat de la requête précédente, lui permettant ainsi d'être plus rapide (si, comme c'est le cas ici, le temps d'accès au cache est faible devant le temps de calcul). C'est ce que démontre notre cinquième programme qui utilise un fichier pour stocker le résultat précédent : 

% time python xpath-cache.py '//date/text()' fichier.xml
2002-03-28
python xpath+cache.py '//date/text()' fichier.xml  0.29s user 0.03s system 99% cpu 0.325 total

% time python xpath-cache.py '//date/text()' fichier.xml
2002-03-28
python xpath+cache.py '//date/text()' fichier.xml  0.02s user 0.00s system 81% cpu 0.020 total

% time python xpath-cache.py '//date/text()' fichier.xml
2002-03-28
python xpath+cache.py '//date/text()' fichier.xml  0.01s user 0.01s system 99% cpu 0.020 total

La première requête est lente mais toutes les suivantes sont bien plus rapides. Si on pose plusieurs fois la même question, le cache peut donc apporter une solution.

Le but de cet article n'était pas de donner un conseil presse-bouton (il faut toujours réfléchir, pour le cas particulier qu'on a à traiter) mais de montrer que les différences de performances peuvent être considérables et que le choix des bonnes techniques peut sérieusement accélérer un programme.


L'article seul

E-books, pourquoi n'ont-ils pas encore décollé ?

Première rédaction de cet article le 16 octobre 2006

Cela fait longtemps qu'on parle des e-books, même si la mode semble un peu passée (elle avait culminé en 2000, même Jacques Attali s'y était mis, avec un projet fumeux et vite avorté). Pourquoi une si bonne idée n'a t-elle jamais marché ?

Comme beaucoup d'utilisateur de l'Internet, je lis beaucoup de textes trouvés en ligne et mon environnement de travail habituel, un PC, ne me convient pas forcément pour lire des textes longs. C'est en partie parce que la lecture sur écran me fatigue mais aussi parce que, contrairement à un livre-papier, le PC ne peut pas être lu couché, ou assis dans le train, ou debout dans le métro. Je souhaiterai une solution plus légère pour la simple tâche de lecture. C'est le principe du livre électronique.

Le mot e-book désigne tantôt le lecteur, l'appareil qui sert à lire les textes et tantôt les textes eux-mêmes. Comme je ne vois pas pourquoi les textes auraient besoin d'un mot spécifique (ce sont des textes, point, des textes numériques si on veut être précis), je n'emploie le mot que pour parler du lecteur.

La technique ayant beaucoup progressé, il devrait être relativement simple aujourd'hui de fabriquer un tel lecteur, ayant des propriétés analogues à celles d'un livre papier :

  • Peu cher, de façon à ce qu'une perte ou un vol ne soient pas une catastrophe,
  • Simple d'utilisation, ne nécessitant pas, par exemple, des mises à jour de sécurité,

Ces propriétés éloignent le e-book de l'ordinateur portable. Mais le e-book pourrait aussi emprunter au monde de l'informatique des caractéristiques utiles :

  • Capacité à lire différents formats de fichiers (texte seul, bien sûr, de préférence en Unicode, mais aussi PDF, HTML, etc),
  • Capacité à se connecter à l'Internet, pas uniquement au site de e-vente du vendeur du e-book mais aussi à n'importe quel serveur de fichiers (un client HTTP dans le e-book est la moindre des choses).

Alors, les e-books ont-ils ces caractéristiques ? Non. Ils sont très chers, des prix qui évoquent plutôt les PDA que les livres de poche, ils sont étonnemment pauvres en fonctions (beaucoup ne peuvent pas lire le texte seul donc, par exemple, pas les RFC). Et surtout, ils sont en général plombés par les DRM, de façon à ne pouvoir lire que les textes vendus par le cyber-boutique ayant signé des accords avec le fabricant. (Voir à ce sujet l'excellent article de Laurent Chemla.)

Pourtant, il existe sur Internet une quantité de textes dont l'accès est gratuit, et qui sont souvent, en prime, distribués sous une licence libre. Ce sont des textes techniques, bien sûr, normes, documentations, cours mais aussi des romans (comme ceux que distribuent Gutenberg et ABU) ou des articles d'encyclopédie comme ceux de Wikipédia. Uniquement avec ces textes d'accès libre, on pourrait passer 24 heures par jour à lire.

Mais les fabricants de e-books ne prennent jamais en compte cette formidable bibliothèque numérique gratuite. Ils ne communiquent que sur la possibilité de lire le dernier Tom Clancy acheté sur leur e-boutique et tellement truffé de DRM qu'il ne peut pas être prêté à un copain, et parfois même pas lu à haute voix (oui, c'est dans la licence des textes distribués par Adobe comme Alice au pays des merveilles, ouvrage pourtant dans le domaine public).

Les e-books actuels, même promus par des visionnaires auto-proclamés comme Attali sont donc des archaïsmes : ils correspondent à une époque où la culture n'était pas largement distribuée en ligne. Leur échec commercial est donc bien mérité. Malheureusement, le poids des compagnies de média est tel que, pour l'instant, aucun industriel ne s'est lancé dans un e-book ciblé spécialement pour lire les textes librement accessibles.

Au moment où je termine ce texte, le Monde publie un article sur le dernier truc de Sony, le Sony Reader. Il semble donc que le e-book revienne à la mode. Il n'y a évidemment aucun détail concret sur le site de Sony mais, selon l'article du Monde, le Sony Reader pourra lire le texte seul. En revanche, le seul mode de distribution cité est la cyber-shop de Sony, aucune allusion n'est faite à la capacité à récupérer des documents distribués sur le Web.

Notons un excellent article de Bob DuCharme sur le même sujet, critiquant un autre modèle de-book (le Kindle d'Amazon) qui a exactement les mêmes problèmes que celui de Sony. (Sans compter les pratiques dégueulasses d'Amazon qui supprime les fichiers de ses clients à distance.) Autre excellent article, celui de Steve Bellovin qui explique pourquoi il n'a pas de ebook. Cet article date originellement de 2006 mais, en 2011, la situation n'est pas meilleure.


L'article seul

RFC 1035: Domain names - implementation and specification

Date de publication du RFC : Novembre 1987
Auteur(s) du RFC : P. Mockapetris (USC/ISI)
Chemin des normes
Première rédaction de cet article le 15 octobre 2006

Couturé de cicatrices, ce RFC qui a été amendé par pas moins de vingt-six autres RFC tient toujours. "1035" est toujours la norme du DNS, un protocole sur lequel repose la quasi-totalité des applications de l'Internet. Le DNS est un des plus grands succès de l'Internet (qui se souvient aujourd'hui du ridicule X.500 ?) et notre RFC est donc une lecture indispensable.

Qui osera reprendre ces vingt-huit (avec le RFC 1034 et le 1035) documents et les consolider en un jeu de normes cohérent et à jour ? Sans doute personne, vue l'ampleur de la tâche. En attendant cette très hypothétique synthèse, prévenons tout de suite les lecteurs : lire le 1035 seul peut entrainer des problèmes.

Si son compagnon, le RFC 1034 pose les principes de base du DNS, la structure arborescente des données et le principe client-serveur du protocole, notre RFC descend, lui, dans les détails très concrets et spécifie, dans sa section 3, le format des données (resource records, les enregistrements du DNS) et dans sa section 4 celui des messages échangés entre clients et serveurs. Ces messages sont composés de plusieurs parties (la partie "Question", la partie "Réponse", la partie "Autorité", qui indique les serveurs faisant autorité pour la zone) et le résultat de la commande dig montre ces différentes sections.

Revenant sur le RFC 1034 (la séparation entre les deux RFC n'est pas toujours très logique et on est quasiment toujours obligé de lire les deux), notre RFC revient ensuite sur le format des fichiers de zone et sur l'algorithme utilisé par les logiciels.

En guise de conclusion, rappelons un avertissement : vue l'importance du DNS aujourd'hui, vue la quantité d'expérience accumulée depuis que ce protocole existe, vu le nombre de RFC qui contribuent à décrire le DNS, l'implémenteur de ce protocole ou le simple curieux qui voudrait apprendre ne doivent pas de contenter des deux RFC fondateurs mais doivent être prêts à avaler de nombreux autres textes.

Téléchargez le RFC 1035


L'article seul

RFC 4678: Server/Application State Protocol v1

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : A. Bivens (IBM)
Pour information
Première rédaction de cet article le 15 octobre 2006

Le succès de l'Internet et des service auquel il donne accés a entrainé une très forte pression sur certains serveurs populaires. Beaucoup de sites Web, comme Google ou Amazon ne pourraient plus, depuis longtemps, tenir le coup avec une seule machine, si puissante soit-elle. Aussi la plupart des gros services sont désormais répartis en plusieurs machines et c'est souvent un répartiteur (load balancer) qui assure la distribution de charge entre ces machines. Notre RFC spécifie un protocole pour piloter ces répartiteurs.

Certains protocoles ont dès le début été conçus pour que le service puisse être assuré par plusieurs machines. C'est notamment le cas du DNS, où les enregistrements de type NS (name server) sont toujours multiples (la plupart des registres, suivant le RFC 1034, exigent au moins deux serveurs). Pour les autres protocoles, une solution élégante existe, les enregistrements DNS de type SRV (server), spécifiés dans le RFC 2782, mais qui n'ont jamais été réellement déployés. Ils permettraient notamment de résoudre le problème de la répartition de charge des serveurs Web.

En attendant une solution dans le protocole, l'approche la plus répandue est de mettre un groupe, une ferme, de serveurs derrière un répartiteur. Celui-ci peut être une machine spécialisée, une boîte noire (appliance), ou bien il peut être un logiciel, comme pen. Le contrôle de ces répartiteurs se fait toujours par un protocole privé, et c'est là qu'intervient notre RFC. (Notons que les solutions comme CARP assurent la redondance mais pas vraiment la répartition de charge.)

Notre RFC (dont il faut noter qu'il est de statut Informational ce qui signifie qu'il n'est pas approuvé par l'IETF) propose donc un nouveau protocole, SASP (Server/Application State Protocol), qui sert à la communication entre un contrôleur, le GWM (Group Workload Manager) et, d'une part le répartiteur (appelé LB pour load balancer) et d'autre part les serveurs effectifs.

Les messages envoyés en SASP permettent ensuite aux acteurs (LB et serveurs) de s'enregistrer auprès du GWM et de lui indiquer leur état, ce qui permet de leur envoyer plus ou moins de trafic.

On notera enfin un point de sécurité important : SASP, conçu pour des environnements fermés (réseaux privés, probablement avec adresses IP privées et coupe-feu devant), n'a pratiquement pas de sécurité. La section 10 du RFC explique ce point et propose des solutions, typiquement l'utilisation de TLS.

Téléchargez le RFC 4678


L'article seul

RFC 4641: DNSSEC Operational Practices

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : O. Kolkman (NLnet labs), R. Gieben (NLnet labs)
Pour information
Première rédaction de cet article le 10 octobre 2006

Comme avec toute technique fondée sur la cryptographie, le protocole DNSSEC impose, non seulement des bons algorithmes et une mise en œuvre correcte, mais surtout des procédures rigoureuse et soigneusement exécutées. C'est le but de ce RFC, qui remplace le RFC 2541 et a lui-même été remplacé par le RFC 6781, et qui explique tout ce à quoi doivent s'attendre les registres qui déploieraient DNSSEC.

Notre RFC rappelle donc des concepts de base du DNS (notamment le fait que la propagation des modifications n'est pas instantanée) puis rappelle les différentes clés utilisées par DNSSEC et leurs caractéristiques souhaitables (longueur, période maximale pendant laquelle on les utilise, lieu de stockages, etc).

Il explique ensuite les considérations temporelles (DNSSEC utilise le temps et nécessite des horloges bien synchronisées, par exemple par NTP).

Enfin, le RFC étudie le rollover, le remplacement d'une clé. Les clés ne pouvant pas raisonnablement être utilisées éternellement, il faut prévoir à l'avance les remplacements périodiques et aussi, hélas les remplacements en urgence en cas de compromission. Il faut apporter beaucoup de soin à ce remplacement, si on veut éviter que, pendant une certaine période, les données publiées dans le DNS soient invalides et donc rejetées par un résolveur DNS paranoïaque (il faut publier la nouvelle clé suffisamment à l'avance pour qu'elle soit présente partout ou bien signer tous les enregistrements avec les deux clés, l'ancienne et la nouvelle).

Le DNS étant hiérarchique, il faut veiller, lors de toutes les manipulations, à bien rester synchronisé avec le gérant de la zone parente, dont les enregistrements de type DS (delegation signer) pointeront vers notre clé.

Bref, pour un registre, déployer DNSSEC, ce n'est pas uniquement signer la zone : c'est aussi mettre en place des procédures de sécurité, analogues à celle d'une autorité de certification.

Le RFC 6781 a depuis remplacé ce RFC et est donc la version actuelle sur les questions opérationnelles liées à DNSSEC.

Téléchargez le RFC 4641


L'article seul

Créer des documents XML depuis un programme

Première rédaction de cet article le 9 octobre 2006
Dernière mise à jour le 19 novembre 2008

On trouve sur le Web beaucoup plus de textes expliquant comment analyser du XML que de textes expliquant comment le produire depuis un programme. D'un côté, c'est logique : produire le XML est bien plus facile et ne mérite pas forcément de longues documentations. D'un autre côté, cela pousse certains programmeurs à ne pas faire attention et à écrire des programmes qui finissent par produire du XML mal formé.

La méthode la plus évidente pour produire du XML est d'exploiter le fait que XML est un format basé sur le texte et d'écrire donc simplement (les exemples ici sont en Python et en C mais le raisonnement est valable pour tous les autres langages de programmation) : 


print "<foo>%i</foo>" % val

Cela fonctionne, mais cela présente plusieurs inconvénients :

  • Comme on traite le XML comme du texte, il est très facile de produire involontairement du XML mal formé et rien ne permet de le détecter : print "<foo>%i<foo>" % val passera inaperçu si on ne vérifie pas le XML produit (ce qui serait de toute façon une très bonne idée).
  • Ici, le format d'expansion de val est %i, ce qui se limite aux nombres. Mais si c'était %s, qui permet n'importe quelle chaîne de caractères, on pourrait avoir des problèmes si la chaîne contenait un caractère utile à XML comme le < ou bien un caractère non ASCII qu'il faudrait penser à encoder proprement, en conformité avec la déclaration XML.

Il est donc en général préférable de produire le XML à partir d'une structure de donnés de plus haut niveau que la chaîne de caractères. Une méthode évidente est d'utiliser DOM, ici pour produire du XHTML : 


from xml.dom.ext.reader import Sax2
from xml.dom.ext import PrettyPrint
from xml import xpath
from xml.dom import getDOMImplementation
...
    blurb = u"<attention aux caractères spéciaux"
    ...
    html_result = getDOMImplementation().createDocument(
        None,
        "html",
        getDOMImplementation().createDocumentType(
           "html",
           "-//W3C//DTD XHTML 1.0 Strict//EN",
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"))
    head = html_result.documentElement.appendChild(html_result.createElement('head'))
    title = head.appendChild(html_result.createElement('title'))
    title.appendChild(html_result.createTextNode("My site: %s" % \
                                     (blurb)))
    ...
    PrettyPrint(html_result)

On crée un mémoire un arbre DOM et on l'affiche avec PrettyPrint. Par construction, il sera bien formé (mais pas forcément valide). Et DOM se chargera de l'échappement des caractères spéciaux XML. Les caractères non-ASCII seront proprement représentés (PrettyPrint semble imposer UTF-8 en sortie mais d'autres méthodes DOM comme toprettyxml() permettent d'autres représentations).

DOM n'est pas très pythonien. Cette norme est en effet conçue pour être indépendante du langage de programmation utilisé et certaines constructions sont donc plutôt déroutantes en Python, par exemple, pour créer un simple attribut, ici href : 

            link = html_result.createElement("a")
            url = html_result.createAttribute("href")
            url.nodeValue = "http://www.ietf.org/rfc/rfc%i.txt" % int(rfcnum)
            link.setAttributeNode(url)
            link.appendChild(html_result.createTextNode("RFC %i" % int(rfcnum)))

.

ElementTree peut donc être préféré. ElementTree, désormais intégré à la bibliothèque standard de Python, permet de manipuler (lire et écrire) du XML de manière plus pythonesque et donc plus natutrelle au programmeur Python. En contrepartie, il n'a rien de standard, contrairement à DOM et il faudra donc tout réapprendre si on passe à un autre langage comme Perl.

Voici un exemple analogue en ElementTree : 



blurb = u"<attention aux caractères spéciaux"

import elementtree.ElementTree as ET

html = ET.Element("html")

head = ET.SubElement(html, "head")

title = ET.SubElement(head, "title")
title.text = "Mon site: %s" % blurb

body = ET.SubElement(html, "body")

link = ET.SubElement(body, "a")
link.text = "Internet Engineering Task Force"
link.attrib["href"] = "http://www.ietf.org/"

print ET.tostring(html, encoding="UTF-8")

# elementtree.SimpleXMLWriter is an alternative, if we just want to
# write the XML. See http://effbot.org/zone/xml-writer.htm

Il existe bien sûr d'autres méthodes (par exemple, pour Python) mais je crois avoir déjà couvert trois possibilités intéressantes.

Et pour C ? Voici un exemple avec la libxml. On n'utilise pas une seule fois la syntaxe XML, c'est la routine xmlDocDumpFormatMemory qui se chargera de produire du XML légal : 


#include <libxml/parser.h>

int
main(void)
{

  xmlNodePtr root, node;
  xmlDocPtr doc;
  xmlChar *xmlbuff;
  int buffersize;
  
  /* Create the document. */
  doc = xmlNewDoc(BAD_CAST "1.0");
  root = xmlNewNode(NULL, BAD_CAST "root");

  /* Create some nodes */
  node = xmlNewChild(root, NULL, BAD_CAST "node", NULL);
  node = xmlNewChild(node, NULL, BAD_CAST "inside", NULL);
  node = xmlNewChild(root, NULL, BAD_CAST "othernode", NULL);

  /* Put content in a node: note there are special characters so 
     encoding is necessary! */
  xmlNodeSetContent(node, 
                xmlEncodeSpecialChars(doc, BAD_CAST "text con&tent and <tag>"));

  xmlDocSetRootElement(doc, root);

  /* Dump the document to a buffer and print it for demonstration purposes. */
  xmlDocDumpFormatMemory(doc, &xmlbuff, &buffersize, 1);
  printf((char *) xmlbuff);

}

Compilé avec gcc -Wall -I/usr/include/libxml2 -c create-xml.c && gcc -lxml2 -o create-xml create-xml.o, ce programme va afficher : 


% ./create-xml   
<?xml version="1.0"?>
<root>
  <node>
    <inside/>
  </node>
  <othernode>text con&amp;tent and &lt;tag&gt;</othernode>
</root>

Un programme C qui produit du XML plus complexe ? Il y a par exemple mon implémentation du RFC 5388.

Pour C, il existe également d'autres bibliothèques comme GenX ou Mini-XML.


L'article seul

RFC 4686: Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : J. Fenton (Cisco)
Pour information
Première rédaction de cet article le 9 octobre 2006

Le courrier électronique n'est pas sûr, on le sait bien. Notamment, il ne fournit pas de moyen d'authentifier l'émetteur et il est trivial d'envoyer un message prétendant venir de Nicolas.Sarkozy@poulaga.fr. Une des techniques prétendant traiter ce problème est DKIM et notre RFC décrit les risques auxquels répond DKIM et les menaces contre DKIM.

Précisons tout de suite que DKIM, contrairement à des techniques comme PGP ne vise nullement à la confidentialité des messages mais uniquement à leur authentification. DKIM, normalisé dans le RFC 6376, répond donc aux menaces d'usurpation d'une adresse. Le RFC commence par analyser les méchants : ce qu'ils peuvent faire (du script kiddie au professionnel entrainé), ce dont ils disposent (les algorithmes, par exemple, puisque la norme DKIM est disponible publiquement), ce qu'ils veulent (usurper une identité, bien sûr mais peut-être aussi réaliser une DoS en empêchant des vérifications).

L'essentiel du RFC, sa section 4, est ensuite consacrée à l'examen détaillé de toutes les attaques possibles, du vol de la clé privée à l'exploitation de limites des MUA qui n'afficheraient pas clairement le contenu qui est signé et ce qui ne l'est pas (DKIM permet de ne signer qu'une partie d'un message) ou bien qui afficheraient les parties non-vérifiées d'une adresse au même titre que les parties vérifiées (par exemple, dans l'adresse Ségolène Royal <plaisantin@hotmail.com>, seule l'adresse plaisantin@hotmail.com peut être vérifiée par DKIM, pas le nom affiché).

Beaucoup des attaques décrites ici ne sont pas spécifiques à DKIM, ni même à la cryptographie et on ne peut donc que rappeler les principes de base de la sécurité informatique, notamment le fait que le maillon faible est en général entre la chaise et le clavier...

Téléchargez le RFC 4686


L'article seul

RFC 606: Host names on-line

Date de publication du RFC : Décembre 1973
Auteur(s) du RFC : L. Peter Deutsch (Xerox Palo Alto Research Center (PARC), MAXC)
Statut inconnu, probablement trop ancien
Première rédaction de cet article le 5 octobre 2006

Ce RFC est le premier à proposer que la liste des machines de l'Arpanet soit mise en ligne, le futur HOSTS.TXT.

Avant notre RFC, plusieurs RFC (le premier étant le RFC 226) donnaient la liste exhaustive des machines de l'Arpanet, l'ancêtre de l'Internet. Ce mécanisme de distribution était lent, peu fiable et la liste, non structurée, n'était pas analysable par un programme. Notre RFC va donc proposer que la liste soit mise en ligne, dans un fichier central, écrit dans un format défini formellement. Ce sera le futur fichier HOSTS.TXT, décidé dans le RFC 608 et qui restera en vigueur jusqu'au déploiement du DNS.

Téléchargez le RFC 606


L'article seul

RFC 226: Standardization of host mnemonics

Date de publication du RFC : Septembre 1971
Auteur(s) du RFC : Peggy Karp (MITRE)
Statut inconnu, probablement trop ancien
Première rédaction de cet article le 5 octobre 2006

Nostalgie des vieux RFC écrits tout en majuscules et avec une date non compatible avec l'an 2000... Notre RFC est le premier à formaliser la notion de nom de machine, douze ans avant l'invention du DNS.

Aucun mécanisme de résolution n'est envisagé (même pas un simple fichier de correspondances comme le futur HOSTS.TXT, des RFC 606 et RFC 608, qui connaitra une grande popularité avant que le DNS ne le remplace) mais il y a une table des noms officiels et de l'adresse correspondante (stockée sur huit bits).

Voici l'intégralité de cette table, qui constitue donc tout l'Arpanet, l'ancêtre de l'Internet de l'époque : 

            HOST #             DESIGNATOR
              1                  UCLA
             65                  UCLA36
              2                  SRIARC
             66                  SRIAI
              3                  UCSB
              4                  UTAH
              6                  MULTCS
             70                  MITDM
              7                  RAND
              8                  SDC
              9                  HARV
             10                  LNCTX2
             74                  LNC360
             11                  STAN
             12                  ILL
             69                  BBN
            133                  BBNB
            144                  AMES
            145                  MITRE
            158                  TIP

Le RFC 229 écrit, lui, par Jon Postel, et plus complet ne surviendra qu'après. Au début des années 1970, plusieurs RFC prétendront être la liste complète de toutes les machines de l'Arpanet.

Merci à Olivier Ricou pour avoir déniché ce document.

Téléchargez le RFC 226


L'article seul

Arrêter d'interdire des adresses de courrier légales

Première rédaction de cet article le 4 octobre 2006
Dernière mise à jour le 13 décembre 2009

Combien de fois ai-je vu une adresse de courrier parfaitement légale être refusée par un formulaire d'inscription quelconque, en général avec une remarque désobligeante, du genre "ERREUR : Votre adresse email est invalide". À quoi est-ce dû ? Au fait que le plupart du temps, les programmeurs qui ont écrit cette vérification ne connaissent pas les règles de syntaxe des adresses de courrier et ne se rendent pas compte qu'il en existe plus de variétés qu'ils ne l'imaginent.

Lorsqu'un formulaire sur le Web vous demande d'indiquer une adresse de courrier électronique, le programme situé derrière vérifie souvent la syntaxe de ladite adresse. Bien sûr, le mieux serait de tester l'adresse, en y envoyant un mot de passe, par exemple. C'est ce que font en général les formulaires d'abonnement à une liste de diffusion. Si cette méthode est un très bon test (si le message est reçu, c'est, par définition, que l'adresse est valide), elle est plus complexe à programmer, nécessite de garder un état (ce qui a été envoyé, ce qui a été confirmé), et elle peut ennuyer le destinataire.

Aussi, le test se limite souvent à la syntaxe : on vérifie, par exemple (attention, je prends exprès un exemple complètement faux) que l'adresse correspond à l'expression rationnelle [A-Za-z0-9_\-\.]+@[A-Za-z0-9\-\.]+, qui autorise postmaster@example.org mais pas stephane+blog@bortzmeyer.org qui est pourtant parfaitement légale.

J'utilise en général des "adresses plus" comme stephane+blog@bortzmeyer.org car elles permettent facilement de trier son courrier (on la retrouve dans l'en-tête Delivered-To). Le MTA est configuré pour délivrer à la boîte dont le nom précède le signe plus (en Sieve, cela se fait avec le RFC 5233) et on peut donc créer sans formalité une infinité d'adresses. À chaque formulaire que je remplis, je laisse une adresse différente, comportant le nom de l'organisation qui gère le formulaire, ce qui me permet de savoir ensuite d'où vient l'adresse par laquelle on me joint. Ce n'est pas forcément le signe plus qui est utilisé, d'ailleurs (le MTA Postfix permet de configurer ce caractère avec l'option recipient_delimiter, MMDFutilisait le signe égal, qui a les mêmes problèmes).

Mais le résultat est que je me fais jeter par de nombreux sites Web. Par exemple, je cherchais à louer un serveur dédié Kimsufi pour l'hébergement de ce blog mais je n'ai jamais réussi à me créer un compte client chez OVH, le fournisseur, car celui-ci s'obstine à refuser mon adresse. J'ai finalement choisi SliceHost qui avait pile la même bogue, mais qui l'a corrigée en quelques heures (alors que, la plupart du temps, les rapports de bogue sur ce sujet sont ignorés).

Le manque de main d'œuvre pour le développement (une technologie comme XForms ou comme les formulaires de HTML 5 simplifiera peut-être les choses dans le futur) fait que les programmes de vérification des données saisies, qu'ils soient écrits en Javascript, PHP ou un autre langage, sont en général assez bâclés. Il est exceptionnel que leur auteur vérifie la norme qui régit la syntaxe des adresses de courrier, le RFC 5322, section 3.4. À leur décharge, il faut préciser que ladite norme est redoutable. Par exemple, toutes les adresses suivantes sont valides :

  • {tropdur}@example.org
  • c&a@hotmail.com
  • directeur@arts-premiers.museum (j'ai vu une fois un code Javascript qui vérifiait que le TLD avait moins de quatre lettres, ce qui est absurde vue l'existence de .museum ou .travel)
  • "Stephane[Bortzmeyer]"@laposte.net

Alors, quel conseil donner au programmeur ? D'abord, il faut bien voir qu'il a très peu de chances de vérifier une adresse par une simple expression rationnelle. Certes, Tom Christiansen l'a fait mais tout le monde n'est pas Tom Christiansen (lisez la très intéressante page de test des expressions). La syntaxe des adresses est décrite par une grammaire, pas par une expression rationnelle. Si on veut analyser tous les cas, il faut utiliser un vrai analyseur syntaxique. N'est-ce pas trop lourd pour une simple et vague vérification ? Dans ce cas, une approche raisonnable est de ne pas chercher à vérifier tous les cas mais de se contenter d'une vérification légère. Par exemple, le RFC 4287, qui normalise le format de syndication Atom a choisi une méthode simple et radicale : atomEmailAddress = xsd:string { pattern = ".+@.+" }. Cette expression est trop laxiste (elle accepte "foo bar[@truc.machin) mais elle attrape quand même une partie des erreurs, en ne refusant aucune adresse légale (ce que je trouve pire que d'accepter des adresses illégales). (Les pros des expressions rationnelles - comme Pascal Courtois qui m'a signalé celle-ci - auront noté que, si le moteur d'expressions est gourmand - greedy, il faut réécrire l'expression en .+?@.+.)

Pour PHP, je recommande très chaudement un excellent article de Douglas Lovell dans le Linux Journal, Validate an E-Mail Address with PHP, the Right Way, qui décrit très bien la difficulté du problème et propose des solutions. Je partage notamment son inquiétude que « There is some danger that common usage and widespread sloppy coding will establish a de facto standard for e-mail addresses that is more restrictive than the recorded formal standard. »

J'ai parlé dans cet article du cas de formulaires Web d'enregistrement, qui vous demandent votre adresse de courrier. Mais Emmanuel Haguet me signale qu'il y a plus fort : des webmails comme celui d'Orange qui refusent d'envoyer du courrier aux adresses qu'ils jugent, bêtement, non standards.

Quelques autres références intéressantes :

J'espère que cet article aura convaincu quelques auteurs de formulaires d'accepter toutes les adresses de courrier légales. Espérons. En attendant, je publie régulièrement les noms de ceux qui sont mal configurés. Il existe aussi un autre projet de publication.


L'article seul

RFC 4690: Review and Recommendations for Internationalized Domain Names (IDNs)

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : J. Klensin, P. Faltstrom (Cisco), C. Karp (Swedish Museum of Natural History), IAB
Pour information
Première rédaction de cet article le 3 octobre 2006

Les IDN ont toujours déclenché des passions et suscité des oppositions vigoureuses, notamment de la part de ceux qui regrettent que tout le monde n'écrive pas en anglais. Autant dire que ce RFC, pourtant écrit de manière très prudente et donc les aspérités ont été gommées, ne va pas passer inaperçu. Il dresse un bilan plutôt négatif des IDN et exprime de nombreuses craintes.

Après un rappel des normes existantes (les IDN ont été normalisés à l'origine dans le RFC 3490) et du vocabulaire du domaine (beaucoup de gens, à commencer par l'ICANN confondent encore langue et écriture), ainsi que la littérature existante (l'ICANN a produit des documents sans intérêt, uniquement pour tenter de faire croire qu'elle avait un rôle dans l'internationalisation de l'Internet), le RFC consacre sa section 2 à lister plusieurs problèmes.

L'équivalence de deux noms dépend du langage : est-ce que cafe.fr et café.fr sont le même domaine ? D'autres peuples d'Europe accordent une plus grosse importance aux accents que les français.

Certaines langues peuvent s'exprimer en plusieurs écritures, par exemple l'azéri. Le même mot en différentes écritures sera considéré comme différent par le DNS.

La canonicalisation des caractères par IDN peut ne pas correspondre aux attentes des utilisateurs (straße.de est canonicalisé en strasse.de).

La forme imprimée de l'IDN peut ne pas être évidente à lire. C'est le problème connu à l'IETF sous le nom de "problème du côté des bus". Une publicité comprenant un URL, chose banale aujourd'hui, pourra t-elle être lue si elle se trouve sur le côté d'un bus qui passe, sachant que de nombreux caractères se ressemblent ?

De même, certains caractères peuvent être facilement confondus (comme .py - le Paraguay et .ру - la Russie, écrit en russe avec les caractères cyrilliques). Cela peut mener à des problèmes de sécurité, par exemple en cas d'hameçonnage.

Une longue section 3 est consacrée à un problème urgent : la migration vers de nouvelles versions d'Unicode. IDN est limité à la version 3.2, mais la 5.0 est déjà sortie. Un manque de stabilité de certaines normes Unicode fait qu'IDN se limite donc à une vieille version d'Unicode, sans moyen simple de mettre à jour.

De ces questions, notre RFC tire les conclusions suivantes :

  • Nécessité de revoir la norme IDN (une révision partielle a eu lieu depuis dans le RFC 5891), notamment en passant d'un modèle "Tous les caractères sont autorisés sauf" à un modèle "Sont autorisés les caractères suivants :",
  • Étudier les solutions non-DNS (par exemple avec un couche supplémentaire dans l'interface utilisateur pour traduire .com en chinois),
  • Restrictions sur l'usage de multiple écritures dans un seul nom.

D'autres conclusions sont explicitement dirigées plutôt vers l'ICANN (notons que le RFC fait comme si l'ICANN était responsable des politiques des registres) :

  • Politiques d'enregistrement plus strictes chez les registres,
  • Politique d'introduction des IDN dans la racine du DNS (ce qu'on nomme souvent les IDN.IDN par exemple café.ré pour l'île de la Réunion).

Le RFC appelle aussi à reconsidérer le rôle (limité) du DNS et à considérer que, peut-être, les efforts d'internationalisation pourraient porter sur des solutions non-DNS, par exemple des moteurs de recherche.

Si ce RFC est très prudent dans ses recommandations (tout est présenté sous forme de question, il n'y a pratiquement pas de directive concrète qui pourrait fâcher), il appartient quand même à la vaste catégorie des textes s'inquiétant, en général assez hypocritement, des problèmes liés à IDN. La plupart de ces textes sont émis par des organismes qui ne veulent pas de l'internationalisation de l'Internet (on peut lire un bon exemple). En fait, la plupart de ces textes, tout comme notre RFC, oublient deux choses :

  • La complexité ne vient pas d'IDN ou d'Unicode, elle vient des langues humaines. Cells-ci sont très complexes, point. On peut le regretter et se dire que cela serait plus simple si tout le monde parlait anglais ou lojban mais ce n'est pas le cas. L'IETF et les autres SDO doivent faire avec.
  • La plupart de ces problèmes sont marginaux. Ils ne se produisent que dans des cas rares, avec des écritures peu courantes. Retarder les IDN à cause de problèmes aussi artificiels serait retarder une évolution de l'Internet vers plus de prise en compte des autres cultures.

Ce RFC, comme beaucoup d'autres textes et discours analogues est, quoique écrit dans le style IETF, de la même eau : du FUD.

Téléchargez le RFC 4690


L'article seul

RFC 793: Transmission Control Protocol

Date de publication du RFC : Septembre 1981
Auteur(s) du RFC : Jon Postel (University of Southern California (USC)/Information Sciences Institute)
Chemin des normes
Première rédaction de cet article le 29 septembre 2006
Dernière mise à jour le 3 mars 2008

Vingt-cinq ans ce mois-ci que le protocole TCP est le protocole de transport le plus répandu de l'Internet. Presque toutes les applications l'utilisent, à commencer par le Web. Il n'a finalement été remplacé par un nouveau RFC qu'en août 2022, avec le RFC 9293.

Spécifier complètement un protocole de transport n'est pas trivial. Contrairement à IP, décrit dans le RFC 791, TCP a un état et chaque paquet doit donc être traité dans le contexte de cet état. Si la machine à états de TCP est relativement simple, il faut quand même 64 pages au RFC pour décrire tous les détails.

L'aventure de TCP est loin d'être finie : le passage à IPv6 ne l'affectera que peu, et, si le RFC 7414 liste de nombreux RFC qui améliorent ou corrigent la spécification initiale, notre RFC d'un quart de siècle est toujours d'actualité.

La machine à états de TCP : tcp

Voici un paquet TCP tel que vu par Wireshark (lancé en mode texte avec tshark -V) lors de l'établissement d'une connexion. Le format du paquet TCP est décrit dans la section 3.1 de notre RFC. On note la notion de port (ici le port 7 pour le protocole echo du RFC 862) ; IP ne permettant que d'identifier qu'une machine, les ports servent à distinguer plusieurs processus sur une machine. On y voir le bit de contrôle SYN (SYNchronize, demande d'établissement de connexion). 

Transmission Control Protocol, Src Port: 36682 (36682), Dst Port: 7 (7), Seq: 0, Ack: 0, Len: 0
    Source port: 36682 (36682)
    Destination port: 7 (7)
    Sequence number: 0    (relative sequence number)
    Header length: 40 bytes
    Flags: 0x0002 (SYN)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
    Window size: 5840
    Checksum: 0xa57b (correct)
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        SACK permitted
        Time stamp: tsval 48358541, tsecr 0
        NOP
        Window scale: 0 (multiply by 1)

On note surtout l'important numéro de séquence. TCP gère des flux d'octets numérotés et les accusés de réception indiquent un numéro de séquence, pas un paquet. Ce numéro est affiché comme zéro par Wireshark mais c'est un numéro relatif. Dans la réalité, sur le câble, ce numéro est initialisé à une valeur tirée au hasard (il est important de la tirer au hasard pour limiter les risques qu'une session TCP soit détournée par un attaquant). tcpdump, lui, affiche la valeur absolue pour les paquets SYN, la valeur qui passe sur le câble. Il affiche une valeur relative ensuite. Si on préfère avoir tout le temps la valeur absolue, l'option -S est faite pour cela. Voici un exemple d'ouverture de connexion (vers le serveur Subversion de CNP3) avec les options par défaut : 

09:18:08.880944 IP6 2001:67c:2219:8::6:69.59834 > 2001:6a8:3080:1::4.443: Flags [S], seq 4131334602, win 14400, options [mss 1440,sackOK,TS val 876788145 ecr 0,nop,wscale 4], length 0
09:18:08.908511 IP6 2001:6a8:3080:1::4.443 > 2001:67c:2219:8::6:69.59834: Flags [S.], seq 3086055825, ack 4131334603, win 5712, options [mss 1440,sackOK,TS val 81172037 ecr 876788145,nop,wscale 7], length 0
09:18:08.908534 IP6 2001:67c:2219:8::6:69.59834 > 2001:6a8:3080:1::4.443: Flags [.], ack 1, win 900, options [nop ,nop,TS val 876788152 ecr 81172037], length 0

Dans le troisième paquet, l'accusé de réception de l'initiateur de la connexion, tcpdump a affiché qu'on accusait réception, et que le prochain octet attendu était le 1 (pas encore envoyé, puisque les numéros de séquence indiquent l'octet suivant). Avec -S : 

09:18:08.880944 IP6 2001:67c:2219:8::6:69.59834 > 2001:6a8:3080:1::4.443: Flags [S], seq 4131334602, win 14400, options [mss 1440,sackOK,TS val 876788145 ecr 0,nop,wscale 4], length 0
09:18:08.908511 IP6 2001:6a8:3080:1::4.443 > 2001:67c:2219:8::6:69.59834: Flags [S.], seq 3086055825, ack 4131334603, win 5712, options [mss 1440,sackOK,TS val 81172037 ecr 876788145,nop,wscale 7], length 0
09:18:08.908534 IP6 2001:67c:2219:8::6:69.59834 > 2001:6a8:3080:1::4.443: Flags [.], ack 3086055826, win 900, options [nop,nop,TS val 876788152 ecr 81172037], length 0

Les deux premières lignes sont inchangées, mais on voit désormais que le troisième paquet contenait en fait un accusé de réception attendant l'octet 3086055826 (puisque le numéro de séquence initial choisi par 2001:6a8:3080:1::4 était 3086055825).

À la fin de l'en-tête TCP, Wireshark montre les options, un champ de taille variable qui contient différentes valeurs, encodées selon un schéma compliqué (l'option peut faire un seul octet ou bien être composée d'un triplet Type-Longueur-Valeur). On y trouve ici la MSS (ici 1460 octets), définie dans notre RFC, et des options qui ont été ajoutées ultérieurement, comme SACK (Selective ACKnowledgment, RFC 2018), ou bien Window scale, RFC 7323.

On peut noter que les options de TCP, étant une famille qui s'agrandit régulièrement, posent parfois des problèmes à des coupe-feux mal conçus (probablement la majorité), qui jettent sans scrupule les paquets contenant des options qu'ils ignorent. Ainsi, il est fréquent que les petits « routeurs » installés par les FAI chez leurs clients, aient des problèmes avec certaines options TCP. À l'heure où j'écris ce texte, le window scaling, pourtant normalisé il y a seize ans, ne passe pas les routeurs d'Alice/Tiscali (sur Linux, il faut mettre la variable sysctl net.ipv4.tcp_default_win_scale à 0). Et le SACK ne passe pas chez Noos (il faut mettre net.inet.tcp.sack.enable à 0 sur une FreeBSD).

Téléchargez le RFC 793


L'article seul

RFC 791: Internet Protocol

Date de publication du RFC : Septembre 1981
Auteur(s) du RFC : Jon Postel (University of Southern California (USC)/Information Sciences Institute)
Chemin des normes
Première rédaction de cet article le 29 septembre 2006
Dernière mise à jour le 18 février 2008

Vingt-cinq ans ce mois-ci, un quart de siècle que le protocole IP, dans sa version 4, sert de soubassement à tout l'Internet.

Voici donc le RFC, écrit par Jon Postel lui-même, qui décrit IP. Ses concepts, le routage, l'adressage , le format de paquets.

Le RFC explique très clairement la place d'IP : il ne fournit presque aucun service « de bout en bout », il se contente d'acheminer des datagrammes.

L'adressage est traité en quelques paragraphes, CIDR n'existait pas encore, et notre RFC parle donc de « classes » d'adresses, qui seront supprimées en 1993. Le routage est décrit très succinctement.

Le format des paquets (section 3.1) occupe finalement l'essentiel du RFC mais la section 3.2, consacrée à la discussion des détails du protocole, est très instructive, notamment sur la difficile question de la fragmentation des paquets.

Il n'existe pas de langage standard pour décrire un format de paquets donc notre RFC, comme tous les autres, utilise dans sa section 3.1, de l'art ASCII. Voici l'en-tête d'un paquet IP : 

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La version vaut toujours 4 pour IPv4. Beaucoup de décodeurs comme tcpdump affichent simplement « IP » tout court, lorsqu'il s'agit d'IPv4. Voici ce qu'affiche tcpdump avec l'option -vvv : 


21:59:43.111985 IP (tos 0x8, ttl  64, id 16854, offset 0, flags [DF], length: 60) 172.19.1.1.35890 > 172.19.1.2.7: S [tcp sum ok] 720694724:720694724(0) win 5840 <mss 1460,sackOK,timestamp 10464274 0,nop,wscale 0>

Le ToS (Type of Service, voir plus loin) vaut ici 8 (en hexadécimal), le TTL (Time to Live, en dépit de son nom, c'est le nombre maximum de routeurs qu'on peut traverser avant que le paquet ne soit abandonné) vaut 64, l'identificateur du fragment vaut ici 16854 et l'option (flag) DF (Don't Fragment) est à « vrai » (c'est la découverte de MTU du RFC 1191). Attention, l'ordre d'affichage n'est pas celui du paquet.

tshark, donne d'avantage de détails que tcpdump, d'une manière qui respecte bien le modèle en couches : 

#  tshark -V -n 
...
Frame 1 (74 bytes on wire, 74 bytes captured)
    Arrival Time: Feb 18, 2008 22:04:15.826000000
...
Internet Protocol, Src Addr: 172.19.1.1 (172.19.1.1), Dst Addr: 172.19.1.2 (172.19.1.2)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x08 (DSCP 0x02: Unknown DSCP; ECN: 0x00)
        0000 10.. = Differentiated Services Codepoint: Unknown (0x02)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 60
    Identification: 0xeeec (61164)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0xf19d (correct)
    Source: 172.19.1.1 (172.19.1.1)
    Destination: 172.19.1.2 (172.19.1.2)

On note que tshark a affiché le champ ToS sous le nom de DSCP, suivant l'évolution qui a eu lieu dans le RFC 2474, qui a complètement changé la sémantique de ce champ et son nom. Normalement, on ne devrait plus parler de ToS, même si ce terme reste fréquent.

Comment changer ce champ ? Un programme comme echoping permet, avec ses options -p et -P, de donner une valeur à ce champ. Le paquet ci-dessus a été généré par un echoping -P 0x08 172.19.1.2.

On notera enfin que c'est ce RFC 791 qui a défini, dans son annexe B, la notion d'ordre des octets sur le réseau. IP est gros boutien, le bit le plus significatif doit être envoyé en premier.

Téléchargez le RFC 791


L'article seul

RFC 4614: A Roadmap for Transmission Control Protocol (TCP) Specification Documents

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : M. Duke (Boeing Phantom Works), R. Braden (ISI), W. Eddy (Verizon), E. Blanton (Purdue University)
Pour information
Première rédaction de cet article le 28 septembre 2006

C'était un RFC de récapitulation. Il ne normalisait rien de nouveau mais dressait une liste commentée des RFC dont la connaissance est indispendable, ou simplement utile, au programmeur qui met en œuvre TCP. Il a depuis été remplacé par le RFC 7414.

Depuis sa normalisation, il y a exactement un quart de siècle (dans le RFC 793), TCP a complètement remplacé NCP. TCP est un des grands succès de l'Internet : quasiment toutes les applications Internet s'appuient sur ce protocole.

Mais le RFC normatif, le RFC 793, quoique toujours valable, est bien vieux et beaucoup de choses ont été ajoutée ou retirées à TCP depuis. Comme pour beaucoup d'autres protocoles Internet (par exemple le DNS), TCP met donc le programmeur en face d'une rude tâche : avant de commencer à coder, il doit d'abord dresser la liste de tous les RFC dont il aura besoin. C'est cette tâche que lui épargne notre RFC en dressant cette liste.

Par exemple, le document original ne contient rien sur le contrôle de congestion, qui ne sera décrit que dans le RFC 2001. Ce RFC (ou plus exactement son successeur, le RFC 5681) fait désormais partie de ceux qu'il faut lire, ainsi que le RFC 1323 qui décrit plusieurs extensions nécessaires pour tirer des performances élevées, ou bien le RFC 3168 qui normalise ECN.

La sécurité ayant bien plus d'importance aujourd'hui, d'autres RFC décrivent comment se défendre contre certaines vulnérabilités par exemple la lecture du RFC 6528 est indispensable pour empêcher un attaquant d'insérer des paquets dans une session TCP existante.

D'autres extensions sont moins consensuelles et restent plutôt expérimentales à ce jour comme l'algorithme Eifel du RFC 3522.

Enfin certaines extensions ont été abandonnées, l'expérience ayant montré leur inutilité ou leur nocivité. C'est ainsi que la proposition du RFC 1146 de tenter de nouveaux moyens de calcul de la somme de contrôle n'a pas pris.

Le protocole T/TCP, normalisé dans le RFC 1644, aurait permis de diminuer nettement la durée des connexions courtes, celles où on échange peu de données (beaucoup de connexions HTTP sont dans ce cas). Promu par des experts comme Stevens, implémenté dans des systèmes comme FreeBSD (option MSG_EOF de sendto), il a été remisé au grenier après que des analyses plus poussées aient montré ses failles de sécurité (il facilite l'utilisation de TCP avec usurpation d'adresses IP).

Les RFC de ces extensions abandonnées ont été reclassifiés comme « intérêt historique seulement » dans le RFC 6247.

Notre RFC décrit ensuite les RFC qui s'appliquent à certains environnements difficiles comme les lignes satellite qui font l'objet des RFC 2757 et RFC 2760 ou les lignes fortement asymétriques, comme le sont les lignes ADSL (traitées dans le RFC 3449).

De nombreux autres cas sont ensuite traitées dans notre RFC. Notre implémenteur n'a pas fini de tout lire !

La section 7 couvre enfin un cas délicat : les extensions à TCP qui, bien que largement utilisées, n'ont jamais fait l'objet d'un RFC ni même, souvent, d'une description formelle.

C'est le cas par exemple des syncookies, option indispensable sans laquelle un serveur Internet peut être mis à genoux très vite par une attaque SYN flood pour laquelle il n'y a même pas besoin de développements spécifiques, l'outil hping suffisant à l'attaquant. Ces petits gâteaux n'ont jamais été normalisés.

Voilà, rappelez-vous qu'un tel travail est forcément temporaire, de nouveaux RFC apparaissent, des idées qui semblaient bonnes sont abandonnées, et il faut donc refaire ce catalogue de temps en temps. Notre RFC est dépassé et la version actuelle est dans le RFC 7414.

Téléchargez le RFC 4614


L'article seul

RFC 4656: A One-way Active Measurement Protocol (OWAMP)

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : S. Shalunov (Internet2), B. Teitelbaum (Internet2), A. Karp (Internet2), J. Boote (Internet2), M. Zekauskas (Internet2)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 27 septembre 2006
Dernière mise à jour le 11 septembre 2008

Mesurer les performances d'une connexion à l'Internet est évidemment essentiel pour tous. Ce RFC propose un protocole, OWAMP, pour effectuer des mesures à sens unique (c'est-à-dire ne nécessitant pas que la réponse revienne).

Tout le monde a besoin de savoir si une liaison Internet fonctionne bien : du client qui veut vérifier les promesses de son fournisseur à l'ingénieur réseaux qui essaie de déboguer un problème de performances, avec les utilisateurs qui crient dans son dos "Ça rame !". Traditionnellement, ces mesures de performance étaient effectuées sur des trajets aller-retour (round-trip). Ainsi, le logiciel ping mesure le temps d'aller-retour (RTT pour round-trip time). Le RFC 5357 normalise un protocole de mesure de RTT, TWAMP. Non seulement cela nécessite que le chemin de retour fonctionne, mais cela interdit de séparer le temps de parcours aller du temps de parcours retour.

Le groupe de travail IETF IPPM (IP Performance Metrics) a donc produit de nombreux RFC spécifiant les métriques à utiliser pour des mesures de performance à sens unique (notamment les RFC 7679 et RFC 7680). En pratique, ces mesures se font en utilisant deux horloges très précises (par exemple GPS) sur les deux machines et en envoyant des paquets depuis la machine sonde vers la machine réceptrice.

Notre nouveau RFC franchit une nouvelle étape en normalisant le protocole de communication entre les deux machines, afin qu'elles puissent se mettre d'accord sur le test, puis l'effectuer. OWAMP (One-way Active Measurement Protocol) comprend deux parties :

  • OWAMP-Control est le protocole bi-directionnel de communication avant le test. Reposant sur TCP (port 861), il sert à se mettre d'accord sur les détails du test.
  • OWAMP-Test est le protocole de test, bâti sur UDP. Il fonctionne par l'envoi de paquets contenant l'heure de la machine émettrice. La réceptrice peut donc facilement calculer le temps de trajet, avec une résolution qui est celle des horloges utilisées par les deux machines.

OWAMP pose quelques problèmes de sécurité puisque, dans une communication à sens unique, il peut être difficile de s'assurer que les messages ont bien été transmis et pas altérés. Comme certains acteurs auraient intérêt à fausser les mesures, OWAMP-Protocol permet aux deux parties de se mettre d'accord sur des mécanismes d'authentification et de contrôle d'intégrité des paquets, en utilisant la cryptographie.

Deux mises en œuvre d'OWAMP en logiciel libre sont disponibles en http://e2epi.internet2.edu/owamp/ et http://www.av.it.pt/jowamp/ On peut lire aussi Comparing 2 implementations. of the IETF-IPPM One-Way. Delay and Loss Metrics, un excellent exposé qui donne beaucoup de détails techniques sur la mise en œuvre de ces mesures de trajets à sens unique. La question de la mesure du temps avec une résolution suffisante (une microseconde) n'est pas évidente sur un Unix de série !

Voici un exemple d'utilisation de l'OWAMP d'Internet2, sur une Debian : 

# Lancer le démon qui servira pour le protocole de contrôle. Ici, pour les tests,
# on le lance en avant-plan (option -Z)
% sudo owampd -U dupont -Z -v -a O
...
# Lancer le client (ici, sur la même machine, ::1, l'adresse IPv6 locale) 
# et mesurer
% owping ::1      
Approximately 13.1 seconds until results available

--- owping statistics from [::1]:43537 to [::1]:43538 ---
SID:    00000001cc734425a191ff7187f24db9
first:  2008-09-11T09:15:50.875
last:   2008-09-11T09:16:01.171
100 sent, 0 lost (0.000%), 0 duplicates
one-way delay min/median/max = 0.0129/0.1/0.0439 ms, (err=1.48 ms)
one-way jitter = 0 ms (P95-P50)
TTL not reported
no reordering
...

Pour une critique vigoureuse de ce RFC (pas du protocole, mais de la rédaction du RFC), voir « How NOT to Write a Protocol Specification », de Dustin D. Trammell.

Téléchargez le RFC 4656


L'article seul

RFC 4685: Atom Threading Extensions

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : J. Snell
Chemin des normes
Première rédaction de cet article le 26 septembre 2006

Petit à petit se construit la pile des formats de syndication de l'IETF. Notre RFC, première extension publiée sur le format Atom, normalise les fils de discussion (threads).

On le sait, une des motivations pour le format Atom était d'avoir une alternative ouverte, non contrôlée par une entreprise particulière, pour la syndication de contenu. Atom, normalisé dans le RFC 4287, est désormais largement répandu. Atom consiste en un format de base, plus la possibilité, décrite dans la section 6 du RFC 4287, d'ajouter des extensions. Le travail sur plusieurs de ces extensions a commencé imémdiatement et la première publiée concerne les fils de discussion (threads).

Notre RFC normalise donc un nouvel espace de nommage XML et de nouveaux éléments notamment <in-reply-to> qui permet à une entrée Atom de pointer vers l'entrée à laquelle elle répond. On notera que ces deux entrées peuvent être sur des sites Web ou des blogs différents, permettant ainsi un système de commentaires distribué.

Téléchargez le RFC 4685


L'article seul

RFC 4471: Derivation of DNS Name Predecessor and Successor

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : G. Sisson (Nominet), B. Laurie (Nominet)
Expérimental
Première rédaction de cet article le 25 septembre 2006
Dernière mise à jour le 27 septembre 2006

Le protocole DNSSEC, censé sécuriser le DNS a, tel qu'il est normalisé dans le RFC 4033 un gros défaut : il permet d'énumerer tous les domaines d'une zone signée. C'est cette faille que tente de résoudre notre RFC.

Pour permettre à un serveur DNSSEC de signer la non-existence d'un domaine, le RFC 4033 a normalisé l'enregistrement NSEC. Celui-ci dit "il n'y a aucun domaine avant XYZ.example" où XYZ est le label suivant celui demandé. "Suivant" est défini comme "suivant dans l'ordre alphabétique". Le gros problème de cette approche est qu'elle permet ainsi à un attaquant d'obtenir tous les domaines de la zone, par chaînage. C'est ainsi que Simon Josefsson a développé un programme de zone walking qui montre bien la vulnérabilité des zones DNSSEC. Muni du contenu de la zone, un attaquant peut ensuite utiliser whois ou un système équivalent pour obtenir des renseignements à des fins de spamming ou bien de harcèlement juridique. Le registre britannique, Nominet, avait ainsi refusé de déployer DNSSEC.

Certains, sans avoir suffisamment réfléchi au problème, disent "mais les données de la zone sont publiques, de toute façon", oubliant ainsi que l'obtention de la zone entière (ce que permet le zone walking) est autrement plus dangereux que la posisbilité d'interroger la zone sur quelques noms choisis : c'est bien pour cela que les registres ne distribuent par leur zone (cas de .fr ou en tout cas pas gratuitement (cas de Verisign).

Notre RFC s'attaque à ce problème en redéfinissant le mot "suivant". Il spécifie un algorithme qui permet d'obtenir un nom suivant ou précédant celui demandé, sans permettre d'utiliser ce nom suivant ou précédant pour obtenir d'autres noms. Le nom "suivant" ou "précédant" n'est pas vraiment lisible (de nombreux exemples figurent dans le RFC) mais est suffisant pour les besoins de DNSSEC.

Kim Minh Kaplan a mis en œuvre notre RFC, en Common Lisp. Son code peut être récupéré avec darcs : 

darcs get http://www.kim-minh.com/src/cl-dnssec
cd cl-dnssec 
make

et ensuite exécuté ainsi : 

%  ./rfc4471 -- P foobar.example.org. example.org.   
P(foobar.example.org., example.org.) = \255{49}.\255{63}.\255{63}.foobaq\255{57}.example.org.

Téléchargez le RFC 4471


L'article seul

RFC 4677: The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : P. Hoffman (VPN), S. Harris (University of Michigan)
Pour information
Première rédaction de cet article le 25 septembre 2006

Comme toute organisation, l'IETF a sa culture, ses règles, ses idiosyncrasies. Et les nouveaux arrivants peuvent avoir du mal à s'y retrouver. Ce RFC, surnommé "Le Tao", visait à guider ceux qui arrivent à leur première réunion IETF. (La forme RFC convenant mal à ce genre de documents, il a depuis été remplacé par une page Web.)

L'IETF est nettement moins formelle que la plupart des autres SDO. Mais elle est sans doute plus exigeante quant à la qualité du travail. Le RFC décrit donc la forme (comment s'habiller, comment faire ses présentations) et le fond : que lire et comment écrire. Il succède au RFC 3160 et a lui-même été rendu obsolète par le RFC 6722, qui remplaçait tous ces RFC par une page Web.

Pour l'habillement, c'est relativement simple. Comme le dit notre RFC, "comme les participants aux réunions doivent porter un badge, le T-shirt ou la chemise sont obligatoires. Les pantalons ou shorts sont recommandés."

Pour les présentations, si les gadgets PowerPoint touchent l'IETF comme beaucoup d'autres organisations, en revanche la publicité y est moins acceptée et les transparents doivent avoir du contenu.

Pour ce qui concerne le travail, ce n'est pas ce qui manque. Le débutant va devoir comprendre le rôle des différentes organisations qui gravitent dans la galaxie IETF (IAB, IESG, ISOC, RFC editor, etc). Et il va devoir apprendre la subtilité du statut des RFC, tous les RFC n'étant pas des normes.

Ensuite, si notre débutant va vouloir travailler à un RFC, il va devoir s'inscrire à un groupe de travail. Rien de plus simple puisqu'il n'y a pas de barrière à l'entrée. Mais les difficultés commencent après, et la description du processus qui mène d'une vague idée à un vrai RFC prend beaucoup de pages.

Bref, l'IETF, c'est intéressant, c'est utile, c'est ouvert, c'est bien documenté grâce entre autres au Tao, mais ce n'est pas pour autant un chemin de roses...

Téléchargez le RFC 4677


L'article seul

GaBuZoMeu, a parser for language tags

First publication of this article on 19 September 2006
Last update on of 25 August 2009

GaBuZoMeu is a set of programs to parse and check language tags (see the RFC 5646 produced by the IETF Working Group LTRU - Language Tag Registry Update).

Language tags are used by several protocols (like HTTP) or languages (like XML) to indicate the human language you want or have. Examples of language tags are "fr" (French), "apa" (Apache), "se-FI" (Swedish, as practiced in Finland) or "uk-Latn" (ukrainian in the latin script).

An IANA registry stores the registered values.

A language tag can be well-formed (syntactically correct) or not. This can be tested without access to the registry. A language tag can be valid or not (all its subtags registered). This depends on the copy of the registry you use (since the registry changes).

GaBuZoMeu includes the following programs:

  • check-wf checks the well-formedness of tag(s). Example of use: "check-wf fr en-AU".
  • check-valid checks the validity of tag(s). Same use.

It complies with RFC 5646.

You can download GaBuZoMeu.

GaBuZoMeu is written in Haskell so you'll need an Haskell compiler such as ghc.

To compile, just type "make". To check that everything is OK, you can type "make test". You should get zero "Errors" and zero "Failures".

GaBuZoMeu is distributed as free software, under the GNU General Public Licence. Remarks, patches and bug reports are welcome.

Written and maintained by Stéphane Bortzmeyer <bortzmeyer@nic.fr>.

Thanks for AFNIC, the .fr registry, for making this work possible.

Some other language tag parsers can be found at the language tag Web site.


L'article seul

Mesurer le temps d'exécution d'un programme

Première rédaction de cet article le 18 septembre 2006
Dernière mise à jour le 5 novembre 2006

On lit très souvent des discussions sur l'optimisation d'un programme informatique, discussions pleines d'argument du genre "X est plus rapide que Y" où X et Y sont des algorithmes, des SGBD, des langages de programmation... Très souvent, les asséneurs de ces arguments n'ont aucun fait sur lequel appuyer leurs affirmations, car ils n'ont jamais mesuré.

Premature optimisation is the root of all evil a affirmé le célèbre C.A.R. Hoare. Il voulait insister sur l'importance qu'il y a un faire un programme correct, avant de faire un programme rapide. Mais on peut aussi appliquer son dicton à l'importance qu'il y a à tester les techniques pour voir laquelle est réellement plus rapide (ou moins gourmande en espace ou autres ressources).

Sur un système Unix, la manière la plus évidente de tester est d'utiliser la commande time, ici pour tester un programme Perl : 

% time perl parse-with-regexp.pl `cat ./test-file`
...
... 0.07s user 0.03s system 24% cpu 0.421 total

On voit que le programme a mis 0,421 secondes à s'exécuter, mais que seul un quart de ce temps à été consacré à du travail du CPU. Soit le programme faisait beaucoup d'entrées/sorties, soit d'autres programmes s'exécutaient au même moment sur la machine.

Un autre bon exemple d'utilisation de time est présenté par Denis Barbier qui montre que, certes, grep fonctionne partiellement en UTF-8 (un problème que j'ai pour passer à UTF-8) mais qu'il est beaucoup plus lent avec cet encodage.

La principale limite de time est qu'elle prend en compte l'initialisation du programme (pour Perl, c'est le chargement du compilateur et de la machine virtuelle, puis la compilation du code, avant même que son exécution ne commence). Si je testais une base de données, time prendrait en compte le temps de connexion en plus du temps d'exécution de la requête. Si je testais une opération réseau, par exemple avec wget, time prendrait en compte le temps de résolution DNS, ce dont je n'ai pas forcément envie.

Il est donc généralement préférable de ne déclencher le chronomètre qu'après que l'initialisation aie été faite. C'est ce que fait echoping, qui ne lance ledit chronomètre (en appelant gettimeofday) qu'après que la résolution de noms en adresse aie été faite (par getaddrinfo) et juste avant de tenter une connexion (par connect).

Bien sûr, la mesure reste un monde compliqué et plein d'embûches. Par exemple, il est recommandé d'exécuter la commande plusieurs fois, pour tenir compte du résultat des caches. C'est pour cette raison que la plupart des benchmarks ne signifient pas grand'chose.

Voici un exemple de mesure de performance d'un serveur réseau. Ici, on veut comparer deux serveurs HTTP, Apache et thttpd. Pour distinguer le temps de résolution de noms (qui dépend du DNS) du temps de connexion TCP (qui, si le serveur est une machine Unix, ne dépend que du noyau, pas du serveur), du temps total, on peut utiliser curl, qui dispose d'options comme --write-out, qui permettent de n'afficher que le temps considéré comme "utile" : 

% curl --silent --output /dev/null --write-out 'DNS: %{time_namelookup} s\nConnect:%{time_connect} s\nTotal: %{time_total} s\n' http://www.demaziere.fr/ 
DNS: 0.001 s
Connect:0.001 s
Total: 0.126 s

Et le même test avec echoping : 

% echoping -v -h / www.demaziere.fr       
...
TCP Latency: 0.046543 seconds
Sent (92 bytes)...
Application Latency: 0.065827 seconds
610 bytes read from server.
Elapsed time: 0.118573 seconds

On voit ici que l'essentiel du temps est bien dû au serveur. echoping, lui, dispose de davantage d'options statistiques, par exemple -n qui permet de répéter un test pour s'assurer de sa reproductibilité et de calculer moyenne et surtout médiane, une valeur en général bien plus utile sur Internet. Essayons pour comparer nos serveurs HTTP : 

% echoping -n 4 -h / preston.sources.org 
...
Median time: 0.007902 seconds (32397 bytes per sec.)
...

Ce premier test était fait sur un serveur Apache. Avec un serveur thttpd, sur la même machine, on obtient : 

...
Median time: 0.011717 seconds (21849 bytes per sec.)
...

Bref, thttpd n'est pas plus rapide, dans ces conditions. Bien sûr, ce test n'épuise pas tout le problème. thttpd résiste peut-être mieux à la charge, par exemple. Mais cela montre l'importance de mesurer les performances, pas de simplement croire les auteurs du logiciel, qui présentent toujours leur logiciel comme "plus meilleur".

Il existe de nombreux autres outils de mesure des performances des serveurs réseau. Par exemple, pour mesurer les performances d'un serveur DNS, on utilise souvent le programme queryperf, distribué avec BIND. Et en local ?

Tous les langages de programmation offrent aujourd'hui un moyen de mesurer le temps d'exécution. Par exemple, pour Python, on a le module timeit.

Voici un exemple de test de performance, entre plusieurs modules d'accès à une base de données PostgreSQL. Si on avait voulu comparer plusieurs SGBD, la méthode aurait été la même. On commence par créer une base de données, à l'aide des instructions SQL suivants : 

CREATE TABLE Registrars (id SERIAL UNIQUE, 
                   created TIMESTAMP NOT NULL DEFAULT now() , name TEXT UNIQUE N
OT NULL);
INSERT INTO Registrars (name) VALUES ('Indomco');
INSERT INTO Registrars (name) VALUES ('Verisign');
INSERT INTO Registrars (name) VALUES ('Gandi');

CREATE TABLE Domains (id SERIAL UNIQUE, name TEXT UNIQUE NOT NULL, 
     created TIMESTAMP NOT NULL DEFAULT now(), 
             registrar INTEGER REFERENCES Registrars(id) NOT NULL);

puis le programme Python suivant va se connecter à la base (en utilisant tel ou tel module, selon la valeur de la variable d'environnement PYTHON_DB) : 

import timeit
import os
import sys

repetitions = 100
inserts = 1000
selects = inserts
deletes = inserts

domain_prefix = "example"

try:
    if os.environ['PYTHON_DB'] == 'psycopg':
        import psycopg
        db_module = psycopg
    elif os.environ['PYTHON_DB'] == 'pypg':
        import pypg
        db_module = pypg
    elif os.environ['PYTHON_DB'] == 'popy':
        import PoPy
        db_module = PoPy
        """ TODO: PoPy has a problem with the paramstyle pyformat. http://www.python.org/peps/pep-0249.html says:
            paramstyle

                String constant stating the type of parameter marker
                formatting expected by the interface. Possible values are
                [2]:

                    'qmark'         Question mark style, 
                                    e.g. '...WHERE name=?'
                    'numeric'       Numeric, positional style, 
                                    e.g. '...WHERE name=:1'
                    'named'         Named style, 
                                    e.g. '...WHERE name=:name'
                    'format'        ANSI C printf format codes, 
                                    e.g. '...WHERE name=%s'
                    'pyformat'      Python extended format codes, 
                                    e.g. '...WHERE name=%(name)s'

    but PoPy crashes:
        src/samples/db-comparison % python test.py
    Traceback (most recent call last):
      File "test.py", line 46, in ?
        run(connection, cursor)
      File "test.py", line 25, in run
        {'name': "%s-%i" % (domain_prefix, i), 'registrar': 'Gandi'})
    PoPy.ProgrammingError: ERROR:  column "gandi" does not exist

    """
    else:
        raise Exception("Unsupported DB module %s" %
                        os.environ['PYTHON_DB'])
except KeyError:
    sys.stderr.write("You must define the environment variable PYTHON_DB\n")
    sys.exit(1)

insertion_time = 0
selection_time = 0
deletion_time = 0

def run(operation, iterations, connection, cursor):
    if operation == "INSERT":
        cursor.execute("SELECT id FROM Registrars WHERE name='Gandi'")
        id = cursor.fetchone()[0]
        for i in range(1,iterations):
            cursor.execute("""
               INSERT INTO Domains (name, registrar) VALUES
                    ('%s', %i)""" %
                       ("%s-%i" % (domain_prefix, i), id))
        connection.commit()
    elif operation == "SELECT":
        for i in range(1,iterations):
            cursor.execute("""
               SELECT Domains.id, Domains.name, Domains.created,
                         Registrars.name AS registrar
                      FROM Domains,Registrars WHERE
                          Domains.name = '%s' AND Domains.registrar = Registrars.id""" %
                 "%s-%i" % (domain_prefix, i))
        connection.commit()
    elif operation == "DELETE":
        for i in range(1,iterations):
            cursor.execute("""
                DELETE FROM Domains WHERE name = '%s'""" %
                "%s-%i" % (domain_prefix, i))
        connection.commit()
    else:
        raise Exception("Unknown operation: %s" % operation)

def run_all(connection, cursor):
    global insertion_time, selection_time, deletion_time
    t = timeit.Timer(stmt="""
run("INSERT", inserts, connection, cursor)
""", setup="""
from __main__ import run, inserts, connection, cursor
""")
    insertion_time = insertion_time + t.timeit(number=1)
    t = timeit.Timer(stmt="""
run("SELECT", selects, connection, cursor)
""", setup="""
from __main__ import run, selects, connection, cursor
""")
    selection_time = selection_time + t.timeit(number=1)
    t = timeit.Timer(stmt="""
run("DELETE", deletes, connection, cursor)
""", setup="""
from __main__ import run, deletes, connection, cursor
""")
    deletion_time = deletion_time + t.timeit(number=1)

if os.environ['PYTHON_DB'] != 'pypg':
    # pypg does not support connection strings :-(
    connection = db_module.connect("dbname=db-comp-registry")
else: # Broken pypg
    connection = db_module.connect(host='localhost', database='db-comp-registry')
cursor = connection.cursor()
# Clean the DB
cursor.execute("DELETE FROM Domains")
connection.commit()

if __name__ == '__main__':
    print "Result with %s" % db_module
    sys.stderr.write("%i repetitions:\n" % repetitions)
    for i in range(1, repetitions+1):
        sys.stderr.write("%i... " % i)
        sys.stderr.flush()
        run_all(connection, cursor)
    sys.stderr.write("\n")
    print "INSERT: %.1f msec/pass" % (insertion_time*1000/inserts/repetitions)
    print "SELECT (with join): %.1f msec/pass" % (selection_time*1000/selects/repetitions)
    print "DELETE: %.1f msec/pass" % (deletion_time*1000/deletes/repetitions)

Son exécution donne : 

INSERT: 0.5 msec/pass
SELECT (with join): 4.5 msec/pass
DELETE: 3.9 msec/pass

ce qui indique que le programme met une demi-milliseconde par insertion, soit 2000 insertions par seconde. On peut refaire tourner le programme avec d'autres modules d'accès à la base pour voir s'il ya des différences de performance.

Empruntées à Andrew Bromage, et pour compléter la citation de Hoare ci-dessus, une belle liste de lois sur l'optimisation :

  • Rule 1. Don't do it.
  • Rule 2. (For experts only) Don't do it yet.
  • Rule 3. (For real experts only) When you've found a performance issue, profile first, find where the bottlenecks are, and then optimise. For if you guess, you'll guess wrong.
  • Rule 4. (For serious guru experts only) Sometimes, performance matters. When it matters, it really matters. If you find yourself in this situation, then the performance that you need must be designed in; it can't be added later. So go ahead and spend ten minutes optimising your code on the back of an envelope before writing anything.

L'article seul

RFC 4620: IPv6 Node Information Queries

Date de publication du RFC : Août 2006
Auteur(s) du RFC : M. Crawford (Fermilab), B. Haberman (JHU APL)
Expérimental
Première rédaction de cet article le 14 septembre 2006

Une nouvelle brique se met en place dans le chantier IPv6 : ce RFC normalise un mécanisme permettant de connaitre le nom d'une machine, en lui demandant (il faut donc connaitre son adresse IP). Cela permet de se passer du DNS, pour les réseaux sans administrateur.

Les réseaux traditionnels étaient composés d'un petit nombre d'ordinateurs, gérés par des administrateurs système professionnels. Mais IPv6 vise à être utilisé dans des environnements très différents, sur des appareils nombreux, et dans des réseaux pas forcément administrés. Si un nouveau contrôleur RFID est branché dans l'entrepôt, faut-il vraiment avoir un serveur DNS à jour pour pouvoir associer son nom à son adresse ? Notre RFC propose une autre solution : on envoie un paquet Node Information Query en ICMP à ce contrôleur et il répond avec son nom. On a donc un système de nommage proche des utilisateurs, sans serveur central.

Pour avoir ce service sur sa machine Linux, il y a le logiciel ninfod (répond aux sollicitations) et nins (détecte les systèmes présents et met à jour le DNS). Apparemment, un logiciel équivalent est disponible en série sur d'autres Unix, comme FreeBSD, mais je n'ai pas investigué.

Merci à Jean-Jacques Sarton pour sa relecture.

Téléchargez le RFC 4620


L'article seul

RFC 2360: Guide for Internet Standards Writers

Date de publication du RFC : Juin 1998
Auteur(s) du RFC : Gregor D. Scott (Director, Defense Information Systems Agency)
Première rédaction de cet article le 14 septembre 2006

Écrire une norme, comme écrire n'importe quelle spécification, est un art. Ce RFC vise à améliorer la qualité des normes IETF en conseillant leurs auteurs sur ce qui fait une bonne norme.

On note que l'IETF s'impose une tâche qui n'est pas considérée comme telle par toutes les SDO : s'assurer que la norme soit lisible et que les implémenteurs la comprennent suffisamment bien pour que les implémentations soient interopérables.

Le RFC couvre donc les points suivants :

  • La nécessité de se pencher de très près sur les problèmes de sécurité.
  • La définition précise du comportement d'un logiciel lorsque celui avec qui il communique viole la spécification (les premiers RFC étaient écrits pour un monde parfait où tout le monde "jouait le jeu").
  • La célèbre règle "Be liberal in what you accept, and conservative in what you send", spécifiée dans le RFC 791. Très souvent citée, parfois mal comprise, cette règle a permis le décollage d'un Internet composé de logiciels très variés, d'origine très différentes. Mais elle est aussi responsable de beaucoup de problèmes liés au laxisme des implémentations et notre RFC recommande donc la prudence en l'appliquant.
  • Le choix des options : trop d'options et l'interopérabilité en souffre (car deux implémentations ne mettent pas forcément en œuvre les mêmes). Pas assez d'options et le protocole ne peut pas s'adapter.
  • La spécification rigoureuse, presque juridique, des obligations et interdictions. Cela se fait par les mots-clés MUST, SHOULD et MAY, définis dans le RFC 2119, mots-clés qui sont écrits en majuscules pour montrer que ce n'est pas leur sens courant qui est utilisé.
  • Les conventions de notation, par exemple pour les automates à états finis, utilisés dans de nombreux RFC.
  • La nécessité de permettre la gestion du protocole, notamment via le protocole standard de l'IETF.
  • La nécessité de s'adapter à un monde varié, non limité aux États-Unis et non limité aux anglophones.
  • Et de nombreux autres points.

Des conseils pratiques apparaissent ensuite dans la section 3, pour décrire le format des paquets et les automates à états finis.

Notre RFC se clot sur une liste de choses à vérifier lorqu'on écrit une norme.

Globalement, les normes produites par l'IETF et distribuées dans les RFC sont d'une qualité très supérieure, notamment en terme de clarté et de précision, aux normes d'autres organismes. Le succès fulgurant de l'Internet en a été le résultat. Mais cela n'interdit pas de s'améliorer et ce document permet aux RFC d'être encore meilleurs.

Téléchargez le RFC 2360


L'article seul

Un ultra-simple compilateur écrit en Haskell

Première rédaction de cet article le 13 septembre 2006

Depuis que je me suis mis au langage de programmation Haskell pour écrire des programmes de type compilateur (analyse syntaxique et sémantique), je me suis dit que ce serait une bonne idée d'écrire un programme ultra-simple, qui illustre les techniques mises en jeu.

J'ai donc fait Simple Compiler. Vous pouvez l'utiliser comme point de départ pour vos programmes. Commencez par lire le README inclus.

Simple Compiler utilise notamment les analyseurs syntaxiques fondés sur la combinaison d'analyseurs.

Un compilateur bien plus complet, mais toujours simple et très bien documenté, figure dans l'excellent article de CoffeeMug, Writing a Lisp interpreter in Haskell.


L'article seul

Développer un site Web avec XSLT

Première rédaction de cet article le 13 septembre 2006

Il existe un million de solutions techniques pour développer un site Web (par exemple, ce blog utilise une technique maison). Je présente ici une solution utilisée récemment : tout en XSLT.

Le site http://www.cosmogol.fr/ est un site très simple, tout en statique et qui ne pose pas de problèmes particuliers. Le cahier des charges était simplement d'assurer une homogénéité graphique des pages, sans devoir tout refaire à la main en cas de changement, en s'en tenant aux normes (HTML valide, langages normalisés, ce qui est justement le cas de XSLT). (Un autre site développé avec ces techniques est http://www.langtag.net/.)

Le gabarit à partir duquel sont incarnées les pages est donc en XSLT (ici, le xsl:template pour l'élément <page> qui est la racine de chaque page): 


  <xsl:template match="page">
    <xsl:variable name="title">
      <xsl:value-of select="@title"/>
    </xsl:variable>
    <html xml:lang="en">
      <head>
        <link rel="stylesheet" type="text/css" href="cosmogol.css" />
        <title>Cosmogol: <xsl:value-of select="$title"/></title>
      </head>
      <body>
        <h1 class="main-title"><xsl:value-of select="$title"/></h1>
        <xsl:apply-templates select="*"/>
        <hr class="before-footer"/>
...

Les pages individuelles sont ensuite réalisées en XHTML, avec quelques éléments à moi comme <page>, déjà cité : 


<page title="Related software">

<ul>
<li><a href="http://www.graphviz.org/">Graphviz</a>, the well-known graph
description language,</li>
...

Le programmes XSLT s'assure de la cohérence du contenu des pages (titre commençant par le sujet du site, pied de page standard, etc). Une feuille de style en CSS assure, elle, la cohérence de l'apparence (merci à Ève Demazière pour les choix faits sur la feuille de style).

Pour obtenir une cohérence encore meilleure, il est bien agréable de pouvoir mettre dans le XHTML des éléments "maison" par exemple, pour expliquer un terme, un élément <wikipedia> : 


<p>Then, type "<wikipedia>make</wikipedia>" to build the program.</p>

Cet élément va être remplacé par du XHTML standard dans le programme XSLT. Je découpe le template en deux, pour pouvoir l'appeler également directement depuis le gabarit XSLT : 


  <xsl:template name="wikipedia">
    <xsl:param name="link"/>
    <xsl:param name="text"/>
    <xsl:variable name="actuallink">
      <xsl:choose>
        <xsl:when test="$link = ''">
          <xsl:value-of select="$text"/>
        </xsl:when>
        <xsl:otherwise>
          <xsl:value-of select="$link"/>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:variable>
    <a><xsl:attribute name="href">http://en.wikipedia.org/wiki/<xsl:value-of select="$actuallink"/></xsl:attribute><xsl:value-of select="$text"/></a>    
  </xsl:template>

  <xsl:template match="wikipedia">
    <xsl:variable name="word">
      <xsl:choose>
        <xsl:when test="@name">
          <xsl:value-of select="@name"/>
        </xsl:when>
        <xsl:otherwise>
          <xsl:value-of select="text()"/>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:variable>
    <xsl:variable name="path">
       <xsl:choose>
          <xsl:when test="function-available('str:encode-uri')">      
            <xsl:value-of select="str:encode-uri($word, true())"/>
          </xsl:when>
          <xsl:otherwise>
            <xsl:value-of select="$word"/>
          </xsl:otherwise>
        </xsl:choose>
      </xsl:variable>    
    <xsl:call-template name="wikipedia">
      <xsl:with-param name="link" select="$path"/>
      <xsl:with-param name="text" select="text()"/>
    </xsl:call-template>
  </xsl:template>

On peut récupérer tous les fichiers du site.

Une façon de l'améliorer en factorisant certains gabarits est décrite en http://stackoverflow.com/questions/167453/xslt-abstractions#167545.


L'article seul

RFC 4645: Initial Language Subtag Registry

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : D. Ewell (éditeur)
Pour information
Réalisé dans le cadre du groupe de travail IETF ltru
Première rédaction de cet article le 11 septembre 2006

Ce RFC, compagnon du RFC 4646, décrit l'état initial du registre des langues de l'IANA.

Il est écrit dans le format dit record-jar, décrit dans le livre The Art of Unix programming.

Il servait juste à initialiser le nouveau registre IANA avec des affectations comme : 

   %% Description d'une langue, ici l'arménien (hy)
   Type: language
   Subtag: hy
   Description: Armenian
   Added: 2005-10-16
   Suppress-Script: Armn
   %%
   %% Description d'une écriture, ici l'alphabet latin
   Type: script
   Subtag: Latn
   Description: Latin
   Added: 2005-10-16
   %%

Le registre a ensuite continué sa vie, accepté de nouveaux enregistrements et même une nouvelle grande mise à jour avec le RFC 5645.

Téléchargez le RFC 4645


L'article seul

RFC 4646: Tags for Identifying Languages

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : A. Phillips (Yahoo), M. Davis (Google)
Réalisé dans le cadre du groupe de travail IETF ltru
Première rédaction de cet article le 11 septembre 2006
Dernière mise à jour le 10 octobre 2006

Successeur du très utilisé RFC 3066, puis lui-même remplacé par le RFC 5646, notre RFC décrit les noms des langues (langues humaines, pas langages informatiques). Toute application qui a besoin d'indiquer une langue doit s'en servir.

Le protocole HTTP par exemple permet à un navigateur Web d'indiquer au serveur quelle langue il préfère (en-tête Accept-Language: dans le RFC 2616), au cas où le serveur aie plusieurs versions d'une page et soit correctement configuré (ce que Apache permet). Cela marche très bien avec des sites comme http://www.debian.org/.

Des normes non-IETF (notamment XML) se réfèrent à ce RFC.

Les noms des langues ont en général deux lettres et sont tirés de la norme ISO 639. Par exemple :

  • "fr" pour le français, à ne pas confondre avec le TLD ".fr", qui désigne la France,
  • "ar" pour l'arabe,
  • "br" pour le breton,
  • "en" pour l'anglais,
  • etc.

La norme complète est plus complexe : par exemple, l'anglais parlé aux États-Unis n'est pas tout à fait le même que celui parlé en Grande-Bretagne. Aussi, notre RFC permet de décrire la langue de manière plus fine par exemple fr-CH désigne le français tel qu'il est parlé en Suisse.

Il y a d'autres caractéristiques que la langue ou le pays. Ainsi, sr-Latn-CS représente le serbe (sr) écrit dans l'alphabet latin (Latn) tel qu'il s'utilise en Serbie (CS).

La question étant sensible (le croate est-il une langue différente du serbe, par exemple ?) l'IETF a évité les problèmes en s'appuyant sur des normes existantes (ISO 639 pour les langues comme le RFC 1591 s'appuie sur ISO 3166 pour éviter l'épineuse question de "qu'est-ce qui est un pays"). Néanmoins, le RFC confie un rôle de registre à l'IANA pour garantir une stabilité des noms (l'ISO ne la garantit pas, ne s'intéressant qu'au présent, alors que l'Internet a besoin de stabilité sur le long terme).

Les changement par rapport au précédent, le RFC 3066 sont détaillés à la fin du RFC. Le changement plus visible est le choix d'avoir désormais un registre complet à l'IANA. L'ancien registre IANA était très incomplet (beaucoup de langues n'étaient pas enregistrées) et ne séparait pas clairement les étiquettes (tag, la langue) des sous-étiquettes (subtag, le pays et/ou l'écriture), le tag complet étant considéré comme opaque aux applications. Le nouveau registre, initialisé par le RFC 4645 est bien plus complet. Il s'appuie toujours sur les normes existantes (ISO 639 pour les langues, ISO 15924 pour les écritures et ISO 3166 pour les pays). La syntaxe, si elle ne change pas en apparence (fr-BE sera toujours une étiquette valable pour le français pratiqué en Belgique), est plus rigoureuse. À son tour, notre RFC 4646, a été remplacé par un RFC plus récent, le RFC 5646.

Les auteurs du RFC ont expliqué leurs choix dans les excellents articles Reasons for Enhancing RFC 3066 et Understanding the New Language Tags.

Les transparents d'un exposé sur ces language tags sont disponibles.

Un analyseur de language tags en logiciel libre existe désormais, GaBuZoMeu.

Téléchargez le RFC 4646


L'article seul

RFC 4647: Matching of language tags

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : A. Phillips (Yahoo), M. Davis (Google)
Réalisé dans le cadre du groupe de travail IETF ltru
Première rédaction de cet article le 11 septembre 2006

Le RFC 4646 qui spécifie les nouveaux language tags, les étiquettes pour indiquer la langue utilisée, étant désormais disponible, ce RFC complète le travail en définissant (partiellement) les algorithmes de correspondance entre une étiquette existante et une étiquette demandée, par exemple lors de la négocation de contenu entre un navigateur Web et un serveur.

Notre RFC définit donc une nouvelle syntaxe, le language range (intervalle de langues) qui exprime des préférences et que l'algorithme doit mettre en correspondance avec les étiquettes disponibles (par exemple, les valeurs de l'attribut xml:lang si le serveur sert des documents XML).

Le RFC définit ensuite deux classes d'algorithmes possibles, le filtering (filtrage), qui va trouver O, 1 ou N documents parmi ceux disponibles et le lookup (recherche) qui va trouver un document et un seul. Le filtrage est par exemple utilisé lorsque le processeur veut extraire d'une bibliothèque de documents XML tous les documents qui répondent au même critère (être en Breton, par exemple). La recherche est utilisée lorsque le processeur doit trouver un document et un seul, par exemple pour envoyer un message d'erreur à l'utilisateur.

L'intervalle ressemble à une étiquette mais certains champs peuvent contenir un astérisque qui signifie l'acceptation de n'importe quelle valeur. Ainsi, *-CH pourra désigner toutes les langues utilisées en Suisse.

À noter que les détails des deux algorithmes, de filtrage et de recherche, sont délibérement non complets : c'est au protocole qui utilise ce RFC de tout spécifier. Même chose pour le cas où le client souhaite indiquer une liste de langues possibles, comme ce que permet le protocole HTTP avec son champ Accept-Language. Notre RFC ne donne pas de syntaxe précise pour de telles listes, ce sera aux futurs RFC utilisateurs de le faire.

Téléchargez le RFC 4647


L'article seul

Vol 93

Première rédaction de cet article le 8 septembre 2006

J'ai été surpris par ce film, consacré aux attentats du 11 septembre 2001 et notamment au devenir du vol United 93, le seul à n'avoir pas atteint sa cible.

Je pensais aller voir un film d'action états-unien traditionnel, avec effets spéciaux, héros, méchants et bagarres et le film de Paul Greengrass est en fait réalisé dans un style reportage, très réaliste (évidemment, n'ayant pas d'expérience d'un détournement d'avion, je ne peux pas dire s'il est réellement réaliste ; il n'y a eu aucun survivant dans le vol 93, donc personne ne peut confirmer ou infirmer).

Dès le début, on est surpris : il n'y a pas deux minutes consacrées à chacun des personnages principaux pour les présenter. On ne connaitra d'ailleurs pas grand'chose d'eux, l'action commence tout de suite.

Ensuite, il n'y a pas de bagarres magnifiées avec grands coups de poing et méchants projetés à cinq mètres. Tout est violent, mais d'une violence sordide, où les bagarres sont confuses, où tout le monde pousse des cris d'animaux, et où le sang coule très vite. Tout est confus et la phrase la plus entendue dans le film est "Quoi ? Qu'est-ce qu'il a dit ? Quelqu'un a compris ?". Tout le monde est hystérique et transpire abondamment.

On ne voit pas de belles images (à part celles du décollage du Boeing), les chasseurs de l'US Air Force ne sont pas montrés, le crash final est invisible.

La caméra est très proche des acteurs et on s'identifie très vite aux personnages. Aux passagers, lorsqu'ils se demandent ce qui va leur arriver puis, lorsqu'ils ont compris le vrai but du commando, lorsqu'ils préparent la contre-attaque. Mais on suit aussi de très près les pirates de l'air, leurs angoisses, leur peur à eux et leur crainte d'échouer dans leur mission. Leur chef est un des rares personnages à ne jamais crier (c'est l'intellectuel du groupe et le seul qui sache piloter) mais il n'assure pas plus pour autant.

Une représentation très différente d'une attaque terroriste, donc, et qui laisse plus estomaqué de ce déchainement de violence primaire que les images bien plus classiques des tours en flamme.


L'article seul

RFC 4234: Augmented BNF for Syntax Specifications: ABNF

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : D. Crocker (Brandenburg InternetWorking), P. Overell (THUS plc.)
Chemin des normes
Première rédaction de cet article le 7 septembre 2006
Dernière mise à jour le 1 février 2008

Ce RFC, désormais remplacé par le RFC 5234, fait partie des RFC ancillaires, qui ne spécifient pas directement un protocole IETF mais fournissent des outils pour les "vrais" RFC. En l'occurrence, il normalise le mini-language pour écrire des grammaires.

Beaucoup de RFC doivent spécifier un langage, en général assez simple (jamais de la taille d'un langage de programmation) mais néanmoins suffisamment important pour que les descriptions informelles du langage soient risquées. Depuis longtemps, on utilise en informatique des notations dérivées du langage BNF pour spécifier formellement un langage. Le problème est qu'il existe plusieurs dialectes de BNF (comme EBNF) et que les RFC ont besoin d'une référence stable. D'où ce RFC, qui succède au fameux RFC 2234 (avec très peu de changements), et qui a lui-même été remplacé par le RFC 5234. Il décrit ABNF, le dialecte IETF de BNF. Classique sur beaucoup de points, ce dialecte a quand même quelques variations, issues d'une histoire très ancienne. Par exemple, le signe | pour le choix est remplacé par /.

Quelques outils sont disponibles pour aider les auteurs de grammaires. Mais je trouve que c'est encore insuffisant. S'il existe deux vérificateurs (qui peuvent tester qu'une grammaire est cohérente), il n'existe guère de générateurs d'analyseurs syntaxiques. En revanche, à des fins de test, il existe un programme, Eustathius, qui génère automatiquement des exemples à partir d'une grammaire. Vous trouverez de nombreux exemples de grammaires ABNF dans les sources d'Eustathius.

À titre d'exemple, voici la spécification de SPF (décrit dans le RFC 4408) en ABNF : 


   record           = version terms *SP
   version          = "v=spf1"

   terms            = *( 1*SP ( directive / modifier ) )

   directive        = [ qualifier ] mechanism
   qualifier        = "+" / "-" / "?" / "~"
   mechanism        = ( all / include
                      / A / MX / PTR / IP4 / IP6 / exists )

   all              = "all"
   include          = "include"  ":" domain-spec
   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
   PTR              = "ptr"    [ ":" domain-spec ]
   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
   exists           = "exists"   ":" domain-spec

   modifier         = redirect / explanation / unknown-modifier
   redirect         = "redirect" "=" domain-spec
   explanation      = "exp" "=" domain-spec
   unknown-modifier = name "=" macro-string

   ip4-cidr-length  = "/" 1*DIGIT
   ip6-cidr-length  = "/" 1*DIGIT
   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

   ip4-network      = qnum "." qnum "." qnum "." qnum
   qnum             = DIGIT                 ; 0-9
                      / %x31-39 DIGIT       ; 10-99
                      / "1" 2DIGIT          ; 100-199
                      / "2" %x30-34 DIGIT   ; 200-249
                      / "25" %x30-35        ; 250-255
             ; conventional dotted quad notation.  e.g., 192.0.2.0
   ip6-network      = <as per [RFC 3513], section 2.2>
             ; e.g., 2001:DB8::CD30

   domain-spec      = macro-string domain-end
   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
   toplabel         = ( *alphanum ALPHA *alphanum ) /
                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
                      ; LDH rule plus additional TLD restrictions
                      ; (see [RFC3696], Section 2)

   alphanum         = ALPHA / DIGIT

   explain-string   = *( macro-string / SP )

   macro-string     = *( macro-expand / macro-literal )
   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
                      / "%%" / "%_" / "%-"
   macro-literal    = %x21-24 / %x26-7E
                      ; visible characters except "%"
   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
                      "c" / "r" / "t"
   transformers     = *DIGIT [ "r" ]
   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="

   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )

   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
                      [ key-value-list ] CRLF

   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
                      "None" / "TempError" / "PermError"

   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
                      [";"]

   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )

   key              = "client-ip" / "envelope-from" / "helo" /
                      "problem" / "receiver" / "identity" /
                       mechanism / "x-" name / name

   identity         = "mailfrom"   ; for the "MAIL FROM" identity
                      / "helo"     ; for the "HELO" identity
                      / name       ; other identities

   dot-atom         = <unquoted word as per [RFC2822]>
   quoted-string    = <quoted string as per [RFC2822]>
   comment          = <comment string as per [RFC2822]>
   CFWS             = <comment or folding white space as per [RFC2822]>
   FWS              = <folding white space as per [RFC2822]>
   CRLF             = <standard end-of-line token as per [RFC2822]>

Téléchargez le RFC 4234


L'article seul

RFC 2672: Non-Terminal DNS Name Redirection

Date de publication du RFC : Août 1999
Auteur(s) du RFC : Matt Crawford (Fermilab)
Chemin des normes
Première rédaction de cet article le 7 septembre 2006
Dernière mise à jour le 16 octobre 2007

Depuis sa normalisation dans le RFC 1034, le DNS a suscité le développement d'innombrables extensions, plus ou moins réalistes, plus ou moins utilisées. L'enregistrement DNAME, sujet de ce RFC, semble très peu utilisé : il permet de donner un synonyme à une zone entière, pas à un seul nom, comme le fait l'enregistrement CNAME. (Ce RFC a depuis été remplacé par une version 2, dans le RFC 6672.)

Les enregistrements DNAME permettent d'écrire des équivalences comme : 

vivendi-environnement.fr. DNAME veolia.fr.

et un nom comme www.vivendi-environnement.fr sera transformé en www.veolia.fr. Le but étant ici de changer le nom de l'entreprise en Veolia sans avoir à s'inquiéter de toutes les occcurrences de l'ancien nom qui trainent dans des signets privés, dans la presse écrite, sur del.icio.us, etc.

En fait, les enregistrements DNAME ne sont pas aussi simples que cela. Le DNAME ne s'applique pas réellement à la zone mais à tous les sous-domaines de l'apex. Il faut donc dupliquer tous les enregistrements de l'apex (typiquement, les MX et les NS). Le vrai fichier de zone pour videndi-environnement.fr ressemblerait plutôt à : 

@	IN	SOA	... Dupliquer le SOA de veolia.fr
        IN   NS  ... Idem pour NS et MX
        IN   MX   ...

        IN   DNAME veolia.fr.

; Et ça suffit, les noms comme www.vivendi-environnement.fr seront
; gérés par le DNAME.

Notre RFC prévoit le cas où le client DNS ignore les DNAME et le serveur devrait alors synthétiser des enregistrements CNAME équivalents.

Les DNAME sont mis en œuvre dans BIND et nsd (depuis très peu de temps pour ce dernier) mais semblent peu déployés (si vous voulez regarder ce que cela donne, testez testonly.sources.org qui est un DNAME de example.org donc, par exemple, www.testonly.sources.org existe). Selon moi, une des raisons est que le problème peut se résoudre tout aussi simplement, sans changement dans le DNS, par l'utilisation d'une préprocesseur ou bien en créant un lien symbolique entre les deux fichiers de zone (si le fichier ne contient que des noms relatifs, ça marche très bien, que ce soit avec BIND ou avec nsd).

Téléchargez le RFC 2672


L'article seul

Tester ses programmes

Première rédaction de cet article le 4 septembre 2006
Dernière mise à jour le 7 février 2008

Peu de programmeurs exécutent des tests systématiques de leurs programmes. Pourtant, l'utilisation de tests systématiques permettrait une bien meilleur qualité du programme, surtout en cas de modification.


L'article complet

Les analyseurs syntaxiques fondés sur la combinaison d'analyseurs

Première rédaction de cet article le 31 août 2006
Dernière mise à jour le 14 novembre 2006

Il est fréquent qu'un programme informatique aie besoin de procéder à une analyse syntaxique d'un document. Cette tâche est en général effectuée par des programmes générés à partir d'une description de la grammaire, description effectuée dans un langage spécialisé. Yacc est le plus courant de ces générateurs d'analyseurs syntaxiques. Mais une autre approche est la combinaison d'analyseurs.

Par exemple, si je veux extraire du registre IANA des langues (décrit dans le RFC 4646) toutes les langues qui s'écrivent couramment avec l'alphabet arabe (ce sont les langages pour lesquels le champ Suppress-Script vaut Arab), je dois analyser ce fichier, écrit avec la syntaxe dite record-jar. Je peux écrire sa grammaire (qui est triviale) en Yacc mais Yacc, comme la plupart de ses concurrents (comme Yappy pour Python) oblige à apprendre un deuxième langage, distinct du langage hôte (C pour Yacc) et ne permet pas d'utiliser les constructions du langage hôte dans la grammaire elle-même, ce qui limite les possibilités de cette grammaire (notamment pour les langages sensibles au contexte).

Une autre solution est d'utiliser le langage hôte pour décrire la grammaire, en décrivant de nombreux petit analyseurs syntaxiques, combinés avec une bibliothèque de fonctions de combinaison, qui mettent en œuvre les opérations de combinaison classiques (comme la répétition, l'optionnel, etc). C'est ce que permet par exemple la bibliothèque de combinateurs Parsec pour le langage Haskell.

Comme premier exemple, essayons d'analyser le fichier /etc/passwd d'une machine Unix (pour cet exemple particulier, où le fichier a une structure très simple, le module Text:Regex serait une autre solution, mais Parsec devient nécessaire si la structure du fichier est plus complexe). La grammaire est : 

field = many (noneOf ":")

line = field `sepBy` char ':'

Ce code est du Haskell pur, utilisant les fonctions de la bibliothèque Parsec (comme many) ou bien ses définitions déjà faites (comme newline).

Une fois la grammaire écrite, on peut la tester facilement avec la fonction parseTest fournie par Parsec. Puis l'utiliser dans un vrai programme avec la fonction parse de Parsec. Voici un test avec ghci (partie de ghc) : 

*Main> parseTest line "a:b:ct:e"
["a","b","ct","e"]
*Main> parseTest line "az"
["az"]
*Main> parseTest line "az:"
["az",""]

Le programme complet pourrait ressembler à : 


field = many (noneOf ":")

line = field `sepBy` char ':'

alllines = line `sepBy` newline

display (Right contents) = concat (map unwords contents)

main = do
    contents <- readFile "/etc/passwd"
    let result = parse alllines "/etc/passwd" contents 
    putStr (display result)

Voici maintenant une partie de la grammaire qui permet d'analyser le registre des langues : 


doublepercent = do {string "%%"; newline} <?> "double percent line"

record = do
   fields <- many1 field <?> "record"
   let therecord = fromList (map extract fields)
   return (recordFactory therecord)

field = do 
        name <- fieldname
        spaces
        colon
        spaces
        value <- fieldvalue
        newline
        return (Field name value)
   <?> "field"

registry = do
     allrecords <- record `sepBy` doublepercent
     eof
     return allrecords

La fonction fromList vient du module Data.Map et sert à transformer la liste renvoyée par parse en un tableau indexé.

Parsec est prédictif par défaut, ce qui veut dire qu'il ne garde pas assez d'état pour revenir en arrière s'il se trompe. Avec certaines grammaires (par exemple, si "x" est défini comme "a c" ou "a b"), Parsec aura consommé l'entrée (ici "a") avant de détecter l'erreur et ne pourra pas revenir en arrière. C'est la source de la plupart des bogues Parsec et c'est un grand sujet d'énervement pour le programmeur, qui doit penser à insérer des try (qui indique à Parsec de garder assez d'état pour pouvoir reculer) judicieusement.

Plusieurs de mes programmes sont écrits avec Parsec (un exemple ultra-simple, conçu à des fins pédagogiques) est aussi disponible) :

Un très bon article d'introduction sur ces analyseurs à combinateurs est Monadic parser combinators qui décrit très en détail ces analyseurs. Les exemples sont dans un langage très proche d'Haskell, Gofer. (La partie sur les monades n'est pas indispensable.)

Des analyseurs bâtis sur le même principe existent pour d'autres langages de programmation comme rparsec pour Ruby, Jparsec pour Java ou bien Combo en C. En Python, il semble n'y avoir que des expérimentations.


L'article seul

RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES

Date de publication du RFC : Novembre 1987
Auteur(s) du RFC : Paul Mockapetris (ISI)
Chemin des normes
Première rédaction de cet article le 30 août 2006

Ce RFC, très ancien, mais jamais remplacé, est toujours la norme officielle du DNS. Modifié, complété, corrigé, par des dizaines de RFC suivants, il reste, avec son compagnon RFC 1035, l'un des plus anciens RFC encore en service.

Il est très intéressant de lire aujourd'hui le RFC qui normalise le DNS. Tout l'Internet dépend fortement du DNS. Mais à l'époque, le DNS n'était qu'une méthode de nommage parmi d'autres. Il l'a finalement emporté et notre RFC ne semble pas ridicule presque vingt ans après. Le DNS a passé le test du temps et le RFC qui le définit reste une excellente source d'information.

Le DNS a été normalisé dans deux RFC : notre 1034 décrit les concepts (mais descend néanmoins beaucoup dans les détails, par exemple sur l'algorithme utilisé) et le RFC 1035 complète avec tout ce que l'implémenteur doit savoir.

Mais, depuis, de très nombreux RFC ont modifié le DNS : supprimant des options (comme IQUERY, les recherches par contenu, jamais réellement déployées et supprimées par le RFC 3425), ajoutant des services comme DNSSEC, ou expliquant tout ce qui n'était pas clair (comme le font les RFC 2181 ou bien le RFC 4592 sur les fameux jokers). Il serait appréciable qu'une âme courageuse s'attache à consolider toutes ces rustines successives en une série de RFC modernes, comme cela a été fait pour le courrier électronique avec les RFC 2821 et RFC 2822. Mais une telle tâche n'a pas encore trouvé de volontaire. Ce serait un véritable travail d'Hercule, vu le nombre de RFC à digérer et le nombre de gens à convaincre, vu aussi le caractère très spécifique d'un service dont dépend presque tout l'Internet.

Parmi les archaïsmes du RFC 1034, notons qu'il spécifie un format de fichiers pour les serveurs de noms, format que lisent des logiciels comme BIND ou NSD, et qu'affiche une commande comme dig : 

@ IN  SOA bortzmeyer.netaktiv.com. hostmaster.bortzmeyer.org. (
        2006071901
        7200
        3600
        604800
        43200 )

  IN  NS  ns1.bortzmeyer.org.
  IN  NS  ns1.generic-nic.net.

  IN MX 0 bortzmeyer.netaktiv.com.

. Aujourd'hui, l'IETF évite en général de normaliser les formats de fichiers des clients ou des serveurs, préférant se concentrer sur ce qui passe sur le réseau (on the wire est une expression qui revient souvent à l'IETF). En effet, la normalisation de ce format, quoique utile pour la communication entre humains, ou la rédaction de cours sur le DNS, n'est pas nécessaire à l'interopérabilité des implémentations.

Téléchargez le RFC 1034


L'article seul

RFC 4627: The application/json Media Type for JavaScript Object Notation (JSON)

Date de publication du RFC : Juillet 2006
Auteur(s) du RFC : D. Crockford (JSON.org)
Pour information
Première rédaction de cet article le 30 août 2006
Dernière mise à jour le 18 janvier 2012

Il existe une pléthore de langages pour décrire des données structurées. XML est le plus connu et voici un de ses concurrents, JSON, décrit dans ce RFC (depuis remplacé par le RFC 8259).

JSON existe depuis longtemps mais n'avait pas de norme formelle. C'est désormais fait dans notre RFC, puis dans son successeur, le RFC 8259.

JSON se veut plus léger que XML. Comme son concurrent XML, il permet de représenter des structures de données hiérarchiques.

À noter que JSON doit son origine, et son nom complet (JavaScript Object Notation) au langage de programmation Javascript, dont il est un sous-ensemble. Mais JSON n'est pas un langage de programmation, seulement un langage de description de données, et il ne peut donc pas servir de véhicule pour du code méchant.

Voici un exemple, tiré du RFC, d'un objet exprimé en JSON : 

  {
      "Image": {
          "Width":  800,
          "Height": 600,
          "Title":  "View from 15th Floor",
          "Thumbnail": {
              "Url":    "http://www.example.com/image/481989943",
              "Height": 125,
              "Width":  "100"
          },
          "IDs": [116, 943, 234, 38793]
        }
   }

Les détails sont dans les sections 1 et 2 du RFC. Cet objet d'exemple a un seul champ, Image, qui est un autre objet (entre { et }) et qui a plusieurs champs. Un de ces champs, IDs, a pour valeur un tableau.

JSON est donc un format simple, il n'a même pas la possibilité de commentaires dans le fichier... Voir sur ce sujet une intéressante compilation.

Voici un exemple d'un programme Python pour écrire un objet Python en JSON (on notera que la syntaxe de Python et celle de JavaScript sont très proches) : 

import json

objekt = {u'Image': {u'Width': 800,
                     u'Title': u'View from Smith\'s, 15th Floor, "Nice"',
                     u'Thumbnail': {u'Url':
                                    u'http://www.example.com/image/481989943',
                                    u'Width': u'100', u'Height': 125},
                     u'IDs': [116, 943, 234, 38793],
                     u'Height': 600}} # Example from RFC 4627, lightly modified

print json.dumps(objekt)

Et un programme pour lire du JSON et le charger dans un objet Python : 

import json

# One backslash for Python, one for JSON
objekt = json.loads("""
{
      "Image": {
          "Width":  800,
          "Height": 600,
          "Title":  "View from Smith's, 15th Floor, \\\"Nice\\\"", 
          "Thumbnail": {
              "Url":    "http://www.example.com/image/481989943",
              "Height": 125,
              "Width":  "100"
          },
          "IDs": [116, 943, 234, 38793]
        }
   }
""") # Example from RFC 4267, lightly modified

print objekt
print ""
print objekt["Image"]["Title"]

Si vous voulez le faire en Go, il existe un bon article d'introduction au paquetage standard json.

JSON dispose d'une page Web officielle, où vous trouverez plein d'informations.

Téléchargez le RFC 4627


L'article seul

RFC 3121: A URN Namespace for OASIS

Date de publication du RFC : Juin 2001
Auteur(s) du RFC : K. Best (Oasis), N. Walsh (Sun)
Pour information
Première rédaction de cet article le 30 juillet 2006

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

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

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

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

Téléchargez le RFC 3121


L'article seul

Fiche de lecture : The Art of UNIX Programming

Auteur(s) du livre : Eric Raymond
Éditeur : Addison-Wesley
0-13-142901-9

Première rédaction de cet article le 27 juillet 2006

Il existe de très nombreux livres de programmation. Et de très nombreux livres sur les détails pratiques de tel ou tel langage ou bien de tel ou tel environnement de programmation. Mais ce livre est original : il présente plutôt l'essence de la programmation sur Unix, pas les détails des outils mais plutôt comment faire des programmes qui soient bien conformes à l'esprit Unix.

Pas besoin de présenter Eric Raymond. L'un des meilleurs auteurs sur Unix et la programmation explique ici les principales caractéristiques d'Unix, pourquoi les programmes Unix sont comme ils sont et pourquoi il faut continuer. Par exemple, qu'il vaut mieux faire des petits programmes (Rule of Modularity), connectés par des interfaces simples (et pouvant donc être composés, comme on compose des fonctions), plutôt que des monstres comme OpenOffice, ininstallables et inutilisables sur un vieux PC et qui, surtout, ne permettent pas facilement de coopérer avec d'autres programmes.

Commme toujours avec Raymond, il présente toutes ses règles et aphorismes comme exprimant un consensus, alors que certaines sont plutôt personnelles. Des dix-sept règles qu'il présente, certaines (comme la Rule of Modularity donnée plus haut ou bien la Rule of Silence, qui dit qu'un programme doit se taire, sauf s'il a quelque chose d'utile à dire) seront en effet approuvées par tous les Unixiens mais ce n'est pas le cas de toutes.

Raymond, après avoir exposés les dix-sept règles, donne ensuite un bon cours de génie logiciel, qui est utilisable dans bien d'autres environnements qu'Unix. Il couvre un très grand nombre de sujets passionnants comme la conception de mini-langages. De nombreuses études de cas ponctuent son exposé.

Il passe ensuite à la mise en œuvre : quel langage de programmation choisir, quel système de contrôle de versions, la documentation, etc.

En résumé, un excellent livre, qui devrait être lu par tous les programmeurs et chefs de projet. Cela leur serait bien plus utile que de passer du temps à faire des diagrammes avec le dernier outil graphique à la mode.


L'article seul

RFC 3682: The Generalized TTL Security Mechanism (GTSM)

Date de publication du RFC : Février 2004
Auteur(s) du RFC : V. Gill, J. Heasley, D. Meyer
Expérimental
Première rédaction de cet article le 26 juillet 2006
Dernière mise à jour le 1 novembre 2007

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

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

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

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

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

Téléchargez le RFC 3682


L'article seul

Configurer Postfix pour authentifier avec un mot de passe

Première rédaction de cet article le 25 juillet 2006
Dernière mise à jour le 17 février 2008

Autrefois, tout était simple, tout serveur SMTP relayait le courrier de n'importe qui vers n'importe qui. Cette possibilité ayant été largement abusée par les spammeurs, les serveurs bien gérés n'acceptent désormais de relayer que pour leur réseau local. Mais cela laisse ouvert le problème des utilisateurs distants. Une des solutions est d'authentifier leurs connexions avec un mot de passe.

Le RFC 6409 fait obligation aux serveurs SMTP d'authentifier les soumissions de courrier (section 4.3. Require Authentication). Il existe plusieurs méthodes pour cela :

  • TLS, qui nécessite un certificat sur chaque client.
  • SASL qui va utiliser un mot de passe qui peut être transmis en clair (il faudra alors chiffrer la communication, par exemple en utilisant TLS, cette fois pour la confidentialité) ou bien utilisé dans un système de défi/réponse.

Le choix va dépendre de :

  • Si vous avez envie de gérer une PKI pour authentifier avec TLS.
  • Du type de clients humains que vous avez (mettre en place une solution de sécurité va vous faire passer du temps au téléphone, avec les utilisateurs).
  • Des logiciels qu'utilisent vos clients.
  • Des bases de données d'utilisateurs que vous avez (si vous comptez les réutiliser avec SASL).

Par exemple, je détaille ici la configuration du MTA Postfix sur une Debian. Un bon HOWTO est Postfix/SASL/TLS HowTo for Debian. (Pour TLS seul, un autre article décrit sa configuration pour Postfix.)

D'abord, je sépare le service de réception normal du courrier (sur le port 25) et le service de soumission de courrier par les utilisateurs authentifiés (cette séparation est dans la logique du RFC 6409). Dans master.cf, je mets : 

smtp      inet  n       -       -       -       -       smtpd

# smtpd_sasl_authenticated_header appeared only in Postfix 2.3
submission inet n      -       -       -       -       smtpd       -o smtpd_etrn_restrictions=reject -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_authenticated_header=yes

Ensuite, je dis à Postfix d'autoriser le relais de courrier pour les utilisateurs authentifiés en SASL. Dans main.cf, je mets : 

smtpd_recipient_restrictions = permit_sasl_authenticated, ...

# SASL options: only secure methods, without plain text
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_local_domain = $myhostname

Avant de recharger Postfix (postfix reload), j'installe les logiciels nécessaires : 

% sudo aptitude install postfix-tls libsasl2-modules sasl2-bin

Il reste à indiquer à SASL où trouver la base des utilisateurs. Dans sasl/smtpd.conf : 

pwcheck_method: auxprop
mech_list: digest-md5 cram-md5

lui dit d'utiliser sa propre base (/etc/sasldb2) et de ne publier que les méthodes d'authentification à base de défi/réponse. On remplit ensuite la base : 

sudo saslpasswd2 -u mail.bortzmeyer.org -c stephane
sudo sasldblistusers2  # Pour vérifier

Faites attention au domaine donné par l'option -u : il doit coïncider avec la variable myhostname de Postfix. Sinon, on obtiendra des messages du genre no secret in database. Attention également au chroot : comme le paquetage Debian de Postfix utilise chroot, il faudra copier la base des utilisateurs dans la chroot (sudo cp /etc/sasldb2 /var/spool/postfix/etc, cela n'est pas fait automatiquement (sauf par cron, de temps en temps), on risque donc des No such file or directory très déroutants dans le journal de Postfix).

On peut ensuite tester avec un client SASL. Cela peut être un Postfix mais je trouve msmtp plus simple pour des tests. Avec cette configuration : 

account bortzmeyer
host mail.bortzmeyer.org
port 587
from stephane@bortzmeyer.org
auth on
user stephane
password VRAIMENTSECRET

ma machine se connecte au port de soumission et s'authentifie. Postfix logue : 

Jul 25 10:57:14 ariane postfix/submission[31542]: 25DFE240814: client=batilda.nic.fr[192.134.4.69], sasl_method=DIGEST-MD5, sasl_username=stephane@mail.bortzmeyer.org

Si on veut utiliser mutt, il peut parler directement à un tel serveur SMTP, en mettant dans le .muttrc : 

set smtp_url="smtp://stephane@mail.bortzmeyer.org:587/

Avec Thunderbird, cela serait Secure Authentication: yes et Connection Security: STARTTLS.

Autre façon de tester, depuis un programme Python, comme expliqué en http://www.mkyong.com/python/how-do-send-email-in-python-via-smtplib/.

Pour terminer de mettre en œuvre complètement le RFC 6409, il faudrait aussi, idéalement :

Merci beaucoup à Noel Jones pour son aide et ses explications.

Comme conclusion pessimiste, notons que, dans la réalité de l'Internet, il y aura toujours un logiciel bogué pour mettre en cause les plus belles configurations. Par exemple, Eudora sur MS-Windows a bien une option "Use port 587" mais, qu'elle soit cochée ou pas, Eudora utilise toujours le port 25 :-(. Heureusement, Thunderbird n'a pas ce problème.


L'article seul

Recherche d'une fonction par sa signature

Première rédaction de cet article le 18 juillet 2006

Un des avantages des langages de programmation typés, c'est qu'ils permettent de rechercher une fonction par son type, donc par l'API souhaitée. C'est ce que permet, par exemple, le moteur de recherche Hoogle.

Haskell est un langage de programmation typé. Toute fonction a une signature, qui comprend le type des paramètres d'entrée et le type du résultat. Cela permet de détecter beaucoup de bogues dès la compilation. Et cela sert de contrat : la signature indique ce que la fonction est capable de faire. À noter qu'il n'est en général pas besoin de déclarer ces types, ils sont trouvés automatiquement par inférence de types.

Un environnement de programmation comme ghc permet d'afficher ladite signature: 

 *Main> :t mkRegex
 mkRegex :: String -> Regex

Ici, la fonction mkRegex prend une chaîne de caractères (String) en paramètre et rend une Regex .

De même, le mode Haskell de l'éditeur Emacs affiche la signature d'une fonction lorsque le curseur passe devant.

On peut pousser cela plus loin et permettre de recherche une fonction par sa signature. Supposons qu'on aie une liste de chaînes de caractères et qu'on veuille les concaténer en une seule. On cherche donc une fonction capable de faire [String] -> String ([Foo] signifie une liste de Foo). Il suffit de taper cette signature dans Hoogle et on obtient : 

Prelude.	unlines	:: [String] -> String
Prelude.	unwords	:: [String] -> String
...

(Prélude est la bibliothèque standard de Haskell.) Voici deux fonctions qui conviennent tout à fait et, notamment, unlines est exactement ce que l'on cherche : 

let result = unlines mylist

Il existe une fonction plus générale, fold, que Hoogle trouve aussi, et qui permettrait d'écrire : let result = foldl (++) "" mylist.

De même, si j'ai oublié le nom de la fonction qui permet de produire un tableau à partir d'un élément et d'un nombre de répétitions (une telle fonction est utile par exemple pour du formatage de données), je cherche  a -> Int -> [a] et je trouve tout de suite replicate (qui me permet ensuite de faire des choses comme replicate 3 '0' pour obtenir "000").

À noter que le bot IRC qui écoute sur le canal #haskell de irc.freenode.net a une interface à Hoogle : 

(16:55:00) bortzmeyer: @hoogle CalendarTime -> String
(16:55:01) lambdabot: Time.calendarTimeToString :: CalendarTime -> String
(16:55:01) lambdabot: System.Time.ctTZName :: CalendarTime -> String
(16:55:01) lambdabot: Time.formatCalendarTime :: TimeLocale -> String -> CalendarTime -> String

L'article seul

RFC 3797: Publicly Verifiable Nominations Committee (NomCom) Random Selection

Date de publication du RFC : Juin 2004
Auteur(s) du RFC : D. Eastlake (Motorola)
Pour information
Première rédaction de cet article le 17 juillet 2006
Dernière mise à jour le 25 juin 2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Téléchargez le RFC 3797


L'article seul

RFC 4589: Location Types Registry

Date de publication du RFC : Juillet 2006
Auteur(s) du RFC : H. Schulzrinne (Columbia University), H. Tschofenig (Siemens)
Chemin des normes
Première rédaction de cet article le 17 juillet 2006
Dernière mise à jour le 25 février 2021

L'IETF s'occupe de tout : voici un RFC pour normaliser les noms de lieux. Le but est d'exprimer de manière standardisée l'endroit où se trouve un appareil mobile, de façon à pouvoir changer son comportement (par exemple, un téléphone mobile s'abstiendra de sonner s'il est dans un place-of-worship, A religious site where congregations gather for religious observances, such as a church, chapel, meetinghouse, mosque, shrine, synagogue, or temple.)

La mobilité étant à la mode, de plus en plus d'appareils sont capables de savoir où ils sont. Par exemple, avec un récepteur de position via des satellites (comme le système GPS), l'appareil peut connaitre sa latitude et sa longitude. Mais cela ne lui dit pas comment il doit se comporter. Pour cela, il a besoin d'une information différente. Or, si la manière d'exprimer la longitude et la latitude est normalisée depuis longtemps, celle d'indiquer le type de lieu où on se trouve ne l'était pas.

C'est chose faite avec ce RFC, qui décrit des termes standards, conçus pour être automatiquement traités (et donc pas affichés à un humain). On y trouve airport, hospital mais aussi bar (qui est distinct de cafe), ces termes n'étant pas exclusifs (on peut être en même temps dans restaurant, airport et public).

L'ensemble des types possibles de lieux est dans un registre IANA, et on peut en ajouter des nouveaux par la procédure « Examen par un expert » (RFC 8126).

Téléchargez le RFC 4589


L'article seul

RFC 2826: IAB Technical Comment on the Unique DNS Root

Date de publication du RFC : Mai 2000
Auteur(s) du RFC : Internet Architecture Board
Pour information
Première rédaction de cet article le 9 juillet 2006

C'est un RFC très politique et qui est donc signé par tout l'IAB. Il explique l'importance d'avoir une racine unique pour le DNS.

Les RFC qui décrivent techniquement le DNS spécifient le protocole, le format de paquets... et l'organisation des données sous forme d'un arbre. Mais ils ne précisent pas si cette arbre doit être unique ou pas. Actuellement, l'écrasante majorité des utilisateurs de l'Internet utilisent le même arbre, celui dont la racine est géré par une marionnette du gouvernement états-unien, l'ICANN. Or, il existe d'autres arbres, parfois sérieux comme ORSN (que j'utilise à la maison, donc en ce moment) et parfois fantaisistes ou malhonnêtes. Chacun de ces arbres (on dit souvent "chacune de ces racines") a sa propre liste de TLD et un nom de domaine n'a donc pas forcément la même signification partout.

Alors, faut-il promouvoir ou au contraire décourager l'usage de ces racines, parfois pompeusement nommées "racines alternatives" (alors que la plupart ne comptent que quelques PC dans des garages) ? Notre RFC est la réponse officielle de l'IAB sur ce sujet. Il commence par annoncer clairement qu'il est nécessaire de garder une racine unique. Le principal argument est que la multiplicité des racines n'empêcherait pas la communication (puisque c'est le même protocole DNS) mais lui ferait perdre sa sémantique, puisque le même URL pourrait mener à deux pages Web différentes ou que la même adresse de courrier pourrait arriver à un destinataire ou à l'autre selon la racine DNS utilisée.

À noter que l'équivalent politicien de notre RFC est le document ICP-3 de l'ICANN, où l'ICANN proclame son refus de toute concurrence.

L'argument de l'IAB est tout à fait juste (si on veut qu'un nom soit sans ambigüité, il faut une racine unique). Mais l'IAB va souvent trop loin en faisant de cette contrainte bien raisonnable une sorte de loi de la nature, qui serait imposée par le protocole DNS lui-même. Le RFC oscille en permanence entre des rappels pratiques très justes et des affirmations parfois imprudentes sur la nécessaire unicité de tout nom.

Téléchargez le RFC 2826


L'article seul

RFC 4504: SIP Telephony Device Requirements and Configuration

Date de publication du RFC : Mai 2006
Auteur(s) du RFC : H. Sinnreich (pulver.com), S. Lass (Verizon), C. Stredicke (Snom)
Pour information
Première rédaction de cet article le 29 juin 2006

Le succès de SIP dans le monde de la téléphonie sur IP a entrainé une floraison de RFC sur le sujet (seize aujourd'hui). L'implémenteur de SIP a de plus en plus de mal à s'y retrouver, d'où ce RFC d'information, qui regroupe en un endroit toutes les informations nécessaires pour le réalisateur d'un téléphone SIP.

Il existe plusieurs sortes de clients SIP (on dit UAC pour User Agent Client). Il y a des téléphones traditionnels, des PDA améliorés, mais aussi des soft phones, des téléphones entièrement logiciels, tournant sur un PC ordinaire.

Les règles de notre RFC s'appliquent à tous : des plus triviales aux plus essentielles, notre RFC liste 93 obligations pour les téléphones SIP, à la fois pour assurer l'interopérabilité et pour être sûr que leur utilisateur bénéficie d'un minimum de fonctions.

Par exemple, l'obligation 40 est que le téléphone doit pouvoir être mis dans un mode "muet", pour ne pas déranger l'entourage (par contre, il n'est pas nécessaire de transmettre cette information au réseau avant l'appel).

Autre exemple, l'obligation 92 dit que le téléphone SIP doit pouvoir appeler un URI SIP (de façon à éviter qu'ENUM devienne une obligation). Cela lui impose un clavier ou dispositif équivalent.

Téléchargez le RFC 4504


L'article seul

RFC 4436: Detecting Network Attachment in IPv4 (DNAv4)

Date de publication du RFC : Mars 2006
Auteur(s) du RFC : B. Aboba (Microsoft), J. Carlson (Sun), S. Cheshire (Apple)
Chemin des normes
Première rédaction de cet article le 27 juin 2006

Plusieurs protocoles permettent à une machine d'obtenir une adresse IPv4, par exemple DHCP ou bien le protocole des adresses Link-Local décrit dans le RFC 3927. Mais notre RFC est le premier qui s'attache à décrire leurs interactions, surtout lorsque la machine change de réseau et doit détecter ce changement le plus vite possible, pour réacquérir une nouvelle adresse.

Le principe de DNA (Detecting Network Attachment) est simplement d'envoyer une requête ARP au dernier routeur connu. Contrairement à la requête ARP classique, le client DNA n'utilise pas la diffusion mais envoie un paquet unicast. S'il reçoit une réponse, et qu'elle a bien l'adresse MAC source attendue, tout est bon.

Ainsi, la machine qui vient de changer de réseau ou qui soupçonne que cela a pu être le cas (ce qui est courant en Wi-Fi où la connectivité va et vient), peut très rapidement vérifier que son adresse IP marche toujours. DNA n'est pas indispensable, ce n'est qu'une optimisation (et qui n'est acceptable que pour les adresses allouées par DHCP), mais qui aidera beaucoup les machines dont la liaison avec le réseau n'est pas réellement permanente.

Téléchargez le RFC 4436


L'article seul

Indexer un blog, avec ses pages aux sujets variés

Première rédaction de cet article le 26 juin 2006

Un truc très agaçant avec tous les moteurs de recherche est leur comportement lorsqu'une page contient des articles très divers et sans lien entre eux (deux cas typiques : les blogs et les archives de listes de diffusion). Le moteur voit tous les mots-clés sur la page et ne comprend pas les frontières entre articles. Ainsi, je vois (dans le journal du serveur Web) un malheureux arriver sur une page après avoir tapé "freebsd ldap" dans Google alors que la page a bien un article sur LDAP et un sur FreeBSD mais qu'ils ne sont pas reliés... Cela donne souvent des résultats surréalistes.

Altavista avait l'opérateur NEAR qui aidait beaucoup à résoudre ce problème. Mais je ne connais aucun moteur actuel qui l'utilise.

Il semble que la solution (mal documentée) soit de mettre dans la section <head> de ses pages HTML, lorsqu'elles sont de type "navigation" (et contiennent donc des articles sans rapport entre eux) : 


<meta name="robots" content="noindex,follow">

Cela semble bien fonctionner avec Google (qui le documente). Mais apparemment pas avec des concurrents comme Exalead.

J'utilise désormais ce <meta> sur toutes mes pages de navigation et je mets : 


<meta name="robots" content="index,follow">

dans les pages ordinaires, celles qui contiennent un article et un seul.


L'article seul

RFC 4409: Message Submission for Mail

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : R. Gellens (Qualcomm), J. Klensin
Chemin des normes
Première rédaction de cet article le 26 juin 2006

Pendant longtemps, le système de courrier électronique de l'Internet ne faisait aucune différence entre le serveur de messagerie et le simple PC de l'utilisateur. Tous utilisaient le même protocole SMTP, spécifié dans le RFC 2821. Depuis le RFC 2476 et plus encore depuis ce nouveau RFC, ce n'est plus vrai. Le simple PC doit désormais utiliser une autre solution, la soumission de message. (Ce RFC a depuis été mis à jour dans le RFC 6409.)

L'ancienne architecture était raisonnable à l'époque où toutes les machines connectées à l'Internet étaient de gros serveurs gérés par des professionnels. Ceux-ci pouvaient faire en sorte que tout soit correctement configuré. Et, donc les autres serveurs, les MTA pouvaient ériger en principe le "Pas touche" et ne jamais modifier ou contester un message reçu.

Aujourd'hui, avec le nombre de micro-ordinateurs non gérés qui sont connectés à Internet, cela n'est plus possible. Le RFC 2476 avait donc séparé les clients SMTP en deux catégories : les MTA qui se connectent au port traditionnel, le numéro 25 et les MUA qui, s'ils veulent envoyer en SMTP, doivent utiliser un autre service, tournant en général sur le port 587, et soumis à d'autres règles :

  • Le serveur est autorisé à modifier le message (par exemple en ajoutant des en-têtes comme Date ou Message-ID s'ils sont absents ou incorrects),
  • Une authentification est souvent requise, surtout si le port de soumission est accessible de tout l'Internet.

Notre RFC, qui remplace le RFC 2476, et a été lui-même remplacé par le RFC 6409, pose en principe que, désormais, les machines des simples utilisateurs devraient désormais utiliser ce service.

Si vous utilisez Postfix, vous pouvez lire un exemple de configuration de Postfix conforme (partiellement) à ce RFC.

Téléchargez le RFC 4409


L'article seul

RFC 4459: MTU and Fragmentation Issues with In-the-Network Tunneling

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : P. Savola (CSC/Funet)
Pour information
Première rédaction de cet article le 12 juin 2006

Les problèmes liés à la MTU des liens Internet empoisonnent la vie des administrateurs du réseau et parfois de ses utilisateurs. Ce RFC étudie en détail un cas particulier, celui des tunnels qui, en réduisant la MTU, requièrent des mesures comme la fragmentation (le découpage d'un paquet de données en paquets plus petits).

Si tous les liens utilisés pour les connexions Internet avaient la même MTU, tout irait bien. Mais ce n'est pas le cas et il faut donc, soit détecter la MTU maximale du chemin (PMTU pour Path MTU), soit laisser les routeurs fragmenter les paquets en paquets plus petits (le RFC décrit aussi d'autres solutions, moins communes).

Aucune solution n'est parfaite et le RFC explique bien pourquoi, par exemple parce que certains coupe-feux bloquent (stupidement) l'ICMP. Chacun des cas est étudié en détail, mais aucune solution générale ne semble possible dans l'Internet actuel. Cette réflexion a fini par mener à un tout nouveau mécanisme, décrit dans le RFC 4821.

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

Téléchargez le RFC 4459


L'article seul

Identificateurs : nommer les choses

Première rédaction de cet article le 2 juin 2006
Dernière mise à jour le 26 juillet 2006

Il existe aujourd'hui d'innombrables identificateurs pour désigner des ressources ou des personnes : les noms de domaine, les numéros de téléphone, les adresses IP, les NIR, etc. Je viens de faire un exposé sur les caractéristiques de ces identificateurs, pour aider à en choisir un pour une nouvelle application Internet.

Parmi les caractéristiques des identificateurs, on trouve :

  • Unicité : l'identificateur désigne t-il une ressource unique (comme le fait un URL ou est-il ambigü, comme, par exemple, un tag de del.icio.us ?
  • Permanence : l'identificateur est-il stable dans le temps, comme le sont les URI du RFC 4151 ou bien volatile comme le sont en général les adresses IP ?
  • Et bien d'autres...

Pour le problème spécifique de la difficulté de réunir toutes les caractéristiques souhaitables à la fois, voir mon autre article « Inventer un meilleur système de nommage : pas si facile ».

Voir les transparents de l'exposé pour en savoir plus.

À noter un excellent article de Norman Walsh sur son blog, pour expliquer que les soi-disant nouveaux schémas de nommage sont souvent des nouveaux rackets pour des registres jaloux du succès de Verisign. Et pour argumenter qu'on peut tout faire avec des URI de type "http".


L'article seul

Stocker et récupérer de l'Unicode dans PostgreSQL

Première rédaction de cet article le 30 mai 2006
Dernière mise à jour le 9 novembre 2007

Ayant récemment eu à stocker et récupérer de l'Unicode dans une base de données PostgreSQL, j'en profite pour expliquer brièvement comment cela marche.

PostgreSQL est un excellent logiciel libre de gestion de base de données. Il permet notamment de stocker les données de type texte sous différents encodages. Tout le processus est bien documenté sur leur site Web.

Au moment où on crée une nouvelle base, on peut spécifier l'encodage de celle-ci. Je recommande toujours l'encodage UNICODE (qui est en fait de l'UTF-8, celui qui a choisi le terme UNICODE n'avait pas forcément saisi les subtilités d'Unicode mais, depuis la version 8.1, PostgreSQL permet le terme correct, "UTF-8"). Cela permet de stocker tous les caractères possibles et imaginables.

Pour manipuler des caractères, il vaut mieux suivre deux règles simples :

  • Choisir un encodage canonique et s'y tenir (ici, UTF-8, que PostgreSQL nommait UNICODE),
  • Ne faire les éventuelles conversions qu'une fois (que ce soit en entrée ou en sortie) de façon à pouvoir se souvenir de quel est l'encodage utilisé.

Ici, je vais supposer que les applications préfèrent du Latin-1. Si on n'a pas besoin de conversion, c'est encore plus simple.

Un avertissement préalable (merci à Daniel Verite pour ses explications) : il vaut mieux que la structure des bases de données aie été créée avec le même encodage que les bases. Comme le dit la documentation de PostgreSQL, For these reasons it is important to choose the right locale when running initdb.. Donc, si vous prévoyez des bases en UTF-8, il vaut mieux avoir fait tourner initdb avec cet encodage. Comme par défaut, initdb utilise la locale courante, on peut facilement se tromper. On installe PostgreSQL, on lance (ou bien le système de paquetages lance pour vous) initdb et il utilise la mauvaise locale. Si vous obtenez ce genre de bogues : 

postgres=# create database u8 encoding 'UTF8';
CREATE DATABASE
postgres=# \c u8
...
postgres=# set client_encoding=latin1;
SET
u8=# select lower('à')
ERROR:  invalid byte sequence for encoding "UTF8": 0xe3a0
HINT:  This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".

c'est probablement à cause de cette incohérence.

Pour l'éviter, je suggère que tout sur le serveur soit en UTF-8. Donc, (re)lancer initdb ainsi (la commande convient pour une Debian, d'autres systèmes d'exploitation peuvent mettre initdb ou bien le répertoire contenant les bases ailleurs) : 

     %  /usr/lib/postgresql/$PG_VERSION/bin/initdb --encoding=UTF8 --locale=fr_FR.UTF8 --pgdata=/var/lib/postgresql/$PG_VERSION/main

et s'assurer que le serveur a bien une locale UTF-8. Par exemple, dans le paquetage Debian, je mets : 

LC_CTYPE=fr_FR.UTF8

dans /etc/postgresql/$PG_VERSION/main/environment.

Une fois passé ce piège, je crée la base (si on a suivi les conseils précédents, l'option --unicode est facultative) : 

      %  createdb --encoding UNICODE ${DB} 
      %  psql -f ./create.sql ${DB}

où le fichier create.sql contient : 

CREATE TABLE Adresses (
   id SERIAL UNIQUE NOT NULL,
   prenom TEXT,
   nom TEXT
);

Je peux ensuite remplir la base. D'abord, utilisons psql, l'interface ligne de commandes de PostgreSQL (je me méfie des cliquodromes) : 

   % psql -f ./insert-utf8.sql ${DB}

où insert-utf8.sql contient du bel UTF-8 : 

INSERT INTO Adresses (Prenom, Nom)
   VALUES ('Stéphane', 'Bortzmeyer');
INSERT INTO Adresses (Prenom, Nom)
   VALUES ('Pierre', 'Louÿs');

Si on préfère que le fichier soit en Latin-1, parce qu'on édite plus facilement du Latin-1, rien de plus simple, mais il faut l'indiquer à PostgreSQL : 

SET CLIENT_ENCODING='iso-8859-1';

INSERT INTO Adresses (Prenom, Nom)
   VALUES ('Stéphane', 'Bortzmeyer');
INSERT INTO Adresses (Prenom, Nom)
   VALUES ('Pierre', 'Louÿs');

et 

 %  psql -f ./insert-latin1.sql ${DB}

produira le résultat attendu.

L'interêt de gérer des fichiers UTF-8 est que cela permet de représenter des caractères qui n'existent pas dans Latin-1. Si vous n'avez affaire qu'à des noms français, ce n'est pas un problème mais supposons que vous vouliez enregistrer le nom d'une célèbre physicienne d'origine polonaise, dont le nom comporte le caractère Unicode U+0142 (LATIN SMALL LETTER L WITH STROKE), qui existe en Latin-2 mais pas en Latin-1, vous pouvez alors : 

INSERT INTO Adresses (Prenom, Nom)
   VALUES ('Marii', 'Curie-Skłodowskiej');

et ces caractères coexisteront sans problèmes avec ceux utilisés en français. C'est bien pour cela qu'Unicode a été inventé.

Le support d'Unicode dans PostgreSQL n'est pas sans faille. La recherche avec les expressions rationnelles, par exemple, ne fonctionne que partiellement : 

carnet=> SELECT * FROM adresses WHERE prenom ~ 'St.phane';
 id |  prenom  |    nom     
----+----------+------------
 19 | Stéphane | Bortzmeyer
(2 rows)

carnet=> SELECT * FROM adresses WHERE prenom ~ 'St\wphane';
 id | prenom | nom 
----+--------+-----
(0 rows)

Le point (qui remplace n'importe quel caractère) a bien fonctionné (PostgreSQL comprend bien la différence entre un caractère et un octet, le caractère é s'écrivant avec deux octets en UTF-8) mais le \w qui veut normalement dire "un caractère alphanumérique" n'a pas été compris.

De même, je n'ai pas pu faire fonctionner la capitalisation pour l'opérateur ILIKE (comme LIKE, mais insensible à la casse) : 

carnet=> SELECT * FROM adresses WHERE prenom ILIKE '%stéphane%';
 id |  prenom  |    nom     
----+----------+------------
  5 | Stéphane | Bortzmeyer
(1 rows)

carnet=> SELECT * FROM adresses WHERE prenom ILIKE '%STÉPHANE%';
 id | prenom | nom 
----+--------+-----
(0 rows)

C'est le genre de petits problèmes agaçants qu'on rencontre souvent avec Unicode.

Affichons maintenant ce qu'on a enregistré. psql -c "SELECT * FROM Adresses" ${DB} suffit mais, si la console utilisée est en Latin-1, il faut le demander : 

   PGCLIENTENCODING=iso-8859-1 psql -c "SELECT * FROM Adresses" ${DB}

Et on voit bien les caractères, qu'ils aient été entrée en UTF-8 ou bien en Latin-1 : 

 id |  prenom  |    nom     
----+----------+------------
  5 | Stéphane | Bortzmeyer
  6 | Pierre   | Louÿs
  7 | Stéphane | Bortzmeyer
  8 | Pierre   | Louÿs
(4 rows)

(Naturellement, les noms qui ne sont pas représentables en Latin-1 seront malmenés.)

Si maintenant, on veut traiter ces données dans un programme, c'est également possible, ici en Python : 

#!/usr/bin/python

import psycopg
import sys

db_encoding = "UTF-8"

if len(sys.argv) <= 1:
    sys.stderr.write("Usage: %s database [encoding]\n" % sys.argv[0])
    sys.exit(1)

db = sys.argv[1]
if len(sys.argv) > 2:
    def tr(text):
        return text.decode(db_encoding).encode(sys.argv[2], 'replace')
else:
    def tr(text):
        return text
    
connection = psycopg.connect("dbname=%s" % db)
cursor = connection.cursor()

cursor.execute("""
   SELECT prenom,nom FROM Adresses
   """)
for mytuple in cursor.fetchall():
    sys.stdout.write("%s %s\n" % (tr(mytuple[0]), tr(mytuple[1])))

cursor.close()
connection.close()

Ce programme va lire les données de la base, il peut les convertir en Unicode (Python manipule nativement l'Unicode), pour traitement (text.decode(db_encoding)) et les mettre dans l'encodage souhaité pour l'affichage (unicode_string.encode(myencoding, 'replace')).

Si on souhaite publier sur le Web, on a tout intérêt à publier en UTF-8, puisque tous les outils Web savent le gérer. Il faut juste penser à indiquer cet encodage au client Web (les détails dépendent du serveur HTTP utilisé).

Tous ces programmes ont été testés avec PostgreSQL 7.4 et 8.1.


L'article seul

RFC 4423: Host Identity Protocol (HIP) Architecture

Date de publication du RFC : Mai 2006
Auteur(s) du RFC : R. Moskowitz (ICSA Labs), P. Nikander (Ericsson)
Pour information
Réalisé dans le cadre du groupe de travail IETF hip
Première rédaction de cet article le 29 mai 2006
Dernière mise à jour le 21 avril 2008

Voici un RFC très ambitieux : il s'agit tout simplement de changer radicalement l'architecture de l'Internet en utilisant un nouveau type d'identificateur, le Host Identifier (HI) pour beaucoup d'usages qui sont actuellement ceux des adresses IP.

Une adresse IP sert actuellement à deux choses : désigner une machine (l'adresse IP sert par exemple à distinguer plusieurs connexions en cours) et indiquer comment la joindre (routabilité). Dans le premier rôle, il est souhaitable que l'adresse soit relativement permanente, y compris en cas de changement de FAI ou de mobilité (actuellement, si une machine se déplace et change d'adresse IP, les connexions TCP en cours sont cassées). Dans le second cas, on souhaite au contraire une adresse qui soit le plus "physique" possible, le plus dépendante de la topologie. Ces deux demandes sont contradictoires. (HIP est depuis normalisé dans un RFC plus récent, le RFC 9063.)

HIP résout le problème en séparant les deux fonctions. Avec HIP, l'adresse IP ne serait plus qu'un identifiant "technique", ne servant qu'à joindre la machine, largement invisible à l'utilisateur et aux applications (un peu comme une adresse MAC aujourd'hui).

Pour pouvoir être vérifié, le nouvel identificateur, le HI sera une clé publique cryptographique, qui sera allouée hiérarchiquement par PKI ou de manière distribuée par tirage au sort (comme le sont les clés SSH ou PGP aujourd'hui).

Cette séparation de l'identificateur et du localisateur est un sujet de recherche très actif actuellement et d'autres propositions que HIP existent.

Soyons patients : si la spécification du protocole est désormais publiée (notre RFC ne décrivait qu'une architecture générale, il est complété par les RFC 5201, RFC 5202, RFC 5203, RFC 5204, RFC 5205, RFC 5206 et RFC 5207, on peut consulter les projets sur la page Web du groupe de travail HIP) et, si des implémentations expérimentales existent déjà et que des serveurs publics utilisent HIP, aucun déploiement significatif n'est encore en vue. (Depuis, HIP v1 a été remplacé par HIP v2, normalisé dans le RFC 7401, puis dans le RFC 9063.)

Téléchargez le RFC 4423


L'article seul

RFC 4406: Sender ID: Authenticating E-Mail

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : J. Lyon (Microsoft), M. Wong (pobox.com)
Intérêt historique uniquement
Première rédaction de cet article le 26 mai 2006

On le sait, le courrier électronique, tel qu'il est spécifié dans les RFC 2821 et RFC 2822, ne fournit aucune authentification, même faible, de l'émetteur. Un expéditeur de courrier peut toujours prétendre être Nicolas Sarkozy <iznogoud@jeveuxetrealelysee.fr> et il n'y a aucun moyen de l'en empêcher. Sender ID vise à diminuer cette facilité de frauder en permettant à un titulaire de nom de domaine de déclarer quelle(s) adresse(s) IP sont autorisées à envoyer du courrier pour ce domaine. (L'expérience a été abandonnée par la suite, et reclassifiée « intérêt historique seulement », en février 2020.)

Sender ID est un concurrent de SPF. SPF avait été spécifié à l'origine (pas dans un RFC mais dans un processus informel) puis, dans le cadre du défunt groupe de travail MARID de l'IETF, une tentative de fusion entre SPF et le protocole de Microsoft, Caller ID, avait été tentée et avait donné naissance à Sender ID.

Sender ID partage donc beaucoup des caractéristiques de SPF (spécifié dans le RFC 4408). Les principales différences sont :

  • Sender ID marque ses enregistrements avec "spf/2.0" et pas avec "v=spf1" mais, si ceux-ci ne sont pas présents, Sender ID utilise les enregistrements SPF, mais en leur donnant un sens différent (ce qui n'aurait jamais dû être accepté par l'IESG et a fait l'objet d'un appel, malheureusement repoussé),
  • Sender ID authentifie surtout une adresse tirée des en-têtes (via l'algorithme PRA, spécifié dans le RFC 4407).

Il est amusant de noter qu'AOL est un des rares domaines à publier à la fois du SPF et du Sender ID : 

% dig +short TXT aol.com 
"spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"
"v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

alors que Microsoft, auteur et principal promoteur de Sender ID ne publie que du SPF.

En même temps que notre RFC a été publié le RFC 4408 sur SPF. SPF, comme Sender ID, avait été discuté dans le groupe de travail MARID, groupe qui avait été autoritairement dissous avant d'avoir atteint un consensus. Malgré le déploiement bien plus important de SPF, l'IESG a choisi de traiter les deux propositions de manière égale et de publier les deux RFC comme expérimentaux. C'est seulement en 2012, avec la publication du RFC 6686, que l'IETF a reconnu que Sender ID n'avait connu aucun déploiement significatif et que SPF restait seul en lice.

Téléchargez le RFC 4406


L'article seul

RFC 1876: A Means for Expressing Location Information in the Domain Name System

Date de publication du RFC : Janvier 1996
Auteur(s) du RFC : Christopher Davis (Kapor Enterprises, Inc.), Paul Vixie (Vixie Enterprises), Tim Goodwin (Public IP Exchange Ltd (PIPEX)), Ian Dickinson (FORE Systems)
Expérimental
Première rédaction de cet article le 24 mai 2006

Ce n'est pas une question de vie ou de mort pour l'Internet mais il est quand même bien agréable de pouvoir spécifier la localisation physique d'une machine, en indiquant sa latitude et sa longitude. Notre RFC permet de le faire dans le DNS.

Les applications possibles sont nombreuses : un traceroute un peu plus explicite, par exemple, ou bien un lien direct vers Google Maps ou encore le guidage automatique d'un missile intercontinental vers sa cible. Une mise en œuvre complète du RFC, en logiciel libre, se trouve dans le répertoire contrib/query-loc de BIND (à partir de la version 9.3).

Le système fonctionne avec des enregistrements de type LOC. Voici un exemple pour nic.af : 

% dig +short LOC nic.af. 
34 31 0.000 N 69 12 0.000 E 1000.00m 1000m 10000m 10m

qui nous indique que le NIC afghan se trouve à 34°31 de latitude Nord et 69°12 de longitude Est (soit à Kaboul). Les chiffres supplémentaires dans l'enregistrement indiquent la précision, y compris en hauteur.

www.bortzmeyer.org n'a pas aujourd'hui d'enregistrement LOC. La zone est gérée par le registrar, Gandi, via une interface qui ne permettait pas ce type de données. C'est désormais possible (LOC est un des choix possibles lors de l'édition de la zone sur le Web de Gandi) mais l'interface est peu pratique (il faut tout calculer soi-même) donc cela attendra.

Notre RFC permet aussi de trouver un enregistrement LOC à partir d'une adresse IP. Par exemple, pour 130.104.3.1 :

  • On cherche si cette adresse IP a un nom (ce n'est pas le cas),
  • On cherche si son réseau a un nom (et on le trouve, 0.0.104.130.in-addr.arpa nous mène vers uclouvain.sri.ucl.ac.be),
  • On cherche alors le LOC du réseau (et on trouve 50°40 Nord et 4°37 Est, à Louvain-la-Neuve en Belgique).

En pratique, notre RFC n'a pas été un grand succès. Très peu d'enregistrements de type LOC se trouvent aujourd'hui dans Internet, ce qui réduit l'intérêt des applications qui les utilisent. Si on veut faire de la géolocalisation, il faut donc plutôt compter sur des bases de données plus ou moins informelles et de plus ou moins bonne qualité, souvent obtenues à partir des bases des RIR.

On trouvera plus de détails sur les enregistrements LOC en http://www.ckdhr.com/dns-loc ou en http://blog.fupps.com/2010/11/14/where-is-your-dns-server-located/. Il existe des services sur le Web qui transforment un nom de domaine en carte, en utilisant les enregistrements LOC, comme http://idefix.net/~koos/kismet/loc2map.php ou http://hewgill.com/tools/dnsloc.

Une utilisation amusante des LOC est celle qui permet de trouver la longitude et la latitude d'un point au Royaume-Uni d'après son code postal, via le domaine find.me.uk : 

% dig TW110LW.find.me.uk. LOC +short
51 25 35.560 N 0 20 38.043 W 0.00m 0.00m 0.00m 0.00m

(C'était l'adresse du NPL à Teddington.)

Un service équivalent existe pour la France, ici pour Villequier : 

% dig +short +nodnssec LOC 76490.cp.bortzmeyer.fr
49 32 58.987 N 0 41 15.835 E 0.00m 1m 10000m 10m

Un autre service amusant avec ces enregistrements est le résolveur DNS latlon.v4.powerdns.org qui retourne un enregistrement LOC correspondant à la géolocalisation de votre résolveur DNS : 

% dig +short LOC latlon.v4.powerdns.org  
48 53 33.007 N 2 20 39.840 E 0.00m 1m 10000m 10m

Vous pouvez voir des enregistrements LOC à travers un DNS Looking Glass, par exemple https://dns.bortzmeyer.org/TW110LW.find.me.uk/LOC.

Téléchargez le RFC 1876


L'article seul

RFC 4405: SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : E. Allman (Sendmail), H. Katz (Microsoft)
Intérêt historique uniquement
Première rédaction de cet article le 23 mai 2006

Une petite extension au protocole SMTP pour permettre d'indiquer, lors de l'envoi de l'enveloppe du message (et non pas dans ses en-têtes) l'expéditeur responsable de l'envoi (responsible submitter). (L'expérience a été abandonnée par la suite, et reclassifiée « intérêt historique seulement », en février 2020.)

On le sait, authentifier l'expéditeur d'un courrier électronique bute souvent sur un problème tout bête : quel expéditeur choisir ? Dans le cas simple, la réponse est évidente. Mais si le message a fait l'objet d'une retransmission ? Ou s'il a été reçu via une liste de diffusion ? Quel est alors l'expéditeur à authentifier ? Il y a eu des propositions (comme l'algorithme PRA du RFC 4407) pour extraire un expéditeur supposé depuis les en-têtes (le contenu du message, spécifié dans le RFC 2822). Mais beaucoup de MTA n'ont pas un accès facile à ces en-têtes et préféreraient filtrer sur les informations contenues dans l'enveloppe (l'information d'acheminement du message, spécifiée dans le RFC 2821).

C'est ce que leur permet notre RFC. Ici, dans une session SMTP, le client indique l'expéditeur avec la classique commande MAIL FROM et le vrai responsable, trouvé par l'algorithme PRA, avec la nouvelle extension SUBMITTER : 

MAIL FROM:<alice@example.org> SUBMITTER=bob@mobile.example

Le MTA peut donc authentifier l'expéditeur avec Sender-ID avant même d'avoir vu le message (et donc les en-têtes).

Téléchargez le RFC 4405


L'article seul

Noir austral

Première rédaction de cet article le 19 mai 2006

« Noir austral », le deuxième roman de Christine Adamo se déroule pour moitié dans l'Australie préhistorique et pour moitié dans la Provence moderne. Les deux histoires finiront par se rejoindre...

D'un coté, le roman nous raconte la longue saga d'une lignée d'aborigènes australiens, depuis leur arrivée sur l'île-continent il y a 70 000 ans jusqu'à l'époque moderne, de l'autre, il nous fait suivre le mal de vivre d'une australienne qui ne supporte plus son travail dans un bureau gouvernemental où on rejette les demandes d'asile des réfugiés. Elle part en Provence à la recherche des traces de sa mère, immigrée venue de France.

Les aborigènes devront faire face à un monde naturel dur, marqué par la présence d'une mégafaune de varans géants et de kangourous carnivores. Après la disparition de ces animaux gigantesques, ils rencontreront les premiers européens venus explorer le monde austral. Et ils seront finalement chassés de leurs terres, massacrés, et leurs enfants enlevés pour être élevés dans des orphelinats où on leur apprend la haine de leur communauté (je conseille au sujet de ces enlèvements la remarquable exposition au Musée d'Australie Occidentale à Perth).

Je ne trahis pas un secret en annonçant que l'australienne moderne, après de nombreuses aventures, pas toujours drôles, dans la terre d'origine de sa mère, finira par rentrer en contact avec le dernier descendant de la lignée aborigène...

J'apprécie beaucoup les romans ayant un fond scientifique et historique : ici, il y a l'évolution humaine, les découvertes du XVIIIème siècle, la faune marsupiale préhistorique, dont il ne reste presque plus rien (en partie à cause des aborigènes), la colonisation.

Malgré toutes les horreurs, finalement, le passé et le présent sont capables de se recontrer et de se comprendre.


L'article seul

RFC 4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : T. Bates (Cisco), E. Chen (Cisco), R. Chandra (Sonoa)
Chemin des normes
Première rédaction de cet article le 18 mai 2006

Une mise à jour du RFC 2796, notre RFC spécifie comment connecter des routeurs BGP sans avoir à configurer chaque couple de routeur, en utilisant un routeur spécial, le route reflector.

L'un des principes de base du protocole BGP (décrit dans le RFC 4271) est que des routeurs iBGP, c'est à dire Internal BGP, à l'intérieur d'un même système autonome doivent être tous reliés entre eux, pour avoir la même information. Si on n'a que trois routeurs dans le système autonome, c'est facile. Si on en a cent, cela fait dix mille sessions à configurer : cela ne passe pas à l'échelle.

Notre RFC explique donc comment utiliser un ou deux routeurs pour distribuer à tous les autres l'information de routage. Il n'y a donc plus qu'à configurer cent sessions, depuis chaque routeur du système autonome vers le route reflector. Cela ne nécessite que des changements de détail au protocole BGP, changements qui sont depuis longtemps intégrés dans les mise en œuvre de BGP (puisque notre RFC n'est qu'une mise à jour du RFC 2796, qui datait d'avril 2000).

Le route reflector ne fait que distribuer les routes, il ne route pas les paquets IP. Sa seule fonction est de routing, pas de forwarding.

On notera que le terme de route server, lui, désigne en général un routeur BGP qui assure cette même fonction de redistribution des routes, mais entre systèmes autonomes différents (eBGP pour External BGP), par exemple sur un point d'échange (voir le RFC 7947).

Téléchargez le RFC 4456


L'article seul

RFC 4407: Purported Responsible Address in E-Mail Messages

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : J. Lyon (Microsoft)
Intérêt historique uniquement
Première rédaction de cet article le 17 mai 2006

Un très court RFC qui décrit l'algorithme PRA (Purported Responsible Address) qui permet de désigner un expéditeur à partir des en-têtes d'un message électronique. (L'expérience a été abandonnée par la suite, et reclassifiée « intérêt historique seulement », en février 2020.)

Il existe en effet plusieurs identités possibles pour l'émetteur d'un courrier : l'adresse indiquée par la commande MAIL FROM de SMTP (RFC 2821) ? Celle indiquée par le champ From: des en-têtes (RFC 2822) ? Aucune n'est idéale et le choix dépend de pas mal de considérations. (Meng Weng Wong, concepteur de SPF), fait remarquer que les gens du logiciel libre préfèrent l'identité SMTP et Microsoft préfère une identité extraite des en-têtes ; selon lui, c'est parce que le logiciel libre sur Unix domine dans le monde des MTA et Microsoft domine dans celui des MUA.)

Par exemple, un message envoyé sur la liste de diffusion des utilisateurs francophones de Debian contient : 

MAIL FROM (SMTP) bounce-debian-user-french=stephane=sources.org@lists.debian.org
From: Demba COULIBALY <demcoul@yahoo.com>
To: debian-user-french@lists.debian.org
Resent-From: debian-user-french@lists.debian.org
Resent-Sender: debian-user-french-request@lists.debian.org

Quel est l'expéditeur ? Demba Coulibaly l'a écrit (et c'est typiquement l'expéditeur que va m'indiquer mon MUA) mais c'est une machine de Debian qui me l'a transmis, via le programme de gestion de listes de diffusion.

Or, tous les efforts d'authentification de l'émetteur d'un courrier dépendent de cette identité.

Notre RFC propose donc de ne pas utiliser le From: aveuglément mais de ne le prendre que s'il est seul, et d'utiliser Resent-From: ou Resent-Sender: s'ils sont présents. Je ne reprends pas l'algorithme ici, il figure dans le RFC mais il est de toute façon trivial (vous pouvez en voir une mise en œuvre en Python, par moi, PRA.py et une en Perl, par Mark Kramer, pra2.pl).

Ce RFC est un des produits du groupe de travail IETF maudit, MARID, qui avait tenté de créer une norme ouverte d'authentification du courrier électronique mais avait été fermé d'autorité avant d'être arrivé à un résultat. Les documents survivants ont été publiés avec un gros avertissement de l'IESG, qui, dans le cas de notre RFC, met en garde contre le fait que l'algorithme PRA ne marche pas pour la plupart des listes de diffusion (la liste Debian, citée plus haut, n'a pas de problèmes).

Une des raisons de la crise du groupe de travail MARID était le fait que PRA est plombé par un brevet de Microsoft. Beaucoup refusaient de normaliser une technologie où il aurait fallu obtenir une licence, même gratuite, de la part d'une grosse société dominante.

Mais PRA illustre aussi à quel point le système des brevets est délirant et a échappé à tout contrôle : l'algorithme PRA est trivial, il tient en quelques lignes de Perl ou de Python et il n'aurait jamais dû être brevetable. Il est scandaleux que les organismes de dépôt de brevet soient payés au nombre de brevets enregistrés, les encourageant ainsi à accepter des brevets futiles, comme celui sur PRA.

Téléchargez le RFC 4407


L'article seul

Qemu, un émulateur de processeur

Première rédaction de cet article le 15 mai 2006

Dans la grande famille des solutions de virtualisation, permettant de faire tourner un système d'exploitation sur un autre, Qemu appartient à la sous-famille des émulateurs de processeur, comme Bochs.

Cela veut dire qu'il lit les instructions machine en mémoire et les évalue, comme ce que fait le CPU (mais bien plus lentement).

Cela permet de faire tourner des systèmes d'exploitation non modifiés, dont on n'a qu'un binaire, comme par exemple Microsoft Windows. Contrairement à User-Mode-Linux, il n'est donc pas spécifique de Linux et, contrairement à Xen, il ne nécessite pas de modifier le système d'exploitation invité.

En outre, Qemu peut tourner sur divers processeurs et émuler divers processeurs donc on pourrait (je n'ai pas testé) faire fonctionner une Sparc virtuelle sur un PC.

J'ai testé Qemu sur ma Debian et tout s'est bien passé, y compris le réseau (contrairement à ce qu'on lit souvent).

Je lance Qemu avec qemu -hda images/freebsd_6.0/freebsd_6_0.img -boot c et Qemu émule un disque dur IDE (Qemu n'émule pas seulement le processeur mais aussi un PC complet) avec le fichier freebsd_6_0.img et démarre dessus. Ainsi, j'ai un FreeBSD complet sur ma Debian. On trouve énormément d'images toutes prêtes, pour les principaux systèmes libres, sur Free OS Zoo.

Si on préfère installer un système soi-même, on crée l'image vide : 

% qemu-img create -f qcow  tmp/fenetres.img 100G

Puis on lance l'émulateur, ici in indiquant de démarrer sur le CD-ROM, qui contient un CD d'installation : 

% qemu -cdrom /dev/cdrom -hda tmp/fenetres.img -boot d

Pour le réseau, Qemu lance par défaut /etc/qemu-ifup qui, chez moi, contient : 

#!/bin/sh

iface=$1

# The Qemu host
myipv4addr=192.134.4.69

# The guest virtual machine
remipv4addr=192.134.4.79

# IPv4
sudo /sbin/ifconfig $iface $myipv4addr  netmask 255.255.255.255
sudo route add -host $remipv4addr dev $iface

# IPv6
# My local network is fd14:6941:e887::/48
sudo /sbin/ifconfig $iface add fd14:6941:e887::1
sudo route add  -Ainet6  fd14:6941:e887::/48 dev $iface
 
# activate ip forwarding
sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

# activate ARP proxy to "spoof" arp address
sudo sh -c 'echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp'
sudo sh -c 'echo 1 > /proc/sys/net/ipv4/conf/${iface}/proxy_arp'

# set "spoofed" arp address
sudo arp -Ds $remipv4addr eth0 pub

Je n'ai pas mesuré de façon rigoureuse les performances mais, au pifomètre, elles sont très inférieures à celles de Xen, qui exécute le code machine directement sur le processeur physique. Un module à l'origine non libre existait pour Qemu pour faire à peu près la même chose mais il n'est plus nécessaire depuis l'apparition de processeurs ayant des fonctions de virtualisation, et du système kvm qui peut les utiliser.


L'article seul

RFC 3748: Extensible Authentication Protocol (EAP)

Date de publication du RFC : Juin 2004
Auteur(s) du RFC : B. Aboba (Microsoft), L. Blunk (Merit), J. Vollbrecht (Vollbrecht consulting), J. Carlson (Sun), H. Levkowetz (ipUnplugged)
Chemin des normes
Première rédaction de cet article le 11 mai 2006

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

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

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

Téléchargez le RFC 3748


L'article seul

RFC 4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : M. Wong, W. Schlitt
Expérimental
Première rédaction de cet article le 10 mai 2006

On le sait, le courrier électronique, tel qu'il est spécifié dans les RFC 5321 et RFC 5322, ne fournit aucune authentification, même faible, de l'émetteur. Un expéditeur de courrier peut toujours prétendre être Jacques Chirac <president@elysee.fr> et il n'y a aucun moyen de l'en empêcher. SPF vise à diminuer cette facilité de frauder en permettant à un titulaire de nom de domaine de déclarer quelle(s) adresse(s) IP sont autorisées à envoyer du courrier pour ce domaine. (Ce RFC a depuis été remplacé par le RFC 7208.)

SPF dépend donc du DNS. Le principe de base est d'ajouter à sa zone DNS, par exemple bortzmeyer.eu, un enregistrement de type TXT (le SPF original) ou bien du nouveau type SPF (créé par notre RFC). Cet enregistrement déclare, dans un langage ad hoc, quelle(s) adresse(s) IP peuvent envoyer du courrier pour ce domaine. Par exemple, bortzmeyer.eu a "v=spf1 mx -all", ce qui veut dire en français que seuls les MX (les serveurs qui reçoivent le courrier) de ce domaine peuvent en émettre, le reste de l'Internet (all) est exclu.

Pour voir ces enregistrements SPF, on peut par exemple utiliser dig : 

% dig +short TXT freebsd.org 
"v=spf1 ip4:216.136.204.119 ~all"
% dig +short TXT gentoo.org 
"v=spf1 mx ptr ?all"

On note que SPF, comme la plupart de ses concurrents, n'authentifie que le domaine, pas la personne émettrice (ce point, et plusieurs autres, est discuté en détail dans la section 10, « Sécurité » de notre RFC).

Authentifier le courrier électronique est plus compliqué qu'il ne semble au premier abord, en partie parce qu'il existe plusieurs identités possibles :

  • L'expéditeur de l'enveloppe (MAIL FROM de la session SMTP),
  • L'expéditeur des en-têtes, qui lui-même dépend de l'en-tête qu'on choisit (From: ? Sender: ? Une combinaison de plusieurs en-têtes comme l'algorithme PRA du RFC 4407 ?).

Les partisans de la première approche (celle de SPF) lisent le RFC 5321 et ceux de la seconde lisent plutôt le RFC 5322. Chacune a ses avantages et ses inconvénients.

La question de l'authentification du courrier électronique est très chaude. Les protocoles candidats, comme SPF, ont fait l'objet de nombreuses polémiques. C'est pourquoi l'IESG a collé un gros avertissement au début du RFC, bien que SPF soit, et de très loin, le plus testé des protocoles d'authentification (avec PGP, qui est dans une catégorie très différente).

En même temps que notre RFC a été publié le RFC 4406 sur Sender ID. SenderID, comme SPF, avait été discuté dans le défunt groupe de travail MARID de l'IETF, groupe qui avait été autoritairement dissous avant d'avoir atteint un consensus. Malgré le déploiement bien plus important de SPF, l'IESG a choisi de traiter les deux propositions de manière égale et de publier les deux RFC comme expérimentaux. Ce n'est qu'en 2012 que l'IETF est revenu sur cette décision et a décidé, dans le RFC 6686, que SPF était le net vainqueur sur ce créneau. SPF est désormais normalisé dans le RFC 7208, qui a remplacé notre RFC 4408.

Téléchargez le RFC 4408


L'article seul

RFC 4472: Operational Considerations and Issues with IPv6 DNS

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : A. Durand (Comcast), J. Ihren (Autonomica), P. Savola (CSC/Funet)
Pour information
Première rédaction de cet article le 10 mai 2006

Le déploiement du protocole IPv6 est une opération de grande ampleur, qui n'a jamais eu d'équivalent sur Internet, et qui met en cause beaucoup de choses. Les normes qui spécifient le protocole ont donc intérêt à être accompagnées de documents comme notre RFC, qui résume les questions spécifiquement DNS pour IPv6.

Programmer des services IPv6 ou bien les déployer nécessite de lire beaucoup de RFC, si on veut connaitre toutes les normes applicables. Il est donc utile d'avoir des documents d'information comme notre RFC, qui fournit un point d'entrée unique sur les questions DNS qui se posent à IPv6.

Le RFC traite, entre autres, les points suivants :

  • Représentation des adresses IPv6 dans le DNS, y compris des catégories d'adresses spécifiques à IPv6 comme les adresses link-local,
  • Mauvais comportement de certains serveurs DNS (détaillé plus loin),
  • Recommandations pour le nommage (un enregistrement IPv6 et un IPv6 pour www.bortzmeyer.org ou bien seulement un IPv4 et le IPv6 pour www.ipv6.bortzmeyer.org ?),
  • Recommandations pour les résolveurs IPv6,
  • Recommandations pour la mise à jour des zones droites (traduction de noms en adresses) et inverses (traduction d'adresses en noms via le domaine ip6.arpa).

Le problème des serveurs incorrects (déjà discuté dans le RFC 4074) est une des plaies d'IPv6. En effet, beaucoup de serveurs DNS ne répondent pas correctement lorsqu'ils reçoivent des requêtes de type AAAA (adresses IPv6, les adresses IPv4 étant dans des enregistrements de type A) ; ils ne répondent pas ou, pire, ils répondent que le domaine n'existe pas, même s'il a des enregistrements d'autres types (le bon comportement serait de renvoyer une réponse vide : ne pas avoir un enregistrement DNS d'un type donné n'est pas une erreur).

Ces serveurs incorrects sont souvent des appliances, boîtes fermées, non documentées et non gérées, qu'il est très difficile de mettre à jour une fois qu'elles ont été déployées. Un résolveur IPv6 peut donc être obligé, en violation des normes, d'ignorer une réponse négative et de reessayer avec un autre type d'enregistrements.

Enfin le RFC rappelle que le transport utilisé pour atteindre le serveur de noms (IPv4 ou IPv6) n'a pas de rapport avec le type de données demandé : en effet, une machine qui interroge le DNS en IPv4 peut parfaitement être capable de faire de l'IPv6 et réciproquement. En outre, le client que voit le serveur DNS n'est en général pas le client final mais son cache récursif local. Ce serait donc une erreur de renvoyer préferentiellement des enregistrements A (IPv4) si la question arrive en IPv4.

Téléchargez le RFC 4472


L'article seul

RFC 3550: RTP: A Transport Protocol for Real-Time Applications

Date de publication du RFC : Juillet 2003
Auteur(s) du RFC : H. Schulzrinne (Columbia U.), S. Casner (Packet Design), R. Frederick (Blue Coat), V. Jacobson (Packet Design)
Chemin des normes
Première rédaction de cet article le 9 mai 2006

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

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

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

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

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

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

Téléchargez le RFC 3550


L'article seul

Vulnérabilités DNS du mois

Première rédaction de cet article le 5 mai 2006

Le mois d'avril 2006 a été marqué par l'intérêt médiatique pour les vulnérabilités du DNS. Mais cet intérêt a peut-être créé une certaine confusion entre des problèmes très différents, qui n'ont été rapprochés que par les hasards de la chronologie.

La plus médiatisée (même la BBC en a parlé) est l'étude du groupe Beehive (menée notamment par Emin Gun Sirer), intitulée A Survey of DNS Security: Most Vulnerable and Valuable Assets, présentée à RIPE 52.

En résumé, cette étude rappelle qu'un nom de domaine dépend d'autres domaines pour sa résolution. Par exemple, sarkozy.fr dépend de .net puisque les serveurs de noms de sarkozy.fr sont dans deviantnetwork.net. Le responsable de ce domaine doit donc tenir compte de ces autres serveurs et la liste des dépendances peut être étonemment longue (le programme dependency-domain.py peut être utilisé pour afficher la liste et le programme ns2dot.py peut produire un joli graphe Graphviz des dépendances). Si ceux-ci trahissent ou bien sont piratés (l'étude mentionne longuement les vulnérabilités de certaines mises en œuvre du DNS), le domaine peut être modifié.

Certains TLD sont, selon cette étude, plus vulnérables car ils dépendent de davantage de serveurs (ainsi, il y a 248 serveurs de noms dans le graphe de dépendance de .fr).

Cette étude soulève un grand nombre de questions. D'abord, elle ne découvre pas grand'chose de nouveau : la question du graphe de dépendance est discutée depuis longtemps (on peut regarder le graphe de dépendance d'un domaine sur l'l'outil du registre polonais). Et cette discussion n'a jamais permis d'arriver à un consensus entre les deux écoles, celle qui pense qu'il faut répartir les risques (avec des serveurs de noms dans des domaines différents), et celle qui pense qu'il faut mettre tous ses œufs dans le même panier (en concentrant les serveurs de noms dans un petit nombre de domaines). Certains gros hébergeurs comme UltraDNS ont même changé de politique (les serveurs de noms de .org étaient tous dans .org mais ils sont désormais dans plusieurs TLD).

Ensuite, l'étude mélange un problème de base du DNS, les relations de dépendance entre serveurs, avec les vulnérabilités des logiciels. Il y a bien d'autres moyens d'attaquer le DNS que de pirater un serveur de noms : par exemple la trahison des administrateurs de ce serveur : il faut avoir confiance dans les administrateurs de ses serveurs secondaires.

Le vrai but de l'étude semble être la promotion de la solution du groupe Beehive : CoDoNS, un système de résolution de noms bâtie sur les tables de hachages distribuées. CoDoNS est une approche très intéressante, et je me félicite que des chercheurs courageux se lancent dans des grands projets comme celui-ci mais la comparaison avec le DNS est tout à fait injuste. Le DNS fonctionne depuis presque vingt ans et a affronté d'innombrables problèmes alors que CoDoNS est encore un prototype de laboratoire qui, dès qu'on l'examine de plus près, révèle un grand nombre de problèmes qui restent à résoudre avant qu'il puisse prétendre remplacer le DNS.

Ceux qui s'intéressent aux questions de gouvernance de l'Internet noteront que CoDoNS ne s'attaque qu'à la question de la résolution des noms de domaine, et ne change rien à leur structure, donc à la hiérarchie d'allocation de ces noms, hiérarchie qui culmine au gouvernement états-unien, via l'ICANN.

D'autre part, et sans qu'il y aie de relation avec l'étude de Beehive, le 28 avril, le NISCC annonçait son étude Vulnerability Issues in Implementations of the DNS Protocol. Menée en envoyant à divers clients et serveurs DNS des paquets délibérement incorrects, elle a mené à la découverte de vulnérabilités dans plusieurs logiciels, souvent très utilisés.

Il s'agit là de vulnérabilités classiques de logiciels écrits de manière un peu négligente, pas de problèmes du DNS en général.


L'article seul

Virtualisation avec User-Mode-Linux

Première rédaction de cet article le 2 mai 2006
Dernière mise à jour le 5 mai 2006

Contrairement à Xen, User-Mode-Linux est, comme son nom l'indique, spécifique à Linux. C'est un noyau modifié pour pouvoir être lancé comme une commande, sur un Linux ordinaire : 

% ./kernel32-2.6.15.3-bs1-tls ubd0=./Slackware-10.2-root_fs
[Messages de démarrage, puis :]
Welcome to Linux 2.6.15.3-bs1-tls (tty0)

darkstar login:

User-Mode-Linux permet par exemple à un hébergeur de proposer une machine virtuelle au client, sur laquelle il sera root, sans avoir à lui dédier une machine physique chère et encombrante (le processus est très bien décrit dans http://www.stearns.org/slartibartfast/uml-coop.html).

Quel plaisir de lancer un noyau sans être root, de voir les messages de démarrage et de pouvoir faire un ps après : 

bortzme  12130  1.0  5.2 33572 26972 pts/1   S+   12:59   0:02 ./kernel32-2.6.15.3-bs1-tls

La commande complète que j'utilise pour lancer la machine virtuelle Ubuntu sur laquelle j'écris cet article est : 

 screen -S ragnetrude sudo kernels/kernel32-2.6.16.11-bs2 ubd0=cows/ragnetrude.cow ubd1=./swap mem=96M eth0=tuntap,,,192.134.4.69 umid=ragnetrude

J'utilise sudo pour être root afin de pouvoir configurer le réseau sur la machine hôte (cela n'est pas forcément nécessaire, permettre l'accès à /dev/net/tun peut être suffisant mais je n'ai pas testé). Je définis la mémoire utilisée par la machine virtuelle (ici, 96 méga-octets). Et je configure une interface réseau qui va utiliser ma machine, 192.134.4.69, comme routeur (l'adresse IP de la machine virtuelle est, elle, configurée dans la machine virtuelle). Enfin, je définis un identificateur, ici ragnetrude.

À noter que screen est très pratique (mais pas obligatoire) pour lancer les machines virtuelles (comme ci-dessus), se détacher du terminal (Control-A d), se reconnecter (screen -r ragnetrude), etc.

Pour lancer tout un système et pas le seul noyau, il faut une image d'un système installé, comme celles qu'on trouve en http://uml.nagafix.co.uk/. Si on veut faire tourner plusieurs machines virtuelles, sans copier à chaque fois ce gros fichier, User-Mode-Linux permet d'utiliser des fichiers COW, pour Copy-on-Write. On les crée avec uml_mkcow (en indiquant sur quel fichier image il s'appuie, ici une image d'Ubuntu) et on peut les utiliser après : 

% uml_mkcow -f cows/ragnetrude.cow images/Ubuntu-x86-root_fs
% kernels/kernel32-2.6.16.11-bs2 ubd0=cows/ragnetrude.cow

On trouve de très bonnes ressources UML (noyaux déjà compilés et images de système de fichiers racine) sur http://uml.nagafix.co.uk/. Il y a aussi des noyaux déjà compilés sur http://www.user-mode-linux.org/~blaisorblade/.


L'article seul

Multics Emacs : histoire de la conception d'un logiciel mythique

Première rédaction de cet article le 27 avril 2006

Comme le savent mes fidèles lecteurs, j'aime beaucoup lire les vieux articles d'informatique : il y a beaucoup de choses à apprendre du passé et, si la liste des failles de sécurité de PHP n'a guère d'intérêt deux ans après, beaucoup d'autres choses en informatique sont bien plus permanentes. D'où mon intérêt pour ce remarquable article, qui décrit la conception et le développement de la première version de l'éditeur Emacs pour le système Multics.

Multics était un système d'exploitation de mainframe, très avancé pour son époque, qui n'a eu qu'un très faible succès commercial, mais qui avait réussi à créer une communauté d'utilisateurs dynamique et créative, comme le font les Unix libres aujourd'hui. Il est donc logique qu'il existe un site Web dédié à Multics, d'où se trouve distribué notre texte, Multics Emacs: The History, Design and Implementation.

(Personnellement, je n'ai fait que de courtes incursions sur un système Multics, vers 1989.)

Multics n'avait comme éditeur que des programmes qui, même à l'époque, étaient jugés archaïques. Par exemple, aucun ne fonctionnait en plein écran, tellement ils étaient optimisés pour des terminaux papier.

D'où la motivation pour développer un nouvel éditeur, Emacs, inspiré du programme du même nom qui tournait sur un autre système d'exploitation, ITS. (Plusieurs éditeurs ont porté le nom de Emacs dont le plus courant aujourd'hui est le GNU Emacs originellement développé par Richard Stallman, et avec lequel j'écris cet article.)

L'article de Bernard Greenberg, écrit en 1979, décrit donc les motivations, les choix techniques, les problèmes, les discussions qui ont accompagné le développement de Multics Emacs. Il nous replonge dans une époque où le seul jeu de caractères était l'ASCII (beaucoup des techniques expliquées ne fonctionneraient pas avec Unicode), il nous décrit les détails de la programmation en Lisp et comment le choix de ce langage avait permis la création d'un "marché" des extensions à Emacs, il cite l'Arpanet, ancêtre de l'Internet, qui permettait de travailler à distance sur la grosse machine Honeywell sur laquelle tournait Multics. Emacs avait tellement révolutionné l'édition de textes qu'on avait commencé à changer des protocoles Internet suite aux limites qu'il mettait en évidence (l'auteur a écrit le RFC 749 suite au développement d'Emacs).

Mais il parle aussi de problèmes éternels en programmation, les compromis de conception qui sont nécessaires, les polémiques sur l'interface utilisateur, l'affrontement entre le gros programme qui fait tout et les petits programmes qui communiquent, les risques et la nécessité de l'optimisation (Emacs passait à l'époque pour un très gros programme, alors qu'il est aujourd'hui ridicule devant les obésiciels comme OpenOffice et Firefox, sans même parler des logiciels de Microsoft).


L'article seul

RFC 4398: Storing Certificates in the Domain Name System (DNS)

Date de publication du RFC : Mars 2006
Auteur(s) du RFC : S. Josefsson
Chemin des normes
Première rédaction de cet article le 27 avril 2006

Il existe de nombreux moyens de distribuer les certificats utilisés en cryptographie, comme les serveurs de clé de PGP. Notre RFC en ajoute un nouvau, le DNS.

Les certificats étant protégés par leur signature, le transport n'a pas besoin d'être fiable. On peut donc se servir du DNS, même sans DNSSEC. C'est ce que faisait le RFC 2538 que notre RFC a légèrement remis à jour.

Notre RFC crée donc un nouveau type d'enregistrement DNS , CERT et définit le format pour y mettre des certificats comme ceux de X.509 ou de OpenPGP. Il contient également une section, la 3, pour discuter du nom à donner à ces enregistrements. (Par exemple l'adresse de courrier pour un certificat OpenPGP, donc ma propre clé PGP, dès que je saurai l'encoder proprement, pourrait être publiée sous stephane.bortzmeyer.org.) Mais je ne connais pas encore de logiciel de cryptographie capable de récupérer un certificat via le DNS.

Un bon tutoriel sur la publication de clés PGP dans le DNS est « How to publish PGP keys in DNS ».

Téléchargez le RFC 4398


L'article seul

RFC 4340: Datagram Congestion Control Protocol (DCCP)

Date de publication du RFC : Mars 2006
Auteur(s) du RFC : E. Kohler (UCLA), M. Handley (UCL), S. Floyd(ICIR)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dccp
Première rédaction de cet article le 26 avril 2006
Dernière mise à jour le 27 avril 2006

Si IP est la base de l'Internet, la grande majorité des applications utilisent un protocole de transport situé au dessus d'IP et ne parlent pas directement IP. Les deux protocoles de transport les plus connus sont TCP et UDP mais il en existe d'autres dont, désormais, DCCP.

Pour comprendre l'intérêt de DCCP, qui vient d'être normalisé, il faut se souvenir des services que fournissent TCP et UDP :

  • TCP fournit un service de flot de données (il ne transporte pas des messages séparés mais un flot continu d'octets) fiable, c'est-à-dire que c'est TCP, pas l'application, qui se charge d'envoyer et de surveiller les accusés de réception, et de demande des retransmissions si un paquet se perd. Outre ce service rendu à l'application, TCP rend un service à l'Internet : il assure le contrôle de congestion, c'est-à-dire qu'il ralentit le débit sortant si les accusés de réception lui montrent que le réseau est surchargé. TCP est donc gentil pour le réseau. Enfin, les données ne sont échangées qu'après l'établissement d'une connexion, établissement pendant lequel les deux parties peuvent s'accorder sur des options.
  • UDP, lui, ne fournit presque rien de plus qu'IP : son service est de datagrammes, c'est-à-dire de messages séparés, et il n'a aucune fiabilité, l'application ne sait même pas si le datagramme est arrivé ou pas. Si elle a besoin d'accusé de réception ou de fiabilité, c'est à elle de les gérer. Si l'application ne pense pas à gérer la congestion, elle risque d'aggraver les problèmes de l'Internet en (ré)envoyant davantage de données justement lorsque le réseau est saturé. Contrairement à TCP, aucune connexion n'est nécessaire.

Il n'est donc pas étonnant que la plupart des applications utilisent TCP, bien plus simple pour le concepteur et pour le programmeur. Mais TCP consomme davantage de ressources et introduit des délais non négligeables, surtout à l'ouverture de connexion. UDP est donc utilisé si le temps de réponse est primordial (cas du DNS) ou bien si l'application peut tolérer la perte d'un certain nombre de paquets (cas des protocoles de transmission de son ou d'image comme RTP, où on peut accepter quelques silences ou quelques trames manquantes).

Entre TCP et UDP, d'autres protocoles de transport ont été créés pour des usages divers mais tous sont restés marginaux.

DCCP aura peut-être davantage de succès :

  • Comme TCP, DCCP fournit un service d'accusé de réception (donc l'application peut savoir quels messages sont arrivés) et nécessite une connexion, ce qui permet de choisir des options. Mais il ne rentransmet pas les données perdues, l'application est juste tenue au courant.
  • Comme TCP, DCCP fournit à l'Internet un service de contrôle de la congestion. Il y en a même plusieurs, choisis lors de la négociation initiale.
  • Comme UDP, DCCP fournit un service de messages non fiable.

On trouvera des détails et des articles plus détaillés sur le site de l'UCLA ou bien sur celui de l'ICIR (qui semble moins bien maintenu et contient des informations dépassées).

Une mise en œuvre limitée de DCCP est inclue dans le noyau Linux mais je n'ai pas encore eu l'occasion de la tester ni de voir quelle API devait être utilisée par echoping (un exemple de programmes figure dans http://wand.net.nz/~iam4/dccp/dccp-cs-0.01.tar.bz2).

Téléchargez le RFC 4340


L'article seul

Décoder les en-têtes du courrier électronique

Première rédaction de cet article le 10 avril 2006

Ma langue maternelle étant le français, je reçois une bonne proportion de messages électroniques dans cette langue, avec des caractères composés comme ç ou ê. La façon dont ils sont encodés pour le voyage dans l'Internet ne me convient pas et je les décode à l'arrivée. Voici comment.

Le RFC 2822, qui normalise la représentation des messages « sur le câble » précise que les en-têtes des messages (donc le sujet, l'expéditeur, etc) doivent être en US-ASCII uniquement. Pour pouvoir représenter des prénoms comme le lien ou bien des sujets avec caractères composés, le RFC 2047, qui fait partie de la série sur MIME, précise qu'ils doivent être encodés. Ainsi, From: Stéphane Bortzmeyer devient typiquement From: =?ISO-8859-1?Q?St=E9phane?= Bortzmeyer.

Lire ces messages n'est pas un problème, tous les MUA modernes savent le lire et l'afficher proprement (j'utilise mutt).

Mais j'utilise mon courrier électronique pour bien d'avantage qu'une lecture rapide, suivie d'une poubellisation : c'est ma bibliothèque, mon outil de travail, une source d'information et une référence. Notamment, il faut absolument que je puisse chercher dans ce corpus de messages. Et, comme je suis un grand partisan de la séparation des outils (un MUA gère le courrier, il n'a pas besoin de concurrencer les outils de recherche), j'utilise l'excellent grepmail.

Je dois donc décoder ces en-têtes avant de les stocker sur ma machine, dans le jeu de caractères que j'utilise (Latin-1 puisque je ne suis pas encore passé à UTF-8).

Le programme pour décoder est un script Python trivial, qui n'utilise que la bibliothèque standard du langage : 

#!/usr/bin/python

import email.Header
import sys

header_and_encoding = email.Header.decode_header(sys.stdin.readline())
for part in header_and_encoding:
    if part[1] is None:
        print part[0],
    else:
        upart = (part[0]).decode(part[1])
        print upart.encode('latin-1'),
print

Et, pour extraire du message ce que je veux décoder, j'utilise l'outil formail, qui fait partie de procmail. formail extrait le champ indiqué : 

SUBPYTHON=`formail -czxSubject: | bin/rewrite-email.py`

:0fw
| formail -i"Subject: $SUBPYTHON"

Et voilà, le courrier est stocké dans ma boîte aux lettres comme si c'était un fichier texte que j'ai édité, dans l'encodage qui convient à mes outils.


L'article seul

RFC 4452: The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces

Date de publication du RFC : Avril 2006
Auteur(s) du RFC : H. Van de Sompel (LANL), T. Hammond (NPG), E. Neylon (Manifest Solutions), S. Weibel (OCLC)
Pour information
Première rédaction de cet article le 10 avril 2006

La guerre des identificateurs, entre les multitudes de solutions qui existent pour désigner les choses de manière unique, ne connait pas de répit : ce RFC propose encore un nouveau schéma, qui vise surtout à faire converger des espaces de nommage existants vers les URI.

On le sait, si on veut désigner une ressource, que ce soit un livre, une page Web ou une personne, il existe beaucoup de solutions concurrentes, des URL aux DOI en passant par les identifiants EPC de RFID. N'y a t-il pas assez de solutions différentes ? Non, ont pensé les auteurs de notre RFC qui viennent de proposer un nouveau schéma pour les URI : info:.

Ces nouveaux URI visent à « récupérer » les espaces de nommage existants comme la classification Dewey ou bien PubMed. En les préfixant du schéma info:, suivi d'un identifiant de l'espace de nommage, on transforme ainsi tous ces vénérables identificateurs en URI.

On verra ainsi peut-être demain des identificateurs comme info:pmid/12376099 (PMID désigne PubMed et vous pouvez chercher ce numéro au NCBI) ou comme info:ddc/22/eng//641.57 (DDC est la classification Dewey).

Ces URI ne sont pas forcément résolvables en une ressource accessible via le réseau et le RFC note qu'ils ne sont pas non plus forcément permanents. Les URI de info: ne sont donc pas forcément directement concurrents des URL (qui sont toujours résolvables) ou des URI tag: du RFC 4151 qui sont toujours permanents. Alors que les tag: utilient le système des noms de domaine, les info: cherchent simplement à sauver les espaces de nommage traditionnels.

Enfin, le RFC attribue la gestion du registre de info au NISO. Bien qu'il existe de nombreux espaces de noms « pré-Internet » dans le monde, c'est donc un organisme états-unien qui les gérera tous.

Téléchargez le RFC 4452


L'article seul

RFC 3261: SIP: Session Initiation Protocol

Date de publication du RFC : Juin 2002
Auteur(s) du RFC : J. Rosenberg (dynamicsoft), H. Schulzrinne (Columbia U.), G. Camarillo (Ericsson), A. Johnston (WorldCom), J. Peterson (Neustar), R. Sparks (dynamicsoft), M. Handley (ICIR), E. Schooler (AT&T)
Chemin des normes
Première rédaction de cet article le 8 avril 2006
Dernière mise à jour le 7 juin 2008

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Téléchargez le RFC 3261


L'article seul

Internet, quel drôle de réseau !

Première rédaction de cet article le 4 avril 2006

Françoise Virieux tente d'expliquer Internet aux enfants de 9 à 12 ans. Ce n'est jamais facile de vulgariser, il ne faut pas profiter de l'ignorance des lecteurs pour leur mentir mais il faut pourtant s'adapter à leur niveau. C'est encore plus difficile avec les enfants qui, à cet âge, utilisent souvent Internet mais n'ont pas d'idées sur son fonctionnement.

Dans ce petit livre (éditeur Le Pommier), Françoise Virieux relève le défi mais le résultat n'est pas très convaincant pour moi : parfois, cela me semble trop complexe (par exemple l'explication du routage), parfois, c'est même faux (le routage en fonction de la charge).

Mais ma principale déception vient d'une présentation trop officielle d'Internet : ce réseau est multiple, pluriel, bouge sans cesse, mais seul les acteurs officiels ont droit de cité dans ce livre. On y prétend qu'il faut se méfier des pages Web personnelles alors que l'information qui serait publiée sur le site Web d'un journal serait fiable, on ne parle pas du tout d'hébergement de services chez soi (tout est chez "le fournisseur d'accès") et surtout la possibilité que le contenu, les choses intéressantes, soit écrit par les internautes eux-mêmes n'est pas mentionné. (A contrario, mon fils - en CE2 - a réalisé un journal en ligne dans sa classe. Cela ne concurrencera pas Slashdot mais c'est un début. Merci donc à Katia Sernik pour cette expérience pédagogique.)


L'article seul

RFC 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : J. Schlyter (OpenSSH), W. Griffin (Sparta)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF secsh
Première rédaction de cet article le 2 avril 2006
Dernière mise à jour le 3 septembre 2007

On le sait, le protocole SSH dépend, pour la sécurité du client, d'une vérification de la clé publique du serveur, lors de la première connexion. Cette vérification étant rarement faite, notre RFC propose un moyen de l'automatiser via le DNS.

Voici une session SSH typique, la première fois qu'on se connecte à foobar.example.org : 

% slogin foobar.example.org
The authenticity of host 'foobar.example.org (172.19.1.33)' can't be established.
RSA key fingerprint is 38:e8:5b:3f:25:41:e2:ca:fa:4e:71:38:b8:db:f0:d1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'foobar.example.org,172.19.1.33' (RSA) to the list of known hosts.
Last login: Sun Apr  2 17:45:12 2006 from ludwigvi.sources.org
NetBSD 3.99.17 (XEN3_U) #5: Sat Mar 25 19:01:14 CET 2006

Comme je ne m'étais jamais connecté depuis cette machine, la clé publique du serveur (dont l'empreinte, le résumé par une fonction de hachage cryptographique, est 38:e8:5b:...) n'était pas stockée (sur Unix, dans ~/.ssh/known_hosts). Comme SSH est sensible aux attaques d'un intermédiaire, une machine qui intercepte la requête du client et prétend être le serveur, il demande une vérification manuelle.

En théorie, je devrais vérifier (par téléphone, par échange d'empreintes signées avec PGP, etc) la clé publique du serveur. En pratique, quasiment personne ne le fait. Comme souvent en cryptographie, on a des techniques formidables et un facteur humain qui fait perdre toute la sécurité qu'aurait pu donner la cryptographie.

Notre RFC propose donc une solution : de distribuer les clés publiques des serveurs SSH via le DNS. Comme celui-ci, par défaut, n'offre aucune sécurité, cela implique évidemment DNSSEC.

Notre RFC normalise donc un nouveau type de données, le SSHFP, qui stocke les empreintes des clés publiques. Par exemple : 

       foobar.example.org.  SSHFP 2 1 38e85b3f2541e2cafa4e7138b8dbf0d1

me permettra de vérifier que je me suis bien connecté vers le bon serveur.

À l'heure d'aujourd'hui, si on veut supprimer cette agaçante question affichée plus haut, il faut utiliser un client SSH comme OpenSSH, dans une version très récente, et activer l'option VerifyHostKeyDNS dans le fichier de configuration. Pour publier les clés dans le DNS, le plus simple est sans doute d'utiliser ssh-keygen -r $DOMAIN ou bien le programme sshfp. (Merci à Phil Regnauld pour les détails pratiques. sshfp devrait être remplacé par hash-slinger.)

Si vous voulez voir des enregistrements SSHFP en vrai, il en existe un sur anoncvs.netbsd.org, le serveur CVS anonyme du projet NetBSD : 

% dig SSHFP anoncvs.netbsd.org
...
;; ANSWER SECTION:
anoncvs.netbsd.org.	86400	IN	SSHFP	1 1 198C34A92FC0B2AB1DA52B688C2F191D2D960C09

(Ou bien, avec le DNS Looking Glass, en https://dns.bortzmeyer.org/anoncvs.netbsd.org/SSHFP.)

Quelques détails pratiques sur l'utilisation de SSHFP figurent dans « How to get OpenSSH to see DNSSEC AD flags on SSHFP lookups with glibc ». Un autre client SSH qui a SSHFP est GateOne (voir la discussion). Sur leur sécurité avec OpenSSH, voir « On the safety of SSHFP records ». Sur leur production et leur publication lorsqu'on a beaucoup de machines, voir « On collecting SSH host keys for SSHFP DNS records ». Sur les limites et certains problèmes de cette technique, voir, du même auteur, « VerifyHostKeyDNS=maybe ». Un exemple de publication est « SSHFP tutorial: how to get SSHFP records, DNSSEC, and VerifyHostKeyDNS=yes to work » de Tony Finch.

Téléchargez le RFC 4255


L'article seul

RFC 4367: What's in a Name: False Assumptions about DNS Names

Date de publication du RFC : Février 2006
Auteur(s) du RFC : J. Rosenberg (IAB)
Pour information
Première rédaction de cet article le 2 avril 2006

Ce RFC rappelle quelques principes des protocoles Internet, que les utilisateurs du DNS risquent d'oublier en croyant que les noms listés dans le DNS portent une sémantique.

L'intérêt du DNS, c'est qu'il permet de choisir des noms très parlants, comme bortzmeyer.org pour mon domaine personnel ou bien elysee.fr pour celui de Jacques Chirac. Mais cet avantage est également une malédiction : cela charge beaucoup le DNS, qui devient l'enjeu de batailles politiques, économiques et juridiques très pénibles.

Autre problème avec ces noms parlants, beaucoup d'utilisateurs croient que le DNS "dit la vérité", c'est à dire que www.whitehouse.com a un rapport avec la Maison Blanche (c'est bien un site politique mis qui abuse du nom) ou qu'un ordinateur nommé www.example.net porte un serveur Web (alors que cela peut être une simple erreur de configuration).

Pire, le RFC estime que certains logiciels font la même erreur et choisissent le protocole de communication à utiliser, ou bien la langue des documents transmis, en fonction d'un nom de domaine. Je dois dire que, à titre personnel, je trouve les exemples du RFC peu convaincants et que je pense qu'il manque de cas réels.

Notre RFC rappelle donc qu'il ne faut pas accorder de sémantique à un nom de domaine et que, si on veut choisir un protocole ou une langue, il faut utiliser les techniques normalisées (par exemple le schéma de l'URI pour choisir le protocole, l'en-tête Accept-Language de HTTP pour indiquer la langue, etc).

Téléchargez le RFC 4367


L'article seul

"Tagging", classer de manière décentralisée

Première rédaction de cet article le 1 avril 2006
Dernière mise à jour le 2 avril 2006

Le tagging, le marquage de ressources par les utilisateurs, sans schéma de nommage et sans thesaurus standard est un des concepts qui a récemment enrichi l'Internet en permettant de créer des services d'accès à l'information, alimentés et classés par leurs utilisateurs.

Traditionnellement, pour s'y retrouver dans une vaste quantité d'informations (par exemple un ensemble de signets ou bien une immense galerie de photos), on confiait à un petit groupe de professionnels de la documentation la tâche d'établir un thesaurus, une liste de mots-clés, et un groupe plus vaste (mais quand même fermé, n'incluant pas la totalité des utilisateurs) était chargé d'appliquer ces mots-clés à chaque ressource, travail très long.

Ce travail peut typiquement être parallélisé et c'est là qu'Internet est une innovation fantastique. On peut désormais enrôler des milliers de bénévoles pour faire le marquage des ressources.

Mais le tagging moderne va plus loin : il n'y a plus de thesaurus, la liste des mots-clés n'est plus figée, elle est établie par les utilisateurs, de manière décentralisée. Je peux taguer une ressource avec le mot-clé foobar ? Je n'ai pas à demander d'autorisation, je le fais. Cela donne ce qu'on nomme la folksonomie, la classification par le peuple, pour le peuple.

Cette idée de tagging est tellement à la mode (tout le monde s'en réclame désormais) qu'elle a même donné lieu à un pastiche, http://www.tagtagger.com/.

Les deux sites à folksonomie les plus connus sont del.icio.us et Flickr.

del.icio.us est un site qui ne contient pas d'informations, uniquement des signets. Chacun enregistre les signets de son choix (vous pouvez voir les miens en http://del.icio.us/bortzmeyer). Et chacun peut marquer ses signets avec des tags. On peut ensuite consulter del.icio.us par utilisateur (comme le lien précedent) ou par tag (par exemple, pour voir les liens sur Xen, on peut regarder http://del.icio.us/tag/Xen. Et il existe de nombreuses autres possibilités (pas toujours bien documentées).

Flickr, quant à lui, contient de l'information en quantité, c'est devenu le principal outil de publication de photos. Toute manifestation contre le CPE est immédiatement suivie d'une publication sur Flickr de toutes les photos prises par les nombreux appareils numériques présents. Ces photos peuvent ensuite être taguées et cherchées par tag, par exemple http://www.flickr.com/photos/tags/Sarlat si je cherche des photos de Sarlat dans le Périgord, ou par utilisateur ou par une combinaison des deux.

Comme avec tous les systèmes où les utilisateurs peuvent non seulement accéder à l'information mais peuvent participer à sa création, les sceptiques se demandent si cela va vraiment marcher. Comment gérera t-on les synonymes (le tiers des photos d'un numbat taguées avec "numbat", un autre tiers avec "fourmilier" et le dernier tiers avec "myrmécobie"), par exemple ? Ce qui est curieux, et montre la nécessité d'essayer avant de prédire "ça ne marchera pas" est que, en pratique, la plupart des folksonomies tendent à s'uniformiser. Les logiciels aident à cette uniformisation en proposant des tags, par exemple si j'enregistre dans del.icio.us le site http://www.bravepatrie.com/, del.icio.us me propose le tag "humour" (car c'est le tag le plus souvent utilisé par les autres qui ont tagué ce site) qui est tout à fait adapté.

Ce mécanisme d'interaction entre utilisateurs (parfois appelé un peu pompeusement "La sagesse des foules") a été bien décrit dans l'article Folksonomies ; Tidying up Tags? du magazine D-lib.

Un avertissement au passage : vous ne verrez pas de photos de moi sur Flickr car je préfère les mettre sur Wikimedia Commons où ne se trouvent que des photos libres (celles de Flickr ont des licences très variées et je ne vois pas de moyen de chercher par licence, pour pouvoir les réutiliser).

Autre avertissement : tout lien que vous mettez sur del.icio.us enrichit une base de données que Yahoo a racheté très cher. Comme le souligne Paul Graham, autrefois, l'informatique était dominée par le hardware lock-in : les fabricants de matériel contrôlaient le jeu. Après, on est passé au software lock-in. Les éditeurs de logiciels commandaient. Désormais, on est au data lock-in : toutes tes données appartiennent à Google ou Yahoo.

Comme le tag peut être apposé par un autre que l'auteur, il fournit une base à des systèmes d'accréditation non-hiérarchiques, en réseau. Par exemple, si j'apprécie les tags de l'utilisateur "nwsmith" sur del.icio.us, je peux regarder tout ce qu'il a tagué en http://del.icio.us/nwsmith et le prendre ainsi pour guide. (Au fait, mes liens à moi sont en http://del.icio.us/bortzmeyer.) Chacun peut ainsi être accréditateur et recommander des sites. Un tel mécanisme avait déjà été proposé pour le projet Interpedia en 1993 (les tags se nommaient seals of approval) et pourrait fournir une base de solution très intéressante au problème récurrent de la validation des données dans une encyclopédie ouverte comme Wikipédia. Au lieu de vouloir interdire les articles supposés "de mauvaise qualité" (ce qui est très subjectif et entrainerait des disputes sans fin), on taguerait les bons articles et on permettrait une navigation par tag.


L'article seul

Pourquoi je ne suis pas encore passé à Unicode

Première rédaction de cet article le 29 mars 2006
Dernière mise à jour le 9 juin 2006

Je suis un grand fan d'Unicode, le jeu de caractères qui enterre tous les autres jeux de caractères en permettant d'encoder toutes les écritures du monde. Alors, pourquoi est-ce que je ne l'utilise pas moi-même sur mon poste ?

J'ai même écrit un cours en français sur Unicode. Mais, sauf exceptions, je ne l'utilise pas. J'édite les pages de mon blog, comme celle-ci, en Latin-1. Mes fichiers textes, par exemple mes sources LaTeX ou DocBook, ou encore mes sources écrits en Python sont également en Latin-1. J'envoie du courrier en Latin-1. Parmi les exceptions, notons que les pages de mon blog sont publiées dans un encodage d'Unicode, UTF-8 et que je configure toujours mes bases de données PostgreSQL pour utiliser Unicode.

Pourquoi ne fais-je pas plus d'Unicode ? Bien sûr, mon choix de n'utiliser que du logiciel libre limite parfois mes possibilités, par exemple pour programmer en Java ou bien pour voir des gadgets qui bougent en Flash. Mais, pour Unicode, le logiciel libre n'est pas complètement désarmé et il existe même de nombreuses et excellentes documentations sur Unicode avec Unix comme Step by step introduction to switching your debian installation to utf-8 encoding ou The Unicode HOWTO, DebFrUTF8 (spécifique à Debian), Make your system use unicode/utf-8 (spécifique à Gentoo) ou encore The Unicode HOWTO ou enfin et surtout UTF-8 and Unicode FAQ for Unix/Linux. (Les utilisateurs de FreeBSD peuvent regarder Unicode Support on FreeBSD, encore très sommaire.)

Le problème est que tout n'est pas "Unicodisé". Les partisans d'Unicode tout de suite mettent en général en avant le fait que tel ou tel logiciel accepte Unicode. Mais, sur Unix, on n'utilise pas qu'un seul logiciel mais toute une boîte à outils dont la combinaison permet des choses extraordinaires. Je ne travaille pas qu'avec OpenOffice (en fait, je fais plus souvent des documents avec LaTeX qu'avec OpenOffice, ce qui nécessite apparemment d'installer une extension et d'ajouter \usepackage[utf8x]{inputenc} dans le source) et il me faut donc attendre, avant de passer à Unicode, que pas mal d'outils aient été adaptés ou aient un équivalent.

Si mon éditeur favori, Emacs, se débrouille maintenant à peu près normalement (mais cela a pris du temps et il est bien plus lent en mode Unicode, ce qui est pénible pour les vieilles machines), et que je peux éditer les pages de Wikipédia en Unicode, si j'arrive à lancer un terminal (LC_CTYPE=fr_FR.UTF-8 xterm -u8 -fn '-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1' où des programmes comme cat ou more l'affichent proprement, bien d'autres ne sont pas "Unicodisés".

Mais c'est surtout grep qui me manquerait : je suis habitué à taper grep écart *.tex et il me trouve tous les fichiers contenant ce mot. Si j'encodais tout en UTF-8, je n'aurai plus d'outil de recherche. (Marc Baudoin me fait remarquer que Perl gère parfaitement l'UTF-8 et peut donc être utilisé pour écrire rapidement un "grep-like" ; en voici un exemple et autre en Python. Cela marche, mais c'est peu pratique d'avoir deux outils différents.)

De même, mon outil d'impression de fichiers textes, a2ps, ne comprend pas l'UTF-8. Je ne vais quand même pas lancer un monstre comme OpenOffice à chaque fois que je veux imprimer un script Python de dix lignes.

Bref, Unicode pour moi sera lorsque les applications traditionnelles auront été adaptées, pas juste deux ou trois gros logiciels. Ce n'est finalement qu'en 2012 que je suis passé à UTF-8.


L'article seul

RFC 4417: Report of the 2004 IAB Messaging Workshop

Date de publication du RFC : Février 2006
Auteur(s) du RFC : P. Resnick (IAB), P. Saint-Andre (JSF)
Pour information
Première rédaction de cet article le 29 mars 2006

Ce RFC est simplement le compte-rendu (fort tardif) d'un séminaire que l'IAB a organisé en octobre 2004 pour examiner, de haut, le statut des solutions de messagerie sur Internet et les recherches souhaitables pour l'améliorer.

Le séminaire associait à la messagerie par courrier électronique les techniques de messagerie instantanée et, même, dans une certaine mesures, certains aspects des blogs.

En effet, la messagerie, comme les autres applications de l'Internet, n'a pas été conçue en chambre : elle a évolué dans le monde réel, s'ajustant, s'étendant, se modifiant, sans schéma directeur bien précis. D'un côté, c'est ce qui a permis son succès, alors que les schémas géniaux d'organisations plus rigides que l'IETF ne connaissaient aucun succès. De l'autre, l'état actuel de la messagerie est celui d'un empilement de diverses techniques, avec peu de principes d'architecture, et qui est menacé par des phénomènes anti-sociaux comme le spam.

Le spam n'était pas un sujet de ce séminaire en tant que tel : les sujets couverts étaient de plus haut niveau, portant sur des principes d'architecture et cherchant à savoir dans quelle direction la recherche devrait se porter. Les sujets étaient :

  • Autorisation : comment un destinataire peut-il simplement et de façon sûre autoriser les envois vers sa boîte ? Les systèmes de réputation sont-ils l'avenir ? Les participants au séminaire ont recommandé leur étude.
  • Multiplicité des canaux de communication : si une conversation commence par courrier et se termine en Jabber, comment marquer les deux échanges pour voir qu'il s'agit de la même conversation ? Par exemple, dans le RFC 2822, les références au sein d'un fil de discussion sont uni-directionnelles, il faudrait étudier des systèmes plus riches.
  • Négociation: par exemple comment décider des options de vie privée avant une conversation (enregistrement ou pas) ?
  • Contrôle par l'utilisateur : un exemple typique est le filtrage du courrier. Que peut apporter l'architecture de la messagerie pour rendre ce filtrage plus efficace et plus simple ? Le langage Sieve est cité comme base possible pour des règles plus puissantes.
  • Transport des messages : transport fiable ou non-fiable mais avec réémission ? Les participants souhaitent le développement de techniques permettant de faire voyager les différentes parties d'un message sur des transports différents. Par exemple, la vidéo contenue dans un message pourrait passer sur un transport moins fiable mais moins coûteux.
  • Identité : notamment comment associer des clés cryptographiques à une identité ? DNSSEC semble l'outil préféré pour cette distribution.

La question des identifiants est souvent revenue dans le séminaire : toutes ces techniques nécessiteront des identifiants uniques et stables.

Téléchargez le RFC 4417


L'article seul

RFC 3704: Ingress Filtering for Multihomed Networks

Date de publication du RFC : Mars 2004
Auteur(s) du RFC : F. Baker (Cisco), P. Savola (CSC/FUNET)
Première rédaction de cet article le 24 mars 2006

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

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

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

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

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

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

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

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

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

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

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

Téléchargez le RFC 3704


L'article seul

Il est recommandé de fermer les serveurs DNS récursifs ouverts

Première rédaction de cet article le 23 mars 2006
Dernière mise à jour le 26 janvier 2009

Il est désormais fortement recommandé d'arrêter les serveurs DNS récursifs ouverts, qui représentent un grand danger pour l'Internet.


L'article complet

RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing

Date de publication du RFC : Mai 2000
Auteur(s) du RFC : P. Ferguson (Cisco), D. Senie (Amaranth)
Première rédaction de cet article le 23 mars 2006
Dernière mise à jour le 14 novembre 2006

Une faille sérieuse de la sécurité dans l'Internet, identifiée depuis de nombreuses années, est la trop grande facilité avec laquelle une machine peut usurper (spoofer) son adresse IP source. Un attaquant peut ainsi déguiser son identité et court-circuiter les filtres. Ce RFC propose une solution, que les FAI devraient déployer, si on veut améliorer sérieusement la sécurité de l'Internet.

Mettons que ma machine soit connectée à l'Internet, via un FAI, avec l'adresse IP 172.20.34.125. Je pingue une machine distante, par exemple www.elysee.fr. C'est ma machine qui fabrique les paquets IP et qui met dans le champ "adresse IP source" le 172.20.34.125. Mais si je suis un méchant, qu'est-ce qui m'empêche de mettre une autre adresse en source ? Rien. (Si vous ne savez pas programmer, ne vous inquiétez pas, des outils comme hping sont là pour cela, avec l'option bien nommé --spoof.)

L'adresse source étant usurpée, l'attaquant ne recevra en général pas la réponse mais, pour certains protocoles, comme UDP, ce n'est pas un problème.

Et cela permet des attaques intéressantes, comme les DoS. La victime ne pourra pas savoir d'où le paquet vient réellement. Il y a aussi les attaques par réflexion où l'attaquant écrit à une machine tiers, en usurpant l'adresse de sa victime. Le tiers va alors répondre à la victime, qui se croira attaquée par le tiers, pourtant innocent. Une telle attaque est décrite en http://www.grc.com/dos/drdos.htm.

Encore pire, les attaques par réflexion avec amplification, qui permettent à l'attaquant d'obtenir un débit sur sa victime supérieur à celui que l'attaquant doit lui-même fournir. Les récentes attaques DNS, utilisant comme tiers des relais DNS récursifs ouverts, appartiennent à cette catégorie. Ces attaques sont décrites en http://weblog.barnet.com.au/edwin/cat_networking.html et une approche du problème est en http://www.isotf.org/news/DNS-Amplification-Attacks.pdf.

Notre RFC propose donc de tenter de mettre fin à ces usurpations. Cela peut se faire chez les FAI, en s'assurant que ne peuvent sortir du réseau du FAI que les paquets IP dont l'adresse est une des adresses allouées par ledit FAI.

Le principe est simple (notre RFC est d'ailleurs très court car, techniquement, il n'y a pas grand'chose à dire) : sur les routeurs du FAI, soit sur ceux faisant face aux clients, soit sur ceux de sortie, mettre en place une règles de filtrage interdisant tout trafic venant d'une adresse non allouée. Par exemple, si le routeur est une machine Linux, et que le réseau du FAI est le 172.20.128.0/22, il suffit de : 

iptables --insert FORWARD --out-interface eth1 --source \! 172.20.128.0/22  --jump LOG --log-prefix "IP spoofing"
iptables --insert FORWARD --out-interface eth1 --source \! 172.20.128.0/22  --jump DROP

Naturellement, il faut bien vérifier qu'on couvre tous les cas : beaucoup d'opérateurs ont du mal à compiler une liste exacte de tous leurs préfixes, ce qui explique en partie le peu de déploiement de ce RFC.

Notons que, comme toute mesure de sécurité, celle-ci a des faux positifs (le RFC cite le cas des mobiles) et qu'elle peut bloquer ou bien rendre très difficiles des usages parfaitement légitimes (le RFC cite le cas du multihoming, traité dans un autre document, le RFC 3704). Elle a aussi des faux négatifs : certaines usurpations ne seront pas forcément détectées, par exemple lorsqu'un client du FAI usurpe l'adresse d'un autre client du même FAI.

Notre RFC date de presque six ans et ne semble toujours pas largement déployé : cela donne une idée de la difficulté du problème. En effet, déployer ce RFC (aussi connu sous son numéro de bonne pratique, BCP38), coûte de l'argent au FAI et en fait économiser aux autres opérateurs de l'Internet, par les attaques que cela leur épargne. On conçoit que le simple bon sens économique et l'absence de régulation autre que celle du marché limitent la mise en œuvre de ce RFC.

Téléchargez le RFC 2827


L'article seul

Les bases de données XML

Première rédaction de cet article le 16 mars 2006

Les bases de données existent en informatique depuis de très nombreuses années et, aujourd'hui, presque toutes celles qui sont en production sont des bases de données relationnelles. Les bases de données XML vont-elles les remplacer, au moins partiellement ?

Une base de données XML est une base de données qui stocke des documents XML. Plus précisément (car un SGBD relationnel peut stocker des documents XML comme texte), elle est optimisée pour le XML et permet d'utiliser des langages de requête XML comme XPath ou XQuery).

Voici un exemple d'utilisation d'une base de données XML ultra-simple, nommée Agouti en l'honneur d'un mignon mammifère (le code sources est disponible) : 


% ./agouti init experimental
% ./agouti add  experimental test.xml
Added test.xml as ID 1
% ./agouti query  experimental '//*[text()="Moi"]' 
1: <author>Moi</author>
% ./agouti delete  experimental 1
% ./agouti query  experimental '//*[text()="Moi"]'
%

Ce qui manque à agouti ?

  • Indexation : pas seulement du texte ou du nom des éléments mais aussi des relations entre éléments pour des expressions comme foo/bar. Le problème est très complexe et a fait l'objet de nombreuses publications comme l'excellente Accelerating XPath Evaluation in Any RDBMS.
  • Validation : tester les documents en entrée contre un schéma.
  • Méta-information : nom du document, date de dépôt.

Alors, quels sont les logiciels sérieux de base de données XML ? Je n'ai testé que DB-XML (les autres sont en Java et ne semblent pas tourner sur du logiciel libre) et cela ne me semblait pas encore très au point.

À noter que les bases de données relationnelles ordinaires peuvent désormais, non seulement stocketrdu XML (après tout, ce n'est que du texte) mais également effectuer des recherches avec des langages comme XPath. Voici comment faire en PostgreSQL. Cela ne transforme pas pour autant le SGBD relationnel en SGBD XML puisque, par exemple, il n'y a aucune indexation des données, obligeant à analyser le document XML à chaque fois.


L'article seul

Programmation réseau avec REST

Première rédaction de cet article le 13 mars 2006
Dernière mise à jour le 8 novembre 2006

REST est une des techniques d'interface d'une application Web avec le monde extérieur. Si un service Web veut être accessible par des programmes, pas seulement par des humains, REST offre une interface simple et facilement accessible.


L'article complet

RFC 4274: BGP-4 Protocol Analysis

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : D. Meyer (Cisco), K. Patel (Cisco)
Pour information
Première rédaction de cet article le 9 mars 2006

Ce RFC analyse les grandes caractéristiques du protocole BGP.

BGP est un protocole riche et complexe (le RFC 4271 fait 104 pages). Et il est bien agréable d'avoir une analyse qui décrit les principaux éléments de BGP et comment remplit-il son cahier des charges. Si ce RFC n'est pas un tutoriel, et ne dispense pas de lire le RFC 4271, il peut quand même servir de carte pour la navigation dans le monde riche et complexe du routage inter-domaine sur Internet.

Téléchargez le RFC 4274


L'article seul

RFC 2629: Writing I-Ds and RFCs using XML

Date de publication du RFC : Juin 1999
Auteur(s) du RFC : M. Rose (Invisible Worlds)
Pour information
Première rédaction de cet article le 9 mars 2006

Dans toute organisation qui s'occupe de technique, le choix du format de fichiers pour la documentation est une question délicate et souvent polémique. L'IETF n'y échappe pas et ce RFC, qui tentait de normaliser un format XML pour l'écriture des RFC n'a pas été un succès complet. (Depuis, il a été remplacé par le RFC 7749.)

Contrairement à beaucoup d'organisations de normalisation, qui produisent des normes dans des formats spécifiques d'un traitement de textes commercial, au mépris des besoins et intérêts des lecteurs, l'IETF a toujours insisté sur l'importance de publier dans un format ouvert. Pour des raisons historiques, les RFC sont publiés en texte brut, encodé en ASCII (ce qui ne permet pas d'afficher correctement les noms des auteurs non anglo-saxons). Toujours pour des raisons historiques, l'éditeur des RFC (qui est indépendant de l'IETF) utilise nroff comme format d'entrée (décrit dans le RFC 2223). Si cela peut sembler archaïque, il faut se rappeler que l'IETF a des exigences bien particulières et qu'un RFC n'est pas une note de service, qui sera jetée au bout de quelques semaines : étant (souvent) une norme, le RFC doit pouvoir être lu par tous, pas seulement par les clients de Microsoft, et il doit être pérenne (le RFC sur IP, le RFC 791 date de septembre 1981 ; quel traitement de textes à forts effets visuels pourrait durer aussi longtemps ?).

Ce format antédiluvien pose néanmoins de plus en plus de problèmes et des alternatives ont été proposées. Il est intéressant de noter qu'aucune n'a fait l'objet d'un consensus et, l'IETF n'ayant aucun moyen de trancher ce genre de querelles, les auteurs de RFC continuent à utiliser plusieurs formats.

Les deux formats les plus utilisés sont le gabarit MS-Word, décrit dans le RFC 3285 et un format XML, décrit dans notre RFC.

Compte-tenu des avantages de XML (portabilité, ouverture du format, possibilité d'édition avec n'importe quel éditeur et possibilité de produire facilement des formats d'affichage comme HTML), le choix semblait évident. Notre RFC décrit, grâce à une DTD, les éléments XML autorisés (au nombre de 42, ce qui rend ce langage bien plus simple que DocBook ou OpenDocument). On trouve des outils de conversion (par exemple vers nroff) de ce format, un index en XML des RFC (je l'utilise pour créer automatiquement le point de départ des articles RFC de ce blog), et des documents d'exemple sur http://xml.resource.org/.

Notre RFC apparait donc ainsi en HTML et le source XML commence avec : 


<rfc number="2629" category="info">
<title>Writing I-Ds and RFCs using XML</title>
<author initials="M.T." surname="Rose" fullname="Marshall T. Rose">
<email>mrose@not.invisible.net</email>
</author>
<date month="June" year="1999"/>
<section title="Introduction" toc="default">
<t>This memo describes how to write a document for the I-D and RFC series
using <xref target="XML" format="default" pageno="false">the Extensible Markup L
anguage</xref> (XML).
This memo has three goals:
<list style="numbers">
<t>To describe a simple XML Document Type Definition (DTD)

Notre RFC souffre de son âge par exemple en utilisant toujours une DTD, technique désormais dépassée. Et la principale transformation, celle en texte, n'est pas faite avec XSLT mais avec un script TCL ad hoc. Une nouvelle version de notre RFC est à l'étude depuis un certain temps.

Comme l'a montré encore récemment une longue discussion à l'IETF, il ne manquait plus à ce format que l'adoption généralisée... Peut-être que son successeur, le RFC 7749 réussira mieux.

Téléchargez le RFC 2629


L'article seul

RFC 4228: Requirements for an IETF Draft Submission Toolset

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : A. Rousskov (The Measurement Factory)
Pour information
Première rédaction de cet article le 8 mars 2006

Il est banal de dire que les cordonniers sont les plus mal chaussés. L'IETF, l'organisme qui normalise les protocoles de l'Internet traite ses projets de norme de manière encore très manuelle. Mais voici un cahier des charges pour la future automatisation.

Les fameux RFC, parmi lesquels se trouvent les normes de l'Internet, commencent leur vie comme Internet-drafts. Ces projets sont soumis au secrétariat de l'IETF, publiés par l'IETF et une minorité d'entre eux deviendront des RFC. Notre RFC explique comment soumettre un draft à l'heure actuelle et c'est un processus très manuel, lent, et propice aux erreurs.

L'IETF prend donc le taureau par les cornes et publie un cahier des charges pour le futur outil (The Toolset) de soumission. Les auteurs disposeront d'une interface Web pour voir leurs soumissions et les annuler éventuellement. L'outil devra pouvoir faire automatiquement un certain nombre de vérifications (comme la syntaxe du titre, ou comme la présence des textes juridiques obligatoires), générer le draft à partir de son source XML, etc.

Naturellement, le RFC insiste beaucoup sur l'importance que le futur outil soit ouvert et pérenne, donc en logiciel libre.

Téléchargez le RFC 4228


L'article seul

Fiche de lecture : Producing open source software

Auteur(s) du livre : Karl Fogel
Éditeur : O'Reilly
0-596-00759-0

Première rédaction de cet article le 27 février 2006
Dernière mise à jour le 1 mars 2006

Il existe de nombreux livres sur les outils et les techniques de production de logiciels. Il y a beaucoup d'ouvrages sur la gestion de projets logiciels. Mais il n'y avait guère de texte s'attaquant à la gestion de projets de logiciel libre, qui est pourtant assez spécifique (moins de camemberts et de diagrammes que dans les projets commerciaux, mais davantage de communication et de textes).

Karl Fogel a déjà écrit un livre sur CVS et a été un des développeurs de CVS et de Subversion. Mais son mérite ici est autre : il essaie d'expliquer comment fonctionne un projet de logiciel libre, du point de vue technique bien sûr, mais aussi et surtout dans les aspects humains.

Les textes précédents sur cette question étaient soient des proclamations très biaisées (tout est super, tout le monde est heureux, la liberté, c'est formidable) soit des productions très partielles, comme le célèbre article d'Eric Raymond, The cathedral and the bazaar, qui a l'avantage d'avoir été l'un des tout premiers à expliquer comment sont produits les logiciels libres, mais dont le principal inconvénient était de ne traiter qu'un seul type d'organisation (le bazar), en oubliant que la principale caractéristiques des logiciels libres est justement leur variété, technique bien sûr, mais aussi organisationnelle. Karl Fogel n'échappe d'ailleurs pas toujours à ce travers (pour des raisons évidentes, la plupart des exemples concernent Subversion) mais au moins il le reconnait.

Le livre couvre donc :

  • L'infrastructure technique du projet. Si les logiciels libres n'utilisent pas MS project, ils dépendent néanmoins de beaucoup d'outils comme le système de gestion de versions.
  • L'organisation du projet, analysée par notre Montesquieu du logiciel libre. Le projet peut être démocratique (au sens athénien du terme, donc une démocratie réduite à une petite élite) ou bien géré par un dictateur. (C'est le terme qui est utilisé, par exemple pour Python. Loin des hypocrisies de la gestion des ressources humaines, le monde du logiciel libre aime bien appeler un chat un chat. Les administrateurs de Wikipédia ont le titre officiel de "bureaucrates".)
  • La question toujours délicate de l'argent et du financement.
  • La communication entre les développeurs, avec tous ses pièges, s'agissant d'organisations internationales, et où l'ultima ratio de la hiérarchie n'est pas toujours possible.
  • La gestion du personnel, celle dont le célèbre Andy Tanenbaum prédisait, dans un débat mémorable en 1993 avec Linus Torvalds, qu'elle serait l'écueil sur lequel se briserait tout projet de logiciel libre.
  • Les questions juridiques, licences, brevets, etc.

Sur tous ces points, Karl Fogel est un grand connaisseur et sait toujours expliquer clairement les enjeux et les bonnes approches.

Un livre dont le but affiché est de servir aux auteurs de logiciel libre mais qui peut être lu par toute personne qui s'intéresse à ces projets qui semblaient utopiques il y a encore quinze ans. Ceux qui se demandent "Comment est-ce que cela peut marcher ?" trouveront sans doute des éléments de réponse dans ce livre.

Le livre est intégralement enligne, en http://producingoss.com/.


L'article seul

Nous sommes tous des sauterelles

Première rédaction de cet article le 23 février 2006
Dernière mise à jour le 2 septembre 2010

Si vous regardez ce blog sans payer, vous êtes un insecte nuisible. C'est ce qu'affirme la campagne actuelle du gouvernement français.

Même chose si vous accédez à une des innombrables ressources libres disponibles sur Internet comme l'encyclopédie Wikipédia ou comme les RFC.

Le gouvernement remet sur la table le projet de loi DADVSI, dont une première version s'était cassée la figure à l'Assemblée, et lance cette fois un lourd arsenal de propagande, autour du site http://lestelechargements.COM (on note l'extension commerciale, qui indique bien les préoccupations du Ministère dit de la Culture).

Le chef d'œuvre de ce site est un film, nommé « Les sauterelles ». Il n'est diffusé qu'en utilisant la technique fermée Flash (là encore, c'est parfaitement logique pour un projet de loi qui s'attaque entre autre au logiciel libre) mais une version MOV est disponible en http://hack.tion.free.fr/video/leshordesbarbares.mov.

Pour illustrer les principe défendu par http://rddv.com/ (ministre de la culture à l'époque et bien oublié aujourd'hui) comme quoi il n'y a pas de citoyen sur Internet, juste des consommateurs, le film les montre comme des insectes ravageant un champ. L'idée que l'internaute puisse être également un producteur, un créateur, n'est manifestement pas arrivée jusqu'au Ministère.

Ce film noir et blanc utilise toutes les techniques de la propagande cinématographique, à un point qui rappelle les plus grandes réalisations de ce domaine comme Le Triomphe de la volonté.

Il illustre surtout la façon dont le gouvernement voit les citoyens : une nuée d'animaux nuisibles et voraces, les sauterelles. Ce n'est pas innocent de représenter les utilisateurs de l'Internet comme des animaux, surtout comme une masse d'animaux indifférenciés, ceux contre lesquels on n'hésite pas à épandre l'insecticide.

Depuis sa publication initiale, le nom de domaine http://lestelechargements.COM n'a pas été renouvellé et est aujourd'hui utilisé par un domaineur. Belle illustration du manque de sérieux et de suite dans les idées, manque qui affecte le département de la propagande...


L'article seul

Formats ouverts, ça veut dire quoi ?

Première rédaction de cet article le 22 février 2006
Dernière mise à jour le 10 juin 2009

Maintenant que le logiciel libre est entré dans les mœurs, il est temps de se demander quelle est sa relation avec les formats ouverts. Qu'est-ce qu'un format ouvert ?


L'article complet

Zéro, de Denis Guedj

Première rédaction de cet article le 22 février 2006

Un roman formidable, qui décrit la lente invention du zéro, à travers cinq époques, et un seul pays, entre deux fleuves...

Denis Guedj, l'auteur de « La Méridienne » et du « Théorème du perroquet » a commis un nouveau roman scientifique. Cette fois, pas de savants républicains mesurant le mètre, pas de personnages historiques, mais cinq femmes, portant le même prénom, qui, chacune à son époque, entre le Tigre et l'Euphrate ont contribué à l'aventure du zéro. Beaucoup d'efforts, de calculs, de dangers, de nuits au sommet de la ziggourat, pour arriver à modéliser... rien.


L'article seul

RFC 2033: Local Mail Transfer Protocol

Date de publication du RFC : Octobre 1996
Auteur(s) du RFC : J. Myers (Carnegie Mellon)
Pour information
Première rédaction de cet article le 21 février 2006

Ce RFC normalise LMTP (Local Mail Transfer Protocol), une variante du protocole SMTP de transmission du courrier électronique.

SMTP convient mal aux cas où le serveur suivant ne gère pas de file d'attente et peut, de manière synchrone, délivrer le message ou bien annoncer avec certitude qu'il est indélivrable. En fait, LMTP est un protocole de communication entre MTA et MDA, pas entre MTA, comme l'est SMTP.

LMTP est très proche de SMTP, il reprend les mêmes concepts et commandes, mais il y a quelques différences, notamment le fait que, si un message a plusieurs destinataires, le succès ou bien l'échec de la délivrance peut être par utilisateur et pas seulement par message.

LMTP est mis en œuvre dans Postfix (voir la documentation provisoire) et dans Cyrus.

Téléchargez le RFC 2033


L'article seul

Growing a language, de Guy Steele

Première rédaction de cet article le 20 février 2006

Pour penser un peu, au lieu de simplement bricoler en PHP... Un excellent article de Guy Steele sur la conception de langages de programmation.

L'auteur est surtout connu comme gourou Scheme. Mais cet article parle plutôt de Java et de comment le faire évoluer. La thèse de l'auteur est qu'un langage ne doit pas forcément être riche mais qu'il doit être évolutif, que ce qui lui manque puisse être facilement ajouté par ses utilisateurs.

Guy Steele cite de nombreux exemples, d'APL (trop dur à faire évoluer) à PL/I (trop riche dès le début).

La principale originalité de l'article est que, pour illustrer sa thèse, il commence par définir tous les mots utilisés dans l'article (non, pas tous, je vous laisse trouver l'algorithme vous-même, avant que l'auteur ne le révèle, vers la fin).


L'article seul

Langages de patch pour XML

Première rédaction de cet article le 19 février 2006

Lorsqu'on veut mettre à jour un gros document XML, il serait très intéressant de pouvoir ne transmettre que la différence avec l'ancien document, le patch. Cela permettrait également de mieux documenter la différence entre les deux fichiers. Mais il n'existe pas de langage standard pour exprimer ces patches. Il y a plusieurs propositions concurrentes.

Un exemple tiré d'une des propositions, XML-patch, vaut mieux qu'un long discours : 


   <add sel="doc"><bar id="ert4773">This is a new child</bar></add>
   <remove sel="doc/foo[@a='1']"/>

Le patch ci-dessus crée un nouvel élément "bar" et détruit un élément "foo". Comme toutes les propositions de langage de patch, celle-ci utilise XPath pour désigner l'endroit où se font les changements.

Les propositions existantes sont :

  • REX, qui vient du consortium W3C et qui est bien plus qu'un langage de patch puisqu'il s'agit d'un moyen de décrire des évenements DOM distants.
  • Xquery Update, également du W3C, et qui est une extension de XQuery, qui avait été prévu pour étendre XPath.
  • XUpdate, de XML:DB, qui semble aujourd'hui abandonné (la dernière version date de 2000).
  • DUL (décrit dans l'Internet-draft draft-mouat-xml-patch-00.txt).
  • XML-patch (décrit dans le RFC 5261). C'est celui que je trouve le plus simple et le plus proche du cahier des charges "un langage de patch".

(Avec un autre langage de données, JSON, Rob Sayre a proposé un format de patch sympathique.)

Une fois qu'on aurait un tel langage, il suffirait de modifier un des programmes de calculs de différence entre fichiers XML (comme Python xmldiff).


L'article seul

Aider une francophonie ouverte sur l'Internet

Première rédaction de cet article le 17 février 2006
Dernière mise à jour le 20 février 2006

Régulièrement, se tiennent des colloques ou conférences sur le développement des NTIC dans l'espace francophone. Tout aussi régulièrement sont lancés de Grands Projets pour aider au développement de ladite francophonie, sur un Internet vu comme dominé par les anciennes colonies de la couronne britannique. Ces grands projets ont souvent en commun de coûter cher, d'impliquer des entreprises privées à finalité commerciale, et de sombrer assez rapidement dans l'oubli, souvent sans laisser de traces. Et s'il était temps d'aider une francophonie plus ouverte ?

L'un des échecs les plus frappants concerne un projet commun des Éditions Hachette et de l'AUPELF-UREF pour mettre en ligne un "Dictionnaire Universel Francophone" qui (une fois les subventions touchées) a disparu du réseau... En 1998, le lancement de ce dictionnaire avait été précédé d'une importante campagne de publicité, avec des proclamations comme : « Pour que sa diffusion soit la plus large possible, l'AUPELF-UREF et l'éditeur ont consenti un impressionnant effort financier afin que les moins favorisés puissent acquérir cet ouvrage indispensable. » Hachette a retiré le lien depuis longtemps mais on peut encore voir l'éléphant blanc sur Web Archive. Vue la licence affichée (« Toute reproduction par quelque moyen que ce soit sans autorisation explicite des ayants droit est formellement interdite. »), ce travail est désormais complètement perdu alors que plusieurs personnes avaient pris la précaution de le sauvegarder.

L'histoire de la francophonie est pleine de ces éléphants blancs : on les annonce par une conférence de presse à grand tapage, avec présence de deux ou trois ministres, on trouve un "partenaire industriel" qui va être ravi des subventions étatiques, et deux ou trois ans, après, il ne reste plus rien. L'ex- projet Quaero de "moteur de recherche européen" a suivi le même chemin (lancement sous le patronage du Président de la République en personne, logiciel non-libre, déclarations grandiloquentes remplaçant le travail concret, etc) jusqu'à sa triste fin.

Je propose de changer sérieusement de méthode : pour que l'argent cesse d'être gaspillé dans des projets qui ne laissent rien de leur passage, il faudrait que :

  • On puisse garantir que les résultats du projet soient accessibles à tous, surtout au cas où le projet se termine. Cela implique des licences libres pour le contenu et les logiciels. Par exemple, pour des documents, des projets financés par l'argent public devraient être disponibles sous une licence comme la GFDL ou bien une des licences Creative Commons. Autrement, le partenaire privé peut bloquer éternellement le contenu qui aura été produit.
  • Et que le projet ne soit pas monté de zéro, ce qui rend très incertain son avenir. Il faudrait au contraire aider au développement de projets existants, qui ont déjà démontré sur le terrain leur aptitude à survivre sans subventions. Trois exemples : Wikipédia, ABU (qui met en ligne des ouvrages du domaine public) et revues.org, un système de publication de revues en sciences humaines.

Le modèle de projet de développement de contenu francophone sur Internet devrait donc être centré sur un projet existant : créer une communauté, un état d'esprit, des pratiques sociales prend en effet du temps et il serait dommage de vouloir réinventer la roue.

Pour prendre l'exemple de Wikipédia, on pourrait imaginer les projets suivants :

  • Salarier des contributeurs à Wikipédia. Lorsque le projet se termine, leurs contributions resteront accessibles à tous, sous licence GFDL. Ces contributions peuvent être l'écriture d'articles nouveaux, la correction d'articles existants, la catégorisation, etc.
  • L'organisation d'évenements Wikipédia permettant aux contributeurs de se rassembler dans un lieu où un bon accès réseau leur permettrait de contribuer à Wikipédia sur un thème donné. Par exemple, pendant le festival du cinéma à Ouagadougou, les cinéphiles férus de NTIC pourraient être invités à une soirée Wikipédia dans un local muni d'ordinateurs où ils ajouteraient à Wikipédia ce qu'ils savent sur le cinéma africain (peu mentionné aujourd'hui dans Wikipédia).

L'article seul

Fichier d'adresses de courrier

Première rédaction de cet article le 16 février 2006

Il est bien pratique de pouvoir garder trace de ses correspondants. Certains logiciels de messagerie le font automatiquement mais, dans un esprit plus unixien, je cherchais une solution indépendante du MUA. Voici comment j'ai fait.

Lorsque le courrier arrive, il est délivré par procmail qui a une recette : 

:0c:tmp/extract-from.lock
* !^FROM_DAEMON
* ^TO_(bortz|bortzmeyer|stephane)
* !^X-Spam-Flag: *YES
* !^X-Bogosity: *(YES|Spam)
| $HOME/bin/extract-from.py

Elle se lit ainsi : si le message ne vient pas d'un démon, s'il est bien pour moi personnellement (et pas envoyé à une liste dont je suis membre), s'il n'est pas un spam, alors, le soumettre au programme extract-from.py.

Ce programme extrait les en-têtes et les mets dans une base de donnée indexée (utilisant Berkeley DB).

Cette base peut ensuite être consultée avec le programme display-from.py : 

 
% display-from.py foobar
Joe Foobar <fu@example.org>: 19 times (last time 09 September 2004)
% display-from.py 'foo?bar'
Joe Foobar <fu@example.org>: 19 times (last time 09 September 2004)
Jill Fobar <jf@example.com>: 1 times (last time 13 October 2005)

Comme on le voit, ce programme permet de chercher par expression rationnelle, et affiche non seulement l'adresse mais également le nombre de messages et la date du plus récent (ce qui donne une idée de la fraicheur de l'information).

La base étant en binaire, il est raisonnable de la sauvegarder régulièrement sous forme texte avec le script backup-db, lancé par cron.

Vous pouvez récupérer les fichiers cités ici :

À faire : ce fichier étant nominatif, le déclarer à la CNIL. Si chaque possesseur de PDA ou de logiciel stockant les carnets d'adresse en faisaient autant, la CNIL s'écroulerait.

Une alternative à ce bricolage local est d'utiliser le logiciel Little Brother's Database (lbdb) mais je ne l'ai pas encore testé.


L'article seul

RFC 4097: Middlebox Communications (MIDCOM) Protocol Evaluation

Date de publication du RFC : Juin 2005
Auteur(s) du RFC : M. Barnes (Nortel)
Pour information
Réalisé dans le cadre du groupe de travail IETF midcom
Première rédaction de cet article le 10 février 2006

Ce RFC étudie les différents candidats au rôle de protocole Midcom, le protocole de communication avec les middleboxes, lancé par le RFC 3303.

Le RFC 3304 spécifiait le cahier des charges du protocole Midcom, qui permettra la communication entr l'agent Midcom et les middleboxes. Notre RFC étudie maintenant les différents protocoles candidats auprès du groupe de travail :

et en déduit que tous pourraient convenir, SNMP étant quand même le plus proche des exigences. Midcom a donc été spécifié comme une MIB SNMP (pas encore publiée comme RFC).

Téléchargez le RFC 4097


L'article seul

RFC 4290: Suggested Practices for Registration of Internationalized Domain Names (IDN)

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : J. Klensin
Pour information
Première rédaction de cet article le 10 février 2006
Dernière mise à jour le 17 mars 2006

Les IDN ont toujours suscité des passions et il n'était donc pas évident de normaliser des politiques d'enregistrement, d'autant plus que chaque langue a ses particularités. L'IETF n'a donc pas essayé et le premier RFC non technique sur les IDN n'est donc pas une norme.

Le RFC 3490 spécifiait la norme IDN, permettant de représenter des noms de machines écrits en Unicode et pas seulement en US-ASCII. Ce RFC 3490, purement technique, ne spécifiait pas les politiques d'enregistrement des registres de noms. Ce choix est tout à fait justifié : au contraire des choix techniques, qui doivent être uniformes, il n'y a aucune raison de normaliser ces politiques, qui dépendent des choix de chaque registre.

Comme exemple de politiques possibles, dans le cas d'une population francophone, on peut imaginer que pere-noel.fx et père-noël.fx puissent être délégués à des entités différentes, malgré le risque de confusion ou bien au contraire que on définisse un lot (bundle) qui est l'ensemble des noms IDN équivalents (par exemple, pere-noel.fx est équivalent à père-noël.fx). Tous les membres du lot seraient alors délégués au même titulaire.

Plusieurs efforts ont été tentés pour discuter de ces politiques et, à défaut de normes, spécifier un cadre commun pour les exprimer. Cela a été fait, par exemple, dans la liste idn-reg-policy, aujourd'hui inactive. Parallèlement, certains registres asiatiques ont écrit le RFC 3743 qui décrit leur cadre politique.

Dans le cadre de la liste idn-reg-policy, Paul Hoffman, un expert en internationalisation avait proposé un langage pour décrire des tables de caractères avec leurs variantes (par exemple, ÿ peut être considéré comme une variante de y et donc pierre-louÿs.fx serait équivalent à pierre-louys.fx).

Notre RFC est proche des dernières versions des propositions d'Hoffman. Il ne présente pas une politique d'enregistrement mais il suggère des pistes, pointe des problèmes potentiels et propose une syntaxe pour exprimer les tables.

À titre d'information, voici la table des caractères utilisés en français, dans cette syntaxe (utilisant la notation Unicode donc U+00E7 est le "c cédille"). Le point de départ de cette table avait été un excellent article de Jacques André : 

# Variant table for the French language

# A sentence with every composed character: 
# Ils se sont réveillés à Nîmes, très tôt, dans la même Citroën
# niçoise sentant l'aïoli où ils avaient joué de cette flûte aiguë la
# nuit de Pâques, près de l'Haÿ-les-Roses.

# a-z
# a and its variants : à â
# á (a acute) does not seem to exist in French: for further study (town names?)
# a with ring above (U+00E5) does not exist in french but in picard
# http://www.picard.free.fr/lgpic/a-e.htm
U+0061|U+00E0:U+00E2
U+0062
# c
U+0063|U+00E7
U+0064
# e and its variants : è é ê ë
U+0065|U+00E8:U+00E9:U+00EA:U+00EB
U+0066
U+0067
U+0068
# i and its variants : î ï
U+0069|U+00EE:U+00EF
U+006A
U+006B
U+006C
U+006D
# ñ (U+00F1) does not exist in french but in breton
# http://www.ouest-france.fr/dossiershtm/cours-de-breton/lecture.htm
# or in basque.
U+006E
# o and its variants : ô. ö (U+OOF6) exists in French? No word uses 
# it.
# ò (U+00F2) does not exist in french but in occitan
# http://occitanet.free.fr/fr/index.html
U+006F|U+00F4
U+0070
U+0071
U+0072
U+0073
U+0074
# u and its variants : ù û ü
# ú (u acute) does not seem to exist in French: for further study
U+0075|U+00F9:U+00FB:U+00FC
U+0076
U+0077
U+0078
# y. ÿ only in names? (L'Haÿ-les-Roses)
U+0079|U+00FF
U+007A
# 0-9
U+0030
U+0031
U+0032
U+0033
U+0034
U+0035
U+0036
U+0037
U+0038
U+0039
# - (hyphen)
U+002D
# Ligature oe: the variant is a *string*
U+0153|U+006F-U+0065
# Ligature ae (æ). Only in names like Lætitia?
U+OOE6|U+0061-U+0065

À noter que le RFC prend ses distances avec l'ICANN, qui a décidé d'établir une table des langages à l'IANA, table pour laquelle l'ICANN n'a ni légitimité, ni compétence et que la plupart des registres ont refusé de remplir.

Téléchargez le RFC 4290


L'article seul

RFC 3303: Middlebox communication architecture and framework

Date de publication du RFC : Août 2002
Auteur(s) du RFC : P. Srisuresh (Kuokoa), J. Kuthan (Fraunhofer Institute), J. Rosenberg (dynamicsoft), A. Molitor (Aravox), A. Rayhan (Ryerson University)
Pour information
Réalisé dans le cadre du groupe de travail IETF midcom
Première rédaction de cet article le 10 février 2006

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

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

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

Téléchargez le RFC 3303


L'article seul

RFC 4297: Remote Direct Memory Access (RDMA) over IP Problem Statement

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : A. Romanow (Cisco), J. Mogul (HP), T. Talpey (NetApp), S. Bailey (Sandburst)
Pour information
Première rédaction de cet article le 9 février 2006

Ce RFC ne spécifie pas une norme, il écrit juste un problème intéressant et appelle aux solutions. Le problème est d'accélérer les transmissions de données entre machines connectées à Internet, en permettant un accès direct à la mémoire de l'autre machine.

Notre RFC décrit très en détail, avec forces chiffres et références, les goulets d'étranglement lors d'une transmission de données entre machines. La simple copie des données prend en général beaucoup de temps. La solution envisagée est la copie directe (DMA) de la mémoire d'une machine à l'autre, au dessus du protocole IP (les solutions existants de DMA fonctionnent au dessus d'un bus machine comme PCI).

Le RFC appelle donc à l'étude d'une solution DMA au dessus d'IP, et propose comme point de départ le RFC 4296, par les mêmes auteurs.

Téléchargez le RFC 4297


L'article seul

RFC 4350: A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government

Date de publication du RFC : Février 2006
Auteur(s) du RFC : F. Hendrikx (NZ government), C. Wallis (NZ government)
Pour information
Première rédaction de cet article le 6 février 2006

Un curieux et intéressant RFC, qui documente la mise en place d'un espace de nommage d'URN pour le compte du gouvernement de la Nouvelle-Zélande.

La syntaxe des URN et la gestion des espaces de noms associés sont définis dans le RFC 8141. Le gouvernement néo-zélandais crée donc un nouvelle espace, préfixé par urn:nzl:, qui servira à des URN tel que urn:nzl:govt:registering:recreational_fishing:form:1-0, URN qui identifieront tous les documents officiels. Ces derniers seront tous en format XML, ce qui assure notamment l'indépendance par rapport à tout éditeur de logiciel (beaucoup de gouvernements sont assez inconscients pour publier et stocker leurs documents officiels dans le format non-libre d'un éditeur logiciel états-unien particulier).

Comme le montre le choix du format, ce RFC n'est qu'une petite partie d'un projet de gouvernement numérique bien plus ambitieux, incluant notamment un engagement à assurer la pérennité de ces documents officiels. Un identificateur stable comme l'URN (ou bien comme les URI tag du RFC 4151) est un élement essentiel de cette pérennité. Le RFC explique les autres choix possibles (on notera que des identificateurs très gonflés par le marketing, comme les DOI n'ont pas été considérés).

Le RFC désigne un registre, le SSC, qui gérait déjà le domaine govt.nz. Il prévoir aussi une délégation sous l'URN officiel, à d'autres organismes (comme les noms de domaine, les URN sont hiérarchiques).

On notera qu'il n'y a pas de mécanisme de résolution des URN en adresses de prévu dans ce RFC : les URN sont ici de simples identificateurs (une solution possible pour résoudre les URN est d'utiliser DDDS, décrit dans le RFC 3401 mais elle ne semble pas envisagée par les néo-zélandais).

Les amoureux de la diversité linguistique noteront que notre RFC discute de la possibilité d'avoir des URN en māori, une des langues officielles.

Téléchargez le RFC 4350


L'article seul

Les langages de schéma XML

Première rédaction de cet article le 2 février 2006
Dernière mise à jour le 16 février 2006

Je viens de finir un exposé sur les langages de schéma pour décrire un langage XML. Les transparents sont disponibles sous une forme adaptée à la présentation ou bien à l'impression. Le source est également disponible.

XML permet de définir plusieurs langages spécialisés, comme Docbook, Atom (format de syndication, RFC 4287), ou bien EPP ou IRIS, chers à tous les registres. Chacun de ces langages est défini par un schéma et ce schéma peut être écrit dans différents langages :

  • le langage originel, DTD (utilisé par le RFC 2629, par Docbook jusqu'à la version 4, l'actuelle),
  • Examplotron, qui permet de créer un schéma à partir d'un document exemple,
  • les W3C Schemas, souvent appelés XSD (utilisés par Wikipedia, par SOAP, ou bien pour EPP et IRIS - RFC 3981),
  • RelaxNG, le petit dernier (utilisé par OpenDocument, Docbook à partir de la version 5, Atom, RFC-editor queue, etc).

Avoir un schéma pour ses documents XML (il faut noter que ce n'est pas obligatoire) permet de les valider et de guider le processus d'édition.

Cet exposé parle donc de :

  • Petit rappel XML. - Pourquoi un langage de schéma ? Validation et édition guidée.
  • Caractéristiques d'un langage de schéma. Décrire la structure et décrire le contenu des éléments (leur type). Ambiguïté et non-déterminisme.
  • Exemple de langage XML qui va être implémenté avec les divers schémas.
  • DTD, l'ancêtre et ses limites.
  • Examplotron.
  • W3C Schemas, le langage d'EPP et d'IRIS.
  • RelaxNG, le langage de Docbook et d'Atom.
  • La notion de bibliothèque de types.
  • Outils de validation avec un schéma : rnv, xmllint ou bien jing.
  • Outils d'édition guidée avec un schéma : nxml mode.

L'article seul

RFC 3401: Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS

Date de publication du RFC : Octobre 2002
Auteur(s) du RFC : M. Mealling (Verisign)
Pour information
Première rédaction de cet article le 2 février 2006

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

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

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

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

Téléchargez le RFC 3401


L'article seul

RFC 3403: Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database

Date de publication du RFC : Octobre 2002
Auteur(s) du RFC : M. Mealling (Verisign)
Chemin des normes
Première rédaction de cet article le 2 février 2006

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Téléchargez le RFC 3403


L'article seul

RFC 3402: Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm

Date de publication du RFC : Octobre 2002
Auteur(s) du RFC : M. Mealling (Verisign)
Chemin des normes
Première rédaction de cet article le 2 février 2006

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

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

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

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


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

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

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

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

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

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

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

Téléchargez le RFC 3402


L'article seul

Virtualisation avec Xen

Première rédaction de cet article le 1 février 2006
Dernière mise à jour le 14 janvier 2007

La virtualisation, qui consiste à créer des machines virtuelles (typiquement plusieurs sur une machine physique), est très à la mode. Plusieurs exposés à JRES 2005 en ont parlé. Il existe plusieurs façons différentes de virtualiser et nous allons commencer par Xen.

Selon le cahier des charges qu'on a, on choisira une ou l'autre solution de virtualisation. Il existe :

  • Les émulateurs de processeur, comme Qemu ou Bochs, qui permettent de donner une illusion complète d'une machine et donc de faire tourner des systèmes d'exploitation non modifiés (mais à un coût élevé, question performances, puisqu'il faut traverser l'émulateur à chaque instruction machine),
  • Les machines compartimentées, comme les jails de FreeBSD ou comme les Vservers de Linux, qui sont limités à un seul noyau, ne permettent pas, par exemple, de modifier la table de routage mais qui suffisent à, par exemple, un hébergeur qui veut laisser ses clients être root, sans pour autant leur confier une machine physique entière,
  • Les hyperviseurs comme l'historique VM d'IBM ou comme Xen, qui est décrit ici. L'hyperviseur n'émule pas un processeur, le système d'exploitation doit être porté sur Xen mais ils offrent les meilleures performances, et permettent de faire tourner plusieurs systèmes d'exploitation sur la même machine physique.

Notons que l'apparition récente de processeurs offrant des fonction de virtualisation comme le Pacifica d'AMD brouille un peu les frontières. Ces technologies permettent par exemple de faire tourner sur Xen un système d'exploitation non modifié.

Un système Xen se compose d'un système d'exploitation hôte (host), nommé dom0 et de plusieurs systèmes d'exploitation invités (guests), les domU. L'hôte, aujourd'hui, avec Xen version 3, doit être un Linux ou, depuis peu, un NetBSD. Les invités que j'ai testé sont Linux, NetBSD ou FreeBSD.

Lorsque l'hôte (dom0) consomme 100 % du CPU, les invités (domU) sont complètement à genoux. Il est donc conseillé d'avoir un dom0 minimum, très sécurisé, et qui ne fait rien d'autre que de lancer les domU.

L'hôte, dom0 nécessite un noyau Xen. Actuellement, le noyau Linux standard n'a pas de support de Xen et il faut récupérer les patches dans la distribution de Xen avant de compiler, ou bien utiliser un noyau déjà compilé par les gens de Xen. Attention : le noyau utilisé dépend étroitement de l'hyperviseur qui tourne, même de la version 3.0.0 à 3.0.2 de Xen, les changements obligent à changer tous les composants ensemble.

Le logiciel de lancement, grub dans mon cas, doit lancer l'hyperviseur qui lancera ensuite le noyau xenisé : 

title           XEN with Debian GNU/Linux, kernel 2.6-custom-brassens-xen0 
root            (hd0,0)
kernel          /boot/xen-3.0-i386.gz dom0_mem=32M
module          /boot/vmlinuz-2.6.16-xen-brassens root=/dev/sda1 ro console=tty0
savedefault
boot

Si on utilise Debian comme système hôte, on dispose désormais dans la version "etch" de Debian d'un jeu complet de paquetages pour Xen.

Pour chaque système invité, il faut créer au moins un disque dur virtuel. Cela peut être une partition ou bien un fichier (créé avec dd, par exemple dd if=/dev/zero of=/xen-machines/images/peggy-root bs=1024k count=1000, puis mkfs ; ce disque virtuel peut être monté, par exemple pour examiner et modifier les fichiers, avec mount -t ext2 -o loop /xen-machines/images/polly-root /mnt). Ce disque dur virtuel doit être rempli avec les fichiers du système souhaité. Si c'est le même que le système hôte, ou bien si une machine du système souhaité est disponible sur le réseau, une copie avec cp ou scp suffit. Si le système invité est un Debian ou un Ubuntu, la commande debootstrap est très pratique (par exemple debootstrap --arch i386 breezy /mnt http://archive.ubuntulinux.org/ubuntu). Sinon, il faut trouver une image du système convoité, à copier sur le disque dur virtuel. (Pour NetBSD, ce n'est pas nécessaire, l'installeur peut tourner sur Xen.) Deux excellents sites, http://jailtime.org/ et http://www.xen-get.org/ en fournissent pour beaucoup de systèmes.

On doit ensuite créer un fichier de configuration par machine virtuelle. Un des miens dit : 

kernel = "/boot/vmlinuz-2.6-xenU"
memory = 64
name = "polly"
vif = ['']
disk = ['file:/xen-machines/images/polly-root,sda1,w','file:/xen-machines/images/polly-swap,sda2,w']
root = "/dev/sda1 ro"

Il spécifie le noyau à lancer (/boot/vmlinuz-2.6-xenU), la quantité de mémoire allouée, les disques virtuels (ici, deux, de type fichier) et la racine du futur système. On peut aussi passer des arguments au noyau du système invité, par exemple extra = "gentoo=nodevfs" pour arriver à démarrer une Gentoo.

Si on fait tourner Xen sur une machine ayant peu de RAM, il peut être utile d'abaisser la quantité de mémoire dédiée à Xen lui-même, ce qui se fait dans le fichier xend-config.sxp, par exemple : 

# Setting it too low has strange effects (freezes of dom0 or domU)
(dom0-min-mem 16)

Ensuite, il ne reste plus qu'à lancer la machine virtuelle, avec xm create fichier-configuration -c. On a alors la joie de voir les messages de démarrage du noyeau s'afficher dans le terminal et, lorsque le démarrage est fini, on a une nouvelle machine à sa disposition.

Xen permet d'afficher la liste des systèmes qui tournent : 

aslan:~ % sudo xm list
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0       46     1 r-----   268.7
diggory                            2       64     1 -b----   214.3
polly                              6       64     1 ------   785.6

Ici, dom0 a 46 mégas de mémoire, les invités, polly et diggory en ont 64 chacun. Avec Xen, les partitions mémoire sont statiques (il faut arrêter une machine virtuelle pour la changer ; si une machine virtuelle ne fait rien, elle bloque quand même la quantité de mémoire allouée). Il existe aussi un xm top pour suivre en temps réel l'activité des machines virtuelles.

Xen crée aussi une carte réseau virtuelle, donc les machines virtuelles ont un accès complet à Internet : 

polly:~ % ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:3E:05:19:FF  
          inet addr:172.19.1.32  Bcast:172.19.255.255  Mask:255.255.255.0

Le préfixe de l'adresse Ethernet, 00:16:3E est celui alloué à Xen mais on peut le changer.

Des manipulations plus intéressantes peuvent être tentées avec le réseau (configurer plusieurs ponts, router, etc) mais je n'ai pas encore eu beaucoup de succès sur ce terrain.

Lorsqu'on veut arrêter la machine virtuelle, c'est un xm shutdown et on a la surprise de voir ladite machine virtuelle afficher Power down à la fin.

Ce texte a été écrit sur un système Ubuntu invité pendant qu'un autre système invité, un Gentoo compilait X.org, le système hôte étant une Debian. J'ai aussi démarré un FreeBSD sur la même machine physique pendant ce temps.

Pour en savoir plus, on peut consulter :

À noter qu'il existe aussi des hébergeurs qui vous louent une domU Xen Xen pour pas cher comme SliceHost.


L'article seul

Tirer davantage du shell Unix avec les fonctions

Première rédaction de cet article le 23 janvier 2006

Beaucoup d'utilisateurs occasionnels d'Unix trouvent l'interface du shell, en ligne de commande, très difficile. Et, surtout, ils ne voient pas quel intérêt elle présente par rapport à une interface graphique, dite GUI. Cet article explique une des forces de l'interface du shell : la possibilité de créer ses propres fonctions et donc d'augmenter les services que le shell peut rendre à son utilisateur.


L'article complet

RFC 4271: A Border Gateway Protocol 4 (BGP-4)

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : Y. Rekhter, T. Li, S. Hares
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 21 janvier 2006

BGP 4 est aujourd'hui l'unique protocole d'échange de routes entre les opérateurs Internet. Il joue donc un rôle central dans le subtil routage d'une machine à l'autre. Un nouveau RFC vient de remplacer l'ancienne norme, sans guère de changements.

BGP est à la fois peu connu de la majorité des utilisateurs d'Internet et en même temps un outil indispensable. Il y a belle lurette que l'Internet est trop complexe pour que les tables de routage soient mises à jour à la main. Il faut donc un protocole pour échanger l'information de routage entre routeurs et pour calculer ensuite la route nécessaire pour acheminer un paquet d'une machine à l'autre. Il existe deux familles de tels protocoles, pour le routage interne à un opérateur (où les différents routeurs ont, par définition, la même politique) et pour le routage externe, entre '''systèmes autonomes''', c'est-à-dire entre opérateurs. BGP est de cette deuxième famille.

BGP fonctionne entre '''pairs''', deux pairs étant des routeurs qui ont été configurés pour s'échanger des routes. Notre RFC décrit le modèle de table de routage, tel que BGP le considère, les messages que peuvent échanger deux pairs et la façon de représenter l'information sur les routes que ces messages contiennent. Le RFC est relativement complexe (plus de cent pages en tout, ce qui est rare pour un RFC) mais le protocole est riche, car il doit pouvoir être utilisé entre machines gérées par des organismes différents, et il doit permettre l'application de politiques de routage complexes.

Tout ceci était déjà dans le prédécesseur de notre RFC, le RFC 1771. Les nouveautés ultérieures comme les extensions multi-protocoles (spécifiées dans le RFC 4760, elles sont notamment indispensables pour IPv6, décrit dans le RFC 2545) ou comme les capacités (RFC 5492) n'ont pas été incluses, contrairement à ce qui a été fait pour SMTP où le RFC 2821 avait incorporé beaucoup de RFC publiées postérieurement au RFC 822 qu'il remplaçait. Il faut donc toujours lire plusieurs RFC si on veut développer une mise en œuvre de BGP (un défi non trivial).

Les principales nouveautés de notre RFC par rapport à son prédécesseur de mars 1995 sont :

  • L'option d'authentifcation et d'intégrité par signature TCP MD5, spécifiée dans le RFC 2385, devient obligatoire. Elle est très contestée, soit parce qu'elle viole le modèle en couches, soit parce que certains auraient préféré IPsec. Mais il ne fait pas de doute qu'elle est très largement utilisée. Peut-être, depuis la publication du RFC 5925, sera t-elle remplacée par TCP-AO (TCP Authentication Option).
  • Formalisation de ''trucs'' très employés comme la répétition de son propre numéro de système autonome dans le chemin d'AS ou comme la coupure d'une session BGP lorsqu'un pair annonce un nombre de routes supérieur à une certaine limite (ce qui indique en général que ledit pair est mal configuré).

En même temps que notre RFC ont été publiés plusieurs autres RFC liés à BGP, le RFC 4272 sur la sécurité, le RFC 4273 sur la MIB de gestion, le RFC 4274 qui analyse le protocole, le RFC 4275 qui étudie les mises en œuvres de la MIB, le RFC 4276 qui examine les logiciels qui mettent en œuvre BGP, le RFC 4277 qui tire les leçons de la longue expérience de l'Internet avec BGP, et enfin le RFC 4278 sur des détails de la signature TCP MD5.

Téléchargez le RFC 4271


L'article seul

RFC 4272: BGP Security Vulnerabilities Analysis

Date de publication du RFC : Janvier 2006
Auteur(s) du RFC : S. Murphy (Sparta)
Pour information
Première rédaction de cet article le 21 janvier 2006

BGP est un protocole absolument vital au bon fonctionnement de l'Internet et il est toujours amusant et parfois un peu inquiétant de s'apercveoir qu'il est très peu sécurisé. Ce RFC fait le point sur les vulnérabilités de BGP, notamment sur celles qui affectent la communication directe entre deux pairs, deux routeurs BGP.

BGP, décrit dans le RFC 4271, est le protocole d'échange de routes dans l'Internet. Si on peut compromettre des routeurs grâce à une faiblesse de BGP, on peut, comme l'explique bien l'introduction de notre RFC, couper une partie de l'Internet mais aussi détourner tout le trafic à son profit (par exemple pour l'espionner) ou bien tricher sur son adresse IP (une bonne part de la sécurité de l'Internet repose sur le fait qu'avec des protocoles comme TCP, correctement implémentés, tricher sur son adresse IP est difficile ; ce n'est plus vrai si BGP est activement compromis).

Il existe deux façons de s'attaquer à BGP : en attaquant la communication entre deux pairs, deux routeurs BGP qui échangent des routes, ou bien en injectant de fausses informations que les routeurs vont relayer. Notre RFC parle surtout de la première attaque, la seconde, sur laquelle je reviendrai à la fin de cet article, est bien plus difficile à contrer.

Notre RFC décrit de manière très détaillée les failles possibles du protocole, et comment un attaquant peut les utiliser pour s'immiscer dans le bon fonctionnement de BGP.

Il ne fournit pas beaucoup de solutions clé en main : à part une mise en œuvre soignée du protocole, la difficulté de sécuriser BGP ne vient pas tellement du canal de communication entre deux pairs (qui peut être relativement protégé par la signature MD5, RFC 2385, par la plus récente TCP-AO, RFC 5925, ou bien par IPsec) mais du fait que le message lui-même, l'annonce de routes, n'est pas protégé. Autrement dit, un pair BGP peut être authentifié, sans que l'on sache pour autant s'il n'injecte pas de routes invalides, que ce soit délibérement ou parce qu'il relaie ces routes qu'il a lui même reçu d'un pair.

Notre RFC cite quelques protections contre ces routes invalides comme le protocole Secure-BGP qui permet de signer les annonces de route. Comme avec beaucoup de protocoles utilisant des signatures cryptographiques, le problème n'est pas tant le protocole (même si la cryptographie est souvent délicate) que l'infrastructure sociale : qui va signer, qui a l'autorité pour dire que tel opérateur est autorisé ou non à annoncer tel réseau ? Il n'existe aucune autorité suprême coiffant tous les opérateurs Internet et pouvant amorcer le processus de signature. (Le RFC 3779 propose une technique pour encoder ces certificats.) Cette approche a depuis été normalisée, sous le nom de RPKI+ROA, dans une série de RFC.

Le RFC 4272 cite également une autre possibilité : le filtrage de routes, basée sur le contenu des registres de route (IRR pour Internet routing registry), exprimé en langage RPSL (Routing Policy Specification Language, RFC 2622). Ces registres, comme celui du RIPE-NCC, sont notoirement mal tenus et rarement à jour et il est peu réaliste de compter dessus. BGP reste donc assez vulnérable à des injections de routes invalides, injections qui en pratique se produisent assez souvent, en général par accident.

Ces attaques BGP ne sont pas que théorie. Une étude de Georgia Tech montre qu'elles sont réellement utilisées par les spammeurs.

Téléchargez le RFC 4272


L'article seul

Fiche de lecture : Creating applications with Mozilla

Auteur(s) du livre : David Boswell, Brian King, Ian Oeschger, Pete Collins, Eric Murphy
Éditeur : O'Reilly
0-596-00052-9

Première rédaction de cet article le 20 janvier 2006

Les logiciels développés par Mozilla, dont le plus connu est le navigateur Web Firefox, sont très répandus mais beaucoup de leurs utilisateurs ignorent qu'ils sont aussi des environnements de développement, des plate-formes pour réaliser des programmes. Ce livre explique comment.

Un des charmes de Firefox est la disponibilité d'un grnd nombre d'extensions : non seulement on peut changer l'apparence du navigateur, mais on peut aussi ajouter des boutons, des menus, avec du code derrière. Par exemple, pour lire des flux de syndication, j'utilise en général Sage. Pour tester des pages Web, Web developer. Pour éditer des textes via des formulaires Web (comme pour Wikipedia), j'utilise ViewSourceWith.

De telles extensions (qui peuvent être développées pour n'importe quel logiciel Mozilla, pas seulement pour Firefox) sont écrites avec un mélange de nombreuses technologies : XUL pour décrire l'interface, CSS pour la présentation, JavaScript pour le code lui-même, XPCOM pour l'intergiciel, la communication entre les composants de Mozilla, RDF pour la description des composants, etc.

Ces technologies sont plus ou moins simples d'accès, plus ou moins documentées et évoluent parfois rapidement. Un livre de synthèse n'est donc pas inutile et c'est l'ambition de ce livre.

En 450 pages, il n'y réussit pas entièrement : il faut dire que le sujet n'est pas facile. On trouve peu de documentations synthétiques en ligne. L'API est particulièrement peu documentée. Et la technologie change rapidement (la version 1.5 de Firefox vient de sortir). Comme le livre est publié sous une licence libre, il est donc prudent de se fier à la version en ligne, la version papier datant de 2002, une éternité pour Mozilla.

Le livre couvre donc successivement toutes les techniques mentionnées plus haut. Vu le nombre d'auteurs, je suppose que chaque chapitre a été écrit très indépendamment car il y a peu de vision globale, juste une succession de techniques, qui semblent parfois redondantes (Javascript et les gabarits XUL, par exemple). Certains domaines qui me semblent importants, comme "chrome", le registre interne des ressources (code, images, etc) sont à peine traitées.

Tout est bien écrit et bien expliqué, certes, mais, en refremant le livre, on se sent un peu dépassé par l'ampleur de la tâche et le foisonnement d'information. Il existe heureusement des logiciels pour automatiser une partie des tâches de création d'une application Mozilla (ils sont décrits dans l'annexe B) et on peut toujours étudier les applications existantes pour voir comment elles marchent.

Je n'ai pas encore essayé de créer une vraie application avec ce livre comme guide, je vous tiendrai au courant.


L'article seul

Fiche de lecture : XML Schema

Auteur(s) du livre : Eric van der Vlist
Éditeur : O'Reilly
0-596-00252-1

Première rédaction de cet article le 16 janvier 2006

Il existe désormais trois langages courants pour écrire des schémas XML c'est-à-dire pour décrire les éléments autorisés ou interdits dans un document XML. La norme du W3C, souvent appelée abusivement "schéma" tout court (une erreur que ce livre commet aussi) est la plus connue.

La norme "W3C Schema" est très complexe : mais ce livre réussit à l'exposer de manière simple, en commençant par un schéma minimum, puis en le compliquant au fur et à mesure que l'on souhaite décrire d'autres propriétés du langage qu'on développe. Il y a un seul fil conducteur dans le livre pour tous les exemples (une bibliothèque, avec description des livres) et cela facilite la plongée progressive dans les arcanes de XSD (autre nom des "W3C Schema").

L'auteur expose donc les schémas plats (où tous les éléments sont au même niveau) et les schémas en poupée russe, où les élément sont emboîtés. Il s'attaque ensuite au deuxième volet de XSD, après la structure du document : les types de données. Il expose en grand détail comment utiliser les types prédéfinis puis comment créer les siens.

À ce stade, on peut écrire son schéma (et c'est ce que j'ai fait avec succès). Mais les points plus subtils de l'écriture de schémas font ensuite l'objet d'un chapitre chacun (la documentation, la création de schémas qui pourront facilement être étendus, les espaces de noms...)

Personnellement, mes seuls manques ont été un chapitre de présentation de certaines normes utilisant les W3C Schemas (ce sont souvent de grosses normes très complexes et un tour d'introduction serait le bienvenu) et un autre chapitre sur les outils existants (validateurs, éditeurs).

En résumé, voici un excellent livre, par un auteur très compétent, qui est également l'auteur du livre "concurrent" chez O'Reilly, sur RelaxNG.


L'article seul

RFC 2821: Simple Mail Transfer Protocol

Date de publication du RFC : Avril 2001
Auteur(s) du RFC : J. Klensin (AT&T Laboratories)
Chemin des normes
Première rédaction de cet article le 13 janvier 2006
Dernière mise à jour le 1 octobre 2008

Ce RFC mettait à jour le vieux RFC 821 qui a été pendant dix-neuf ans (!) la spécification du protocole SMTP, le principal protocole de transport de courrier électronique, l'application qui a assuré le succès de l'Internet. Il a depuis été remplacé par le RFC 5321.

Compte-tenu de l'immense succès de ce service et du protocole SMTP, on comprend que beaucoup ont reculé devant la mise à jour de SMTP. Elle était pourtant nécessaire puisque le protocole avait été étendu, notamment par l'invention de ESMTP (originellement dans le RFC 1425, une version améliorée - E signifie Extended - qui permettait au client et au serveur SMTP de négocier des options (comme le transport du courrier sur 8 bits). Cette modification, et beaucoup d'autres, rendait très difficile de déterminer le comportement normal d'un serveur SMTP.

Remettre à plat le protocole et en donner une description à jour et normative était donc une tâche utile, mais ingrate ; il n'y a pas de prestige à gagner dans de telles tâches de ménage (on notera d'ailleurs que le DNS souffre terriblement de ce problème, plusieurs dizaines de RFC étant désormais nécessaires pour le programmer correctement ; l'incapacité de l'IETF à faire pour le DNS ce qui a été fait pour SMTP est un sérieux problème). En outre, il fallait le prestige et la compétence de John Klensin, auteur de nombreux RFC, pour mener cette tâche à bien.

Le nouveau RFC décrit donc le modèle de SMTP, les entités qui participent à l'envoi d'un message, les commandes qu'elles peuvent échanger. On notera que le format des messages n'est pas décrit dans ce RFC mais dans son compagnon, le RFC 2822. Le RFC 2821 ne décrit que le protocole de transport, pas ce qui est transporté.

Ce nouveau RFC intègre donc les modifications des vingt dernières années, comme ESMTP. Il n'entraine aucun changement dans les serveurs de messagerie, se contentant de tout décrire de manière homogène. Signe des temps, notre RFC a aussi une longue section consacrée à la sécurité, complètement absente du RFC 821. La question de l'usurpation d'identité est traitée mais pas résolue : si SMTP n'authentifie pas l'émetteur, ce n'était pas par paresse ou étroitesse de vue de la part de Jon Postel, l'auteur du RFC 821. C'est tout simplement parce qu'il n'existe aucun fournisseur d'identité sur l'Internet, réseau décentralisé et sans commandement unique. Aucun protocole ne peut combler ce manque.

Mon expérience du courrier électronique remontant à quelques années (bien après le RFC 821 mais bien avant le RFC 2821), je me souviens avec amusement des tentatives d'autres protocoles (notamment le ridicule X.400) de s'imposer, par des mesures bureaucratiques ou par du simple FUD, portant souvent sur des questions de sécurité. La vérité est qu'aucun des concurrents n'avait fait mieux que SMTP, dans un réseau ouvert : tous n'ont été déployés que dans des petits réseaux fermés, où la question de l'authentification est évidemment plus simple.

Comme notre RFC ne change pas le protocole, les principes de SMTP demeurent : un protocole simple, efficace, relativement facile à implémenter et n'utilisant que des commandes textes, ce qui permet de déboguer aisément avec des outils comme telnet. Ces principes sont à la base de la révolution du courrier électronique qui fait qu'on n'imagine plus aujourd'hui une carte de visite sans une adresse électronique.

Mais l'Internet continuant d'évoluer, des limites de notre RFC apparaissent déjà. Par exemple, les nombreux efforts pour apporter des mécanismes d'authentification de l'émetteur (par exemple pour lutter contre le spam) ont souvent buté sur des problèmes de vocabulaire : le RFC 2821 ne décrit qu'imparfaitement l'architecture du courrier et le vocabulaire, pour des actions aussi simples que l'envoi d'un message à une liste de diffusion ou que la réécriture des adresses en cas de forwarding (faire suivre automatiquement un message), reste flou et mal standardisé. Il est donc difficile d'affirmer si telle ou telle nouvelle technique est contraire aux principes du courrier Internet, ceux-ci n'étant pas formellement écrits.

La norme de SMTP est désormais le RFC 5321.

Téléchargez le RFC 2821


L'article seul

RFC 2822: Internet Message Format

Date de publication du RFC : Avril 2001
Auteur(s) du RFC : P. Resnick (Qualcomm)
Chemin des normes
Première rédaction de cet article le 13 janvier 2006
Dernière mise à jour le 1 octobre 2008

Le RFC 822, qui spécifiait le format des messages envoyés par courrier électronique, avait dix-neuf ans lorsque notre RFC a été publié, afin de mettre enfin à jour ce vénérable ancêtre. Lui-même a été remplacé depuis par le RFC 5322.

Comme son compagnon, le RFC 2821, qui décrit le protocole de transport des messages, notre RFC est le résultat d'une remise à plat complète d'une spécification très ancienne, pleine de succès, mais qui avait été modifiée successivement et qui devenait difficile à comprendre, par l'accumulation de changements.

Notre RFC décrit donc le format des messages lorsqu'ils circulent sur le réseau (un logiciel de lecture de courrier peut naturellement les afficher de manière différente, plus adaptée aux humains) : le message comprend deux parties, l'en-tête et le corps. L'en-tête est composée de plusieurs champs, les plus connus étant From: (l'expéditeur), Subject: (l'objet du message) ou bien encore Received:, un champ dit "de trace", qui sert aux administrateurs de courrier électronique à déterminer par où est passé un message.

Parmi les champs de l'en-tête, plusieurs contiennent une adresse de courrier électronique et notre RFC 2822 décrit la syntaxe de ces adresses. Terriblement complexe (la forme "Stephane Bortzmeyer <bortzmeyer@internatif.org>" n'est que la plus simple mais bien d'autres sont permises), elle est le cauchemar des implémenteurs (la syntaxe des dates est également très chevelue). La norme de syndication Atom (RFC 4287), par exemple, se contente d'une expression rationnelle minimale pour décrire ce format : ".+@.+".

Il est à noter que la très grande majorité des codes Javascript ou PHP qu'on trouve en abondance sur le Web pour "vérifier une adresse électronique" sont faux : ils rejettent à tort des adresses valides (comme bortzmeyer+sncf@nic.fr sur le serveur de la SNCF, par exemple). Ce travail d'amateurs ou de stagiaires indique que leur auteur n'a pas lu le RFC 2822.

Le corps du message n'est quasiment pas spécifié par notre RFC, les choses perfectionnées (par exemple le multimédia) étant laissées à la norme MIME (RFC 2045 et suivants).

Après plusieurs années de bons et loyaux services, notre RFC a été remplacé par le RFC 5322.

Téléchargez le RFC 2822


L'article seul

Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?

Première rédaction de cet article le 10 janvier 2006
Dernière mise à jour le 25 novembre 2008

On explique souvent les problèmes du protocole réseau IPv6 par le faible nombre d'applications portées sur IPv6. Mais faut-il vraiment suggérer aux développeurs de se pencher sur un protocole peu répandu ou plutôt leur proposer de travailler à un niveau d'abstraction supérieur ?

IPv6 est présenté comme le protocole de l'avenir pour Internet depuis dix ou quinze ans. Mais, à l'heure d'aujourd'hui, il reste très peu utilisé. Une des raisons, pointées par exemple par Matthieu Herrb dans son excellent exposé à JRES 2005 est que beaucoup d'applications ne sont pas encore compatibles. Notamment, pour traduire un nom en adresse IP, les applications utilisent encore trop souvent l'antédiluvienne fonction gethostbyname() au lieu de getaddrinfo(), qui avait été normalisée dans le RFC 3493, il y a bientôt six ans ! Cela indique la difficulté à faire bouger l'enseignement (des étudiants apprennent encore avec des cours où on leur montre gethostbyname()). Bien sûr, les grosses applications très orientées réseaux comme BIND ou Apache ne sont pas concernées mais les ennuis viennent souvent des innombrables applications dont le réseau n'est pas le point principal mais qui ont besoin, par exemple, de récupérer un fichier (songeons aux processeurs XML, qui ont besoin de récupérer schémas ou bien feuilles de style, alors que le gourou XML qui les programme n'est pas forcément un gourou réseau).

Demander aux programmeurs de changer leur code juste pour accepter IPv6, alors que ce protocole est très peu utilisé aujourd'hui, ce n'est pas très motivant. Il vaudrait mieux attaquer le problème différemment. La vérité est que programmer en C avec les fonctions socket(), getaddrinfo() et autres connect(), c'est faire de l'assembleur, c'est travailler à un niveau trop bas. Cette technique a tous les inconvénients de l'assembleur, notamment le manque de robustesse face aux changements futurs. Au contraire, le programmeur devrait :

  • Le mieux serait qu'il programme dans un langage de plus haut niveau que C. Par exemple, en Python, en utilisant la bibliothèque standard httplib, le programme passe à IPv6 sans même que le programmeur s'en rende compte, juste lors d'une mise à jour de Python (à noter que la bibliothèque urllib2 est d'un niveau encore plus élevé et que Python a des bibliothèques pour beaucoup d'autres protocoles).
  • S'il programme en C, plutôt que de tout faire lui-même (souvent mal), le programmeur devrait compter sur des bibliothèques existantes comme libcurl ou Neon (ces deux excellentes bibliothèques acceptent IPv6 depuis longtemps). (Un exemple de client REST avec curl se trouve en get-station.c et permet de récupérer des informations sur les stations Vélib'.)

D'accord, si on programme juste un client. Mais si on veut faire un serveur ? Ondřej Surý me rappelle que Apache, surtout connu comme serveur HTTP, est, depuis sa version 2, bien plus que cela. Il est désormais une plate-forme de développement de serveurs Internet. On peut développer des modules Apache pour écrire des serveurs pour d'autres protocoles, Apache se chargeant de tous les détails. Il est livré avec des modules pour POP et echo et le registre de .cz, où travaille Ondřej, a réalisé son serveur whois et son serveur EPP en modules Apache.

En travaillant ainsi, le programmeur pourrait oublier les aspects réseaux et se concentrer sur son code « métier ». Et il aurait, gratuitement, IPv6, HTTPS et demain sans doute beaucoup d'autres choses qu'il n'aurait jamais développées lui-même (comme la future séparation de l'identificateur et du localisateur). Espérons que c'est ce qui sera enseigné aux futurs programmeurs.

À titre d'annexe, voici un petit programme tout bête (quasiment l'équivalent de wget) en Python, qui marche en IPv4 et IPv6 sans effort de la part du programmeur : 

import httplib
import sys
host = sys.argv[1]
path = sys.argv[2]
conn = httplib.HTTPConnection(host)
conn.request("GET", path)
r = conn.getresponse()
print r.status, r.reason

Une étude très détaillée de la programmation réseau indépendante de la version (et qui marche donc avec v4 et v6) se trouve dans l'étude d'EGEE, IPv6 compliance with C/C++, Java, Python and Perl. J'ai bien aimé l'approche de créer une petite bibliothèque qui assure l'indépendance par rapport à la version d'IP, de façon à ce que l'essentiel du programme soit identique pour v4 et v6. L'étude de cas concerne un protocole spécifique à EGEE. Si on utilise un protocole courant comme HTTP, il y a souvent encore plus simple : utiliser une bibliothèque comme libcurl ou httplib cités plus haut. Leur étude inclut le code des serveurs. Vous pouvez comparer leur code avec mon serveur echo en Python.

Pour terminer sur une nuance, peut-on citer des applications qui ont besoin d'appeler les fonctions de bas niveau, de manipuler directement des adresses IP ? Oui, toutes les applications de débogage, comme tcpdump, de surveillance comme ping ou bien de mesure comme echoping. Toute règle a ses exceptions mais celles-ci ne doivent pas faire oublier que la règle s'applique toujours pour la grande majorité des applications.


L'article seul

RFC 4071: Structure of the IETF Administrative Support Activity (IASA)

Date de publication du RFC : Avril 2005
Auteur(s) du RFC : R. Austein (ISC), B. Wijnen (Lucent)
Première rédaction de cet article le 9 janvier 2006

Ce RFC fait partie des nombreux RFC "bureaucratiques" au sens où il ne décrit pas un protocole réseau mais le fonctionnement interne de l'IETF. Il introduit l'ensemble des structures administratives de l'IETF, qui étaient précémment plus ou moins informelles. Ces structures ont par la suite été complètement changées par le RFC 8711, quatorze ans après.

Comme toute organisation de normalisation, l'IETF a des activités ancillaires : organiser des réunions, publier des documents, etc. Et a donc besoin d'une structure pour prendre en charge cette activité "administrative". Jusqu'à présent, tout fonctionnait informellement, ce qui ne pouvait pas durer, vu le caractère crucial des travaux de l'IETF.

Sous le nom générique d'IASA (IETF Administrative Support Activity), notre RFC décrit donc :

  • IAD (IETF Administrative Director), la personne qui va diriger l'activité administrative (actuellement Ray Pelletier).
  • IAOC (IETF Administrative Oversight Committee), le groupe de travail qui va superviser l'activité administrative. Dirigé par Lucy Lynch, de l'ISOC, il a un site Web très complet. (C'est cette IAOC qui a été supprimée par le RFC 8711, remplacée par l'IETF LLC.)

L'IASA est, en pratique, une branche de l'ISOC (qui fournit un parapluie financier et légal à l'IETF), même si elle est supervisée par l'IAOC.

On notera qu'une autre structure a été créée récemment et qui n'est pas décrite dans ce RFC, l'IETF Trust.

Téléchargez le RFC 4071


L'article seul

JRES 2005: les documents sont en ligne

Première rédaction de cet article le 8 janvier 2006

Les documents de la conférence JRES (Journées RÉSeaux, la plus importante conférence francophone d'ingénieurs réseaux et système) de décembre 2005 sont en ligne.

JRES est une conférence qui rassemble essentiellement le monde de l'Enseignement Supérieur et de la Recherche, donc ceux qui ont construit l'essentiel de l'Internet en France, longtemps avant que les médias ne se mettent à en parler.

Parmi les exposés, il y en a deux à moi, sur les Systèmes de Gestion de Versions et sur la lutte contre le spam

.

L'article seul

E-learning, faut-il vraiment autant de discours ?

Première rédaction de cet article le 3 janvier 2006
Dernière mise à jour le 9 janvier 2006

On parle souvent de la nécessité de développer le e-learning, en d'autres termes l'utilisation d'outils informatiques en réseau pour l'enseignement. Il existe une importante offre de logiciel libres et non-libres sur ce thème et d'innombrables colloques coûteux ont été organisés autour du sujet. Pendant ce temps, les outils les plus simples et les plus efficaces restent sous-utilisés.

L'approche courante du e-learning est une approche orientée outils : achetez et installez tel outil et vous ferez du e-learning. Or, non seulement tous les outils existants sont chers ou, au minimum (pour le cas des logiciels libres) complexes et difficiles à installer mais cela oublie que le e-learning est un processus, pas un outil. Il dépend de bien d'autre chose que la disponibilité de la dernière usine à gaz à la mode.

En effet, à l'heure actuelle, dans la plupart des établissements d'enseignement (même ceux qui affirment faire du e-learning), même les outils les plus simples de travail en groupe sont sous-utilisés. Faites les tests suivants lorsqu'il faut évaluer une université ou école qui affirme faire du e-learning :

  • Peut-on interroger un enseignant par courrier électronique et répond t-il (et dans quels délais) ?
  • Les documents nécessaires au travail sont-ils disponibles en ligne ? (Une note au passage : le logiciel Sympa, surtout connu comme gestionnaire de listes de diffusion, permet également le dépôt de documents sur un site Web.)
  • Les enseignants peuvent-ils facilement envoyer un courrier à tous les étudiants de leurs cours ?
  • Les immenses ressources d'ores et déjà disponibles en ligne comme Wikipedia sont-elle utilisées ? Et en écriture, pas seulement en lecture (je cite Sylvestre Ouédraogo : « Dans nos universités, la construction du savoir tend à disparaître pour faire la place à "l'injection du savoir". C'est vrai que la démarche collaborative dans Wikipédia peut aider à réveiller cette créativité et à redonner confiance aux étudiants. »

Avant de faire des QCM via le Web, ce sont ces simples utilisations qu'il faudrait développer. Moins de colloques et davantage de NTIC !

[J'ajoute, sur le e-learning, une remarque très juste de Jean-Louis Fullsack, que le e-learning croît lorsque les moyens décroissent donc qu'il sert souvent de rideau de fumée pour dissimuler la baisse des ressources allouées à l'enseignement en général.]


L'article seul

RFC 4282: The Network Access Identifier

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : B. Aboba (Microsoft), M. Beadles (ENDFORCE), J. Arkko (Ericsson), P. Eronen (Nokia)
Chemin des normes
Première rédaction de cet article le 3 janvier 2006
Dernière mise à jour le 4 janvier 2006

Autrefois, chaque FAI avait sa propre base d'utilisateurs et tous ses équipements réseaux savaient comment interroger cette base. Aujourd'hui, il est de plus en plus fréquent qu'on doive s'authentifier auprès d'un autre FAI que le sien, parce qu'il sous-traite à un vrai opérateur, parce que son réseau de collecte est différent de son épine dorsale, parce qu'on est en déplacement et qu'on bénéficie d'accords de roaming avec un autre FAI... Le network access identifier, décrit dans ce RFC, permet à l'abonné d'avoir une identité unique, que les équipements réseaux du FAI du moment sauront auprès de qui vérifier. (Le NAI a depuis été sérieusement réformé dans le RFC 7542.)

Le NAI est de la forme user@sub.realm.example. Il ressemble syntaxiquement à une adresse de courrier électronique mais n'en est pas une (les règles de syntaxe ne sont même pas exactement identiques, voir la section 2.5 du RFC). La partie droite, le domaine d'authentification (realm), ressemble à un nom de domaine mais ne l'est pas forcément même si c'est conseillé par le RFC (mon NAI actuel est bortzmeyer@net2.nerim.nerim).

C'est ce NAI qu'on configure dans son client réseau, par exemple dans les fichiers du répertoire /etc/ppp sur une machine Unix.

Lorsque le premier équipement réseau du trajet (le RFC le nomme NAS pour Network Access Server) reçoit le NAI, il sait, d'après la partie droite, à qui il doit demander d'authentifier l'utilisateur indiqué en partie gauche. Par exemple, si mon NAI est jean.durand@gold.iap.example, il sait qu'il doit authentifier jean.durand auprès des serveurs (par exemple Radius, RFC 2865) de gold.iap.example.

Notons que, pour faciliter ce routage vers le bon serveur d'authentification, le RFC prévoit une syntaxe (facultative) avec routage explicite (section 2.7), en utilisant le point d'exclamation. Ainsi, myserver.example.org!jean.durand@gold.iap.example est un NAI légal, qui demande que l'authentification passe d'abord par gold.iap.example, qui devra ensuite rediriger vers myserver.example.org.

Notre RFC est une mise à jour du précedent RFC sur les NAI, le RFC 2486. Le principal changement est l'addition de l'internationalisation, qui permet désormais des NAI comme stéphane@immeuble.cité.fr. La partie gauche sera traitée par un profil de l'algorithme stringprep, décrit dans le RFC 4013, la partie droite sera encodée en IDN, immeuble.xn--cit-dma.fr. Le RFC 7542, qui a remplacé notre RFC, a sérieusement changé le modèle d'internationalisation (en supprimant Punycode).

Téléchargez le RFC 4282


L'article seul

Articles des différentes années : 2024  2023  2022  2021  2020  2019  2018  Précédentes années

Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.

Un article de ce blog au hasard.