Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

È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 4141: SMTP and MIME Extensions for Content Conversion

Date de publication du RFC : Novembre 2005
Auteur(s) du RFC : K. Toyoda (PCC), D. Crocker (Brandenburg)
Chemin des normes
Première rédaction de cet article le 21 décembre 2005


Traditionnellement, la règle d'un MTA était "Ne touche pas au courrier, fais-le passer sans changement". Le MTA était juste un facteur, pas un secrétaire de rédaction, afin de garantir quel acteur a la responsabilité d'un message. Pour tout un tas de raisons, cette règle semble avoir de moins en moins appliquée. Ce nouveau RFC peut donc se permettre de spécifier un mécanisme pour demander à un serveur SMTP de faire des conversions du contenu du message.

Le serveur SMTP peut donc annoncer, en utilisant les mécanismes de Extended SMTP (RFC 2821) qu'il accepte ce nouveau mécanisme, s'il est prêt à effectuer ces conversions coûteuses.

Voici un exemple de session SMTP où le client va demander une conversion d'image dans un autre format, en utilisant la syntaxe du RFC 2533 :

      <<RFC 2822 message with MIME Content-Type:TIFF-FX
      Per:
      (  image-file-structure=TIFF-minimal
         dpi=400
         image-coding=JBIG
         size-x=2150/254
         paper-size=letter
      )
      with MIME body-parts including:
      Content-Convert:
         (&(image-file-structure=TIFF-minimal)
           (MRC-mode=0)
           (color=Binary)
           (|(&(dpi=204)
               (dpi-xyratio=[204/98,204/196]) )
             (&(dpi=400)
               (dpi-xyratio=1) ) )
           (|(image-coding=[MH,MR,MMR])
             (&(image-coding=JBIG)
               (image-coding-constraint=JBIG-T85)
               (JBIG-stripe-size=128) ) )
           (size-x<=2150/254)
           (paper-size=[letter,A4])
           (ua-media=stationery) )
      >>

Téléchargez le RFC 4141


L'article seul

Épépé

Première rédaction de cet article le 19 décembre 2005


Un étonnant roman de Ferenc Karinthy autour d'un thème tout simple : comment amorcer la communication quand on ne partage rien avec ceux avec qui on veut communiquer ?

Un linguiste (évidemment distingué) prend l'avion pour aller à un congrès et se retrouve dans une ville inconnue, où on parle une langue qu'il ignore totalement et dans une écriture qu'il n'a jamais vue. Il n'a pas de pierre de Rosette, personne ne parle une langue qu'il connaît. Pire, il ne semble y avoir aucune régularité dans cette langue : les signes utilisés pour écrire varient, la prononciation des mots apparemment aussi.

La liftière de l'hôtel où il a échoué, la seule personne qui lui manifeste de la sympathie, essaie de lui apprendre son nom mais cela semble un mot différent à chaque fois : Épépé, Bébé, Tiétié ?

Le héros va utiliser toutes ses ressources intellectuelles pour découvrir une amorce qui lui permettrait de commencer à comprendre cette langue, mais le fossé qui le sépare des habitants de cette ville, toujours affairés, jamais prêts à passer du temps avec l'étranger pour l'aider peut-il être comblé ?

Le linguiste tente même de décoder sa note d'hôtel, sans résultat. Il ne peut même pas repérer la date.

J'ai beaucoup aimé l'idée d'attaquer délibérement un policier, pour être emmené à un endroit où on va l'interroger, où on va forcément enquêter.

Pas mal d'informaticiens, surtout ceux qui ont essayé leur neurones contre des cryptogrammes inconnus, voudront sans doute, à la lecture du livre, aider le héros. Est-ce possible ?


L'article seul

RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : E. Nordmark (Sun Microsystems), R. Gilligan (Intransa)
Chemin des normes
Première rédaction de cet article le 19 décembre 2005


La version actuelle, la 4, du protocole IP avait eu bien de la chance, d'être déployée dans un environnement quasi-vierge. IP version 6 doit au contraire se frayer un passage dans un monde où tout est en IPv4. D'où l'importance des mécanismes de transition, dont ce RFC décrit deux exemples.

Cette transition est un des principaux défis auquel doit faire face IPv6. Il est même possible que sa difficulté soit la cause principale de ses problèmes, plus que ses qualités ou défauts intrinsèques.

Mettant à jour le RFC 2893, notre RFC décrit deux mécanismes (il en existe de nombreux autres, plus exotiques) pour assurer la transition : la "double pile" qui consiste pour une machine à avoir les deux protocoles (et donc les deux compétences pour son administrateur) et le tunnel configuré pour faire passer de l'IPv6 dans un Internet très majoritairement IPv4.

Dans le premier cas, la machine a les deux protocoles et, parfaitement bilingue, peut parler avec n'importe quelle autre machine, que cette dernière soit v4 ou bien v6. Mais cela empêche d'abandonner IPv4 et sa pénurie d'adresses. Et cela ne résoud pas tous les problèmes comme par exemple "Quelle adresse choisir si la machine avec laquelle je veux parler est également double pile ?" (très partiellement discuté dans la section DNS du RFC).

Le tunnel traite un problème un peu différent : une des extrémités du tunnel met les paquets IPv6 dans un paquet IPv4, les envoie à l'autre extrémité du tunnel, où on décapsule le paquet IPv6. La technique étant relativement complexe dans ses détails, elle forme l'essentiel de notre RFC.

Pour plusieurs raisons, comme le problème de MTU que notre RFC discute en profondeur, les performances sont alors moins bonnes.

Dans le cas du tunnel, deux machines qui n'ont qu'IPv6 peuvent se parler au travers de l'Internet actuel (peu d'opérateurs routent la v6). Mais cela ne résoud pas le problème de parler aux machines purement v4 (comme l'est, aujourd'hui, www.bortzmeyer.org).


Téléchargez le RFC 4213


L'article seul

Campagne de presse contre Wikipedia

Première rédaction de cet article le 16 décembre 2005
Dernière mise à jour le 10 avril 2006


Ouh là là, cette fois, ça fait très fort contre Wikipedia : après avoir ignoré cette encyclopédie libre et collaborative, les médias se déchainent. Suite à un cafouillage bien réel, mais ultra-minoritaire, c'est une pluie d'articles qui tombe contre Wikipedia.

Tout est parti d'un problème avec un article de Wikipedia, celui sur John Seigenthaler, l'accusant de liens avec l'assassinat de Kennedy. Seigenthaler a protesté publiquement et, sur la base de ce problème, plusieurs articles sont parus sur le Web anglophone, certains raisonnables (News.com), d'autres délirants (Wikipedia Class Action, lancée par un troll connu, qui n'a pas aimé un article consacré à son organisation).

La presse francophone a suivi, comme d'habitude : Libération ou ZDnet. Même France Info en a parlé au journal du mercredi 14. À chaque fois, les mêmes thèmes : "Wikipedia n'est pas sérieux", "Les textes devraient être écrits par des professionnels sérieux (sous-entendu : comme nous)", "Je l'avais bien dit".

Puis, après cette touchante unanimité, tout s'écroule à la parution de l'enquête de Nature qui montre que Wikipedia n'a pas plus d'erreurs qu'une encyclopédie traditionnelle, Encyclopædia Britannica (on peut lire la réponse de Britannica et celle de Nature. Curieusement, alors que Libération avait sonné la charge contre Wikipedia, un projet trop anarchique pour eux, c'est le Figaro qui défend l'encyclopédie libre. L'Internet brouille souvent les frontières politiques. LCI a également publié un article favorable.

Un excellent article de George Johnson dans le New York Times va encore plus loin et montre que, sur la plupart des points où une encyclopédie était accusée d'une erreur, la vérité était en fait bien plus compliquée, comme le montre le désormais célèbre cas des frères et sœurs de Mendeleiev.

On le voit, Wikipedia dérange : son modèle éditorial remet en cause pas mal de certitudes et son succès engendre, comme il se doit, attaques malveillantes et critiques pas innocentes.


L'article seul

Fiche de lecture : Developing feeds with RSS and Atom

Auteur(s) du livre : Ben Hammersley
Éditeur : O'Reilly
0-596-00881-3

Première rédaction de cet article le 16 décembre 2005


Les blogs et la syndication étant actuellement deux des occupations les plus populaires sur le Web, il fallait donc un livre chez O'Reilly sur les formats de syndication : c'est chose faite.

Ce livre couvre les différents formats RSS et une version assez préliminaire du format Atom (qui vient d'être normalisé dans le RFC 4287). Le chapitre historique qui retrace l'histoire de la syndication et des guerres entre formats nommés RSS est d'ailleurs passionnant et éclaire bien des questions.

Il continue par un chapitre sur l'utilisation de la syndication (il cite de nombreux outils mais pas un de mes favoris, rss2email, qui permet de convertir un flux de syndication en liste de diffusion par courrier). Puis il décrit en détail les principaux formats de syndication, s'attardant sur les innombrables modules qui ont fait le succès de la version 1.0 de RSS (celle qui utilise RDF).

Les chapitres suivants sont plus techniques : analyse de flux de syndication depuis un programme (presque tous les exemples sont en Perl), avec discussion pour savoir si l'analyseur doit être strict ou bien laxiste, des considérations sur les flux réels rencontrés dans la nature et surtout un chapitre passionnant sur des utilisations « inhabituelles » de la syndication, essentiellement pour des tâches d'administration système ou bien pour exploiter des sources d'information qui ne sont pas syndicatées (par exemple Google, avec un programme de conversion de recherches Google en flux RSS).

Bref, un livre assez court, très bien fait, peu à jour pour tout ce qui concerne Atom mais qui est quand même une bonne introduction au monde merveilleux de la syndication.


L'article seul

Utilisation de syslog pour la documentation de l'administration système

Première rédaction de cet article le 15 décembre 2005


Sur tout site informatique un peu complexe, documenter les actions des administrateurs système est une tâche complexe. Idéalement, il faudrait qu'en plus d'installer, régler et réparer, l'administrateur système maintienne une épaisse documentation. Peu le font, parfois pour des mauvaises raisons (désir de garder ses petits secrets), parfois pour de bonnes (manque de temps). Pourquoi ne pas utiliser un outil déjà installé, syslog, pour pouvoir au moins effectuer le minimum de documentation ?

Merci à Sophie-Charlotte Barrière pour avoir imaginé cette technique.

Rien de plus agaçant que de passer des heures à déboguer un problème avant de s'apercvevoir qu'un collègue avait récemment fait un changement, sans le documenter. Bien sûr, il aurait dû le faire. Bien sûr, il aurait dû suivre les procédures ISO-quelquechose et rentrer dans le système de GED dix pages de textes pour dire simplement "j'ai ajouté un /etc/logrotate.d/nsd pour faire tourner les journaux". Mais n'y a t-il pas des solutions plus légères ?

Une raison que les administrateurs système donnent souvent à l'absence de documentation sur leurs actions est "Pas le temps", voire "Je le ferai demain" (ce qui n'arrive jamais car il y a d'autres choses à faire demain). Il faut donc une technique ultra-légère, et qui ne nécessite pas de changer de machine ou bien de lancer le seul navigateur Web avec lequel le CMS de documentation fonctionne.

syslog a toutes ces caractéristiques : il est très répandu, tout machine Unix l'a déjà. Il permet d'envoyer les évenements dans un fichier ou bien dans un programme ou encore être envoyé sur une machine centrale de traitement et d'achivage. Et il peut être appelé très rapidement avec le programme logger.

Enregistrer ses actions est donc aussi simple que de taper :

%   logger Ajout de /etc/logrotate.d/nsd

Et l'action sera enregistrée, avec le nom de la personne qui l'a effectue, et la date :

Nov 30 16:46:10 esther bortzmeyer: Ajout de /etc/logrotate.d/nsd

logger a plein d'options utiles. Par exemple, si l'action concerne la sécurité :

logger -p security.info Suppression de awstats

et, via sa configuration en /etc/syslog.conf, syslog va alors mettre le message dans un fichier différent et qu'on espère d'avantage lu. Il est important de soigner cet /etc/syslog.conf car ce n'est pas l'application qui décide du fichier ou système où le message va être enregistré, c'est le programme syslog.

On dispose ainsi d'un véritable journal des actions effectuées, qu'on peut ensuite consulter avec tail, grep ou l'excellent xlogmaster. On peut aussi les trier avec Swatch.

Il peut être prudent de sauvegarder ce journal (tout Unix, par défaut, détruit régulièrement les vieux journaux, par exemple avec le programme logrotate).

Une autre solution pour trier facilement est d'avoir une facilité locale de syslog dédié à cette technique. Mettons qu'on utilise "local3", on peut alors définir un alias alias logit="logger -p local3.info" et une commande logit Mise a jour du noyau va alors automatiquement enregistrer avec cette facilité.


L'article seul

RFC 4264: BGP Wedgies

Date de publication du RFC : Novembre 2005
Auteur(s) du RFC : T. Griffin (University of Cambridge), G. Huston (APNIC)
Pour information
Première rédaction de cet article le 15 décembre 2005


Un assez court RFC, pour décrire un cas pathologique de routage BGP entrainant un coincement permanent dans un état non-optimal.

Depuis sa normalisation sous sa forme actuelle, dans le RFC 1771, le protocole de routage BGP a largement servi l'Internet et a connu peu de problèmes fondamentaux. C'est un des grands succès de l'IETF.

Néanmoins, BGP réserve toujours son lot de surprises : dans un immense réseau sans administration centralisée, comme l'Internet, il y a toujours des cas particuliers gênants. Ce RFC décrit un syndrome particulier, le "coincement" (wedgie), où le routage converge vers un état non-optimal (le trafic IP ne passe pas là où il devrait passer) qui peut être semi-permanent, c'est-à-dire survivre jusqu'au redémarrage d'un ou de plusieurs routeurs.


Téléchargez le RFC 4264


L'article seul

RFC 4287: The Atom Syndication Format

Date de publication du RFC : Décembre 2005
Auteur(s) du RFC : M. Nottingham (editor), R. Sayre (editor)
Chemin des normes
Première rédaction de cet article le 12 décembre 2005
Dernière mise à jour le 28 mai 2011


La syndication des sites Web, c'est-à-dire la récupération de résumés structurés par un autre site, par le biais des flux (feeds) RSS est à la mode. Tout le monde en fait et n'importe quel blog affiche un lien vers son flux RSS. Beaucoup de gens lisent le Web essentiellement via un agrégateur RSS, qui lit de nombreux flux RSS et présente ces résumés sous une forme qui permet une navigation facile.

Mais ce succès cache une rude rivalité entre les différents RSS. Il en existe plusieurs, le 0.9, le 1.0, le 2.0 et ce ne sont pas des évolutions plus ou moins récentes de la même norme, mais des normes bien différentes et incompatibles.

L'IETF tente donc de régler le problème, avec la norme Atom. Atom est spécifié dans ce nouveau RFC, et peut-être fera t-il la synthèse entre tous les formats de syndication. Ou bien peut-être rajoutera t-il juste une Nième norme incompatible avec les autres, l'avenir le dira.

Rien d'extraordinairement nouveau dans ce RFC, qui reprend les élements classiques d'un flux RSS. Atom est bâti sur XML et et ses éléments de type content peuvent inclure du texte brut, du XHTML mais aussi n'importe quel élément XML, que l'usage des espaces de noms sépare de l'XML d'Atom.

On note que ce RFC est, à ma connaissance, le premier RFC utilisant XML qui se serve de RelaxNG et non pas les W3C Schema comme langage de schéma, pour décrire les éléments autorisés et leurs relations. À une époque, un groupe de l'IETF avait tenté de rendre obligatoire l'usage des W3C Schema, plus complexes et moins expressifs mais l'IETF avait finalement pris, dans le RFC 3470 une approche plus nuancée, reconnaissant le pluralisme des langages de schémas, même si ce RFC montre un fort biais en faveur des W3C Schemas, utilisés notamment dans les RFC 3730 et RFC 3981.

Ce blog est doté d'un flux de syndication Atom, en /feed.atom. Son moteur de recherche permet de produire le résultat des recherches au format Atom.


Téléchargez le RFC 4287


L'article seul

DADVSI, ou le contrôle étroit des logiciels libres

Première rédaction de cet article le 7 décembre 2005


Le projet de loi DADVSI, Droit d'Auteur et les Droits Voisins dans la Société de l'Information, doit passer au parlement à partir du 20 décembre. Ce projet, parmi d'autres mesures, prévoit d'interdire "Le fait, en connaissance de cause, de fabriquer ou d'importer une application technologique, un dispositif ou un composant ou de fournir un service, destinés à faciliter ou à permettre la réalisation, en tout ou en partie, du fait mentionné au 1° ci-dessus [le fait en question est le contournement des plombages des documents]". Cela revient à menacer le logiciel libre.

En effet, si on a un logiciel libre qui met en œuvre des mesures de DRM, rien n'est plus facile que de les supprimer, puisqu'il suffit d'éditer le source et de le recompiler. Donc, tout logiciel libre est visé par l'article 13, cité ci-dessus, et cette interprétation n'est pas le résultat de ma paranoïa mais figure en toutes lettres dans l'exposé des motifs qui dit "y compris lorsque ces moyens [techniques] ont une utilisation limitée autre que ce contournement".

Le gouvernement a donc trouvé la solution : puisqu'il n'y a pas de mesures techniques sérieuses tant qu'il existe des logiciels libres, supprimons les logiciels libres. Une fois de plus, la propriété intellectuelle l'emporte sur toute autre considération , même sur le droit d'auteur (puisque l'auteur d'un logiciel ne peut plus choisir le mode de distribution de celui-ci, de crainte d'être accusé d'avoir facilité le contournement des DRM).

Il est donc urgent de s'opposer à ce projet de loi, en écrivant à son député, en signant la pétition, etc. Sinon, rien n'arrêtera l'arrogance des titulaires de gros portefeuilles de propriété intellectuelle, qui sont prêts à tout interdire pour garder leur gâteau.

Pour en savoir plus : le site EUCD.info.


L'article seul

Fiche de lecture : Relax NG

Auteur(s) du livre : Eric ven der Vlist
Éditeur : O'Reilly
0-596-00421-4

Première rédaction de cet article le 7 décembre 2005


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. RelaxNG, le plus récent, est le moins connu des trois et méritait donc bien un livre chez O'Reilly, avec un faisan sur la couverture, pour gagner d'avantage de popularité.

Autrefois, les schémas XML ne pouvaient s'écrire qu'avec une DTD et c'est la seule solution décrite dans la norme XML. Les limitations des DTD ont mené à l'invention de nouveaux langages, le plus connu étant W3C Schema, aussi dit XSD.

XSD est très complexe, souffre d'une syntaxe XML verbeuse, et est en même temps limité dans les schémas qu'il permet de décrire. Bien qu'il bénéficie d'une présence supérieure dans les médias, il n'a pas été choisi pour certains gros projets (Docbook, OpenDocument, Atom, etc) qui ont préféré RelaxNG.

C'est un signe de la simplicité de RelaxNG que le fait que ce livre soit à la fois relativement mince et très complet : il est rare qu'un sujet en soit absent. L'annotation d'un schéma (par exemple pour le documenter ou pour y mettre des métadonnées) fait ainsi l'objet d'un chapitre entier.

L'auteur, Eric van der Vlist, est également l'auteur du O'Reilly sur XSD, il connait donc bien les deux "concurrents", même si sa préférence pour RelaxNG ne fait guère de doute. Francophone, il est également un des piliers de la liste xml-fr, où il répond en général très rapidement aux questions.

Ce livre couvre donc l'essentiel de RelaxNG : ses principes (ne valider que la structure, pas le contenu des éléments, ne pas changer les valeurs des éléments), puis sa syntaxe (RelaxNG a deux syntaxes, une XML et une dite compacte, bien plus lisible).

Il explique ensuite comment contraindre les valeurs des éléments grâce aux bibliothèques de types (extérieures à RelaxNG proprement dit), puis explique en détail comment réaliser des schémas qui, au lieu d'être des blocs monolithiques, soient extensibles ou restrictibles facilement, de façon à ce que leurs utilisateurs puissent n'utiliser que ce qu'ils veulent.

Le livre se termine sur un remarquable chapitre sur le déterminisme dans les schémas et pourquoi RelaxNG ne l'impose pas.

Notez que le schéma des fichiers XML de ce blog est écrit en RelaxNG.


L'article seul

RFC 4236: HTTP Adaptation with Open Pluggable Edge Services (OPES)

Date de publication du RFC : Novembre 2005
Auteur(s) du RFC : A. Rousskov (Measurement factory), M. Stecher (CyberGuard)
Chemin des normes
Première rédaction de cet article le 6 décembre 2005


OPES est composé d'un grand nombre de RFC. Celui-ci décrit l'adaptation d'OPES au cas du protocole HTTP, le protocole principal du Web.

S'appuyant sur les RFC 3835, pour la description de l'architecture, et RFC 4037 pour OCP, le protocole de communication entre un processeur OPES et son serveur sous-traitant, notre RFC décrit les adaptations spécifiques à HTTP, quels messages transmettre, lesques peuvent être ignorés, les transformations autorisées et sous quelles conditions, etc.

OPES spécifiant que les processeurs OPES doivent obéir à une exigence de traçabilité et laisser trace de leur activité, ce RFC spécifie deux nouveaux en-têtes HTTP que nous verrons dans les flux HTTP, dès que des processeurs OPES seront déployés : OPES-System, le principal, qui identifiera le processeur OPES, et OPEN-Via.

Les deux exemples complets de session donnés par notre RFC concernent un application classique pour le Web, le filtrage de certains URL (le processeur OPES reçoit une demande GET et renvoie une erreur 403, "accès interdit") et un service de traduction au vol des pages, plus futuriste.


Téléchargez le RFC 4236


L'article seul

Fiche de lecture : In the beginning was the command-line

Auteur(s) du livre : Neal Stephenson
Éditeur : Avon Books
0-380-81593-1

Première rédaction de cet article le 6 décembre 2005


Aujourd'hui, on entend et on lit très souvent, comme si cela allait de soi, que l'interface d'un logiciel doit être graphique et, de préférence, WYSIWYG. Toute mise en doute de ce dogme ne peut être, semble t-il, que l'œuvre de dinosaures obtus, attachés aux incompréhensibles commandes d'Unix. C'est ce dogme que Neal Stephenson, le célèbre auteur de la trilogie "Cryptonomicon" a décidé d'ébranler.

Dans ce petit livre, le raisonnement de Stephenson est simple : la ligne de commande, contrairement à l'interface graphique, est un langage. Comme tout langage, elle prend du temps à être maitrisée. Mais, une fois que c'est fait, elle permet bien plus d'expressivité qu'une interface graphique, qui ne permet que de choisir parmi des options pré-définies.

Stephenson compare l'utilisateur de l'interface graphique à un singe qui ne sait pas parler, seulement montrer du doigt (ou de la souris) la banane qu'il veut, peut-être en ajoutant quelques grognements.

Stephenson ne se limite pas au sujet évoqué dans le titre : il analyse toute l'évolution de l'informatique depuis vingt ans, l'influence des feuilletons télé et de Disneyland sur la mentalité états-unienne, les voitures, et les épopées antiques comme Gilgamesh. Qui a dit que les informaticiens étaient incultes et ne philosophaient pas ?


L'article seul

RFC 3835: An Architecture for Open Pluggable Edge Services (OPES)

Date de publication du RFC : Août 2004
Auteur(s) du RFC : A. Barbir, R. Penno (Nortel Networks), R. Chen (AT&T Labs), M. Hofmann (Bell Labs/Lucent Technologies), H. Orman (Purple Streak Development)
Pour information
Première rédaction de cet article le 30 novembre 2005


Après le RFC 3752, qui décrit à quoi peut servir OPES, le cadre conceptuel des entités intermédiaires qui se mettent entre client et serveur pour modifier requêtes et/ou réponses, ce RFC décrit l'architecture d'OPES.

Notre RFC décrit donc le vocabulaire d'OPES (producteurs, consommateurs, flux, entités) et explique leur rôle. L'entité va, soit modifier un flux (en s'insérant entre producteur et consommateur), soit distribuer le travail à une autre entité OPES. Plusieurs entités OPES peuvent en effet transformer successivement le flot.

La communication avec ces "sous-traitants" se fera avec le futur OCP (OPES Callout Protocol), dont le cahier des charges est le RFC 3836 et qui est décrit dans le RFC 4037.

Le RFC décrit également les règles que suit un entité OPES et qu'il faut donc lui transmettre.

Comme OPES a suscité beaucoup de réserves, notamment de la part de l'IAB (dans le RFC 3238), notre RFC consacre toute sa section 4 à y répondre.

Tel qu'il est donc spécifié, le service OPES doit donc :

  • Rendre obligatoire le consentement explicite du producteur ou du consommateur,
  • Être accessible en IP, donc ne pas être totalement invisible,
  • Révéler sa présence en marquant son intervention (par exemple, en HTTP, en ajoutant un en-tête),
  • Permettre d'exprimer des préférences de protection des données, par exemple avec P3P.
  • Et d'autres obligations.

Téléchargez le RFC 3835


L'article seul

RFC 3752: Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios

Date de publication du RFC : Avril 2004
Auteur(s) du RFC : A. Barbir (Nortel Networks), E. Burger (Brooktrout Technology), R. Chen (AT&T Labs), S. McHenry, H. Orman (Purple Streak Development), R. Penno (Nortel Networks)
Pour information
Première rédaction de cet article le 29 novembre 2005


Traditionnellement, l'architecture de l'Internet était de bout en bout, ce qui signifie que les éléments intermédiaires ne jouaient qu'un rôle réduit. Aujourd'hui, cette architecture a de fait évolué et les "trucs au milieu", qui changent les données échangées sont de plus en plus nombreux. OPES (Open Pluggable Edge Services) tente de formaliser cette nouvelle architecture.

C'était un principe cardinal de l'Internet : mettre l'intelligence aux bords du réseau, chez le client et le serveur, et ne pas tenter de fournir des servics avancés dans le cœur du réseau. Ce principe a été informellement remis en cause par l'accumulation d'éléments intermédiaires qui ajoutent leur propre traitement. Citons par exemple :

  • Un relais Web comme Squid qui garde en mémoire les pages demandées, pour les servir plus rapidement la prochaine fois,
  • Un relais Web comme Junkbuster qui filtre les publicités hors des pages Web.

Ces logiciels ne relèvent pas d'une architecture commune et chacun utilise son propre protocole, son propre mécanisme de configuration, ses propres méthodes de traçabilité...

OPES va donc essayer d'ordonner tout cela. Ce premier RFC décrit des scénarios d'usage afin de donner une première approche d'OPES et des cas où il peut être utile.

Notre RFC décrit donc des services qui peuvent modifier les requêtes envoyées à un serveur ou bien modifier les réponses du serveur. Il explique ce qu'est un processeur OPES (l'entité qui va faire les modifications) et un serveur sous-traitant (callout server), auquel le processeur transmet certains traitements. Une description plus précisé de l'architecture d'OPES figure dans le RFC 3238.

Comme OPES soulève d'énormes problèmes à la fois liés à l'architecture (il redéfinit une architecture traditionnelle de l'Internet) et à la sécurité (puisqu'un processeur OPES s'interpose entre deux acteurs, il peut agir de façon maligne), l'IAB a exprimé, dans le RFC 3238 de sérieuses réserves auxquelles le RFC 3835, qui décrit l'architecture d'OPES, répond.


Téléchargez le RFC 3752


L'article seul

IETF Trust: l'IETF perd officiellement sa propriété intellectuelle

Première rédaction de cet article le 27 novembre 2005
Dernière mise à jour le 30 juillet 2007


L'IETF, la principale organisation de normalisation de l'Internet, vient de créer une nouvelle entité, l'IETF trust qui doit gérer toute sa propriété intellectuelle (RFC 4748). Pourquoi cette nouvelle entité ?

Faisons d'abord un peu d'histoire : l'IETF n'existe pas officiellement, il n'existe pas de « personne morale » de ce nom. La propriété intellectuelle (notemment le copyright de ses documents, les RFC) est détenue par l'ISOC. Avant cela, il n'y avait pas de règles précises : les RFC et tout le travail qui avait mené à un RFC (discussions sur les listes, documents intermédiaires, archives des logiciels de suivi de tâches) avait un statut indéterminé, ce qui ne gênait personne tant que seuls quelques ingénieurs barbus s'intéressaient à Internet.

Mais maintenant que l'Internet est une grosse affaire, qui intéresse beaucoup de requins, il était difficile de continuer de manière informelle. L'IETF a donc tenté de se formaliser un peu (par exemple par la création de l'IASA, IETF Administrative Support Activity, décrit dans le RFC 4071). Et c'est là que l'IETF s'est aperçu que l'essentiel de sa production passée, sans que personne ne s'en soit réellement rendu compte, était détenue par une organisation privée, CNRI (Corporation for National Research Initiatives), dont le président a été décoré par George W. Bush.

CNRI assurait traditionnellement, de manière informelle, via sa filiale Foretec, l'infrastructure de l'IETF. Cela semblait très généreux. Mais cela l'est moins lorsqu'on s'est aperçu que CNRI réclamait la propriété intellectuelle de tout ce qu'avait développé l'IETF sur ses machines... Beaucoup de membres de l'IETF ont alors découvert que la brutalité des mœurs de l'entreprise privée n'était pas limitée aux porteurs de costumes et cravates mais qu'elle se pratiquait également entre adeptes du T-shirt (l'uniforme traditionnel de l'IETF).

L'IETF n'ayant pas d'existence légale et pas de moyen de faire respecter les droits de ses membres, un accord a donc été cherché : l'infrastructure de l'IETF sera gérée désormais par Neustar, cette fois avec un vrai contrat, et CNRI (ainsi que l'ISOC) accepte de transférer une partie de « sa » propriété intellectuelle vers la nouvelle entité, créée pour la circonstance, l'IETF Trust.

CNRI ne cède pas tant que cela. L'article 10.1 des statuts prévoit que CNRI (et l'ISOC) gardent un droit de veto sur toute modification des statuts jusqu'en... 2010 et l'annexe A permet à CNRI, à quelques exceptions près, de choisir de manière discrétionnaire ce qui sera effectivement transféré à l'IETF Trust.

Tout le dossier peut être consulté sur le site Web de l'IASA / IAOC, (IETF Administrative Oversight Committee), une des structures créées par le RFC 4071 ou sur celui du Trust. Le Trust a désormais une FAQ.


L'article seul

RFC 4193: Unique Local IPv6 Unicast Addresses

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : R. Hinden (Nokia), B. Haberman (JHU-APL)
Chemin des normes
Première rédaction de cet article le 26 novembre 2005


Le RFC 3513 sur l'adressage IPv6 spécifiait des adresses purement locales à un site, les adresses site-local qui commençaient par FEC0::/10. Ces adresses ayant été rendues obsolètes par le RFC 3879, notre RFC 4193 spécifie un remplacement : des adresses quasi-uniques mais attribuées sans registre central.

Les adresses locales à un site ont été très utiles lorsque les RIR n'attribuaient pas d'adresses IPv6 et qu'il était difficile d'en obtenir. Elles permettaient de se mettre doucement à IPv6, sans démarches bureaucratiques. Mais elles avaient le même inconvénient que les adresses privées IPv4 du RFC 1918 : en cas de connexion de deux sites utilisant ces adresses (par exemple suite à une fusion d'entreprises), le risque de collision est élevé.

Notre RFC propose donc une meilleure solution : dans un espace réservé, FC00::/7, le site qui souhaite des adresses quasi-uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC, qui utilise l'heure et l'adresse MAC comme point de départ, et a pour but d'éviter que tout le monde prenne le même préfixe. La probabilité de collision entre sites est donc très faible, vue la taille de l'espace d'adressage de IPv6.

Si on veut son ULA (Unique Local Address), on peut faire tourner cet algorithme en http://www.kame.net/~suz/gen-ula.html ou en http://www.sixxs.net/tools/grh/ula/.


Téléchargez le RFC 4193


L'article seul

RFC 4033: DNS Security Introduction and Requirements

Date de publication du RFC : Mars 2005
Auteur(s) du RFC : R. Arends (Telematica Instituut), R. Austein (ISC), M. Larson (VeriSign), D. Massey (Colorado State University), S. Rose (NIST)
Chemin des normes
Première rédaction de cet article le 21 novembre 2005
Dernière mise à jour le 15 février 2010


Le DNS n'est pas sûr, on le sait (le RFC 3833 décrit les vulnérabilités du DNS en détail). Comme la quasi-totalité des applications de l'Internet dépendent du DNS à un moment ou à un autre, cette vulnérabilité inquiète beaucoup de gens. Notre RFC, avec ses compagnons RFC 4034 et RFC 4035, propose une solution à certains de ces problèmes, solution nommée DNSSEC.

Ce RFC décrit le deuxième DNSSEC, le premier était présenté dans le RFC 2535 mais n'a jamais été un succès.

DNSSEC-bis propose une sécurisation des données, pas du canal. La cryptographie permet en effet de sécuriser un canal de communication entre deux machines (ce que fait SSL) ou bien de sécuriser le message lui-même, qui peut alors être authentifié et protégé quels que soient les messagers intermédiaires : c'est ce que fait DNSSEC.

Pour cela, DNSSEC signe cryptographiquement, par la cryptographie asymétrique, les enregistrements DNS. Plus rigoureusement, il signe des RRsets ou Resource Record Sets, c'est-à-dire un ensemble d'enregistrements ayant même nom et meme type (en pratique, rassurez-vous, la différence entre enregistrement et RRset est peu importante). Cette signature est portée par un nouveau type d'enregistrement, le RRSIG. Le RRSIG authentifie un enregistrement qui figure en partie gauche tandis que la partie droite contient la signature, ainsi que quelques informations utiles comme l'algorithme utilisé (c'est typiquement RSA + SHA1).

Les parties publiques des clés utilisées par le registre de la zone pour la signature sont publiées dans des enregistrements de type DNSKEY. Pour "amorcer la pompe" de DNSSEC, on récupère typiquement ces clés via un canal non-DNS, par exemple un accès à un serveur Web authentifié.

Voici par exemple un enregistrement RRSIG tel que l'affiche dig :

   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                                  20030220173103 2642 example.com.
                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

Ici, le signataire example.com (ce nom apparait en partie droite) a authentifié l'adresse IPv4 (la signature couvre un enregistrement de type A, c'est indiqué juste après le type RRSIG) de host.example.com. La signature est le texte en base64 (RFC 4648) qui figure à la fin. S'il possède la clé de example.com (on peut la récupérer, par exemple, dans l'enregistrement de type DNSKEY ou "hors bande", par exemple sur une clé USB remise en mains propres), un résolveur DNS pourra alors être sûr de l'authenticité de cette adresse et ceci même si l'enregistrement a été transmis via des relais inconnus.

Enfin, DNSSEC spécifie également deux autres types d'enregistrement, plus subtils : NSEC et DS.

Les NSEC servent à répondre à une question délicate : authentifier la non-existence d'un domaine. En effet, DNSSEC marche par la signature d'enregistrements (ce choix a été fait pour éviter de modifier trop fortement le protocole DNS). Mais, si un nom n'existe pas, il n'y a pas d'enregistrement à signer ! Le problème est résolu avec les enregistrements de type NSEC (Next Secure). Ces enregistrements (qui sont signés comme les autres) indiquent quel est le prochain domaine de la zone. Ainsi, lorsqu'on demande nimportequoi.example.org, le serveur de example.org peut répondre par un NSEC pointant vers le domaine suivant.example.org qui, lui, existe. Voici un exemple d'enregistrement NSEC qui dit que alfa.example.com a des enregistrements de quatre types et que le nom suivant est host.example.com (donc, on peut être certain que beta.example.com n'existe pas) :

   alfa.example.com. 86400 IN NSEC host.example.com. (
                                   A MX RRSIG NSEC)

On note que, puisque les NSEC permettent d'obtenir le domaine suivant, puis le suivant du suivant, ils donnent donc potentiellement accès à l'intégralité de la zone, tout comme un transfert de zones. Ce problème, connu sous le nom de zone walking a contribué à la décision de certains registres (typiquement ceux qui ne veulent pas distribuer leur fichier de zone) de ne pas déployer DNSSEC. C'est ainsi que Simon Josefsson a développé un programme de zone walking qui montre bien la vulnérabilité des zones DNSSEC. Ce problème est résolu en remplaçant les NSEC par les NSEC3 du RFC 5155.

Les enregistrements DS (Delegation Signer), quant à eux, permettent d'authentifier les délégations. En effet, signer les enregistrements de délégation (les NS, pour name servers) dans la zone parente ne suffit pas, puisqu'il faut aussi permettre de trouver la clé de la zone fille. Un enregistrement DS va donc pointer vers l'enregistrement DNSKEY de la zone fille (si celle-ci n'est pas elle-même signée, le DS est inutile).

DNSSEC bis est aujourd'hui mis en œuvre dans plusieurs serveurs de noms dont BIND (à partir de la version 9.2) et NSD (à partir de la version 2.3.0).

L'outil dig permet d'effectuer une requête avec DNSSEC :

% dig +dnssec @ns3.nic.fr +dnssec A ripe.net.  
...
;; ANSWER SECTION:
ripe.net.               600     IN      A       193.0.0.214
ripe.net.               600     IN      RRSIG   A 5 2 600 20051221061607 20051121061607 49526 ripe.net. 2NePKf/On6ZgcQD0zpinEou4QiojhW1A2IKoxHBdtawMa7aSeQdL+hZp RktjuqbFwv9rkVPOVXPGWhtB9sSfoI5         aMjHWjrjdsAfc6LTBLr2veHiV +6qOeiV24ALYwZKpwP5tEh6hiJXN6fVAxQ6ye32u7+01xL+dG9oaMA6x 6x/5GkJKHfS4E         EbF+OaUX2m2DlQHsh0n

On voit ici la réponse à la question posée (l'adresse de ripe.net) et la signature.

On peut aussi récupérer la partie publique de la clé :

% dig  DNSKEY ripe.net.                     
...
;; ANSWER SECTION:
ripe.net.               3480    IN      DNSKEY  256 3 5 AQPhEMiv80EEjX6gYDc8E7Osfumf4C/pZxBmTRRiOVL3h6lx1CIVCyPl V34WuVUkqqpID2fxGzmUFTG0f61x9lzRapX0lIdlo2AtRCYWpkPY+D3F IrMYukWiC8pyeHF/a/Wk6HZNLVYko2dcLwUpfiDrK7zCFgR9DLcZkOmj N5xB9CBzVrZDkd1lsGCC9hytndbLuZ3VtpE=
ripe.net.               3480    IN      DNSKEY  257 3 5 AQOTT7bx7N38sPgDWniKnHnSnTxYxdMpEq7dyrDHDaRQgq7DULPWX6ZY 0U1XKKMuNloHRP7H8r17IBhgXcPZjZhtSGYagtPe22mhAMjZ4e8KGgP9 kJTTcpgzoYulvSiETBxjQ42EZWJG+6bxK+vyrwTbqEScmdZfqQz3ltVw k6Sos0UuSmTeb2C6RSkgHaTpKCu5yIrncVer1gvyvXGv3HOel8jiDGuj 8peNByiaSRD4OIJUxu1jUqLvfDH6Anq6ZeNohxsYVUVajiRl1T+3x5+8 acgwat3V55Z1Nm4O4Z1BKECdPO65EXIEC7/pqs5XvpsiJbafdj03uqLS a3aScpy3

Et si je veux signer ma zone, quelles solutions puis-je utiliser ? Une version récente de BIND inclue les logiciels dnssec-keygen et dnssec-signzone qui fournissent tous les services nécessaires. Testons-les sur une Debian en version lenny. Il faut d'abord générer la clé de la zone :

% dnssec-keygen -a DSA  -b 1024 -n  ZONE sources.org

Cette commande laissera sur le disque les fichiers Ksources.org.+003+55957.key et Ksources.org.+003+55957.private. Il faut évidemment les sauvegarder précieusement (autrement, il faudra changer la clé, une opération complexe qu'on nomme le rollover) et vérifier que la clé privée n'est pas accessible à tous.

Il faut alors inclure la clé publique (ici, le contenu de Ksources.org.+003+55957.key) dans le fichier de zone.

Ensuite, à chaque modification de la zone, il faudra signer :

% dnssec-signzone sources.org
sources.org.signed

Le programme dnssec-signzone produit un fichier du même nom que la zone mais suffixé par .signed. Un exemple de règle dans un Makefile pour automatiser cela est :

reload: sources.org.signed example.org.signed foobar.example.signed

%.signed: %
        @echo Signing requires a lot of entropy in /dev/random, do not hesitate to load the machine...
        dnssec-signzone $^

L'avertissement sur l'entropie vient du fait que, sur une machine Linux peu chargée, /dev/random se bloque s'il n'a pas assez d'entropie pour générer des nombres vraiment aléatoires, et on a l'impression que dnssec-signzone est arrêté.

dnssec-signzone produit également un fichier avec les enregistrements DS, pour qu'on puisse les transmettre à son registre (uniquement pour une nouvelle clé ou bien une clé qui change).

Le cas présenté ici, avec une seule clé, est le plus simple. Elle est peut-être préférable pour les petites zones, ou pour ceux qui débutent avec DNSSEC. Mais le RFC recommande une autre approche, plus complexe mais plus sûre, la séparation en deux clés, la KSK (Key Signing Key) et la ZSK (Zone Signing Key). La première, introduite dans le RFC 3757, ne sert qu'à signer la seconde. Elle est typiquement très robuste (à l'heure actuelle, typiquement de 4096 bits) et change relativement rarement car c'est elle qui est utilisée par les autres zones, comme trust anchor. La seconde, la ZSK, est plus légère (par exemple 1024 bits, taille au delà de laquelle la signature des grandes zones devient vraiment pénible) et sert à signer les enregistrements. Du fait de cette utilisation, il y a d'avantage d'information qui « fuit »,; et qui peut donc aider un attaquant. Elle change donc plus fréquemment, ce qui ne pose pas trop de problèmes opérationnels puisqu'elle n'est connue que localement.

Pour créer la KSK, on doit normalement s'entourer de multiples précautions (si la zone qui l'utilisera est vitale, on s'enfermera dans une cage de Faraday, on se déconnectera du réseau, etc). Ensuite, on tape :

% dnssec-keygen -f KSK \
    -a RSASHA1 -b 4096 -n ZONE example.org

(Cette opération peut prendre plusieurs heures sur une machine qui a peu d'entropie.) On garde évidemment précieusement la partie privée de cette clé ! On publie la partie publique (par exemple en l'envoyant à la zone parente ou bien en la mettant sur son site Web) et on la met dans son fichier de zone.

La ZSK se génère avec une commande presque identique à part l'option -f et une clé plus petite :

% dnssec-keygen \
    -a RSASHA1 -b 1024 -n ZONE example.org

Les deux clés se mettent ensuite dans le fichier de zone. Au moment de la signature, dnssec-signzone ne signera qu'avec la ou les clés qui n'ont pas été générées avec l'option -f KSK. Toutefois, BIND ne trouve pas forcément les signatures seul et, selon la façon dont les clés ont été nommées et/ou placées, il peut être utile de dire à dnssec-signzone quelle est la KSK (option -k) et quelle est la ZSK (nom de fichier après le nom de la zone) :

dnssec-signzone -t -k example.org.KSK example.org example.org.ZSK 

Notez que tout ce processus peut s'automatiser partiellement avec des outils comme OpenDNSSEC.

Quelques documentations sur la configuration de DNSSEC :

Voyons maintenant quelques points important de DNSSEC mais qui ne sont pas mentionnés dans le RFC (celui-ci ne fait que spécifier un protocole, il ne traite pas de tous les problèmes liés à ce protocole).

On notera que le RFC ne spécifie pas l'API du service. Que doit faire une fonction comme getaddrinfo(3) lorsqu'une vérification DNSSEC échoue ? L'API actuelle ne permet pas de donner de détails sur la cause de l'échec. En outre, à ma connaissance, aucune mise en œuvre actuelle ne permet à l'administrateur système de définir une politique de sécurité (par exemple dans son fichier de configuration /etc/resolv.conf).

Aujourd'hui, plusieurs registres ont commencé à déployer DNSSEC comme le RIPE-NCC, notamment pour les domaines de résolution inverse (in-addr.arpa) qu'il gère ou bien le registre suédois. La racine du DNS est en cours de signature.

Si on souhaite plus d'informations, on pourra regarder un excellent article de Bert Hubert, l'auteur de PowerDNS ou bien le portail de DNSSEC. Et, sur mon blog, il y a de nombreux articles sur DNSSEC.


Téléchargez le RFC 4033


L'article seul

Le portable à 100 dollars, intérêt et limites

Première rédaction de cet article le 18 novembre 2005


Lors du SMSI à Tunis, le célèbre Nicholas Negroponte, ancien directeur du MediaLab du MIT et visionnaire connu, a présenté un PC portable promu "portable à cent dollars". Le but est de fournir au service public d'éducation des portables bon marché qui pourraient être donnés aux élèves et étudiants, notamment dans les pays les moins développés.

Attention, le projet a beaucoup évolué depuis cette description, il vaut mieux se référer au site officiel.

L'engin, doté d'un design très original, n'a pas réellement été montré à Tunis. À part des simples maquettes, le seul ordinateur était une version très expérimentale, qui est loin d'avoir toutes les caractéristiques du futur appareil. Notamment, deux fils discrets partent de la machine et vont sous la table où, dissimulé par la nappe, se trouve l'essentiel de la machine, tout ce qui n'a pas encore pu entrer dans l'appareil.

Une fois l'engin au point, ses caractéristiques seront les suivantes :

  • Processeur à 500 Mhz,
  • Mémoire flash (pas de pièces mobiles donc pas de disque dur),
  • Alimentation électrique manuelle (on tourne une manivelle),
  • Système durci, pour résister à la vie dans un monde rude,
  • Le système d'exploitation est un Fedora, avec uniquement du logiciel libre.

La distribution se fera uniquement via le service public d'éducation de façon à éviter le dévelopemment d'un marché secondaire, qui pourrait encourager le vol et la revente (la plaie habituelle des portables). De même, le design très original de l'engin vise à détecter rapidement le recel.

Maintenant, cet appareil va t-il contribuer à la lutte contre la fracture numérique, un grand thème du SMSI ?

Notons d'abord que cent dollars représente une somme considérable pour les pays visés. C'est souvent plus élevé que le salaire mensuel de l'instituteur. Or, on peut trouver sur eBay des portables d'occasion, souvent mieux dotés que la machine de Negroponte, et qui sont moins chers que cela. Ceci dit, la comparaison est partiellement injuste car le portable à 100 $ a d'autres avantages comme le durcissement qui devrait lui éviter de tomber en panne au bout de quelques mois.

Ensuite, il y a une grande incertitude industrielle : le prix d'un équipement dépend très peu de sa conception technique et essentiellement de sa production en masse ou pas. Si réduit que soit le portable pour être le moins cher possible, cela ne servira à rien s'il n'est pas produit en très grande quantité et j'ignore ce que décideront à ce sujet les industriels.

Enfin, la plus grosse limite du projet est que les problèmes matériels jouent certes un rôle dans la fracture numérique, mais ils ne sont pas les seuls : il existe aussi une fracture dans l'accès à la formation, dans l'esprit d'initiative, dans la participation à des projets internationaux et cette fracture ne se réduit pas aux contraintes matérielles (pour le développement logiciel, par exemple, il y a peu d'obstacles purement techniques à la participation des africains). Prétendre qu'une machine va donc à elle seule combler le fossé numérique est donc imprudent. Espérons qu'au moins des initiatives comme celle-ci contribueront à banaliser l'ordinateur dans les pays du Sud, leur laissant ainsi le loisir de s'attaquer aux problèmes non-techniques.


L'article seul

RFC 3833: Threat Analysis of the Domain Name System (DNS)

Date de publication du RFC : Août 2004
Auteur(s) du RFC : D. Atkins (IHTFP Consulting), R. Austein (ISC)
Pour information
Première rédaction de cet article le 16 novembre 2005


Comme beaucoup de protocoles Internet, le DNS avait été conçu sans se préoccuper de la sécurité. Comme souvent, on s'aperçoit avec DNSsec que l'ajout de la sécurité à un protocole n'est pas si triviale que ça. Mais, avant de penser à la solution,il faut étudier le problème : c'est ce que fait ce RFC qui analyse les risques liés au DNS et les possibilités qu'offre ces failles aux fraudeurs.

Modifier des réponses DNS ou bien injecter de fausses réponses qui seraient acceptées par les clients permet en effet nombre d'attaques, comme de rediriger les requêtes censées aller au serveur d'une banque vers le serveur d'un méchant qui copierait les mots de passe.

Il faut noter que le RFC ne parle que des faiblesses du protocole, pas des bogues des mises en œuvre.

Enfin, rappelons que beaucoup d'attaques d'usurpation ne nécessitent pas de faille du DNS : ces attaques peuvent simplement exploiter la crédulité ou bien la distraction de l'utilisateur. D'où l'importance de mesures de sécurité comme celles de SSH qui contrôle la clé cryptographique du serveur où il se connecte.

Le RFC note que les attaques suivantes sont possibles :

  • Interception des paquets (questions ou réponses) et émission par l'attaquant d'un autre paquet. Tous les protocoles permettent cela mais c'est plus facile avec le DNS, où question et réponse tiennent souvent dans un seul paquet chacune. Cela nécessite en général que l'attaquant soit situé entre le client et le serveur.
  • Fabrication d'une réponse vraisemblable. Cela peut se faire en devinant l'ID (un numéro choisi par le client DNS et qui lui permet de mettre en correspondance requêtes et réponses) d'une requête (et le nom demandé), ce que la faible taille des ID (16 bits) rend possible.
  • Chainage de noms, une technique qui consiste à injecter des données dans le cache de la victime en utilisant une indirection. Par exemple, une réponse de type NS (name server) va entrainer des requêtes dans un domaine potentiellement complètement différent, pour résoudre les noms en partie droite de la réponse.
  • Trahison par un serveur : si je branche mon portable sur un réseau que je ne contrôle pas, le serveur cache de ce réseau peut envoyer à ses clients des données mensongères. Même chose si un des secondaires d'un domaine décide de tricher, alors qu'il devrait n'envoyer que ce qu'a décidé son primaire.
  • Déni de service

Le RFC discute également des problèmes qui ne sont pas des vulnérabilités à proprement parler mais qui compliquent la solution de sécurité, comme la nécessité de pouvoir signer la non-existence d'un domaine ou bien les jokers (wildcards), qui compliquent tant de protocoles liés au DNS.

Le RFC se termine par une discussion des problèmes liés à DNSsec lui-même (DNSsec ne résoud pas toutes les failles de sécurité du DNS).


Téléchargez le RFC 3833


L'article seul

ViewSourceWith, pour éditer proprement des formulaires Web

Première rédaction de cet article le 7 novembre 2005
Dernière mise à jour le 8 novembre 2005


Rien de plus agaçant que ces formulaires Web où le seul moyen d'entrer des informations complexes est via un champ d'édition de type <TEXTAREA> : on n'a pas un vrai éditeur à sa disposition, on n'a pas les équivalents-clavier auquel on est habitué ni tous les gadgets de son éditeur favori. Lorsque, par exemple, pour envoyer un message, un site Web n'indique pas d'adresse de courrier électronique mais seulement un formulaire, j'ai envie de mordre.

Le problème a quand même une solution technique partielle : ViewSourceWith, une extension du navigateur Web Firefox dont le nom est trompeur : elle ne sert pas seulement à voir le source mais aussi (et surtout pour moi) à éditer avec l'éditeur de son choix tout champ <TEXTAREA>. On dit une fois à ViewSourceWith quel est son éditeur préféré et il ajoute une option "View with" dans le menu "clic droit". On peut alors travailler avec son environnement préféré et, lorsqu'on quitte l'éditeur, le texte est dans le formulaire.

Combiné avec le mode Emacs de Wikipédia, ViewSourceWith rend l'écriture d'articles pour Wikipedia très agréable. Voici d'ailleurs la partie de mon ~/.emacs qui charge automatiquement le bon mode :

;; Wikipedia
; http://www.emacswiki.org/cgi-bin/wiki/download/wikipedia-mode.el
(if (locate-library "wikipedia-mode")
    (progn
      (autoload 'wikipedia-mode
	"wikipedia-mode.el"
	"Major mode for editing documents in Wikipedia markup." t)
      (if (locate-library "longlines")
	  (autoload 'longlines-mode "longlines.el"
	    "Minor mode for editing long lines." t)
	)
      ; If emacs is launched by Mozex, it is probably for wikipedia
      (add-to-list 'auto-mode-alist '("mozex\\." . wikipedia-mode))
      ; ViewSourceWith is better, it has the site name in the file name
      (add-to-list 'auto-mode-alist '("fr\\.wikipedia\\.org_" . wikipedia-mode))
      )
)

ViewSourceWith a remplacé pour moi Mozex qui faisait la même chose mais ne semble plus maintenu (une version non officielle semble toujours en cours). Sinon, certaines personnes préfèrent utiliser It's All Text.


L'article seul

L'encyclopédie libre Wikipedia

Première rédaction de cet article le 6 novembre 2005
Dernière mise à jour le 27 février 2006


Vous l'avez remarqué, beaucoup d'entrées de ce blog comportent des liens vers l'encyclopédie Wikipedia. Dés que j'utilise un terme ou un sigle ou un concept qui risque de ne pas être compris de tous les lecteurs, je mets un lien vers Wikipedia. Pourquoi celle-ci ? N'y a t-il pas d'inconvénients derrière ce concept d'encyclopédie que n'importe qui peut modifier à sa guise ?

Commençons par préciser les principes de fonctionnement de Wikipedia. Wikipedia est une encyclopédie en ligne, accessible notamment par le Web, et qui est éditable par tout visiteur. Il est recommandé de créer un compte mais ça n'est même pas nécessaire et, de toute façon, créer un compte ne fournit aucune certitude d'identité. Les contributeurs ne sont donc pas forcément identifiés.

A priori, cela ne peut pas marcher : des crétins vont écrire n'importe quoi, des incompétents vont effacer les contributions des experts, des fanatiques vont écrire des articles soi-disant informatifs mais en réalité louangeurs sur le nazisme ou la scientologie ou bien encore détailler le complot du 11 septembre ou expliquer que les fruits frais protègent du sida.

En pratique, cela marche pourtant. Comme pour le logiciel libre, il ne faut pas s'arrêter aux préjugés et dire "cela ne peut pas marcher". Il faut regarder les faits et (comme pour le logiciel libre) les faits sont que cela fonctionne à peu près, malgré ce que disent le bon sens et les experts auto-proclamés.

Il y a en effet beaucoup plus de gens honnêtes et de bonne foi que de trolls. Le nombre et l'activité de réparation de ces gens honnêtes permettent de tenir à distance les vandales. Quant aux incompétents, le fait que n'importe qui puisse corriger est également une arme puissante : contrairement à un document papier ou à un site Web figé, il est rapide et facile de corriger les erreurs.

Il est frappant de constater que les critiques de Wikipedia ne tentent pas de projets alternatifs. Soit ils défendent mordicus le statu quo, la production de savoir contrôlée uniquement par la minorité qui est payée par les grands éditeurs d'encyclopédies, soit ils voudraient un truc du genre de Wikipedia mais "plus strict" ou "plus contrôlé", sans jamais tenter de réaliser leur idée (ils pourraient même utiliser le contenu actuel de Wikipedia comme point de départ, puisque celui-ci est sous une licence libre, la GFDL).

Wikipedia s'inscrit donc dans la grand courant né à la fin du vingtième siècle de libération des œuvres de l'esprit. Après le logiciel libre, les documents libres suivent logiquement. Remplaceront-ils totalement les documents non-libres ? Peut-être pas mais ils auront certainement une grande place.

Du point de vue pratique, enfin, notons que je n'ai tout simplement pas trouvé d'alternative (même non libre et non coopérative) à Wikipedia. Les francophones préfèrent souvent organiser de beaux et coûteux colloques sur la nécessité de créer des contenus francophones sur Internet mais, lorsqu'il s'agit de mettre la main à la pâte, les volontaires sont rares. Je ne trouve pas pour l'instant d'encyclopédie francophone en ligne en dehors de Wikipedia. Quant aux dictionnaires, il y avait eu voici quelques années un gros tapage sur la coopération entre les Éditions Hachette et l'AUPELF-UREF (Agence Francophone pour l'Enseignement supérieur et la recherche) pour mettre en ligne un "Dictionnaire Universel Francophone" qui (une fois les subventions touchées) a disparu du réseau...


L'article seul

RFC 4144: How to Gain Prominence and Influence in Standards Organizations

Date de publication du RFC : Septembre 2005
Auteur(s) du RFC : D. Eastlake 3rd (Motorola)
Pour information
Première rédaction de cet article le 5 novembre 2005


Encore un RFC sur les procédures et pas sur les protocoles. Celui-ci vise à éduquer les participants aux organismes de normalisation en promettant plus d'efficacité à leurs actions, s'ils suivent quelques règles.

Aujourd'hui, une grande partie de la politique industrielle et parfois de la politique tout court se fait via des organismes de normalisation comme l'IETF, le W3C ou OASIS. Ce qui se passe dans ces organismes devient donc de grande importance et beaucoup de gens tentent d'y participer, souvent avec des résultats mitigés, par exemple car ils ont ignoré la culture particulière de l'organisme où ils sont intervenus.

Ce RFC est donc destiné à tous ceux qui voudraient participer à un organisme de normalisation avec succès. Il donne des conseils de bon sens, assez classiques mais toujours bons à rappeler : par exemple qu'il est normal qu'un organisme apparaisse toujours comme une secte fermée, quand on le regarde de l'extérieur. Ou que la conquête d'une certaine influence prend du temps et des efforts. Ou encore qu'il faut être actif dans le groupe, qu'on ne peut pas espérer devenir quelqu'un qui compte juste par un ou deux messages sur une liste de diffusion.


Téléchargez le RFC 4144


L'article seul

Mise en œuvre de ce blog

Première rédaction de cet article le 2 novembre 2005
Dernière mise à jour le 16 février 2006


Description des techniques informatiques utilisées pour développer ce blog : XML, Relax NG, XSL, etc. Les pages sont statiques (produites essentiellement par XSL) et les fichiers XML édités avec emacs.


L'article complet

RFC 2606: Reserved Top Level DNS Names

Date de publication du RFC : Juin 1999
Auteur(s) du RFC : D. Eastlake, A. Panitz
Première rédaction de cet article le 30 octobre 2005


Ce RFC est très court mais a suscité (et suscite toujours, via d'actuelles tentatives de le modifier) beaucoup de débats. Il est en effet situé à l'intersection des domaines de l'IETF et de l'ICANN puisqu'il normalise certains noms de TLD et certains noms de domaines dans les TLD comme .com.

On a souvent besoin de noms de domaine sans avoir envie de les réserver : le cas le plus fréquent concerne la documentation. Si j'écris un texte expliquant comment configurer le logiciel, mettons, NSD, j'ai besoin de mettre des noms de domaines et il est préférable d'utiliser des noms qui ne sont pas déjà en service. En effet, un certain nombre de lecteurs utiliseront littéralement le nom qui apparait dans la documentation, au lieu de comprendre que ce n'est qu'un exemple. On voit ainsi souvent des francophones utiliser, bien à tort, le domaine toto.fr alors qu'il est bel et bien alloué et que son titulaire n'est peut-être pas ravi de cet usage !

Un autre usage courant concerne les tests de logiciel : si on veut créer un domaine "bidon" sur ses serveurs, il est préférable de ne pas masquer ainsi un domaine réel.

Ce RFC réserve donc quatre TLD, .example pour la documentation, .test pour les tests, ainsi que .invalid et .localhost. Malgré une demande fréquente, il n'existe pas dans ce RFC de TLD pour un usage local (.local était souvent proposé mais n'a acquis un statut officiel qu'avec les RFC 6761 et RFC 6762, bien plus tard). L'IETF est plutôt hostile à tout ce qui est "local", notamment en raison des problèmes que cela pose lorsque deux organisations fusionnent ou bien se connectent (c'est pour la même raison que les adresses IPv6 site-local ont été remplacées, dans le RFC 4193). La méthode recommandée est donc plutôt d'utiliser un sous-domaine pour les données privées par exemple local.example.net.

Le RFC réserve également trois domaines de second niveau, example.com, example.net et example.org. Tous ces domaines ont été bloqués par l'IANA et, pour les domaines de second niveau, un serveur Web a été installé, qui renvoie à ce RFC.


Téléchargez le RFC 2606


L'article seul

Fiche de lecture : Haskell: the craft of functional programming

Auteur(s) du livre : Simon Thompson
Éditeur : Addison-Wesley

Première rédaction de cet article le 27 octobre 2005


Un livre original qui est plutôt orienté vers l'apprentissage de la programmation fonctionnelle que vers celui du langage Haskell.

Il n'est probablement pas indispensable de savoir déjà programmer et ce livre pourrait être utilisé comme support de cours. L'auteur commence par les concepts de base de la programmation fonctionnelle, et, pour une fois, les exemples ne sont pas tous les sempiternels exemples mathématiques à base de factorielle et de Fibonacci mais des exemples graphiques avec des images que l'on transforme (pour faciliter la mise en œuvre, une intéressante implémentation entièrement en art ASCII est présentée par la suite).

Il explique ensuite l'environnement Hugs, utilisé pour la pratique, puis expose les différents concepts utilisés : listes, fonctions comme objets de première classe (pouvant être passées en argument), application partielle et curryfication, introduction à la preuve de programmes, le système des classes, la programmation paresseuse...

Comme le livre vise à enseigner la programmation fonctionnelle, plus que le langage Haskell, d'importants pans de celui-ci ne sont pas traités du tout : les monades sont très vite expédiées, les enregistrements nommés pas mentionnés, l'inférence de types est complètement absente (et l'auteur déclare donc systématiquement ses types). Les questions pratiques comme le contenu du Prélude, les bibliothèques existantes ou les entrées/sorties sont très peu traitées. Le lecteur ne doit donc pas s'imaginer qu'il pourra programmer en Haskell immédiatement, ni lire le code de darcs immédiatement.


L'article seul

RFC 4151: The 'tag' URI Scheme

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : Tim Kindberg (Hewlett-Packard), Sandro Hawke (W3C)
Pour information
Première rédaction de cet article le 26 octobre 2005
Dernière mise à jour le 13 mars 2006


Les URI comme http://www.bortzmeyer.org/4151.html ou ISBN:0-395-36341-1 (RFC 8254) sont devenus la référence en matière d'identificateurs de ressources sur le réseau. Quelques alternatives comme les DOI n'ont jamais eu aucun succès (la lettre d'information de l'International DOI foundation ne contient que des URL et aucun DOI). Les URI commencent toujours par un schéma, un plan comme http ou mailto et ce RFC crée un nouveau schéma : tag.

Ce nouvau schéma sert uniquement à construire des identificateurs uniques, stables et compréhensibles. Il n'est pas prévu de mécanisme de résolution en adresses.

Le RFC décrit les autres éléments du cahier des charges et les raisons pour lesquelles les autres mécanismes ne sont pas satisfaisants. Notamment, un identificateur doit pouvoir être créé sans recourir à une autorité centrale.

Ainsi, un identificateur tag: est typiquement construit à partir d'un nom de domaine ou d'une adresse de courrier (mais n'importe quelle source d'unicité - tagging entity - comme un numéro de téléphone pourrait être utilisée), suivie d'une date de création. Par exemple, cela peut donner tag:bortzmeyer@internatif.org,2005-10-26:/Blog/RFC4151.

Comme exemple d'utilisation, le RFC 4151 sur le format de syndication ATOM recommande que chaque entrée du flux de syndication aie un identificateur unique, le <atom:id> et conseille When an Atom Document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change. Put another way, an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements. It is suggested that the atom:id element be stored along with the associated resource. The content of an atom:id element MUST be created in a way that assures uniqueness.

Et il est conseillé d'utiliser le schéma tag: pour cela, ce que fait le flux de syndication de ce blog.

Pour plus d'informations, une page Web de l'auteur du RFC fait le point sur le schéma tag:.


Téléchargez le RFC 4151


L'article seul

CPL (Courants porteurs en ligne) à la maison

Première rédaction de cet article le 23 octobre 2005
Dernière mise à jour le 23 octobre 2010


La technique CPL (Courants porteurs en ligne) permet de créer facilement un réseau local sans passer de câbles. Comment fonctionne t-elle ? Simplement par modulation du courant électrique qui circule sur sa porteuse de 50 Hz. L'adaptateur CPL se branche sur une prise électrique normal, d'un côté et sur un port Ethernet ou USB de l'ordinateur de l'autre côté (je n'ai utilisé qu'Ethernet).

Je ne parlerai ici que des CPL utilisés en local, dans une maison ou en appartementcpl-bewan-powerline.jpg , bien qu'il semble possible d'utiliser également le CPL pour des réseaux métropolitains (CPL outdoor, dit-on dans la langue de Faraday).

Avec la première norme CPL Homeplug 1.0, le débit théorique était de 14 Mb/s, plus proche de 5 en pratique (d'ailleurs, l'adaptateur Ethernet ne parlait que l'Ethernet 10 Mb/s, ce qui pouvait poser un problème avec des commutateurs neufs de très bas de gamme qui ne font que de l'Ethernet 100 Mb/s). Les normes suivantes, dites « Turbo », promettent du 85 Mb/s théoriques et la norme actuelle, « AV », du 200 Mb/s.

Le signal est apparemment arrêté par le compteur électrique de l'appartement, ce qui est un avantage : le voisin ne peut pas sniffer votre réseau ou bien utiliser votre connexion Internet. Dans un bureau, j'ai constaté que le signal ne passait pas entre deux couloirs : il y avait deux réseaux électriques distincts, joints par un appareil qui filtrait apparemment les fréquences du CPL.

Quels sont les avantages et les inconvénients par rapport au Wifi, bien plus connu ?

  • Le CPL est bien plus sûr : pas d'espionnage du réseau et pas d'ouverture de sa connexion Internet à tout le voisinage,
  • Pour les deux techniques, la capacité du réseau est partagée mais, avec le CPL, elle est partagée entre moins de monde (en général uniquement l'appartement) alors que le Wifi devient de plus en plus limité avec son vaste déploiement,
  • Les risques des ondes radio pour la santé ne sont encore qu'imparfaitement connus (notez que le CPL n'en est pas forcément exempt),
  • Mais la carte Wifi coûte typiquement moins cher, car elle est produit en plus grande série (et parfois incorporée dans l'ordinateur). Même en comptant le prix de la base, le Wifi est donc souvent moins cher (cela dépend évidemment du nombre de postes).

Aujourd'hui, un adaptateur CPL Ethernet coûte environ 30 €. (À l'été 2009, j'ai vu pour la première fois des adaptateurs CPL dans un vide-grenier, au Mesnil-sous-Jumièges, à 5 € pièce.)

J'utilise des adaptateurs Lea Netplug, achetés à la boutique Free. Avant, j'ai eu des Bewan Powerline et des CMM Celetron. Ils ont marché du premier coup (sauf un CMM défaillant qui, après une longue période de pannes aléatoires, a fini par s'arrêter complètement et a dû être renvoyé, à mes frais, pour échange). Ces appareils fonctionnent sans problèmes ensemble (y compris ceux de la première génération avec les matériels modernes).

Par contre, les adaptateurs CPL, en permanence sous tension, chauffent et leur durée de vie n'est pas illimitée. Au bout de quelques années, ils commencent à produire des pannes aléatoires (qui disparaissent si on débranche l'adaptateur puis le rebranche) ou bien à générer des parasites qui font qu'on perd les gros paquets (ping passe mais pas ping -s 1400). Il faut donc alors les remplacer. J'ai ainsi perdu une série de trois adaptateurs Lea en quelques mois :-( (Je viens d'acheter des nouveaux Bewan.)

(Une autre cause courante de problèmes avec les adaptateurs CPL semble être les nourrices, les multi-prises. Personnellement, cela ne m'est jamais arrivé cpl-cmm-celektron-profile.jpg mais il peut être plus prudent de tester en branchant directement sur la prise murale. Les « biplites », dédoubleurs de prise murale, peuvent sembler une solution intéressante mais tous les adaptateurs CPL que j'ai testés étaient trop gros : une fois franchés sur la biplite, ils bloquent les deux prises.)

Comme l'adaptateur est vu comme une prise Ethernet par l'ordinateur, cela fonctionne indépendamment du système d'exploitation, ce qui est bien agréable dans un monde où beaucoup de fournisseurs considèrent que l'usage de MS-Windows est obligatoire. Ici, au contraire, mes machines Debian et NetBSD n'ont pas eu de problèmes.

La seule limite est que le logiciel de gestion, lui, ne tourne que sur MS-Windows (ou parfois sur certaines versions de RedHat avec certaines bibliothèques). Ce logiciel permet de configurer des mots de passe (je n'ai donc pas utilisé cette fonction) ou bien de regarder la qualité du signal reçu par l'adaptateur. (Une solution possible serait peut-être l'outil plconfig mais je n'ai pas encore essayé de définir des mots de passe avec cet outil. Même chose avec l'autre outil, plc.) Dernière possibilité (pas encore testée), le récent logiciel Faifa (à noter qu'il dispose d'un paquetage Debian, mais pas encore dans la version stable).

On notera que le FAI Free propose désormais des adaptateurs CPL pour connecter ses Freebox au boîtier qui contrôle la télévision. Ces adaptateurs, nommés Freeplug, ne communiquent pas forcément avec d'autres équipements (apparemment, ils utilisent toutefois Homeplug AV). cpl-freeplug.jpg

Il existe un livre en français couvrant tout le monde des CPL, « CPL par la pratique », de Xavier Carcelle.


L'article seul

RFC 4192: Procedures for Renumbering an IPv6 Network without a Flag Day

Date de publication du RFC : Septembre 2005
Auteur(s) du RFC : F. Baker (Cisco), E. Lear (Cisco), R. Droms (Cisco)
Pour information
Première rédaction de cet article le 22 octobre 2005


Rénuméroter son réseau, par exemple, parce qu'on change de fournisseur d'accès, n'a jamais été drôle. C'est même souvent pénible, l'adresse IP du réseau se trouvant en général dans de nombreux endroits sur les machines. Sur Unix, un outil comme grep est une aide considérable pour retrouver ces endroits. Si on a la chance d'avoir des adresses PI (Provider Independant), on ne connaitra pas ls joies de la renumérotation. Sinon, il faudra lire ce RFC.

IPv6 rend théoriquement les choses plus faciles. Notamment parce qu'il permet, depuis le début, d'attribuer plusieurs adresses IP à la même interface (c'est en général possible également en IPv4 mais c'est moins bien géré, car cela été ajouté après).

Le RFC dresse une liste de tout ce qui peut avoir besoin de changer lors de cette opération. La liste est suffisamment longue pour qu'il n'y aie aucun espoir de tout réussir en une seule journée, le flag day.

Puis il décrit la procédure à suivre soigneusement, en n'oubliant rien et en étant conscient, comme le rappelle Clausewitz, cité par le RFC, que de toute façon quelque chose ira mal...

Une grande partie de cette procédure peut d'ailleurs également convenir pour IPv4. Souhaitons que ce RFC soit donc largement utilisé pour limiter les cafouillages qui se présentent souvent lors d'une telle opération.


Téléchargez le RFC 4192


L'article seul

RFC 4185: National and Local Characters for DNS Top Level Domain (TLD) Names

Date de publication du RFC : Octobre 2005
Auteur(s) du RFC : John Klensin
Pour information
Première rédaction de cet article le 21 octobre 2005


Depuis que les noms de domaine en Unicode sont disponibles (IDN, décrits en RFC 3490), la question se pose d'enregistrer des domaines de premier niveau (TLD, Top Level Domain comme .org ou .ci) en Unicode. Le problème n'est pas technique (un TLD est un domaine comme un autre et peut être enregistré grâce aux IDN) mais politique.

L'ajout de nouveaux TLD est en effet contrôlé par le gouvernement des États-Unis, via une organiation écran, l'ICANN. Celle-ci s'oppose régulièrement au déploiement des IDN donc il y a peu de chance que des TLD en Unicode soient acceptés.

Le RFC propose donc une autre solution : traiter la représentation des TLD en Unicode uniquement comme une question de présentation à l'utilisateur. .org resterait ainsi en US-ASCII mais le logiciel pourrait afficher et accepter en entrée une traduction chinoise, en caractères chinois.

Il n'y aurait donc pas de changement du nombre de TLD.

L'idée semble raisonnable mais on peut regretter que, pour la défendre, l'auteur du RFC ignore d'autres solutions. Par exemple, la section 1.3.2 du RFC discute de certains mécanismes qui pourraient être utilisés pour s'assurer que le TLD en US-ASCII et le TLD en Unicode aient le même contenu. Il conclut que ces mécanismes ne sont pas suffisants (et donc qu'il vaut mieux avoir un seul TLD par pays) mais il oublie d'autrs possibilités techniques comme un simple lien symbolique entre les deux fichiers de zone (solution qui marche très bien avec les logiciels BIND et NSD).


Téléchargez le RFC 4185


L'article seul

"The hideous name" de Pike et Weinberger

Première rédaction de cet article le 19 octobre 2005


Il est toujours bon de relire les textes historiques de sa discipline. On croit souvent, bien à tort, que c'est inutile en informatique, en raison de la rapidité des changements. Mais c'est oublier que l'informatique est beaucoup moins dynamique qu'elle ne le croit. Si la vitesse des processeurs et la quantité d'effets visuels que produit le moindre programme augmente chaque année, le nombre de concepts fondamentaux pour l'informaticien est beaucoup plus stable.

Parmi ces concepts, le nommage des ressources fait l'objet en 1985 d'un article important de Rob Pike and Peter J. Weinberger, The hideous name, qui est disponible en ligne.

Les auteurs couvrent notamment deux domaines où le nommage est essentiel et visible à tous : les noms de fichiers et les adresses de courrier électronique (rappelons qu'en 1985, pendant que les experts officiels en France ne connaissaient même pas encore le modèle OSI, le courrier électronique était déjà un outil de travail banal).

Pour les noms de fichier, Pike et Weinberger font l'éloge de la syntaxe Unix, /home/pike/papers/naming.ps où rien dans la syntaxe n'indique le matériel et notamment l'éventuel changement de disque dur. Les auteurs étendent cette syntaxe au nommage des ressources en réseau, prônant un modèle du genre /network/gandalf/home/weinberger dont on sait qu'il ne s'est finalement pas imposé. En revanche, ils critiquent la façon dont le protocole IBIS utilise un séparateur différent après le nom de machine (le :). C'est pourtant cette syntaxe qui est utilisée aujourd'hui, par exemple par SSH.

VMS fournit le contre-exemple parfait à Pike et Weinberger, puisque le séparateur est différent selon qu'il sépare des répertoires ou bien des répertoires et un fichier, par exemple [DISK1.CS.PIKE]PAPER.PS. Les auteurs reconnaissent toutefois que le langage de programmation C a le même défaut.

Pour le courrier électronique, cet article, écrit à une époque où le DNS était ultra-expérimental, n'a pas trop mal vieilli. Les auteurs font bien la différence entre nommage et résolution (la syntaxe des noms "domaine" - appelée "syntaxe ARPANET" à l'époque - était déjà répandue, même sans son mécanisme de résolution actuel, le DNS). Par contre, curieusement, ils ne semblent pas avoir prévu que cette syntaxe remplacerait toutes les autres. Difficile de prévoir, surtout le futur.


L'article seul

RFC 4177: Architectural Approaches to Multi-homing for IPv6

Date de publication du RFC : Septembre 2005
Auteur(s) du RFC : G. Huston (APNIC)
Pour information
Première rédaction de cet article le 13 octobre 2005


Le multihoming, ou capacité pour un site Internet d'être relié à plusieurs fournisseurs d'accès Internet (FAI), est à la fois une très forte demande de la part des utilisateurs et un problème très complexe, qui n'a pas encore de solution satisfaisante. Le protocole IPv6 apporte quelques outils supplémentaires mais ne résoud pas magiquement le problème.

Si tous les FAI étaient parfaitement fiables, et merveilleusement connectés, il n'y aura guère besoin de multihoming. Mais, en pratique, tout site qui veut une bonne fiabilité et une bonne connexion avec tout le monde a souvent intérêt à avoir plusieurs fournisseurs. La technique "normale" pour cela est d'avoir des adresses IP indépendantes (PI pour Provider Independant) et de faire du BGP avec tous ses fournisseurs. C'est techniquement assez complexe et c'est surtout très coûteux, sans compter la difficulté d'obtenir des adresses PI auprès des RIR (IPv6 ne change rien à ce sujet).

En attendant, le client de base reste donc très dépendant de son FAI.

Le groupe de travail Multi6 de l'IETF travaille sur la question et ce RFC explique son analyse des différentes architectures envisageables (le RFC 3582 détaillait le cahier des charges du multihoming IPv6). On est encore loin d'une solution.

Le RFC identifie cinq architectures possibles. Pour les comprendre, il faut d'abord lire la section 2 du RFC, qui rappelle que l'adresse IP est actuellement utilisée pour deux choses bien différentes, comme identificateur d'une machine et comme index dans les tables de routage (certaines solutions de multihoming vont séparer les deux fonctions) :

  • Adresses PI et routage BGP, comme vu plus haut. Le problème est de passage à l'échelle : que deviendront les routeurs BGP si un million de sites publient leur route ? Le problème n'est pas celui du nombre d'adresses IP (qu'IPv6 résoud) mais celui du nombre de routes.
  • Utilisation des techniques de mobilité : être connecté à un deuxième FAI n'est pas différent d'être en voyage et connecté par un FAI distinct de son FAI habituel.
  • Les trois dernières architectures prévoient toutes une séparation des deux fonctions de l'adresse IP. Les sessions (par exemple TCP) seraient maintenus entre deux machines identifiées, non pas par une adresse IP, mais par un identifiant de plus haut niveau.

Le RFC décrit ensuite en détail les différentes façons de réaliser cette séparation et ces conséquences (il s'agit de remettre en cause un principe central des applications Internet).


Téléchargez le RFC 4177


L'article seul

RFC 2782: A DNS RR for specifying the location of services (DNS SRV)

Date de publication du RFC : Février 2000
Auteur(s) du RFC : A. Gulbrandsen (Troll), P. Vixie (ISC), L. Esibov (Microsoft)
Chemin des normes
Première rédaction de cet article le 8 octobre 2005


Ce RFC spécifie un nouveau type d'enregistrement DNS, le SRV pour "service". Traditionnellement, les enregistrements contenus dans le DNS permettaient seulement de spécifier l'adresse IP correspondant à un nom comme www.bortzmeyer.org. Si on voulait avoir plusieurs machines mettant en œuvre un service, il fallait mettre plusieurs adresses dans le RRset, dans l'ensemble des enregistrements. Et, si on voulait en plus que certaines de ces adresses ne soient utilisés qu'en secours, si les premières ne répondent pas, ou si on voulait que certains adresses soient utilisés d'avantage que d'autres, parce qu'elles correspondent à des machines plus rapides, eh bien il n'y avait pas de solution. Plus exactement, il n'y en avait que pour le courrier, qui avait un type spécial, MX, ayant à peu près ces capacités. Mais les autres services, comme le Web, ne pouvaient pas en bénéficier.

Ce RFC introduit donc un nouvel enregistrement, SRV, qui est depuis longtemps disponible dans les serveurs de noms. Un enregistrement SRV permet d'obtenir, pour un service, non pas une adresse IP mais le nom d'un serveur physique, avec une priorité, qui permet de rendre obligatoire le passage par certaines machines d'abord, et un poids, qui permet de donner une plus grande probabilité d'usage pour certaines machines. La priorité est déterministe et absolue (si une machine de meilleure priorité est disponible, elle doit être utilisée), le poids est probabiliste (il vaut mieux essayer les serveurs de meilleur poids). L'enregistrement donne également le port à utiliser.

Le service se spécifie en le préfixant d'un trait souligné (_), caractère illégal dans les noms de machine, ce qui supprime le risque de collision. Par exemple, certains clients LDAP cherchent le serveur LDAP de leur domaine, non pas en essayant une convention comme ldap.MONDOMAINE.org mais en demandant le SRV de _ldap._tcp.MONDOMAINE.org. Une telle convention a également été proposée pour whois, afin de découvrir le serveur whois faisant autorité pour un domaine donné.

Un RRset, un ensemble d'enregistrements SRV pour le service Web de example.org pourrait donc être :

_http._tcp     SRV 0 1 80 old-slow-box.example.org.
               SRV 0 3 80 new-fast-box.example.org.
               SRV 1 0 80 personal-box.adsl.my-isp.net.

ici avec deux serveurs de même priorité (zéro), un rapide ayant un poids de 3 et un lent ayant un poids de 1, puis un serveur de secours (priorité 1). Tous écoutent sur le port 80.

Pour les développeurs, il existe déjà une bibliothèque qui met en œuvre le RFC 2782 : Ruli (pour Resolver User Layer Interface) qui simplifie considérablement la tâche du développeur. Si un si faible nombre d'applications utilise les enregistrements SRV, ce n'est donc pas faute de support logiciel.

Car, malheureusement, on constate que très peu d'applications acceptent d'utiliser les SRV. Je ne connais par exemple aucun navigateur Web qui le fasse, même pas Firefox, pour lequel la discussion a commencé il y a des années (idem pour Chrome). Pour des raisons qui m'échappent, une très belle idée, qui résoudrait de nombreux problèmes de gestion d'un parc de serveurs, reste ainsi, six ans après sa normalisation, quasiment inconnue.

À part XMPP, l'utilisation la plus courante aujourd'hui doit être dans le DNS Service Discovery du RFC 6763.


Téléchargez le RFC 2782


L'article seul

Le gouvernement français va proposer un filtrage systématique des contenus sur Internet

Première rédaction de cet article le 22 septembre 2005


Le 16 septembre, l'association IRIS révélait que le gouvernement avait l'intention de proposer une loi imposant aux FAI de filtrer automatiquement, par défaut, tous les accès à Internet, sous prétexte de protéger les enfants contre les contenus illégaux.

La semaine du 19, une grande campagne de presse a commencé, par exemple dans le Parisien, Métro et le Monde, sur le thème classique des dangers de l'Internet pour les enfants et sur la nécessité pour le gouvernement de faire quelque chose.

Le 22, le premier ministre, Dominique de Villepin, annonce qu'il va "renforcer l'obligation qui pèse sur les fournisseurs d'accès afin que ces logiciels [de filtrage] soient disponibles automatiquement" et que "À défaut de solution concertée dans les semaines à venir, la législation sera modifiée pour assurer une protection adéquate des mineurs.".

La LCEN date d'à peine plus d'un an qu'on envisage déjà de la modifier, ce qui ne contribue pas à améliorer la crédibilité du gouvernement qui l'avait fait voter. Il est évidemment plus simple, lors d'une conférence de la famille, d'annoncer une agitation législative (qui ne coûte rien) plutôt que, par exemple, d'annoncer un budget important pour construire des crèches.

La mesure proposée est évidemment liberticide, irréaliste (je ne m'étends pas là dessus ici mais le fait que les détails pratiques soient renvoyés à un futur et hypothétique décret montre bien que le gouvernement est conscient qu'il n'y a pas de solution technique à ce problème) et fait la part belle à la vision puritaine des logiciels de filtrage, tous d'origine états-unienne.

À deux mois de la plenière du SMSI à Tunis, la France rejoint le camp de tous les pays, en général peu sympathiques, qui vont réclamer un contrôle des contenus de l'Internet.

Mais c'est aussi une mesure qui reflète une vision terriblement traditionnaliste de l'Internet : manifestement, les auteurs de cette proposition de loi n'ont pas digéré la fin de la période Minitel et voudraient un Internet bâti sur une stricte séparation des consommateurs, qu'on protège comme des enfants, et qui n'accèdent à l'Internet que via des professionnels, les FAI, qui sont chargés de surveiller les enfants en question. Un fournisseur d'accès comme AOL (cité en exemple par les organisations conservatrices qui soutiennent cette proposition de loi) a toujours défendu et pratiqué cette vision.

La réalité de l'Internet a toujours été autre : il existe beaucoup de façons de se connecter, il y a beaucoup de services disponibles, pas seulement le Web, il y a beaucoup de logiciels et de techniques possibles. Filtrer sérieusement, comme le font les gouvernements chinois et tunisiens, nécessite de casser l'architecture qui a fait le succès de l'Internet, de canaliser les connexions, et finalement de faire de l'Internet un réseau de télécommunications traditionnel, bien plus rassurant pour les gouvernements que pour les enfants.

Est-ce la voie que certains envisagent d'emprunter en France ? Personne ne l'admettra mais des indices comme cette proposition de loi permettent de le supposer.


L'article seul

RFC 1984: IAB and IESG Statement on Cryptographic Technology and the Internet

Date de publication du RFC : Août 1996
Auteur(s) du RFC : IAB & IESG
Pour information
Première rédaction de cet article le 22 septembre 2005


Un RFC très politique, que ce 1984 qui s'attaque aux restrictions d'usage à la cryptographie. Au moment où il est sorti, la cryptographie était de fait interdite en France (et la situation, si elle s'est améliorée, est encore loin d'être parfaite). Et les États-Unis restreignaient très sévèrement l'exportation de logiciels cryptographiques (là encore, ces restrictions n'ont pas complètement disparu).

Le RFC prend nettement position : l'IAB et l'IESG, ensemble, affirment que la cryptographie forte (pas les systèmes ultra-bridés qui étaient proposés à l'époque avec les navigateurs Web) est indispensable à la sécurité de l'Internet, qu'il n'existe aucune autre méthode réaliste d'assurer une sécurité raisonnable sur un réseau ayant l'architecture de l'Internet et que cette sécurité ne doit pas être sacrifiée aux intérêts des polices et des services secrets.

Le RFC se penche aussi sur des cas plus techniques, comme sur les clés cryptographiques ne servant qu'à la signature, qui ne devraient jamais faire l'objet d'un dépôt de séquestre, puisqu'il n'existe aucune raison légitime de les "saisir".

Ce RFC dont le numéro ne doit rien au hasard, a marqué une étape dans la construction politique de l'Internet.


Téléchargez le RFC 1984


L'article seul

Fiche de lecture : CSS 2 - Pratique du design Web

Auteur(s) du livre : Raphaël Goetter
Éditeur : Eyrolles

Première rédaction de cet article le 6 septembre 2005


Au jour d'aujourd'hui, ce livre représente un état de l'art du Web débarassé des scories de la "guerre des browsers", déclenchée par Netscape et qui avait abouti à un grande balkanisation du Web.

Un des effets de cette guerre avait été la prolifération d'éléments HTML non-standards, produisant des effets visuels supposés attirer les clients vers un navigateur particulier, comme le célèbre <BLINK>.

En même temps que cette guerre, et s'appuyant sur cette course aux effets visuels, le webmestre moyen, en général peu cultivé en informatique documentaire, avait pris l'habitude de ne plus séparer contenu et présentation (ce qui était pourtant un principe cardinal du Web) et de tout mélanger, structure et effets visuels. La version 3.2 de HTML était allé particulièrement loin en ce sens.

Aujourd'hui, on en est revenu, on comprend mieux l'intérêt de séparer le fond (utile par exemple aux moteurs de recherche) de la forme. Et les normes ont évolué, la version 2 de CSS ajoutant à CSS ce qui lui manquait : la possibilité de positionner des éléments sur la page. Même les sites très pro-CSS devaient utiliser des tables HTML dès qu'il fallait positionner, par exemple un menu à droite. Avec CSS 2, on peut enfin écrire une page HTML sans une seule indication de présentation, celle-ci étant concentrée dans la feuille de style CSS.

Il ne reste donc plus qu'à apprendre CSS 2. Si CSS 1 était assez simple, la version 2 oblige les webmestres à apprendre un peu d'informatique graphique et un livre n'est donc pas inutile. Celui-ci répond bien aux problèmes, il est très concret, ne couvre pas uniquement la norme mais aussi sa mise en œuvre dans les navigateurs, par exemple avec ses énormes bogues et limitations dans Microsoft Internet Explorer (CSS 2 est loin d'être correctement mis en œuvre partout).

Démarrant doucement, avec un exposé de CSS accessible aux débutants, le livre continue par un festival de trucs et de bricolages qui devraient satisfaire même les bons connaisseurs de CSS.

Le ton assez pontifiant du livre est souvent assez énervant, ainsi que la préciosité du langage mais les concepteurs de pages Web sont comme les informaticiens, ils manquent souvent de distance avec leur sujet.


L'article seul

Le sans-fil, une chance pour l'Afrique ?

Première rédaction de cet article le 28 août 2005


Dans les discussions, les colloques ou les sommets sur le développement des Nouvelles Technologies de l'Information et de la Communication (NTIC) en Afrique, on présente souvent les techniques sans-fil comme la solution aux problèmes de connectivité de l'Afrique.

Cela inclut les réseaux locaux (avec la technique Wi-Fi), les réseaux métropolitains (avec des liaisons radio plus classiques) et les réseaux à grande distance, via les satellites (technique VSAT, par exemple, qui a toujours bénéficié d'un lobbying assez lourd).

Pour comprendre les avantages et les limites du sans-fil, il faut revenir sur la situation des télécoms en Afrique. Elle a été largement étudiée et d'innombrables études ont été produites à ce sujet par diverses ONG ou organismes onusiens. Citons par exemple l'excellent livre collectif sous la direction d'Annie Chéneau, "Enjeux des technologies de la communication en Afrique".

En deux mots, la fracture numérique avec le Nord est énorme : l'infrastructure téléphonique filaire est très limitée, de mauvaise qualité et mal entretenue. Obtenir une ligne est un exploit et cela coûte très cher.

Dans la plupart des pays, ce réseau filaire est de trop mauvaise qualité pour permettre le déploiement de services d'accès à l'Internet comme ADSL.

Face à cette situation, il est tentant de vouloir prendre un raccourci et de décréter que le filaire n'était qu'une étape dont l'Afrique pourrait se passer, en sautant directement au sans-fil. Ce choix apparaît purement technique et ne suscite pas en général de débats passionnés.

Mais c'est oublier que les choix d'infrastructures sont en général à très long terme et stratégiques, c'est-à-dire qu'ils exercent une influence qui va au-delà de la technique.

L'infrastructure filaire est en effet tributaire d'une société humaine qui marche : il faut du personnel, des travaux de génie civil, donc des cartes, des corps de métier différents qui coopèrent, une bonne dose d'organisation (pour éviter que d'autres travaux ne détruisent accidentellement le réseau), une certaine stabilité (les réseaux filaires sont vulnérables, par exemple aux voleurs de cuivre, métal relativement cher).

C'est cette société humaine qui est défaillante dans la plupart des pays d'Afrique : toutes les infrastructures au sol (eau, électricité, téléphone) y marchent mal en raison de cette défaillance, pas en raison des particularités techniques du téléphone filaire.

Envisage-t-on de résoudre ce problème ? Non. On envisage seulement de renoncer à avoir une infrastructure stable au sol et on passe par la voie des airs.

Cela a deux conséquences : on renonce à faire marcher des réseaux au sol, alors que l'eau et l'électricité, elles, n'ont pas de solution de rechange.

Et, même en se limitant aux télécommunications, on renonce à fournir un accès de masse au téléphone.

En effet, le sans-fil, avec ses infrastructures au sol limitées, convient bien aux situations d'urgence, aux événéments temporaires, ou bien aux habitats très dispersés. Mais, si on veut connecter la grande majorité de la population, il revient bien plus cher (puisque le coût de chaque abonné ne baisse pas avec le nombre d'abonnés) et il entraine une rude concurrence pour l'accès à la bande passante, qui est partagée entre tous.

Choisir systématiquement le sans-fil, c'est renoncer à l'accès pour tous au profit d'un accès pour un petit nombre, entreprises, ONG, riches particuliers.

En outre, lorsque le sans-fil passe par des satellites, c'est une menace directe pour l'indépendance du pays : les communications internes vont alors passer par un satellite contrôlé par un pays étranger, qui peut augmenter ses tarifs ou tout simplement couper l'accès en cas de désaccord.

Si on vise réellement l'accès de tous aux NTIC, il n'y a donc pas d'alternative au développement d'une infrastructure filaire au sol. Cette infrastructure au sol s'intègre naturellement dans les autres réseaux (eau et électricité notamment), soit parce qu'elle utilise les mêmes tranchées, soit simplement parce qu'elle repose sur la même infrastructure humaine (services techniques des collectivités locales, cartes du sous-sol, etc).


L'article seul

"Software carpentry" : un excellent cours de programmation

Première rédaction de cet article le 8 juillet 2005


Ce document, "Software Carpentry" est encore un brouillon à l'heure qu'il est mais il est très prometteur. Il s'agit d'un cours de programmation destiné aux scientifiques (non-informaticiens) et aux ingénieurs (non-informaticiens également).

75 % du contenu convient aussi à des gens qui sont déjà informaticiens. Peu de programmeurs utilisent en effet tous les outils présentés. "Introduction: Meeting Standards" et "Introduction: A Quick Self-Test" peuvent vous permettre de voir si vous avez besoin du cours :-) Le test est inspiré d'un article de Joel Spolsky, le célèbre auteur des excellentes chroniques "Joel on software", dont je vous recommande la lecture.

Ce cours enseigne la programmation, certes mais aussi les outils et l'environnement. Par exemple, le chapitre "Version Control" est très bien, pour une technique indispensable et peu connue.

Même chose pour "Testing Concepts" : la plupart des cours d'informatique en fac ne parlent que d'algorithmique et de structures de données et jamais de tests, de gestion de versions, de build, etc. On peut ainsi se retrouver avec une équipe de programmeurs qui ont tous un diplôme universitaire en programmation et dont aucun n'est capable d'écrire une suite de tests, ou même d'y penser.

J'ai aussi bien aimé le fait que les auteurs pratiquent ce qu'ils prêchent et utilisent Trac pour gérer leur cours :-)


L'article seul

RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses

Date de publication du RFC : Mai 2005
Auteur(s) du RFC : S. Cheshire, Apple, B. Aboba, Microsoft, E. Guttman, Sun
Chemin des normes
Première rédaction de cet article le 8 juillet 2005


Ce RFC normalise une pratique ancienne, l'attribution automatique d'adresses IP à des machines sur des réseaux "non-gérés". Il existe plein d'ordinateurs qui ne sont pas administrés par un professionnel et qui ont besoin d'adresses IP pour communiquer. C'est le problème connu à l'IETF sous le nom de "problème du bureau du dentiste" : le dentiste est riche, il a plusieurs ordinateurs, mais il n'est pas informaticien, il ne va pas configurer un serveur DHCP (RFC 2131) pour attribuer une adresse à ses ordinateurs.

IPv6 résoud ce problème avec l'autoconfiguration sans état, RFC 4862, un mécanisme peer-to-peer, qui ne demande pas de serveur central (DHCP étant l'autoconfiguration avec état, il dépend d'un serveur central).

Depuis des années, une solution pour IPv4 existe dans Microsoft Windows mais n'était pas encore normalisée : c'est désormais chose faite avec ce RFC.

Selon notre RFC, lorsque une machine se retrouve connectée à un réseau, elle peut utiliser un algorithme normalisé pour obtenir une adresse dans la plage 169.254.0.0/16, qui avait été réservée dans le RFC 3330.

L'algorithme est simple dans son principe, même si le RFC a besoin de beaucoup de pages pour expliquer les détails : chaque machine choisit au hasard une adresse dans la plage et elle n'a ensuite qu'à tester pour voir si une autre machine ne l'utilise pas déjà.

Cette norme correspond à l'expansion des réseaux non-gérés, ceux du bureau du dentiste, bien sûr, mais aussi à tous ces réseaux d'appareils qui ne sont pas des ordinateurs mais ont déjà ou auront bientôt une adresse IP (lecteurs RFID, imprimantes, badgeuses, etc).

On note que ce RFC ne résoud pas le problème des noms de ces machines, qui, à l'IETF, a été traité par le groupe de travail DNS extensions via Linklocal Multicast Name Resolution (LLMNR) (RFC 4795).


Téléchargez le RFC 3927


L'article seul

Que voterait Darth Vader dimanche ?

Première rédaction de cet article le 26 mai 2005


Ce qui m'a le plus gêné dans Star Wars, épisode III, la revanche des Siths, n'est pas que le scénariste mette en garde contre le risque de dictature. Comme on le voit dans le film, il est fréquent que les "sauveurs" restent à leur poste après la guerre et s'y installent définitivement.

Mais, justement, la comparaison qu'a fait Lucas avec la situation aux Etats-Unis est trompeuse. Il n'y a pas de risque de dictature militaire aux Etats-Unis. Dobeliou ne ve pas se faire proclamer empereur. Cette technique (utiliser une crise pour arriver au pouvoir et devenir dictateur) marchait bien pendant l'empire romain mais une autre solution est possible : rester démocratique à l'intérieur et piétiner ses principes à l'extérieur.

C'est que ce fait Israël depuis des années, ce qu'ont fait la France et la Grande-Bretagne pendant leurs guerres coloniales (la France a bien eu un coup d'Etat mais très modéré par rapport à celui de Palpatine), et ce que font les Etats-Unis aujourd'hui.

C'est cela, le danger, aujourd'hui, et le camarade Lucas, en pointant un danger bien plus lointain, détourne des vrais problèmes.

Bref, les états-uniens de droite qui réclament le boycott de Star Wars se trompent. Ce film ne vise pas la bonne cible et ne menace donc pas grand'monde.


L'article seul

Fiche de lecture : Pragmatic Version Control using Subversion

Auteur(s) du livre : Mike Mason
Éditeur : The pragmatic bookshelf

Première rédaction de cet article le 26 mai 2005


[Avertissement : c'est le premier livre de la série "Pragmatic" que je lis. Cette série tente apparemment de faire l'intermédiaire entre O'Reilly et "XXX pour les nuls".]

Un bon livre pour deux sortes de public, ceux qui ne connaissent pas les systèmes de contrôle de versions (ou qui connaissent uniquement des systèmes très archaïques comme RCS ou ClearCase) et ceux qui font du CVS depuis dix ans et passent à Subversion.

Mise en page très agréable, bons dessins, la présentation vaut les O'Reilly.

Les explications sont correctes et détaillés. Une fois qu'on a accepté que tous les exemples soient avec des sources Java, tout se passe bien :-)

Le titre de pragmatic est assez mérité, il y a peu de discussions (par exemple les systèmes de contrôle de versions décentralisés sont à peine mentionnés), pour pouvoir passer aux tâches concrètes tout de suite.

Alors que j'utilisai déjà beaucoup Subversion, j'ai encore appris des commandes dans ce livre ("svn praise" qui affiche un fichier avec le nom du committeur de la ligne en face de chaque ligne) et des options ("svn status -u" qui vérifie le statut avec le serveur, pas uniquement en local).

Regret principal : dans une série qui se veut concrète, l'auteur n'a pas pensé à séparer clairement l'utilisation de Subversion de son administration (notamment dans les chapitres 7 et 8 sur l'organisation du dépôt). Or, il y a beaucoup plus d'utilisateurs que d'administrateurs et un livre où les chapitres Administration seraient regroupés en un endroit clairement marqué serait sans doute préférable pour les utilisateurs ordinaires.


L'article seul

RFC 4084: Terminology for Describing Internet Connectivity

Date de publication du RFC : Mai 2005
Auteur(s) du RFC : J. Klensin
Première rédaction de cet article le 17 mai 2005


Autrefois, tout était simple, il n'y avait qu'un seul type d'accès Internet : l'accès complet. Aujourd'hui, les offres sont bien plus éclatées : il y a la traduction d'adresse (NAT), le filtrage (plusieurs FAI bloquent le port 25 - celui du courrier - en sortie, pour gêner les vers Windows qui tentent d'émettre du spam), les passages obligatoires par des relais plus ou moins transparents.

Très peu de fournisseurs documentent ces restrictions.

Rien de plus agaçant que d'avoir payé l'hôtel pour avoir "une connexion Internet" avant de découvrir qu'elle ne donne pas accès au port 22 et qu'on ne peut donc pas faire du SSH vers ses serveurs lorsqu'on est en déplacement.

Une des raisons au manque de documentation est l'absence d'un vocabulaire commun pour décrire ces offres. Le marché ne peut fonctionner qu'en présence d'information et il n'y a pas d'information sans la standardisation des termes.

C'est ce à quoi s'attaque le RFC 4084. Tâche difficile car, selon les mots de l'auteur, "il faut éviter d'utiliser un vocabulaire péjoratif". Il est en effet essentiel que ce vocabulaire soit utilisé par les fournisseurs d'accès. L'IETF n'a aucune autorité pour forcer l'usage de ces termes et ils doivent donc plaire à tous, clients et fournisseurs. D'autre part, il faut parler en termes de services pour l'utilisateur et évidemment pas en termes techniques, pour être compréhensible par le client.

Le RFC distingue donc notamment : "Connectivité Web", qui ne donne accès qu'à ce service, ce qui est le cas de beaucoup de points chauds WiFi, "Client seulement" (qui interdit la plupart des services "peer to peer" comme la téléphonie Skype ou comme BitTorrent), "Connectivité Internet filtrée" et "Connectivité Internet complète".

Peut-être verra t-on un jour une loi sur la protection des consommateurs obliger à décrire une offre de connexion Internet avec les termes du RFC 4084 :-)


Téléchargez le RFC 4084


L'article seul

RFC 3987: Internationalized Resource Identifiers (IRIs)

Date de publication du RFC : Janvier 2005
Auteur(s) du RFC : M. Duerst (W3C), M. Suignard (Microsoft)
Chemin des normes
Première rédaction de cet article le 10 février 2005


On se souvient que Microsoft avait annoncé officiellement que la compagnie n'entendait pas gérer les noms de domaine internationaux (IDN) dans son navigateur Internet Explorer tant qu'il n'était pas possible d'internationaliser tout l'URL.

En effet, si IDN (RFC 3490) permet d'écrire http://www.académie-française.fr/seances, il ne permet pas de gérer http://www.académie-française.fr/séances. Les IRI, que normalisent le RFC 3987, permettent cela et, si Microsoft tient parole, devraient permettre au dernier navigateur Web sans support IDN de rejoindre ses concurrents.

Les IRI fonctionnent en complément des IDN. Dans l'IRI http://www.académie-française.fr/séances, le nom de machine est géré par IDN et apparaitra donc comme www.xn--acadmie-franaise-npb1a.fr lors des échanges entre logiciels. En revanche, la partie droite de l'IRI, /séances, restera parfois en Unicode. Elle n'est interprétée que par le serveur final et n'a pas forcément à subir les règles très restrictives qui affectent les noms de machines.

La nécessité de traduire l'IRI (en Unicode) en URI (en US-ASCII) dépendra du schéma de l'IRI (le schéma est indiqué par le premier terme, avant le deux-points). Certains schémas existants comme "http" n'acceptent pas forcément l'Unicode et il faudra alors que le logiciel traduise l'IRI en URI, selon un mécanisme analogue à celui des IDN, en utilisant le traditionnel encodage en %. Les schémas les plus récents et les futurs schémas pourront éviter cette étape.

Naturellement, il faudra mettre à jour navigateurs et serveurs, mais les navigateurs gèrent déjà tous Unicode pour l'affichage et cela ne devrait pas être trop difficile pour eux.

Malgré les inquiétudes habituelles de ceux qui verraient bien l'Internet rester exclusivement en anglais, les IRI marquent donc une nouvelle étape vers une internationalisation réelle.

Un bon article sur le sujet est An Introduction to Multilingual Web Addresses.


Téléchargez le RFC 3987


L'article seul

RFC 3981: The Internet Registry Information Service (IRIS)

Date de publication du RFC : Janvier 2005
Auteur(s) du RFC : A. Newton (Verisign), M. Sanz (DENIC)
Chemin des normes
Première rédaction de cet article le 7 janvier 2005


Le RFC, 3981, décrit le protocole IRIS, Internet Registry Information Service, qui va tenter de remplacer le protocole whois.

Les limites du protocole whois d'accès à l'information sociale du registre sont connues depuis longtemps (et citées dans le cahier des charges du groupe de travail CRISP, le RFC 3707). Citons notamment :

  • aucun mécanisme d'authentification (donc pas possible de donner des réponses différentes selon le client),
  • pas de structuration des données (donc nécessité d'analyser une sortie texte en essayant plus ou moins de deviner, tâche pour laquelle Gandi avait développé un script Perl de 6000 lignes),
  • pas de mécanisme standard de redirection, permettant par exemple de faire des requêtes hiérarchiques (cas des registres minces, ou bien cas d'allocation en cascade comme avec les adresses IP ou encore cas d'un prestataire ayant sa propre base, avec d'avantage de détails, comme le fait EuroDNS).

IRIS va tenter de résoudre ces limites. Il est bâti sur le langage XML, et le mécanisme des W3C Schema. Le RFC 3982 décrit le premier schéma, "dreg", conçu pour les registres de noms de domaine, un autre schéma, "areg", pour les RIR, étant en préparation. Notons donc qu'un registre de nom de domaines pourrait utiliser le protocole IRIS (RFC 3981) avec un autre schéma que dreg (RFC 3982), par exemple si son modèle de données est très différent du consensus de Marina de Rey.

Le RFC 3981 n'est pas évident à lire et le lecteur pressé peut se contenter du RFC 3707, puis de l'appendice B du RFC 3981, "IRIS Design Philosophy". Le RFC 3982 est tout aussi trappu mais c'est une tentative de formaliser le modèle de données d'un registre de noms de domaines et c'est donc un document important.

IRIS, par ses nouvelles possibilités, pose plein de questions politiques ou sociales. Par exemple, par son mécanisme d'authentification, il permet des réponses différenciées, peut-être verra t-on des registres faire payer pour avoir accès à plus de renseignements. D'autre part, en faisant sauter une limite technique aux redirections, IRIS encouragera peut-être le déploiement de serveurs IRIS privés, en plus de ceux des TLD ou des RIR.

La question du déploiement effectif d'IRIS est ouverte. Il faut rappeler que IRIS n'est pas le premier protocole à tenter d'éjecter whois : rwhois, whois++ et LDAP avaient déjà essayé. whois, simple et bien connu, a toujours résisté. Verisign a déjà créé deux mises en œuvre libres d'IRIS, je n'en connais pas encore d'autres : le choix des W3C Schema rend de toute façon très complexe la mise en œuvre d'IRIS. Le RIPE-NCC dispose d'un serveur IRIS pilote.

(Depuis, IRIS n'a eu aucun succès et, en mars 2015, un autre candidat à la succession de whois est apparu, RDAP.)


Téléchargez le RFC 3981


L'article seul

Articles des différentes années : 2017  2016  2015  2014  2013  2012  2011  Précédentes années

Syndication : en HTTP non sécurisé, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu, en HTTPS, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.